You can look at the Wikipedia page on railway defect dectectors [0].
Under "rail break monitors" it mentions both electrical continuity and time-domain reflectometry can be used, and are most frequently used on high-speed tracks.
In addition, there are vast array of other detectors using acoustic sensors, strain gauges, accelerometers, cameras in the visible and infrared spectrum or laser measurement, that potentially could have detected an anomaly (i.e. damage to the wheels of other trains before the incident).
That's not what "hot" means in this context. "Hot" means "highly radioactive", i.e. high number of decay events per second, high concentration of short half-life isotopes, high power/volume resulting from radioactive decay.
Nuclear reactors do not work off radioactive decay. U-235, for example has a half life of 704 million years. Radioisotope thermal electric generators [0] by contrast do run off radioactive decay, an isotopes used for that application have short half-lives, such as Pu-238 with 87.7 years.
Commercial nuclear reactors use unenriched or minimally enriched fuel. This means that, within a fairly short period of time, the percentage of fissile material in the fuel drops to the point where continuing to use it is no longer economical. At that point the fuel is a mixture of extremely hot fission products, transuranics, unreacted fuel, and non-fissile (but fertile) isotopes such as U-238.
It's not practical to use the decay energy from the fission products for power. What would make much more sense would be to remove the fission products and recycle the fuel that remains into new fuel (for a reactor that's designed to use it). This would be a much more efficient use of mined nuclear fuel (allowing nuclear power to be used for thousands of years), it would vastly reduce the volume of nuclear waste, and it would mean nuclear waste would only be hazardous for decades to centuries.
The US was on the path to this with the Integral Fast Reactor and Pyroprocessing [1] developed by the Argonne National Laboratory. This was killed [2] in 1994 by the Clinton administration. Not for any technical reason, but because it was a "threat to nuclear non-proliferation". How that makes sense when, to the best of my knowledge the process developed by Argonne couldn't be used to produce weapons-grade material, and even if it could the US already had nuclear weapons so it wouldn't be proliferating it to a non-nuclear country, I don't know. But, apparently, since some other forms of nuclear waste reprocessing can be used to generate weapons-grade material (by extracting Pu-239), it was a bad symbol so it had to go.
Your question is rather ambiguous. Do you mean using chemistry to develop new techniques or combine unusual ingredients to create food that has novel flavors or textures? That would fall under Molecular Gastronomy, which has been highly influential within fine dining in the last few decades.
Do you mean processing ingredients with the goal to take cheap ingredients and make a product as hyper-palatable as possible? That would generally be called "ultra-processed food"; you're not going to find a Doritos chip in nature.
Do you mean developing completely completely new flavors via chemical synthesis? I don't think there's much possibility there. Our senses have evolved to detect compounds found in nature, so it's unlikely a synthetic compound can produce a flavor completely unlike anything found in nature.
Also, I think you're overestimating jelly. Gelatine is just a breakdown product of collagen. Boil animal connective tissue, purify the gelatine, add sugar and flavoring and set it into a gel. It's really only a few of techniques removed from nature. If you want to say it's not found in nature, then fair enough, but neither is a medium-rare steak.
I mean using chemistry to create food using atypical ingredients that aren't normally classified as food or entirely synthetic. Take more simpler or more abundant compounds to create original food instead of using plants and wildlife. Flavors don't need to be new, but as others mentioned there are plenty of recently invented flavors. Doritos is ultra-processed corn, what i'm saying is Doritos but there is no corn involved. The original article is about meat-like food, I was saying "why meat-like" , if it is food that has similar taste like meat, that's fine, but it doesn't need to be like meat, it just needs to taste good and have palatable texture. Maybe we can have something tastes better than meat!
Have you seen the presentation from GDC 2017 on the architecture of Overwatch [0]? If you watch the video in detail -- stepping through frame-by-frame at some points -- it provides a nearly complete schematic of the game's architecture. That's probably why the video has since been made unlisted.
I'm not aware of anything quite like that, but most submarines have something like a Rescue Buoy [0], Submarine Emergency Position-Indicating Radio Beacon (SEPIRB) or Submarine Emergency Communications Transmitter (SECT). I think those might differ based on whether they're attached by a cable and allow communicating to the submarine, or just broadcast a distress signal with the position. In any case, they're designed to be automatically deployed in the event of an emergency or catastrophic event, and based on this Quora answer [1] they're attached by an independent mechanism with a timer which has to be regularly reset to stop it deploying. I think it might be a clockwork mechanism, with an electronic alarm when it's about to go off to remind the crew to wind it.
It's a bit of a long read, but I think the best introduction is still this [0] and the comments were here [1]. Yes, it's presented in the context of rust and gamedev, but ECS isn't actually specific to a particular programming language or problem domain.
> I'm not sure about language design or system architecture but this is almost universally not true for any mathematical or algorithmic pursuit.
I don't agree. While starting with the simplest case and expanding out is a valid problem-solving technique, it is also often the case in mathematics that we approach a problem by solving a more general problem and getting our solution as a special case. It's a bit paradoxical, but a problem that be completely intractable if attacked directly can be trivial if approached with a sufficiently powerful abstraction. And our problem-solving abilities grow with our toolbox of ever more powerful and general abstractions.
Also, it's a general principle in engineering that the initial design decisions, the underlying assumptions underlying everything, is in itself the least expensive part of the process but have an outsized influence on the entire rest of the project. The civil engineer who halfway through the construction of his bridge discovers there is a flaw in his design is having a very bad day (and likely year). With software things are more flexible, so we can build our solution incrementally from a simpler case and swap bits out as our understanding of the problem changes; but even there, if we discover there is something wrong with our fundamental architectural decisions, with how we model the problem domain, we can't fix it just by rewriting some modules. That's something that can only be fixed by a complete rewrite, possibly even in a different language.
So while I don't agree with your absolute statement in general, I think it is especially wrong given the context of language design and system architecture. Those are precisely the kind of areas where it's really important that you consider all the possible things you might want to do, and make sure you're not making some false assumption that will massively screw you over at some later date.
> ... it is also often the case in mathematics that we approach a problem by solving a more general problem and getting our solution as a special case.
This is a really good point. LLL and "Feynman's" integral trick come to mind. There are many others.
I got it in my head that this doesn't apply to NP-complete problems so should be discounted. When trying to "solve" NP-complete problems, the usual tactic is to restrict the problem domain into something tractable and then try to branch out other regions of applicability.
> Those are precisely the kind of areas where it's really important that you consider all the possible things you might want to do, and make sure you're not making some false assumption that will massively screw you over at some later date.
I will say that abstraction is its own type of optimization and generalization like this shouldn't be done without some understanding of the problem domain. My guess is that we're in agreement about this point and the talk essentially makes this argument explicitly.
I actually think that it does a disservice to not go to Nazi
allegory, because if I don't use Nazi allegory when referring
to Oracle there is some critical understanding that I have
left on the table; there is an element of the story that you
can't possibly understand.
In fact, as I have said before and I emphatically believe, if
you had to explain the Nazis to somebody who had never heard
of WWII but was an Oracle customer, there's a very good chance
that you actually explain the Nazis in Oracle allegory.
So, it's like: "Really, wow, a whole country?"; "Yes, Larry
Ellison has an entire country"; "Oh my god, the humanity! The
License Audits!"; "Yeah, you should talk to Poland about it,
it was bad. Bad, it was a blitzkrieg license audit."
Under "rail break monitors" it mentions both electrical continuity and time-domain reflectometry can be used, and are most frequently used on high-speed tracks.
In addition, there are vast array of other detectors using acoustic sensors, strain gauges, accelerometers, cameras in the visible and infrared spectrum or laser measurement, that potentially could have detected an anomaly (i.e. damage to the wheels of other trains before the incident).
[0]: https://en.wikipedia.org/w/index.php?title=Defect_detector