> 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
Received on Wed Jan 14 2009 - 20:38:17 UTC
This archive was generated by hypermail 2.2.0 : Wed Jan 14 2009 - 20:48:04 UTC