Could you actually explain what you disagree with? In my opinion, everything in the comment you're replying to is obviously correct.
If you're going somewhere where there is a chance you might get lost, injured or trapped by weather, and need rescue, you should already be bringing something like a Garmin inReach. That's a highly ruggedized device with a battery that lasts for over a week without recharge, is small enough to keep in a pocket, provides two-way messaging and weather reports, can track your position at regular intervals so your family can see where you are, and can, without any setup and even when you're seriously injured, be used to directly send out an SOS with automatic reporting of your position and two-way voice communication.
As excellent as Starlink is, it is nowhere near a substitute for those capabilities. And the inReach has existed for longer than Starlink, ergo Starlink doesn't change the risk profile. The only real argument that Starlink changes the risk profile is if you're comparing Starlink vs nothing, or Starlink + PLB vs just PLB. And sure, in those cases Starlink is a significant improvement, but it's still inferior to something like an inReach.
The second part of the argument is that having better connectivity is no substitute for fundamentals, which is overwhelmingly, obviously correct. Yes, bring all the connectivity you want, the more the better if you're willing to carry it. But your plan shouldn't be built around the assumption that you can be rescued if things go wrong. If you get complacent due to having better connectivity it's entirely possible for it to worsen, rather than improve, your risk profile.
You've got that completely backwards. Correctly applying Bayes' theorem, if an anomaly is observed you incorporate the prior into the calculation of the posterior probability. You don't just give up and say "the prior is miniscule so the likelihood is useless".
And then, even that's not enough. Decision theory needs to be applied to decide what action to take. That means taking into account the expected QALYs, cost and inconvenience across the distribution of possible outcomes. There's a whole spectrum of possible decisions, from immediately performing surgery, performing an invasive test like a biopsy, performing other less invasive tests, scheduling a follow-up non-invasive test at a later date, or just following a regular schedule of non-invasive tests and looking for any evolution along a longer time period.
The real problem is the binary thinking of either "we think you have X" and therefore tests must be performed or "we think you don't have X" and therefore tests shouldn't be performed. If medical organizations adopted empirically grounded decision frameworks, by applying them consistently doctors would be able to see something anomalous, assess that the risk isn't high enough to warrant immediate investigation, and be protected from a lawsuit in the unlikely case it was, in fact, something. And then we could do away with this "if we look we might find something" nonsense, which is pure fallacy.
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.
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.
There's nothing wrong with refining models, but it's a bit besides the point. At a 1995 Planetary Defense workshop Edward Teller proposed the development of a 1Gt device for that purpose. Fusion bombs are actually quite straightforward to scale by adding more stages, so it wouldn't be terribly more difficult to produce a 10Gt device instead. What the model tells you is how large a device you need, but all that's needed is a conservative model that tells you the minimum size you need, and then you can add a generous margin of safety on top of that. The goal is to stop the asteroid hitting Earth, there's nothing wrong with deflecting it "too much".
But right now we have exactly zero such devices prepared. Existing nuclear devices are about 3 orders of magnitude too small, and none of them are set up for a launch into an intercept. That's where the focus should be -- getting something, anything, of roughly the right order of magnitude that would provide a credible response to a detected inbound asteroid.
Time would be much less of a problem if Terrestrial Time was used internally everywhere. That is: if TT (realized as TAI) were used as the fundamental definition of time, rather than UTC; and UTC were treated as just another timezone.
Then, there would be only three problems, which decompose nicely:
1. Trying to keep the system time accurate, and accounting for the possibility it isn't.
2. Having up-to-date time zone information
3. Converting TT to/from a date/time in some particular format in a particular timezone.
(1) is fundamentally unavoidable. (3) is complicated but well-defined. (2) should be handled by the system. All that's left is calculations on time values, which if they're in TT (i.e. actual time) are very well behaved.
Ultimately this is the fault of the standards bodies. POSIX defines time in terms of UTC. NTP tries to keep the system clock synced with UTC. Postgres "timestamp with timezone" stores UTC. Zone files state offsets in terms of UTC, and even worse, transition times are stated with reference to a timezone (see tzfile(5) and RFC 8536), which is completely insane.
This could change. Existing standards can't but new standards could be introduced to succeed the old ones and exist side-by-side. Maybe, instead of proposing changing UTC because they find leap seconds inconvenient, an organization like Facebook could actually do something useful and push for them.
I'm not trying to detract from the monumental achievement SpaceX's engineers have made with the development of the Raptor, but that development work didn't take place in a vacuum. Unfortunately, I don't have a credible source for this, but I have seen multiple reports that the Raptor program was explicitly a continuation of the IPD program, with SpaceX receiving technical data, hardware, and even hiring engineers who worked on it.
That the IPD was hydrolox and didn't proceed to the point of a full engine, let alone a flight is besides the point.
What you said was: "They kind of did invent full-flow engines though", which is completely false.
The short answer to your question is that larger engines have very few advantages and many disadvantages.
Specific impulse is the most obvious parameter of a rocket engine, but it's relatively less important for a first stage where thrust/weight is also a very important concern. Specific impulse depends on the chemistry, combustion cycle, combustion efficiency and nozzle design. There isn't any obvious reason why it would scale either way with engine size.
Thrust/weight is very important for engines on a first stage because of gravity losses. Imagine if the rocket sitting on the pad had a thrust/weight of just 1.1; that would mean that at liftoff 91% of the thrust would be wasted just countering gravity. You both want a high thrust/weight at liftoff and a small dry mass to give the second stage the most momentum possible at stage separation. High thrust also helps for reuse in making the burn time of the first stage shorter (for fixed specific impulse and propellant load), which means that at stage separation the first stage isn't too far downrange and is easier to return to the launch site.
Note that there's both the thrust/weight of the rocket as a whole, and of the engines themselves. The engines comprise a significant proportion of the first stage's weight, though, so looking at engine weight (and thrust to weight) is also useful. Consider the RS-25, Merlin 1D, and Raptor. Their specific impulses are 366s, 282s, and 330s (at sea level), so the RS-25 looks pretty good. But their thrust/weight ratios are roughly 60, 185, and 200 (target). The Merlin 1D was, I believe, the highest thrust-weight ratio liquid-fueled engine ever. This is one of the primary reasons, in addition to cost, it is considered so good, despite having such anemic specific impulse.
You can optimize thrust/weight several ways. Firstly, you can try to cram more thrust out of an engine of a fixed size. This is done by driving up chamber pressures as high as you can, which might be easier with a smaller engine due to square-cube scaling. Secondly, you can make the engine smaller, without changing its thrust, and try to cram as many of them in as possible. Consider thrust/area as another important metric -- for fixed rocket dimensions, being able to cram more engines into the base is an easy way to get more thrust and improve the total thrust/weight of the stack.
Another consideration, which has all too often been ignored in the rocketry business, is cost. More specifically $/thrust, if we're looking at a first stage. Here, smaller engines have a clear advantage in that your tooling doesn't need to be as large and expensive, and you're going to need more of them so you can start to leverage economies of scale rather than having each engine being an individual, artisan-produced artifact. That obviously has a limit -- there's a point at which more engines would make things more expensive, but judging from the thrust and cost of the Raptor, I would guess it's right around the optimal point.
Finally, it's worth noting that, all other considerations aside, going bigger in rocket engines tends to make the engineering more difficult. The square-cube law makes heat flux in the combustion chamber scale roughly linearly with engine size, which makes cooling more difficult. And the larger the combustion chamber, the more at risk it is of combustion instabilities. Look, for example, at the Russian RD-170 engine. It looks like four engines but is actually one engine with four combustion chambers. They did that because while it looks more complex, it actually makes things easier.
If you're going somewhere where there is a chance you might get lost, injured or trapped by weather, and need rescue, you should already be bringing something like a Garmin inReach. That's a highly ruggedized device with a battery that lasts for over a week without recharge, is small enough to keep in a pocket, provides two-way messaging and weather reports, can track your position at regular intervals so your family can see where you are, and can, without any setup and even when you're seriously injured, be used to directly send out an SOS with automatic reporting of your position and two-way voice communication.
As excellent as Starlink is, it is nowhere near a substitute for those capabilities. And the inReach has existed for longer than Starlink, ergo Starlink doesn't change the risk profile. The only real argument that Starlink changes the risk profile is if you're comparing Starlink vs nothing, or Starlink + PLB vs just PLB. And sure, in those cases Starlink is a significant improvement, but it's still inferior to something like an inReach.
The second part of the argument is that having better connectivity is no substitute for fundamentals, which is overwhelmingly, obviously correct. Yes, bring all the connectivity you want, the more the better if you're willing to carry it. But your plan shouldn't be built around the assumption that you can be rescued if things go wrong. If you get complacent due to having better connectivity it's entirely possible for it to worsen, rather than improve, your risk profile.