The distinction is simply (but critically!) this: the standard operating procedure (and, in fact, the only available way!) to shut down a piece of crash-only software is to crash it forcibly. There is no quit button, no shutdown command, no remote API, there is just kill. Sounds simple enough, but where it really gets interesting is in how this mindset affects your design and implementation decisions.
Imagaine for a moment what it would be like if during every second of work during every day of the week each and every thing you did was accompanied by a corresponding design exercise along the lines of "okay, but what if it crashes right then." Now that would sure produce some "software with good error handling", now wouldn't it. That is crash-only software.
Yep, you'd be forced to think more about transactions. What activities needed to be carried out as a transaction, and for what activities it didn't matter. Because at any point the process could exit.
Imagaine for a moment what it would be like if during every second of work during every day of the week each and every thing you did was accompanied by a corresponding design exercise along the lines of "okay, but what if it crashes right then." Now that would sure produce some "software with good error handling", now wouldn't it. That is crash-only software.