inamerrata

In his epic battle with Adrian over exceptions, Ben mentioned:

Save your work? That’s for sissys. Use a journalling file-saving model. Save everything the user does immediately. You can support the traditional file save/load facility using checkpoints or other niceties but I fail to see why any application in this modern age of fast hard drives should ever lose data the user has entered more than a few hundred milliseconds ago.

That’s really very true. Certainly there are caching issues — memory is much faster than disk, and you don’t want to store intermediate state all the time, and likewise you probably want to keep some history, but certainly don’t want to keep all of it. But generally, disk is fast enough (compared to user interaction and network speeds) that there really isn’t any excuse for losing data.

If my battery and power shorted out right now, I’d lose: (a) this entry; (b) the fact I’ve got Planet Humbug open to read Ben’s blog and my Back-button history; (c) the fact I’ve got three terminals open, and their history (both scrollback and command invocations); (d) what email I’m currently reading.

Saving this blog entry takes at most half a second, mostly because to do so I have to hit some keys and a menu gets highlighted. Saving all my scrollback from scratch seems to take under 5 seconds, mostly because I have to cut and paste it into another application first. And the other two items are fairly trivial annotation issues.

This isn’t even that hard an issue to solve: it’s only relevant for long-running apps with user interfaces — so xterm and bash, but not sed or ls. It requires somewhere for apps to dump their status ($TMPDIR or a dotfile in $HOME). And it requires some code to do recovery, possibly with a user interface in order to choose which point in history you want to recover. And given those issues, for many apps, there’s no reason not to then just automatically recover after a crash, at least as long as you give the user an easy way of avoiding getting into a “recover to a point where you always crash; always recover when you crash” loop (or at least an easy way of getting out of it).