"We reserve the right to retain your security feet pics indefinitely, but won't use them for advertising purposes. We may use them for other business purposes, subject to change at any time without notification."
--new TOS
Then, a few months later x.ai announces a new SOTA frontier model, FeetGrok.
The prospect of going to a website I've never visited before, getting a captcha, and it saying "we don't think those are YOUR feet, access denied" is a little TOO believable.
25 years is the standard time horizon for automatic declassification, and someone high up probably decided to collect things together to publicize in an attempt to score some political kudos.
Speakers can act as part of a useful microphone circuit but you're missing all the amplifiers and ADCs and other stuff to use it as one in any sane speaker driver circuit. They'd have to intentionally add all that, which maybe they would, but it'd be easier to just stick a tiny $0.05 all in one microphone chip on there.
Unfortunately smart phone cameras kinda suck performance wise. Radiation detectors fundamentally need some mass to actually absorb and detect radiation, so while cameras are basically similar to semiconductor radiation detectors the performance is so bad as to be useless. I haven't really ever seen the camera detectors be used for anything useful.
Radiacode detectors are about the only affordable detector with actually useful performance out there, and they are around $300. Which is also drastically cheaper than anything else out there, the next cheapest actually useful detector out there that I know of is 10x that price.
They are more prevalent than you think, especially in places like ports and airports. But part of the problem is they are typically expensive for anything more sophisticated than a basic Geiger counter, like most commercial offerings start at $5k and can very quickly go into the hundreds of thousands or millions of dollars per unit. And they require a lot of training to use effectively.
At least in the US there is also a pretty substantial network of teams and equipment for providing radiological technical support in an emergency. Examples of this are DoE RAP and the USNG CST. Now part of the motivation for this work was that a lot of the techniques for actually doing a search are fairly primitive, but there is a major support network with most of the tools and skills ready to go 24/7. It tends to all be very low key and fly under the radar, mostly because even a hint of one of these teams being deployed tends to cause a panic.
In fact, the house down the street to my parents' was torn down and rebuilt in the 80s because it had contaminated rebar.
When I was a kid, a neighbor, who is a civil engineer had a Geiger counter and went through the neighborhood and said he found nothing abnormal.
However, there is a cluster of cancer cases of people in the neighborhood of all kinds (breast, testicular, melanoma, liver, and kidney, of which my mother died of), including two friends who still lived there, and were diagnosed in their early 30s. Could be just bad luck, but I still wonder. My father still lives there.
I guess I should at least skim your dissertation, but is there a device that could be employed to sweep the neighborhood?
The cheapest worthwhile detectors out there are the Radiacode ones. They are excellent for what they are, but they run around $300. Cheaper Geiger counters are unfortunately kinda useless, at least for this. It's also not particularly easy to know what you're looking at and how to interpret it even with a good detector, unfortunately I'm not sure how much luck you'd have so don't waste $300.
When doing heavy ion testing for space flight hardware, there's a potential for the hardware to be a little hot after a full day of testing. Not really dangerous but hot enough that you need to let it sit for a day. At one facility I went to, the physicists there said in the past a group didn't let their hardware cool off and it alerted radiation detectors in the Lincoln Tunnel, NYC.
Ha, that's me. Thanks for posting this. It's late where I am but I can answer questions. I took a brief break on this topic after I graduated and worked on other stuff, but the company I'm at now has done a lot of subsequent work on this, including making it practical in the field. Though as I mentioned in the prior thread, bridging the valley of death and selling it as a product is still a challenge.
There's been a lot of development since this dissertation to let it run in real time, and to integrate with tactical radiation detectors that the military/police/civil defense teams tend to use. Unfortunately that's mostly unpublished work at present.
Australia had some fun with a lost mining source - rather than run a geophysics plane 80m above ground from mine to city they held off to test a gadget with some whirly stuff about a crystal pack ... as I understand it.
Not us, but probably an imaging radiation detector with LIDAR. Its another technology for search, with its own tradeoffs and advantages. We are friends with a couple companies that make that tech, but it's a different thread of R&D. Arguably a bit more mature; doing localization like we do with "normal" detectors on the ground is pretty challenging. We've done pretty realistic joint exercises with the military with our tech (called QkRad) but nobody has actually fielded it in a real emergency yet. We are around TRL 7 if you know that terminology.
These sort of loss events happen much more often than is reported widely. Not like something that happens every day, but there are a non negligible number of events every year. The Nuclear Threat Initiative catalogs publicly known events if you want to browse.
> probably an imaging radiation detector with LIDAR.
Sorry - had to laugh at "LIDAR" - the source bounced off a truck in W.Australian Pilbara and the Eastern States specialists rolled along the road in a van picking up the lost source by direction.
The environment would be best described as flat. Very flat. Road, flat ground. No buildings, no reflections or refraction, not a lot for a LIDAR to do.
I'm still impressed with the direction to source capabilities over what we started with many years ago; crystals stacked with lead plate separating top crystal from lower crystals .. to get a sense of what was cosmic and what was not.
It was probably an imaging radiation detector regardless, the spinny bit would likely be some sort of camera to add context to the radiation image.
Imaging detectors can get a lot fancier than just two planes. One design is basically segmented crystals and you look at the timing between the separate segments light up as a gamma ray passes through each quadrant. You can then work backwards from those sub nanosecond time difference to get the direction, and stack up a bunch of events to make a sort of picture (more like a blobby heat map).
For neutrons there is an even crazier imaging technique called a coded aperture that I won't even try to describe here. Suffice to say it's very clever and unintuitive.
Ha - my mental model was to spin a partial shield about a crystal and watch the incoming counts and timings - dipping when shield passes between source and crystal, increasing on the gap transit.
With a few tweaks.
> the separate segments light up as a gamma ray passes through each quadrant.
Err, one single ray (we doing wave fronts or particles in our slit experiment here) surely only impacts and flashes once in one segment .. or passes through with no impact?
Spinning shield is a thought people have had but it doesn't work very well in practice (for gamma imaging). Usually you want to avoid anything that blocks gammas as much as possible because you need every one you can get. I wanted to try spinning one of the scintillator logs we used, which is more or less the same idea, but it isn't practical either for a bunch of reasons.
Gammas tend to act more like particles in the detector. They don't stop all at once, they tend interact multiple times and deposit their energy in multiple places along a line via a ton of different physical interactions. My description was simplifying and conflating things a bit, you can look up optically segmented detectors, as well as Compton scatter cameras if you want a better answer. There are other imaging approaches, too.
> Usually you want to avoid anything that blocks gammas as much as possible because you need every one you can get.
Agreed- my first order assumption run with that one was that any shielding would be light weight.
> they tend interact multiple times and deposit their energy in multiple places along a line via a ton of different physical interactions.
Huh. Okay, although all of the form gamma energy packet interacts with doped crystal and scintillates I'd assume. I can see that you've got a bit more going on here in the detection instrumentation.
Fast enough to catch everything or throwing in calibrations for deadtime?
Hmm, anyhow, seems like much fun was had in the lab working on the dissertation,
good job :-)
My time was almost always pressed to get more fieldwork done and never quite got the amount of playing about time I wanted :/
Yeah I think I explained it badly. They sorta stream through the detector until they interact, and then potentially undergo multiple compton scatters or photoelectric absorption (or other weird stuff) that produce secondary particles that actually excite a region around the discrete interactions and those excited atoms are what produces the observable signal. Then (at least for a scintillator) the atoms that got excited relax and release a flash of light with a characteristic decay time that is the main limit on how precisely you can resolve individual gammas. Semiconductors are kinda similar but dislodging electron-hole pairs; the higher mobility of these pairs is why the resolution is so much tighter. Imaging detectors have more electronics attached, e.g. two photomultipliers at each end or pixellated photomultipliers, and timing analysis of these pulses is how you get position. Things like a full energy deposition peaks happen when the gamma ray dies in the detector, but it doesn't necessarily dump its energy all in one spot. Since you have to wait for all the excited atoms to decay or the total charge from electron-hole pairs to be collected you have to integrate the total amount of light/charge over some window to get the total energy deposited. Sometimes they escape out the other side and take some of their remaining energy with them, which causes some distinct features in the spectrum too.
The timing and electronics for doing position sensing of the gamma path through the detector (i.e., what you need to reconstruct an image) are... complex. Dead time and false correlates (e.g. another gamma in the detector at the same time, aka false coincidences) are a thing and they are factors that contribute to uncertainties. There's a bunch of statistical analysis you have to do to try and correct for these effects and pull the signal out of the noise. In a Compton camera, you can correlate the first scatter's trajectory back into a cone of possible incident directions, which you then stack up to form a picture. Hence why I said the image you get out is very blobby and more like a heat map than an image. But you pay a price in efficiency, as you can only count some fraction of the actual interactions in the detector now. I'm a bit rusty on the really nuts and bolts details, I don't work with this type of detector anymore. We mostly try to avoid using this type of detector for our localization, because they are crazy expensive and complex.
Cheers for that, we're a lot more on the same page now - I got a little time with fancy detectors but principally spent years with straight up crystal packs and scintillation energy bucket counting, calibrations against doped concrete pads, stacked atmosphere flights, open water and known ground truth flights, geometry configurations, temperature control, and a banquet of derived corrections for radiometric mapping - we also ran passive magnetics, LIDAR, gravity, microwave et al in parallel.
Notable sites included most of the hotter mine sites about the globe, Finnish / Russian sea borders, and the odd live underground test here and there (Pokhran-II exchange) .. but enough about that.
Good luck. I'd wager that most methods to protect your privacy aren't nearly as effective as we think they are. While I don't think it means that you shouldn't try to protect your information, I typically assume that anything short of very extreme measures is only mildly effective.
One of the biggest problems in software development is that our graph of authoritative personal data is cyclical. You might have heard about how difficult it was for someone erroneously declared dead to change the record, and I'm sure most of us have experienced problems with changing an address. A friend recently went through two name changes and one phone number change, and it took like eight months for the bottom-feeders to realign.
We are now in an adversarial situation regarding our personal information, but our adversaries depend on sources we have a modicum of control over. If I signed my dog up for a physical mailer, I wonder how long would it take for a portion of the internet to consider Doctor-Professor Kensington a legal individual.
I've tried signing up for bank accounts with deliberate typoes in my name. It worked. Name didn't match the ID they had me scan. The Revolut sign-up form randomly ignores keypresses so that's my plausible deniability. I just intentionally didn't correct them.
im constanty being asked to fill out captchas (which i close) and am accused of being a bot by many of the sites i visit, so i guess im doing something right?
Companies like Red Hat/IBM operate in Illinois and for better or worse have controlling interests in Linux and across open source projects pretty broadly. Wouldn't they be forced to include the capability in their products, which then percolate out to everyone just by network effects?
I don't see how they enforce it though? Isn't this saying every linux instance needs basically a backdoor network access? How would verify the 30 pods on my node are from minors or adults without that? Or this is more about a user facing node? So my aws nodes need to verify my age before I ssh in?
There's no verification necessary. Instead, you'd just set a flag on all of those pods that says "this is an adult". Or more likely, you wouldn't set anything, there would be no changes at all, because that would be the default.
However, if I gave my child a laptop with Linux installed, the law would force the OS to provide some setting somewhere that I can toggle that switches the installation to child mode. (On Linux, I imagine it would make sense to have this be a per-user toggle, so my kid's account would be in child mode, and the root account would not.) The applications on that computer would then be required to check that setting if they want to show "adult content" (here defined as algorithmic feeds, notifications between certain hours, the ability to receive messages from identified adults). Similarly (this isn't clear but would presumably be technically required) browsers would pass this setting on to websites in some way.
Another way of seeing it is this: you know the DNT/Do Not Track header that you can optionally set in your browser and (theoretically at least) websites will not track you? This is essentially that but for certain kinds of content. If you set the header, websites won't be allowed to show algorithmic feeds, etc.
Basically all of this is in the article, which lays it out very clearly (if you ignore the Claude-isms).
systemd is a massive blob of code that infects every part of a system and all of its subsystems. It completely changed the way system administration was done, the way init scripts work, and added tons of things to init that some argue aren't necessary, like dhcp and DNS.
Newer linux folks like it because they're used to it, people who don't like it use devuan, gentoo, or one of the others that still lets one use openRC or whatever else.
upthread someone mentioned that systemd already has the ability to store the birthdate of a user. Why would an init system need that? It doesn't, but here we are.
Maybe I'm about to be too pedantic, but I never quite got the argument of systemd being massively bloated based on examples of it including DNS and DHCP. Sure it's a mono-repository that includes all these services, but in the end you do run them separately? The actual "systemd, the init system" doesn't have DNS, DHCP or a user birthday database built-in, those are contained in their own services, namely systemd-resolved, systemd-networkd, and systemd-userdbd respectively, and, although systemd does genuinely lead you down the path of using them (which might be a real problem!), there isn't actually a definite requirement to do so. systemd will gladly run your BIND, ISC DHCP and NetworkManager for you if you tell it to, no? In fact we do so at my place of work. Just because they are under the same project as the init system doesn't mean they are one monolith, I think. To me that feels like saying "Why does the GNU C library include a bootloader!".
Now it's not like there's not plenty to dislike about systemd, it is a wide-reaching project that has managed to get a huge mindshare of the lower-level services needed to run a basic Linux server or desktop, and that has caused many utilities and services to appear that have a hard dependency on it, which is obviously bad for anyone running services that aren't part of the systemd package set, just take a look at NixOS, it's practically built purely on systemd, with efforts to support alternative init systems essentially archived at this point. Plenty of people also quite dislike Lennart, or how involved corporations are in the systemd development, and other people have loads of other reasons. One of my own gripes is speed for quite a few basic procedures in networkd. There's enough stuff to hate about it! I think it's not really necessary to pretend that your init system runs a DNS server and stores birthdays.
> Newer linux folks like it because they're used to it, people who don't like it use devuan, gentoo, or one of the others that still lets one use openRC or whatever else.
This is a bad generalization. Counterpoint, I've been using Linux as a daily driver for like 25 years now (and have also used other Unixes/likes fairly extensively). I have my gripes with systemd, but I personally prefer to use it over OpenRC etc. I don't think I'm alone, either, as distros like Devuan are pretty far down on usage lists. There are plenty of Greybeards out there who dislike systemd enough to use something else, but I suspect there are at least as many out there who like it or don't care enough to use an alternative.
This incident inspired my PhD dissertation on radiation source search. The techniques to search for sources like this are remarkably primitive, even today. My company works on this tech, but it's hard to get traction because the US government basically stopped investing in CBRN technology around when the Cold War ended, and hardly any other countries take it seriously as a threat.
Not that search techniques would have helped stop this incident, they basically didn't even know it was lost until the capsule was already broken and people were dying.
Wow you got you some markov chains, Monte Carlo, Gamma Radiation, what a fun dissertation. I especially liked the bit about how the NaI detector is not a sphere and sensitivity depends on incident angle. I would never have thought of that. You even did a trip to ORNL, how cool is that!
Walking around with a Giger counter while wearing a hazmat suit seems like fun too, but I suppose it would freak people out. This seems like a much more stealthily way to locate a lost source.
Actually, someone walking around with a detector and us localizing in real time is what the current state is. There's been a lot of development since this dissertation to let it run in real time, and to integrate with tactical radiation detectors that the military/police/civil defense teams tend to use. Unfortunately that's mostly unpublished work at present.
And they got that position of dominance more via shady deals and sketchy practices than by producing excellent software. Microsoft has done some good engineering, but that's not what made them what they are.
--new TOS
Then, a few months later x.ai announces a new SOTA frontier model, FeetGrok.
reply