You are describing environments where it is very common to have hardware redundancy. I mean, sure they may have hardening for each component to reduce the likelihood of losing one of them. But hardware redundancy is a standard tool in safety critical systems.

Which is why in aerospace and safety critical systems, RTOSes are used and not fully fledged OSes.

Also, redundant hardware is quite common (and mandatory by most standards), look up TMR, triple modular redundancy

And yet at some complexity level you have things like ARINC 653 where the usual implementation is to have a classic RTOS running on each of the partitions provided by the "application executive", and today's serverland is hypervisors running VMs running containers. I believe we are too centered on the "Linux vs Minix" debate while in actual practice both tendencies are reflected in most systems.

>RTOSes are used and not fully fledged OSes.

The idea that "RTOS" and "fully fledged OS" are incompatible with each other is outdated.

seL4 advanced the state of the art with its formally-verified support for mixed criticality, years ago already.

There’s actually a real-time microkernel that millions of children use daily. It’s called the Nintendo Switch.

(But seriously, it’s a homegrown microkernel RTOS.)

The idea might be outdated, but as I have yet to seen a system running seL4, in practice it is very much true still.

On a plane or missile I'd assume several computers, with the majority winning the decision

One of those computers just went out. Now how do you form your majority? Besides which, in such systems there's a governing system coordinating the election. What happens if your governing system goes out?

Your governing system isn't a single system, it's multiple using a suitable algorithm to establish quorum. This is a well studied problem in distributed systems.

So one computer is out and the other 2 are giving different answers to the same question?

The question is increased resilience not perfection.

At some point, a military device / weapons system recognises that it's not operating to spec and either disables itself or diverts and destroys itself in a non-target region.

Keep in mind that for most weapons, not activating when not specified is far more useful than failing to activate where and when specified. See the case of several "broken arrow" nuclear weapons incidents in which failsafes prevented unintended detonation. In once case with only a single fail-safe preventing that detonation which would have been in a civilian populated region of the United States.

No, there's plenty of single purpose systems.

These applications indeed have special requirements which general-purpose components almost certainly won't be able to fulfill. Not should they - the tradeoffs in complexity and cost are rarely worth it for the hyperscaling or embedded world where Linux is most commonly used these days.

>Weapons systems are another environment you'd prefer to have resiliency. You'd hate to lose control of a missile while in mid-flight.

https://devblogs.microsoft.com/oldnewthing/20180228-00/?p=98...

> any of the hardware comprising the system

You probably mean the other way around: the system comprising hardware.