2 ms·

Some remarks: > > Memory overcommit on Linux can be turned off. No, it can't in reality. Nothing works in Linux when you turn of the overcommit as more or le

Some remarks: > > Memory overcommit on Linux can be turned off. No, it can't in reality. Nothing works in Linux when you turn of the overcommit as more or less every Linux lib and program relies on this behavior. > However, as I mentioned. Memory allocation failures are rare and when they happen you need to fix a bug anyway. So crashing on a rare condition instead of running untested error recovery code is probably preferable in general. That does not apply to safety critical code. "Just crashing" a system in (for example) a nuclear power plant is not an option! Or imagine, the controller of your car breaks crashes at some critical point in time and you can't break until the system rebooted. Of course all code paths need to be tested. That's an obvious fact.

vlovich123 4y ago
> That does not apply to safety critical code. "Just crashing" a system in (for example) a nuclear power plant is not an option! Or imagine, the controller of your car breaks crashes at some critical point in time and you can't break until the system rebooted. Of course all code paths need to be tested. That's an obvious fact. That’s one strategy. Another strategy is to run parallel controllers and using majority consensus. Distributed systems tells us that provides better guarantees but you have to design your system better instead of your code to avoid coupling (eg so that bad sensor data doesn’t take down multiple CPUs you need to basically duplicate a lot of your electronics). Safety critical systems should probably also be using formal proofs but that’s a secondary thing. However, on net that hardware duplication is probably a fraction of the cost and building your systems to reboot quickly in the face of the fault and testing fault handling regularly catches entires swathes of problems more simply and cheaply.

vlovich123 4y ago

> That does not apply to safety critical code. "Just crashing" a system in (for example) a nuclear power plant is not an option! Or imagine, the controller of your car breaks crashes at some critical point in time and you can't break until the system rebooted. Of course all code paths need to be tested. That's an obvious fact. That’s one strategy. Another strategy is to run parallel controllers and using majority consensus. Distributed systems tells us that provides better guarantees but you have to design your system better instead of your code to avoid coupling (eg so that bad sensor data doesn’t take down multiple CPUs you need to basically duplicate a lot of your electronics). Safety critical systems should probably also be using formal proofs but that’s a secondary thing. However, on net that hardware duplication is probably a fraction of the cost and building your systems to reboot quickly in the face of the fault and testing fault handling regularly catches entires swathes of problems more simply and cheaply.