> What do you think about the concept of crash-only software? While I'm certain that it's great for large, complex, high-availability applications which infrequently write persistent state to disk, I don't think it's of much use for small software components. Such programs are unlikely to be able to architecturally differentiate between micro-reboots and macro-reboots, not to mention that the average consumer-grade application already supports auto-saving and can start up cleaning in a short period of time - even moreso for suckless programs.
> What about removing the running flag from dwm and replacing quit() > with kill(pid)? My interpretation of the original paper's statement that 'stop=crash' was that a crash and a stop instruction are considered equivalent, ie. that there is no path dedicated to storing resources on shutdown which would be unavailable in the case of a crash, and not that an application should have no method to cleanly exit and require the use of kill. The collection of articles seems to imply that 'crash-only' refers to the usage of rebootable components and frequent saving of persistent state to cope with errors instead of using more complex error recovery mechanisms. In fact, since dwm doesn't have any persistent state and consists of a single logical module, Neale's script _would_ arguably make it crash only software. Brendan MacDonell
