Every time I go on a trip I plan to spend half a day “setting up my laptop”. Mostly this means copying files back and forth until it somewhat resembles my main machine, and hoping I haven’t forgotten anything (say, for instance, the time I went to the RH Summit and forgot to bring the VPN key. Sigh).

I’m much too lazy to set up rsync for my desktop configuration for this purpose, and anyway I suspect that I’d spend as much time tweaking any rsync script as I do just copying things around. Instead I’ve spent my time more usefully, thinking about how this could be automated for KDE or Gnome.

What I’m thinking about in particular is a new role for kde.org or gnome.org: give everybody who uses the desktop a little space on the web site, and automatically encrypt and upload certain bits of data; then automatically download and synchronize it when the user logs in and has a network connection.

Initially this could just be a few things relating to my identity: the contents of my keyring (including passwords for web sites), information about my various mail accounts, my gaim accounts, newsgroups I use and information about what articles I’ve read, my blog list in RSSOwl, my calendar, my sticky notes, my .cvspass file, probably even my mozilla bookmarks.

I think that is actually pretty minimal and that over time we’d find more things to add — just go through the list of programs you use daily and it is pretty easy to see bits of configuration that relate to your identity, as opposed to machine- or session-local ephemera. But initially just starting with one or two of these to work out the concept would be fine.

The synchronization phase is the only tricky point. I’m often using both my machines at once, and if I make an account on some website using my main machine, and make another account around the same time using my laptop, I think it is reasonable to expect that the results will be merged — that I won’t lose one or the other.

This means that simply copying config files around in a naive manner is probably not workable. I don’t think there are any big problems solving this; in most cases I care about, it boils down to computing the union of two lists.

In the unusual case where the two configurations refer to one account with different passwords, I suppose we could defer to the user at synchronization time. I doubt this happens often.

In the bigger view I think this is just the first step toward integrating the desktops with their respective web sites. There are plenty more ways this could be done.

Up until now I’ve thought that bumptop (and lowfat, and to a lesser extent croquet) was pretty but not very useful. The demos show a lot of nice file manipulation tools, but I use nautilus very rarely; so bumptop has seemed like it put a lot of energy into the wrong place.

I’ve been thinking about it a bit more and I’m not as sure as I once was. It took a while, but I finally realized that my desktop is littered with things that, on a bumptop desktop, would be active objects subject to manipulation — that bumptop actions are not limited to “files” but instead “desktop objects (some of which are files)”.

So, for instance, all the launchers on the gnome menu and on my various panels would fit into this category. So would things like URLs I dragged to the desktop, notification area icons, other panel applets like the mail checker, methusalem-based task trackers, etc.

Something like a panel full of launchers, or the gnome menu itself or that matter, would instead become a bumptop container of some kind. Menu editors would just go away, deferring to a more general (and, if this whole idea makes any sense at all, easier to use) organizational technique.

Technologically it all seems like a good time.. groovy physics-based 3d-ness; downloading hibernating python bits from the web to live like fireflies on the desktop, telling us the state of our imap account or calendar or remote build, until we delete them or bury them under a pile of crumpled PDFs; treating our applications like the edsels they are and, finally, stripping them of their chrome, choosing instead to pull bits from youtube and google video and our mythtv servers to remix them in place in a specialized desktop… a google of hackers could spend years having fun on this.

I’m still skeptical though: the extended definition of “desktop objects” still only covers a small minority of what I do daily. I only occasionally use launchers (and those I have set up nicely on an auto-hide side panel), and the whole point of applets and notifiers is that they are typically passive.

A sillly destop idea: .desktop files should start with “#! some-new-program” and be executable. Then I could run them directly from the command line. Naturally the script interpreter would know how to parse command line arguments and pass them on to the underlying program appropriately.

I was reading about Gnome 3.0 recently (and I’m working on a long post about it), when I ran across a post by Luis Villa about Gnome versus web development. (BTW you should read his blog if you don’t already.)

I found this pretty compelling in general — it is a nice analysis and it is also a list of things that can actually be addressed without going crazy.

I’m interested in the deployment issue, since I’ve done some playing in this area with Java Web Start. And, though I think I don’t agree that this is really a blocker, it is still fun to think about a bit — the technology is fun and cool, I’m just not convinced it solves a pressing problem. (Your response here…)

First, yes, with C or C++ I think deployment is just going to continue to suck.

Java already solved this problem in a pretty nice way. It is no big deal to write a single-click install, with automatic updating, good security (either a sandbox or signatures for apps that need more permissions), etc. This could use a little work for better Gnome integration, and of course we should be shipping this in Fedora, but the amount of needed work here is quite small. (I assume C# has something similar but I really don’t know.)

I looked into this for Python a little this weekend. And, it looks like Python Eggs and the Python cheese shop provide a nice basis to make this work. Finishing this is pretty concrete:

• Define an XML document describing an application. This would include the same kinds of things that ended up in JNLP: icons, splash screens, the required python version, a list of python egg URLs, etc.
• Add some kind of signing to python egg downloads. Unfortunately I don’t think sandboxing is an option. One idea would be to restrict eggs to python.org and gnome.org URLs — but that interferes with the idea of easy deployment.
• Make a new URL type so that Mozilla will know to run appropriate python script to parse the XML, install the eggs, and launch the application.

For best results this would incorporate some things I was looking at for NetX: having the ability to download an application without running it; dbus integration so that a previously cached application won’t try to update itself in a net-less environment; drag-and-drop of entire applications from Mozilla to the panel; and now, integration with mathusalem when downloading eggs.

I’ve uploaded the slides from my auto-tools talk at NCLUG last night. I had a great time up there, as always, though I missed Bob Proulx this time.

I thought the talk went well. It was a gentle intro to the auto-tools: what they do, how to read the common bits, where to get more information. If you want a really thorough tutorial I recommend reading Alexandre’s 550 slides.