Why is nobody questioning the propriety of using an off-the-shelf Windows PC in safety-of-life applications?
Agreed. So the app shouldn't contain anything extra not related to it's primary function.
However, handling error conditions reported by the operating trumps the extraneous code rule. But there are many ways to handle an error, including ignoring it if that's the proper thing to do.
Crashing is never the proper thing to do. If the program had simply exited at the very minimum, a restart would have taken a lot less time than a complete reboot of the machine. The software crashed that badly that it required a reboot of the machine.
> Why is nobody questioning the propriety of using an off-the-shelf Windows PC in safety-of-life applications?
They are, in the other threads. But using a better OS for the task wouldn't prevent the coding error the programmer did.
Let's say they chose Linux. A signal goes off or something else happens and their read call fails. Since they expect all their I/O to succeed they crash just like the Windows box.
If they bothered to handle the error and check for EINTR they'd know it was interrupted and not a hardware failure.
My point is, changing operating systems doesn't protect you from poorly coded applications.
No, that's a recipe for failure. Hardware will fail. Period.
Hoping that nothing will fail and therefore not taking steps to mitigate it is akin to designing cars not to crash. [0]
Failures need to be explicitly designed for and tested. It's truly depressing that companies where failure is fine (ex. Netflix's Chaos Monkey) understand this, while companies where failure is deadly don't.
