Don't planes need to be restarted every few flight or all the flight input data goes crazy? https://gizmodo.com/turn-it-off-and-on-again-every-149-hours...

If anything, I hope we’ve learned that node uptimes are unimportant. It used to be a badge of honor to show some system hadn’t been rebooted in $years. Now that just implies that there’s unpatched vulnerabilities and countless hand-made configuration changes that nobody remembers and that will be lost if the machine dies.

A sign of a responsible organization these days is how short-lived their hosts are. If every machine in an organization has an uptime less than a week, I feel pretty confident in that org’s ability to recover from a disaster. I also know it’s harder for attackers to keep a foothold once in the system, since everything is being constantly updated and reimaged.

It's true that unmatched neglected systems are a Hazzard

But these days systems can be patched without restarting

So "uptime" is not necessarily accurate

* hazard

Hazzard is a fictional county in Georgia that's the setting for the TV show “The Dukes of Hazzard”.

Whenever we see a big mistake on these fields, it becomes a scandal. Whenever we see a big mistake in tech companies, it's just part of the daily news.

TL;DR: they don't work either.

See the Boeing 737MAX fiasco for reference.

Regulations are pretty easy to circumvent with enough money it seems.

Regulatory capture is a risk. The FAA allowed the max to be certified, and resisted grounding it after accidents. That is terrible, and there were congressional enquiries and legal settlements in the billions for Boeing - including several specifically for manipulating and misleading regulators. That all sounds like an argument for better regulatory oversight rather than no regulation.

I wasn't against regulatory oversight.

I was mentioning that it's a system as flawed as everything else if you just expect it to work.

Also I'd like this kind of direct life threatening decisions to become criminal charges (not just fines) for the ones signing them off, please, including in software regulations.

There was absolutely nothing wrong with the software on the 737MAX. It failed because of systems engineering, not software.

Agreed. Software doesn't happen in a vacuum tho.

Those are easier to regulate. People research how large of a radiation dose is appropriate for an x-ray, or how long certain parts/materials can sustain what kinds of loads, and they can use this information to come up with appropriate regulations.

It's much harder to come up with the same kind of concrete regulations for software security (i.e., device must deliver no more than X dosage to patient). We might have to settle for forcing companies to carry exploit insurance, and make it easy to sue for breaches.

In aerospace? Extremely well. Software (in context) that is subject to DO-178 certification is generally more reliable than the plane hardware. This is an industry where the 737 MAX, a plane safer than driving per-mile, is considered a death trap because the standard for safety is being 1000x safer than driving.

The software in one of the highest reliability industries is one of the highest reliability components. Unlike in other industries, especially consumer electronics, where even in low reliability products the software is almost always the lowest reliability component.

To put a more concrete take on this. In consumer systems, 5 9s is viewed as a gold standard. A level to aspire to, not necessarily one to achieve. In critical aerospace systems, 9 9s is viewed as the minimum, a level to never drop below. Many systems see 12 9s or higher.

The minimum standard in aerospace is 10,000x higher than the maximum standard in consumer. And the software reaches and exceeds that standard. That is how far the gap is and how well it works.

However, the downside is the expense and time. But, this can be mitigated by only applying these techniques where it matters. A key component of the DO-178 standard is identifying how critical each portion of the software is. You then only apply the most rigorous techniques for the highest criticality pieces. Of course, this requires the pieces to be well isolated, so that errors in one piece of non-critical code can not affect critical code; otherwise the non-critical code is actually, transitively, critical and thus demands increased rigor.

These techniques are tried and true in the most demanding circumstances. It would be prudent to start from these expensive working standards and work downwards to invent cheap working standards rather than fixing cheap non-working standards into cheap working standards. I think every software developer here can attest to it being much easier to start from something working, no matter how crude, than to start from something broken.

I call BS on 12 9s. To actually meet that a system operating for all of the common epoch would have only 60 milliseconds of downtime. There is no way since Wilbur and Oliver that any aerospace system could accomplish enough runtime to be sure it isn't 11 nines instead.

As for your actual point most systems would be better with a GC'd memory safe language then the hard real time those specs you mention are written from.

I am not talking about individual airframes. I am talking about quality of service over the entire fleet.

The DO-178 standards were instituted 30 years ago [1]. There are ~700 million passengers per year flying on commercial airlines in the US since 2003. Extrapolating that backwards to 1992, that would be ~20 billion service requests fulfilled. In 2019, the US averaged 1.57 trillion passenger miles over ~1 billion passengers resulting in a average flight of 1500 miles. That corresponds to around 3-4 hours on average at cruising speed. It takes around 3 minutes for a plane at cruising altitude to crash. So, since the DO-178 standards were introduced there have been 1.6 * 10^12 safety-critical service segments where a software failure over that period could cause a fatality.

There have been exactly zero fatalities connected to software errors since the DO-178 standard has been introduced. So, over 1.6 * 10^12 service segments every single one of them was successfully delivered by the software without failure. 12 9s.

Also, just in case it is not clear, calculating over multiple airframes does not result in redundancy reducing error rates. Every single airframe must succeed in their service of every single service request. An analogous situation in IT would be having 10,000 servers with zero redundancy achieving 5 minutes of total downtime divided over all 10,000 servers resulting in 9 9s reliability.

[1] https://en.wikipedia.org/wiki/DO-178B

> There is no way since Wilbur and Oliver that any aerospace system could accomplish enough runtime to be sure it isn't 11 nines instead.

Especially when some plane models need to be rebooted every couple of weeks because of software bugs ;)

https://www.theregister.com/2020/04/02/boeing_787_power_cycl...