OTOH, this is an attached processor, so it's in addition to your current setup. Still doesn't sound likely to blow circuit breakers, but possibly equivalent to running two computers.

There are, or at least were, many applications that were useful and on Windows, but not available on Linux or BSD. Switching off of those can be a significant cost. But if you change the underlying system, those probably won't be available anyway.

The core is a LONG way from the surface. Volcanoes aren't. The mantle plumes move slowly.

OTOH, we've known that the magnetic poles were getting ready to switch for decades now. We don't know when or why or how long it will take. This is probably related to that, but we don't have any really good models.

Use BlastEm, a Mega Drive/Genesis emulator by Michael Pavone whose nightly builds recently grew support for 32X, an accessory that bolts two SH-2 CPUs onto the Genesis.

Unfortunately, when they are separated like that each half becomes nearly useless. They need to be merged, though with clear demarcations so you can skip a part that isn't currently relevant.

I think a giant context is not going to be the answer. It's just got too many problems. Better will probably be parsing the context into connected pieces, and at a different level assembling the "lemmas" into "theorums". (Yeah, those aren't quite the right words, but I'm not sure the right words exist, and that's the analogy from math proofs. Code library isn't the right concept as the "lemma" will often be quite specific to the current task.)

But 1st and 2nd grades???
Sorry, but that sounds like a REALLY bad idea. More than half of what those grades should be about is learning to operate well in groups.

Chances that you do this: zero

You mean like XML does?

Your mistake is thinking of "the government" as a unitary entity. Different parts of it want different things.

I'm sure you're familiar with the countdown protocol, all the pre-flight checks, etc. These power up a range of subsystems, motors, etc, so that everything can be verified prior to ignition itself. The complete sequence takes a very long time. Under normal flight conditions, you can't check for absolutely everything (instrumentation is mass, and mass is the enemy) but there's still a lot. However, during an engine test, you can pack a lot more sensors in.

This is where you'd want to be spotting loose connections, pumps that aren't quite even, pressures that aren't as steady as they should be, vibrations that shouldn't be there or do not match expectations, turbulent flows, and so on.

At ignition, it takes between 3-6 seconds to go from stopped to 90% thrust. For humans, that's near-instant. For a computer sensor that's operating a million samples per second, that's 3-6 million readings. A computer performing a billion calculations per second shouldn't have much difficulty in comparing 3 million readings against model predictions and determining if both the values themselves and the rate of change at each point such a sensor exists are all good. Emergency shutdowns during those first 3 seconds are perfectly viable.

Vibrations are the ones that are likely the most interesting, because those are likely to change before something breaks, not sure how fast you can make infrared sensors, but that's also an area where things are likely to alter before point of failure.

Well, the use case is clearly to produce binaries with smaller memory footprint. But *I* didn't even notice that Debian had disabled it.

Lazy, yes. Bright, no. If you can't trust the average person to figure out that bread that's loaded with salt and sugar isn't healthy, then you can't trust the average person to figure out what a healthy balanced meal is.