Saving the Remote Environment

Kaboom!

So I was at Superhappydevhouse when my thinkpad unexpectedly went into hibernation. It took me a little while to figure out that someone across the room inadvertantly flipped the switch that controlled the outlet I was plugged into, and my battery had died. The din in the room was loud enough that I could not hear it's last, plaintive beeps.

My battery was resurrected at the flip of a switch, but I lost some time setting up application sessions, so I asked around as to how people save session data in their application of choice.

While there is no way to restore the complete state of my Linux system upon a crash (a car battery to thinkpad power adapter is on my list of things to do), there are quite a few things I can do to make things less painful. Here are the best of state-saving helpers I looked at:

emacs

First, Emacs has the commands desktop-save and desktop-read.

This feature is directory dependent, that is, emacs will ask you what directory your desktop config file is in.

I have one emacs desktop file in each of my project directories now. The desktop feature doesn't re-tile your windows, but it at least brings up all the files you had open and, of course, emacs tells you which ones have auto-save data.

The single-desktop-per-directory limitation encourages subdirectories for different work modes.

screen

I don't run most programs in crappy emacs shells, I use real terminals. I need something to save the state of all my terminals. I have finally been getting to know GNU screen. Good tutorial here.

Using screens keybindings is painful. However, unlike gnome terminals bindings, they don't collide with the readline namespace. Alt-B really takes me back a word, instead of popping up some useless menu. (Update: I have since been enlightened by Eterm, and now run screen in an eterm window.)

Screen runs as a daemon and manages consoles - sort of like a text-only window manager. Obviously, it can't restore running applications after a crash. However, run over an ssh session, it will happily run whether you are attached or not, so it's a nice way to work remotely. Evidently, it can also be configured to tee I/O for multiple clients, aiding in collaborative development.

Screen encourages one to work remotely on a more reliable system; which effectively means it encourages one to have a non-production machine that is internet accessible.

firefox

Third, Firefox has SessionSaver.

http://kb.mozillazine.org/SessionSaver

Session saver is useful, but not exactly feature complete. A few things I noticed:

One, to overwrite a saved session, you have to open the session, configure as desired, right click on the saved session to delete it, and re-save the current browser state with the same name.

Two, SessionSaver actually uses a good bit of CPU.

Three, SessionSaver explicitly suggests that you save your data via WebDAV and has some utilities to make it easier to do.

More encouragement for remote work. I'm starting to get the message...

The overall hint is that I should give in and store everything on a remote server. I could use screen, emacs, and webdav/sessionsaver to store everything there.

WebDAV

I had been experimenting with WebDAV long ago, so I re-installed it on a server I have access to. My primary goal is to get this going with firefox sessionsaver. However, my secondary, more exciting goal is to get this working with the actively developed and nearly useable DavFS2 for the linux kernel. WebDav installation and usage is tangent to the omnibus remote-coding review of this article, but I *will* handle this in a subsequent article.

ssh-agent

As long as we're on a roll, lets slap on another convenience utility for setting up our sessions that I have ignored for a long time: ssh-agent. Ssh-agent helps you manage passwordless ssh logins - here is a good explanation. If you run linux, you should already have this tool, and every other tool I'm covering (with the exception of a quick SessionSaver download for firefox). This particular tool is something that is a better friend to system administrators than developers, but it *might* save me time in the long run.

am I really better off?

So now I can quickly login with ssh-agent, reconnect to my screen session, fire up desktops with emacs and sessions with firefox. If my laptop dies, very little time lost. (and thinkpads are cheap so I always have two of them running - very, very little time lost.) I figure in a week or so I'll actually be used to using them.

The answer is yes; I am better off. Philosophically, I have come to the same place I came to years ago when starting my last business. I recognized that I wanted every business application I touched on a daily basis to be a web-application. Personal mobility and data integrity are worth spending time and money on.

So what happens when my server dies?

Well, my server has RAID 1 and is probably in the most reliable colo my friends can afford. Unless it gets maliciously cracked, I think it's going to stay up and hold on to my data.

However, these tools have made me a little more dependent on one particular server and an internet connection. They have also made me a little more security conscious.

Hmmm...I guess I don't know if I'm better off after all. This clearly and definitively proves that you need to read very bad haiku to put your pain in perspective:

Switch to remote work
Trading worries for worries
Emotional wash

Deposit days now?
Why tilt at crazy windmills?
silent dividends...

Synchronize, Backup
Endless server maintenance
Gag me with - - - a spoon.

No! not the next blog!
I have a better idea?!?!?.;
It hurts, I know-Yiiiiiii!

(Update: I should mention Elinks somewhere, which is my ideal reader for primarily text-based web sites. You'll want to read it's FAQ. Try it with gmail vs. any other browser and I think you will agree. Blazing fast, and no advertisements. It supports JavaScript as well. Just the ticket for a text-based environment.)