Wandering Thoughts archives

A quick tour of my desktop

I've finally gotten around to creating a screenshot of my desktop, now available here (500Kb PNG). My desktop is two 1280x1024 LCD panels in side by side mode, so this is a 2560x1024 picture. (You can probably easily spot the dividing line between the two panels.)

This screenshot shows a number of things that I've talked about, such as pyhosts and xrun; also visible is an xterm showing off the very handy ziconbeep feature (look at the top left). The overall appearance is fairly representative of what my desktop normally looks like, including the clutter of Firefox windows that drove me to lazy hacks.

One of my peculiarities is immediately visible; I like to have things present on both physical screens, so you can see duplicates of things like the fvwm pager. In practice I rarely use the ones on the left screen, but I like having them there for some reason. Another peculiarity is that I mostly work on the right screen (the left side of the right screen is my primary working area) and use the left screen mostly for overflow and secondary windows.

(Also, my 'working area' is the space below the xruns; in practice there is an invisible dividing line around there that I rarely cross with active windows. You can see this in the top height of the browser and emacs windows.)

The window manager is fvwm 2.5.x (specifically a relatively current build from CVS). The thing at the top left is an FvwmIconMan instance that swallows all of my terminal windows (primarily xterms, but I also use gnome-terminal and 9term). Terminal windows are my most common sort of windows and FvwmIconMan gives me a very compact way of keeping track of all of them.

The thing at the right just below the pager is stalonetray, which I use to give all of the Gnome applets and widgets somewhere to hang out (since I don't actually use Gnome). Most of the time all it contains is the Gnome volume control.

(If this leaves you with further questions, leave a comment.)

Sidebar: a bonus from 1996

I have pulled out of the archives my desktop screenshot from 1996 that is referenced on my old desktop writeup on my old site; you can find it here. Although some of the details have changed, I think it's recognizable as a version of what I have now. I've changed things since 1996 but by and large not my tastes.

Looking back at the 1996 screenshot, some things now make me wince. For example, I can't believe that I spent so long wasting the valuable top left corner on nothing more than load monitors. (Of course today I am similarly wasting the top right corner on, well, nothing.)

What windows I use window titlebars on

Yesterday, I said that I consider window titlebars as user interface elements and think it's sensible to ask if they're useful for any particular interface. As you might have guessed from what I've written, I don't consider consistency between programs to justify bad interfaces in things that I use a lot, and so I'm perfectly willing to eliminate titlebars on some of my windows if they're not justified.

So, are they justified for me?

In my environment, there are a continuum of answers. In some cases (such as xrun) I consider the titlebar an essential part of the interface; if I didn't have a titlebar, I'd have to display the same information in the main program area somehow. At the other extreme are things like my digital clock display, where a titlebar would be utterly pointless (and indeed normal people's environments make such things into 'applets', which don't have titlebars either). In the middle ground are cases like web browsers. A lot of the time a web browser's titlebar (showing the <title> of the page) is essentially pointless; it either shows stuff I don't care about or duplicates information on the page itself. But some of the time a browser's titlebar information is actually pretty useful, and in general I've found that leaving it out feels a little too minimal; a web page by itself can be awfully blank-faced, and having a titlebar somehow makes it a bit better.

(Honestly compels me to also admit that having titlebars is my window manager's default behavior, and sometimes I use a program more than a bit but not quite enough to go to the effort of turning its titlebars off.)

The situation with my terminal windows is complicated, but they don't have conventional titlebars. Ultimately the reason is not that their titlebars wouldn't have useful information, but that they take up too much space because I use so many terminal windows and I overlap them so much. The result is that I want as much space for real text as possible; space for titlebars is space that I can't be using for real text, so out they go. I work around the loss of information in part by putting the hostname (and an indication of whether or not I'm root) into my shell prompt.

Sidebar: how I deal with missing window controls

Of course showing the window's title is only part of the purpose of titlebars (arguably the lesser purpose these days). They also contain various standard controls for things like closing the window or maximizing it, and they give you something to grap onto to move it. With no titlebar, I don't have those controls either.

My solution is twofold. First, I attach the window operations that I do a lot to 'chorded' mouse buttons; for example, Alt plus the middle mouse button will move a window. Second, I have a popup menu in my window manager that gives me do all of the things that the titlebar controls do; this is arguably slower than the controls themselves, but is not too annoying for infrequently used options.

I say it's only arguably slower because of Fitts's Law. Titlebar controls are usually fairly small and must be hit with relative accuracy. My popup menus require very little precision at all to summon and generally have larger targets once they've popped up. Thus I would not be surprised if actual measurements showed that experienced users could perform window management faster through popup menus than through the controls.

(Of course this is where everyone notes that keyboard controls are even faster.)

Another building block of my environment: xrun

Sometimes I use a machine so often that tools like pyhosts and dmenu just aren't fast and convenient enough. For instance, I do most of my work on one of our login servers (which one doesn't matter), so with my habit of disposable windows I am forever opening and closing terminal windows and so on.

My main tool for dealing with this is a simple program called xrun (which was originally written by Mark Moraes). Xrun puts up a grid of text labels, each of which is clickable; when you click a label, it runs the associated command. You define the labels and the commands that they run. This probably sounds abstract, so let me show you a picture:

(This deliberately includes the window manager decoration, because it's part of the overall interface; the window title tells me what machine this xrun is for.)

By itself, xrun would be only a modest convenience boost, so the important thing is how I run it. I don't run xruns on my workstation; instead, I use my rxexec script to run each xrun on the server it's for with my full environment initialized. Effectively I get new terminal windows as fast as if I typed 'xterm &' from an existing window on the machine, because this is pretty much what is actually happening.

One of the interesting side effects of this is that I can still start new terminal windows even when normal logins to the machine are blocked or broken (during system shutdown, for example). This is periodically useful and sometimes misleading.

(These days you can get a lot of the same effects by using multiplexed SSH connections. I don't think it's quite as fast, although on modern hardware you'll probably never notice under normal circumstances.)

The myth of isolated, independent sysadmins

A while back I wrote about the myth of a completely shared knowledge base across sysadmins. Well, there's a mirror inverse of this myth: the equally persistent idea that you can be a completely isolated individual sysadmin, tucked into your own silo and working purely on your own responsibilities. This is the universe in which a multi-sysadmin group has the mailer person, the DNS person, the fileserver person, and so on, and no one has to spend any time trying to bring other people up to speed on their speciality.

This is a myth because you cannot be so completely isolated unless you expect your organization to throw out all of the work that you've done when you leave. If your co-workers are so isolated from you that they have no practical ability to work on your systems, there is no one to pick up the pieces when you leave (or even when you go on vacation). Your systems will have to be replaced from scratch, or at the very least someone will have to invest roughly equivalent amounts of effort from scratch in order to understand them.

(Oh, you document things so that someone else could pick it up from where you left off? Great, have you tested that documentation, and if so, on who?)

There are probably jobs where this is the case, where all you do is write one shot programs and build one off short term systems, where everything is completely different every time and you start from scratch (such a job could be either demoralizing or exhilarating, depending). But most jobs are not like this; most places want a longer lifespan for their programs and systems, and they want more continuity. You are building elements of a larger, longer lived environment, not independent one offs.

This doesn't mean that you should try to go all of the way to even knowledge across your group, because that's still a myth too. You need to find a middle ground. My personal line in the sand is that everyone in your group should be able to do basic troubleshooting of every important system. If all other people can do when there's a problem is shrug and say 'we've got to wait until <X> is here', you've become too isolated.

I will note in passing that it is not a particularly pleasant feeling to realize, on your way out, that you have become this sort of person and that you are leaving your successor something that they will wind up razing to the ground and rebuilding from scratch. Knowing that you are going to see all of your hard work and beautiful systems thrown away, and worse, that it's your fault.

(This has happened to me and it was very educational. And I have seen it happen to other people. Because I am not exactly perfect, it will probably happen to me again.)

My brute force email archive

Years ago, I had a brainwave about archiving my email. The brainwave was simple: 'disk is cheap'. So I changed my .forward to save a copy of all of my email to a file, in addition to the other filtering I was doing with it. I don't point a mail client at the file or otherwise use it for anything in my regular email setup; it is purely a backup and completely separate from my regular email client.

(To be honest, it might have evolved out of my careful caution when I started using procmail. Since I didn't entirely trust procmail, I think that I set up my .forward to save a backup copy of all of my email in a file. At some point I then realized that disk space was cheap and didn't actually clear the file, just let it accumulate.)

Recently I realized that it needed one more thing to be really complete and useful; it needed to get a copy of my outgoing email, not just my incoming email. Thus over the past few years I've switched to cc'ing myself on everything I write (generally done automatically by my MUA, replacing saving the messages itself).

There are two important attributes of this brute force archive that make it so useful. First, it is truly comprehensive; it has everything, not just the things that I thought I was going to want (or need) later. I wouldn't say that I'm bad at picking what I'll need later, but I'm not completely accurate at it. Having a complete archive as a backup means that I don't have to be; my accuracy is more a matter of convenience than of necessity.

Second, it's separate from my regular mail environment so that my full archive doesn't clutter up (and slow down) my normal mail folders. This matters because how I want to use my regular folders is very different from how I use a comprehensive archive. If I tried to use only a comprehensive archive, I would immediately start losing important things in it; there would be so much volume and even so many false positives in searches that it would be pretty much useless. I need my regular folders to be curated and sorted (and, sometimes, pruned), to contain the things that I think matter and that I want to be paying attention to. This is nothing like a comprehensive archive.

In theory I could do all of this within a single mail environment. I would just have to be very disciplined about always saving a copy of every message (both received and sent) to my special 'archive' set of folders, no matter how trivial the message was, and then also having it in my regular set of folders as I processed it and perhaps saved it again.

In practice, having the system handle it all by just writing everything to a file is simpler and more reliable (and it's grunt work; computers exist to automatic grunt work). Also, since this file exists entirely outside of any MUA I may use, I know for sure that no MUA is touching it and doing things to the messages; they are archival perfect, exactly as originally received (and exactly in the order they were originally received).

PS: when I say everything I really do mean everything. So yes, this does mean that I get kind of irritated at people who email us ten megabyte files out of the blue (which happens every so often). But disk space really is cheap, and if I need to I can always bzip2 the archives.