4 ms·

Crashing on error is almost always the right default behavior. If you do anything else by default, then you get in to the land of data corruption and security

by hedora 1y ago

Crashing on error is almost always the right default behavior. If you do anything else by default, then you get in to the land of data corruption and security holes. If you do this, and then find your thing crashes in production, then that means you didn't test it well enough. Before someone mentions safety critical systems, consider the fact that the first apollo landing's computer crashed when it detected it was violating realtime bounds ("alarm 1201" means the OS detected CPU exhaustion + rebooted without clearing process state). At that point, it went into a reboot loop, and got close enough to the surface for Neil Armstrong to nudge the lander to a safe landing. https://apollo11space.com/apollo-11-computer-problem/ https://apollo11space.com/apollo-11-computer-problem/

bmink 1y ago
I love the Apollo 11 computer stories but by today’s standards it was more of an MCU than a computer. And sure, in the embedded space it is true that in a lot of cases error recovery doesn’t make a whole lot of sense and it makes more sense to reset quickly. But there are many systems today that take a long time to restart so you can’t just abort if you have a chance to recover.
AlotOfReading 1y ago
The Apollo guidance computer specifically had a pretty unusual definition of "crashing" too. What it would do is save all the critical data, turn everything off, reinitialize the hardware, and restart all the jobs from designated reentry points. Very unlike what we think of as crashing. Regardless, a modern boot chain is much more complicated than anything the Apollo computers had to deal with, where rebooting (as opposed to the safe restart procedure above) simply involved setting the program counter to some default value.
- lunar-whitey 1y ago
  The LM computer’s recovery routines for this scenario are more accurately described as “checkpoint/restore” than “crash” (as most people would understand the latter). The former technique is still used in high availability systems today.
lunar-whitey 1y ago
This summary of events is incorrect. The LM guidance computer’s executive routines detected an overload (which occurred because Buzz Aldrin had left the rendezvous radar on) and continued to operate in a degraded state where lower priority work was not performed. These faults were reported and the landing proceeded with the computer remaining responsive to inputs despite the concerns the alarms produced. Armstrong’s control changes near the end of the descent were made for reasons unrelated to the rendezvous radar error. Modern systems use more formal techniques to achieve the same goal: graceful degradation. For a detailed account of computer operations during the Apollo 11 landing, you can read this analysis from an engineer who worked on the program: https://www.doneyles.com/LM/Tales.html https://www.doneyles.com/LM/Tales.html

by hedora 1y ago

bmink 1y ago

I love the Apollo 11 computer stories but by today’s standards it was more of an MCU than a computer. And sure, in the embedded space it is true that in a lot of cases error recovery doesn’t make a whole lot of sense and it makes more sense to reset quickly. But there are many systems today that take a long time to restart so you can’t just abort if you have a chance to recover.

AlotOfReading 1y ago

The Apollo guidance computer specifically had a pretty unusual definition of "crashing" too. What it would do is save all the critical data, turn everything off, reinitialize the hardware, and restart all the jobs from designated reentry points. Very unlike what we think of as crashing. Regardless, a modern boot chain is much more complicated than anything the Apollo computers had to deal with, where rebooting (as opposed to the safe restart procedure above) simply involved setting the program counter to some default value.

lunar-whitey 1y ago
The LM computer’s recovery routines for this scenario are more accurately described as “checkpoint/restore” than “crash” (as most people would understand the latter). The former technique is still used in high availability systems today.

lunar-whitey 1y ago

This summary of events is incorrect. The LM guidance computer’s executive routines detected an overload (which occurred because Buzz Aldrin had left the rendezvous radar on) and continued to operate in a degraded state where lower priority work was not performed. These faults were reported and the landing proceeded with the computer remaining responsive to inputs despite the concerns the alarms produced. Armstrong’s control changes near the end of the descent were made for reasons unrelated to the rendezvous radar error. Modern systems use more formal techniques to achieve the same goal: graceful degradation. For a detailed account of computer operations during the Apollo 11 landing, you can read this analysis from an engineer who worked on the program: https://www.doneyles.com/LM/Tales.html https://www.doneyles.com/LM/Tales.html