Persistent sessions: an apparently unwritten program

When I “shut down” my computer—any computer—at the end of the day, or to go off on an errand, I’m usually actually “suspending” or “hibernating” it. I run like this—accumulating disk corruption and, if I suspend rather than hibernating (because hibernation doesn’t work on my current laptop), wasting power—for weeks or months on end until either an upgrade forces me to reboot or, inevitably, something crashes. (On my current laptop, that something is usually something in the wireless networking stack; I’m not entirely sure what. A “crash” doesn’t necessarily brick the machine until I power-cycle it, but at least renders it mostly unusable without a reboot.) Or (on my desktop), because either it overheated or the power flickered (despite the UPS!), it simply turns itself off.

I go to such great lengths to avoid rebooting, and am so very frustrated every time a system crashes, hangs, or loses power because the software doesn’t support proper, persistent sessions. (I’m picking on Linux here, which is what I use primarily, but Windows is no better.) I always have well over a dozen terminals (between a screen session and Konsole tabs), each in a different directory, many with a Vim session open, in addition to two browsers and an IM client. But the most that the best “session saving” features of any current desktop environment or window manager can do is recognize that I had a Konsole window open, or perhaps how many tabs it had open and at best what directory each was in.

This is not good enough. The mere directory isn’t usually enough for me to remember what I was doing there. And this really shouldn’t be up to the desktop environment or window manager, because session saving should extend to terminal sessions that don’t involve a GUI at all. If my computer crashes, or if I have to reboot, I should be able to boot it and each terminal, once I log in, back where I was, in the same milieu—editors open to the same files in the same places, a little of the scrollback buffer visible to show what I was doing.

My current workaround is a shell script that I source in every terminal, that sets up my environment (changes directory and then prints an explanatory message) based on which terminal it was called from. But I have to maintain this script, and I have to anticipate what I’m going to want to be doing. This isn’t good enough; it should Just Work.

Have I missed something that does what I want? This shouldn’t be all that hard

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s