Automatically hardlinking duplicate files under /usr/share/doc with APT //at 20:43 //by abe

On my everyday netbook (a very reliable first generation ASUS EeePC 701 4G) the disk (4 GB as the product name suggests :-) is nearly always close to full.

TL;DWTR? Jump directly to the HowTo. :-)

So I came up with a few techniques to save some more disk space. Installing localepurge was one of the earliest. Another one was to implement aptitude filters to do interactively what deborphan does non-interactively. Yet another one is to use du and friends a lot – ncdu is definitely my favourite du-like tool in the meantime.

Using du and friends I often noticed how much disk space /usr/share/doc takes up. But since I value the contents of /usr/share/doc a lot, I condemn how Nokia solved that on the N900: They let APT delete all files and directories under /usr/share/doc (including the copyright files!) via some package named docpurge. I also dislike Ubuntu’s “solution” to truncate the shipped changelog files (you can still get the remainder of the files on the web somewhere) as they’re an important source of information for me.

So when aptitude showed me that some package suddenly wanted to use up quite some more disk space, I noticed that the new package version included the upstream changelog twice. So I started searching for duplicate files under /usr/share/doc.

There are quite some tools to find duplicate files in Debian. hardlink seemed most appropriate for this case.

First I just looked for duplicate files per package, which even on that less than four gigabytes installation on my EeePC found nine packages which shipped at least one file twice.

As recommended I rather opted for an according Lintian check (see bugs. Niels Thykier kindly implemented such a check in Lintian and its findings are as reported as tags “duplicate-changelog-files” (Severity: normal, from Lintian 2.5.2 on) and “duplicate-files” (Severity: minor, experimental, from Lintian 2.5.0 on).

Nevertheless, some source packages generate several binary packages and all of them (of course) ship the same, in some cases quite large (Debian) changelog file. So I found myself running hardlink /usr/share/doc now and then to gain some more free disk space. But as I run Sid and package upgrades happen more than daily, I came to the conclusion that I should run this command more or less after each aptitude run, i.e. automatically.

Having taken localepurge’s APT hook as example, I added the following content as /etc/apt/apt.conf.d/98-hardlink-doc to my system:

// Hardlink identical docs, changelogs, copyrights, examples, etc

DPkg
{
Post-Invoke {"if [ -x /usr/bin/hardlink ]; then /usr/bin/hardlink -t /usr/share/doc; else exit 0; fi";};
};

So now installing a package which contains duplicate files looks like this:

~ # aptitude install perl-tk
The following NEW packages will be installed:
  perl-tk 
0 packages upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
Need to get 2,522 kB of archives. After unpacking 6,783 kB will be used.
Get: 1 http://ftp.ch.debian.org/debian/ sid/main perl-tk i386 1:804.029-1.2 [2,522 kB]
Fetched 2,522 kB in 1s (1,287 kB/s)  
Selecting previously unselected package perl-tk.
(Reading database ... 121849 files and directories currently installed.)
Unpacking perl-tk (from .../perl-tk_1%3a804.029-1.2_i386.deb) ...
Processing triggers for man-db ...
Setting up perl-tk (1:804.029-1.2) ...
Mode:     real
Files:    15423
Linked:   3 files
Compared: 14724 files
Saved:    7.29 KiB
Duration: 4.03 seconds
localepurge: Disk space freed in /usr/share/locale: 0 KiB
localepurge: Disk space freed in /usr/share/man: 0 KiB
localepurge: Disk space freed in /usr/share/gnome/help: 0 KiB
localepurge: Disk space freed in /usr/share/omf: 0 KiB

Total disk space freed by localepurge: 0 KiB

Sure, that wasn’t the most space saving example, but on some installations I saved around 100 MB of disk space that way – and I still haven’t found a case where this caused unwanted damage. (Use of this advice on your own risk, though. Pointers to potential problems welcome. :-)

Conkeror in the Debian NEW queue //at 22:57 //by abe

I already mentioned a few times in the blog that I’m working on a Debian package of the Conkeror web browser. And now, after a lot of fine-tuning (and I still further new ideas how to improve the package ;-) Conkeror is finally in the NEW queue and hopefully will hit unstable in a few days. (Update Thursday, 03-Jul-2008, 18:13 CEST: The package has been accepted by Jörg and should be included on most architectures in tonight’s updates.)

Those who could hardly await it can fetch Conkeror .debs from http://noone.org/debian/. The conkeror package itself is a non-architecture specific package (but needs xulrunner-1.9 to be available), and its small C-written helper program spawn-process-helper is available as package conkeror-spawn-process-helper for i386, amd64, sparc, alpha, powerpc, kfreebsd-i386 and kfreebsd-amd64. There are no backported packages for Etch available, though, since I don’t know of anyone yet, who has successfully backported xulrunner-1.9 to Etch.

Interestingly the interest in Conkeror seems to have risen in the Debian community independently of its Debian packaging. Luca Capello, who sponsored the upload of my Conkeror package, pointed me to two blog post on Planet Debian, written by people being fed up with Firefox 3 already and are looking for a more lean, but still Gecko based web browser: Decklin Foster is fed up with Firefox’ -eh- Iceweasel’s arrogance and MJ Ray is fed up with Firefox 3 and its SSL problems.

Since my previously favourited Gecko based web browser Kazehakase never became really stable but instead became slow and leaking memory (and therefore not much better than Firefox 2), I can imagine that it’s no more an candidate for people seaking for a lean and fast web browser.

Conkeror has some “strange” concepts of which the primary one is that it looks and feels like Emacs:

• The current location is shown in a status bar below the website, where Emacs usually shows buffer names. All input, even entering new URLs to go to, is done via the mini-buffer, an input line below the status bar.

• Instead of tabs it uses Emacs’ concept of buffers. So no tab bar clutter and though easy access to all currently open pages.

• It has no buttons, menu-bar or such. And except the status bar and mini-buffer, it uses the whole size of the window for the displayed web page. This is the main reason why I prefer Conkeror on the 7” EeePC: I don’t want to waste any pixels for buttons or menu bars and still have a fully functional web browser.

• It of course has Emacs alike keybindings (with a slight touch of Lynx). While this may seem awkward for the vi world (Hey, they have the vimperator^*, also in Debian since a few days!), as an Emacs user you just have to remember that you web browser now also expects to be treated like an Emacs. It just works:

  C-x C-c

  Exit Emacs -eh- Conkeror

  C-x C-f

  Open File -eh- web page in new buffer

  C-x C-b

  Change to some other tab -eh- buffer

  C-x C-v

  Replace web page in this buffer and use the current URL as start for entering the new one

  C-x 5 2

  Open new frame -eh- window

  C-x 5 0

  Close current frame -eh- window

  C-x k

  Close tab, -eh- kill buffer

  C-h i

  Documentation

  C-s

  Incremental search forward

  C-r

  Incremental search backward

  C-g

  Stop

  l

  Go back (Think info-mode)

  g

  Go to (Open web page in this buffer)

  (Hehe, I like the faces of vi users having read these keybindings and now wondering how to remember them. SCNR. Well, sometimes vi key bindings are a mystery to me, too. :-)

  There are of course many more and nearly all are the same as in Emacs, even the universal argument C-u and the M-x command-line are there. E.g. C-u g lets you open a web page in a new buffer, too.

• Conkeror also has very promising concept for following and copying links with the keyboard only. Opera is very inefficient here since you have to jump from link to link to get to the one you want. In Conkeror you just press f for following or c for copying links and then all links on the currently shown part of the page show a small number attached to it. Then you just enter the number (and additionally press enter if the number is ambigous) and the link is either opened or copied to the clipboard.

  A funny anecdote about how this concept grew over the time: Early versions of Conkeror (back in the days when it just was a Firefox externsion as vimperator) numbered all links on the page, not only the visible ones. On large pages with many links or buttons (e.g. my blog ;-), this took minutes to complete. The idea to just number the visible links is so simple and important – but someone first needed to have it. :-)

Footnotes

*) I just noticed that there is now also muttator, making Thunderbird look and behave like vim (and probably also mutt), too. Wonder into which e-mail client the Emacs community will convert Thunderbird. GNUS? RMAIL? VM? Wanderslust? What will it be called? Wunderbird? Thunderslust? (SCNRE ;-)

Perfect Team: autossh and GNU Screen //at 01:06 //by abe

SSH is definitely one of my most often used tools, not only for system administration at work but also on the road with my netbook, an EeePC 701 running Debian Sid.

On the road, it often happens that I have a flaky WLAN or UMTS connection, so I often have to kill (via <Enter>~.) and reconnect my SSH session due to a changed IP address or so.

First step against problems arising from using SSH over unreliable network connections is of course GNU Screen. Second step is use SSH keys and ssh-agent to not needing to type the password on every reconnect.

But it’s still very annoying to kill the SSH connection and call ssh again manually. For luck there is autossh, a wrapper around SSH which regularily checks via two tunnels connect to each other on the remote side if the connection is still alive, and if not, it kills the ssh and starts a new one with the same parameters (i.e. tunnels, port forwardings, commands to call, etc.).

It’s quite obvious that this is perfect to be combined with screen’s -R and -d options (Reattach if a detached screen is around, else start a new screen; detach a currently attached screen), so I found myself very often typing (or fetching it from the commandline history :-):

autossh -t sym.noone.org 'screen -Rd'

-t is necessary to allocate a terminal device on the remote machine which is not done by default if you directly call a command via ssh.

In comparision to OpenSSH, autossh needs the single quotes, because otherwise it would parse -Rd as options to parse to ssh and bail out. That’s not a real problem, but when you’re used to just type ssh -t sym.noone.org screen -Rd without any quotes, you’ll run into this then and when.

Update, 25-May-2010, 14:55: As Carsten Hey points out, autossh also supports the -- option to declare that all following options and parameters must be passed to ssh itself. (End of Update)

Typing that often and mistyping it then and when cries for an shell alias or an shell function. So I came up with the following shell function:

asc() {
    autossh -x -a -t "$@" 'screen -RdU'
}

I used a function instead of an alias in case of autossh will in future regard all parameters given after the command as part of the command as ssh does.

The additional options -x and -a disable X and SSH Agent forwarding which both don’t work if you reattach to an already running screen.

And if you’re using Zsh as I do, you can even add some more format string magic to set the window title more or less to the expanded alias, eh, function:

function asc() {
    # Set the title to something more obvious, e.g. the expanded
    # alias, eh, function
    print -Pn "\e]0;%n@%m: autossh -t $* 'screen -RdU'\a";
    autossh -x -a -t "$@" 'screen -RdU'
}
compdef asc=ssh

Update, 25-May-2010, 14:59: As Hauke points out in a comment, Zsh users should also declare that asc should have the same tab completion as ssh itself. The example above has been updated accordingly. (End of Update)

In the meantime on the EeePC I use asc on the commandline more often than ssh itself. And I nearly no more type autossh. (The most common exception here is autossh hostname tail -F /path/to/some/logfile.)

Using that function you can also add common ssh options for tunneling, etc. — I use it most often like this:

asc -D 1080 sym.noone.org

This opens a SOCKS proxy on localhost, port 1080 and that way I can surf via the host I’m connecting to by SSH.

There’s one small drawback though: You didn’t expect that I can just invent some new three letter command without a namespace clash, did you? There is a free game called Advanced Strategic Command whose binary (and Debian package) is named asc, too. If you have that game installed, you can always call it using its full path, e.g. /usr/games/asc on Debian.

P.S.: My whole grml based .zshrc is also available via git at git.noone.org as well as on github.

ratpoison and focus follows mouse //at 00:22 //by abe

I use ratpoison as window manager on my ASUS EeePC netbook “nemo” for more than two years now. But although I’m very happy with ratpoison in the EeePC, there are two feature wishes which have been refused by upstream: One is more flexibel window name matching for the unmanage command. The other one is “focus follows mouse” between ratpoison frames.

Well, I always guessed that it was possible, but it took until now to find outhow to implement “focus follows mouse” for ratpoison.

There’s an ancient but still useful tool called Not a Window Manager (nawm) which is a small awk-like interpreter offering mostly window handling functions.

The following .nawmrc implements “focus follows mouse” in nawm:

window newwin;  # stores window to raise
window lastwin; # stores previous window to prevent race conditions
leave {
    lastwin = currentwindow;
}
enter {
    newwin = pointerwindow();
    if (name(newwin) != "" && newwin != lastwin) {
        raise newwin;
        sync;
    }
}

The leave hook is necessary to prevent flapping between two windows if switched between them via ratpoison’s commands.

I also had to add the following hook to my .ratpoisonrc to work around some cases where ratpoison’s own window switching didn’t work anymore. Only happened with more than one frame — with one frame banishing the mouse cursor was annoying, so I filtered that case:

addhook switchwin exec if [ `ratpoison -c fdump|fgrep -o frame|wc -l` -gt 1 ]; then ratpoison -c banish; fi

Unfortunately nawm has been removed from Debian Sid about a year ago due to being buggy and orphaned. There was not upstream development for seven years or so either.

So for the moment you can get nawm either from Debian Lenny or from snapshot.debian.org.

But I had to fix a segfault in nawm when calling name() on a window without name to be able to use it at all, so you will probably have to rebuild it anyway with the following patch:

diff -u nawm-0.0.20030130/builtins.c nawm-0.0.20030130-patched/builtins.c
--- nawm-0.0.20030130/builtins.c        2010-10-25 06:00:02.000000000 +0200
+++ nawm-0.0.20030130-patched/builtins.c        2010-10-25 04:15:25.000000000 +0200
@@ -546,8 +546,12 @@
     *name = gcstrdup("");
   else
     {
-      *name = gcstrdup((char *)nm);
-      XFree(nm);
+      if ((char *)nm) {
+        *name = gcstrdup((char *)nm);
+        XFree(nm);
+      } else {
+        *name = gcstrdup("");
+      }
     }
 }

And yes, I’m thinking about adopting and reintroducing the nawm package into Debian Sid.

But I’d prefer if anyone could give me a hint how to do this with more current and still maintained tools (or a patch against ratpoison :-). I looked into suckless-tools, but I haven’t found anything in there which provides hooks on X events. And the Perl module Tk seems to be able to set X event hooks, but only within the application being written itself.

Still happy with the ASUS EeePC 701 //at 16:02 //by abe

Recently Eric asked on the LUG Vorarlberg mailing list about netbook experience. I wrote a lengthy reply summarizing my experiences with the ASUS EeePC 701. And I thought this is something I probably should share with more people than only one LUG:

I ordered an ASUS EeePC 701 (4G) with US keyboard layout at digitec in Spring 2008, got it approximately one month later and posted a first resumé after one month in my blog.

I’m still very happy with the EeePC 701, despite two commonly mentioned drawbacks (the small screen resolution and the small SSD – which I both don’t see as real problems) and some other minor issues.

What matters

• Very robust and compact case. And thanks to a small fan being the only moving part inside, the EeePC 701 is also very robust against mobile use.
• Very pleasing always-in-my-daypack size (despite the 7" screen it’s the typical 9" netbook size) and easily held with one hand.
• Black. No glossy display. Neither clear varnish nor piano laquer. Short: No bath room tile. Textured surface, small scratches don’t stick out and don’t matter.
• Debian (previously Lenny, now Sid) runs fine on it, even the webcam works out-of-the-box.
• Despite all those neat features, it was fscking cheap at that time. And it was available without Windows.

Nice to have

• There’s power on the USB sockets even if the EeePC is turned off but the power supply is plugged in.
• The speakers are impressingly good and loud for their size. (But my demands with regards to audio are probably not too high, so audiophiles shouldn’t run to ebay because of this. ;-)
• It has three external USB sockets.

What doesn’t matter

• The small 7" 800×480 screen: I like small fonts and do most things inside a terminal anyway. And even with 800×480, those terminals are still much bigger than 80×25 characters. Only some applications and webpages have no heart for small screens.
• The small disk size: Quite a lot of programs fit on 4 GB of disk space. Additionally I use tmpfs a lot. And music and video files are either on a external 500 GB Western Digital 2.5" “My Passport” disk (which I need quite seldomly) or much more come via sshfs and IPv6 from my home server anyway. :-)
• The small keyboard: I just don’t have any problems with the size or layout (right shift right of the cursor up key, etc.) of the keyboard. Well, maybe except that any standard sized keyboard feels extremely large after having used the EeePC exclusively for some weeks. ;-)
• The to 630 MHz underclocked 900 MHz Intel Celeron: It’s enough for most of the things I do with the EeePC. Also the original 512 MB RAM are somehow ok, but for using tmpfs, but no swap space at all, 1 GB or 2 GB are surely the better choice.
• A battery runtime of 2.5h to 3h is fine for me.

What’s not so nice

• The “n” key needs to be pressed slighty stronger than other keys, otherwise no “n” appears. So if one of my texts in average misses more “n” than other letters, I typed it on the EeePC. ;-)
• Home, End, Page-Up, and Page-Down need the Fn key. This means that these keys can only be used with two hands (or one very big hand and I have quite small hands). This is usually no problem and you get used to it. It’s just annoying if you hold the EeePC with one hand and try to type with the other.
• What looks like a single mouse button is a seesaw and therefore two mouse buttons below one button. This makes it quite hard to press both at the same time, e.g. for emulating a middle mouse button press. It usually works in about half of all cases I tried it. My solution was to bind some key combination to emulate a middle mouse button in my window manager, ratpoison:

  bind y ratclick 2

  And that mouse button bar already fell off two times.
• The battery reports only in 10% steps, and reporting in percentage instead of mAh is an ACPI standard violation because reporting in percentage is only allowed for non-rechargable batteries. It also doesn’t report any charging and discharging rates. But in the meanwhile nearly all battery meter can cope with these hardware bugs. This was quite a problem in the early days.
• Now, after approximately 1.5 years, the battery slowly fritzes: When charging there are often only seconds between 10% and 40%. Rigorously using up all power of the battery helped a little bit. Looks like some kind of memory effect althought the battery is labeled Li-Ion and not Ni-MH and Li-Ion batteries are said to have no memory effect.
• The SD card reader only works fine if you once completed the setup of the original firmware or set the corresponding BIOS switch appropriately. No idea why.

Similar models

Technically, most of this also counts for the EeePC 900SD (not 901) which only differs in screen, resolution and disk size as well as CPU, but not on the the case. So same size, same robustness, same battery, same mainboard, bigger screen, resolution, disk and faster CPU. (The 901 has a different CPU, a different battery, and a different, glossy and partially chromed case.) See Wikipedia for the technical specifications of all EeePC models.

ASUS’ only big FAILure

Stopping to sell most EeePCs with Linux and cowardly teaming up with Microsoft after having shown big courage to come out with a Linux only netbook. Well, you probably already know, but it’s better without Windows…

So basically you no more get these really neat netbooks from ASUS anymore and you get nearly no netbooks with Linux from ASUS in the stores anymore. It’s a shame.

Would I buy it again?

Sure.

Well, maybe I would also buy the 900SD, 900AX (replacing the harddisk with an SSD) or 702 (8G) instead of the 701, but basically they’re very similar. See Wikipedia for the differences between these EeePC models. And of course I still prefer the versions without Windows.

But despite the low price, the EeePC 701 is surprisingly robust and still works as on the first day (ok, except battery, the mouse button bar and the “n” key ;-), so I recently bought a second power supply (only white ones were available *grrrr*) and ordered a bigger third party battery plus an adapter to load the battery directly from the (second) power supply without EeePC inbetween.

What desktop do I use on the EeePC?

None.

I use ratpoison as window manager, uxterm, urxvt, and yeahconsole as terminal emulators (running zsh with grml based .zshrc even as root’s login shell :-), wicd-curses as network manager and xmobar (previously dzen2) with i3status as text-only panel. Installed editors are GNU Emacs 23, GNU Zile and nvi. (No vim. :-)

And of course a netbook wouldn’t be a netbook if it wouldn’t have a lot of network applications installed. For me the most important ones are: ssh, scp, autossh, sshfs, miredo, conkeror, git, hg, and rsync.

/var/cache/apt/ on tmpfs //at 16:44 //by abe

My ASUS EeePC 701 (4G) “nemo” running Debian Sid has a 4 GB SSD as main disk, which is on the one hand quite full (mostly with software I use, but also local working copies of software I work on) and on the other hand an SSD, so I always try to reduce the amount of write to disk without losing convenience. Similar issues have systems which run off a CF or SD card or maybe even an USB stick.

Since I ordered a 2 GB RAM bar together with the EeePC, I not bound to the 512 MB which it had originally. But on the other hand I seldom needed more than 1 GB of RAM. Usually I needed between 400 MB and 1 GB of RAM. So it’s quite obvious to use tmpfs on as many places as possible.

Making /tmp, /var/run and /var/lock tmpfs were the most obvious directories to mount as tmpfs. Especially /var/run on tmpfs brought up a few bugs a while ago (mostly init.d scripts relying on /var/run/$PACKAGENAME/’s existence), but it’s no hassles to use nowadays. Even in Debian Stable such bugs got fixed.

Next target to explore for was /var/cache. According to the FHS, /var/cache is intended for cached data from applications. […] The application must be able to regenerate or restore the data. So it should be safe to put anything under /var/cache on tmpfs.

One directory in there which gets written quite often and with a lot of data on Debian Unstable is /var/cache/apt and its subdirectories, especially /var/cache/apt/archives. If you update your Sid installation daily, all new or updated .debs will be downloaded to /var/cache/apt first.

So I put /var/cache/apt on tmpfs by putting the following line into /etc/fstab:

tmpfs /var/cache/apt tmpfs defaults,noexec,nosuid,nodev,mode=0755 0 0

But despite FHS stating that anything under /var/cache must be reproducible by the application, apt is puking and refusing to work:

!447 Z31 ?0 L1 root@nemo:pts/0 (-zsh) 16:13:10 [~] # apt-get update
E: Archive directory /var/cache/apt/archives/partial is missing.
!448 Z32 ?100 L1 root@nemo:pts/0 (-zsh) 16:13:17 [~] # 

If you create /var/cache/apt/archives/partial, it will also argue about /var/cache/apt/partial.

Of course the workaround is simple: Just put mkdir -p /var/cache/apt/partial /var/cache/apt/archives/partial in /etc/rc.local.

But nevertheless, this is a bug in apt – which already has been reported by madduck earlier this year (#523920). Unfortunately the APT maintainers have not yet even commented on this FHS violation and therefore also a Debian Policy (Section 9.1.1) violation.

One more thought about /var/cache/apt vs only /var/cache/apt/archives: apt-file also caches its data under /var/cache/apt. So if you want to use apt-file after a reboot and have /var/cache/apt mounted as tmpfs, you have to run apt-file update first and it will download all Contents files (can be dozens of megabytes) and not only the differences to previously downloaded Contents files.

So if you use apt-file a lot, you probably go better with making only /var/cache/apt/archives tmpfs and not whole /var/cache/apt.

How I use my virtual desktops //at 00:29 //by abe

Many months ago I stumbled upon this German written meme about how users use their virtual desktops. I use virtual desktops since my very early Unix times (tvtwm on Sun Sparc SLC/ELC/IPX with greyscale screens running SunOS 4.x), so in the meantime I use them nearly everywhere the same way.

Short Summary

3x5, no overlapping windows, either tiling or fullscreen, keyboard navigation, xterms, yeahconsole, FVWM, panel for systray.

Window Manager of Choice

My window manager of choice is FVWM since more than a decade. I tried others like Sawfish, Metacity and Compiz, but I couldn’t get them behave like the FVWM I got used to, so I always came back.

Since I hate overlapping windows, I use FVWM a lot like a tiling window manager. FVWM has this nice function to maximize windows so that they occupy as much space as available, but do not overlap other windows. This function was also often missing when I tried other window managers. I though do not want to use real tiling window managers since I have a few sticky windows around (e.g. the panner with the virtual desktops and xosview) and they shouldn’t be overlapped either.

Virtual Desktops

Switching between virtual desktops is done with the keyboard only – with Ctrl-Shift as modifier and the cursor keys. The cursor keys are usually pressed with thumb, ring and small finger of the right hand. Which hand presses Ctrl and Shift depend on the situation and keyboard layout, but it’s usually either ring and small finger of the left hand, or pointer and middle finger of the right hand. So I’m able to switch the virtual desktop with only one hand.

I have always three rows of virtual desktops and usually four or five columns.

The top row is usually occupied with xterms. It’s my work space. The top left workspace usually contains at least one xterms with a shell and one with mutt, my favourite e-mail client since nearly a decade. At home the second left virtual desktop in the top row usually contains a full-screen Liferea (my preferred feed reader) while at work it contains the GNU Emacs main window besides two xterms. Emacs and the emacs server are automatically started at login.

This also means that I switch the virtual desktops when I switch between mutt and Emacs for typing the content of an e-mail. Did this already during my studies. (At home mutt runs inside a screen, so there I just switch the virtual terminal with Ctrl-A Ctrl-A instead of the virtual desktop. Not that big difference ;-)

The other virtual desktops of the the top row get filled with xterms as needed. Usually one virtual desktop per task.

The middle row is for web browsers. One full screen browser (usually Conkeror or Opera) per virtual desktop, often opened with many tabs (tabs in Opera, buffers in Conkeror) related to the task I’m accomplishing in the xterms in the virtual deskop directly above.

The third row usually contains root shells for maintenance tasks, either permanently open ones on machines I need an administrate often (e.g. daily updates of Debian testing or Debian unstable machines), or for temporary mass administration (Linux workstations on the job, all Xen DomUs of one Xen server, etc.) using pconsole.

yeahconsole

Additionally I have a sticky yeahconsole running, an xterm which slides down from the top like the console in Quake. (It’s the only overlapping thing I use. :-) My yeahconsole can be activated on every virtual desktop by pressing Ctrl-Alt-Z (with QWERTY layout, Ctrl-Alt-Y with QWERTZ layout). It’s the terminal for those one-line jobs then and when, e.g. calling ccal, translate, wget or clive.

Changes over time

Of course the desktop usage changes from time to time:

At work I have more than one monitor, so in the meanwhile the second row with the web browsers “moved” to the second screen – with independent virtual desktops (multiple X servers, no Xinerama). The second row on the main screen at work is now used the same way as the third row with a slight preference for the permanently open shells while the third row is more used for mass administration with pconsole.

At home I used XMMS respective Audacious for a long time (my FVWM panner and xosview are exactly as wide as WinAmp2/XMMS/Audacious, guess why:-) which usually was sticky the same way as the panner and xosview are. But when I started using last.fm recently, I moved to Rhythmbox (after testing some other music players like e.g. Amarok) which I use in fullscreen as I do with web browsers and the feed reader. So it occupies a complete virtual desktop, usually the second one in the middle row – below the feed reader because I don’t need a corresponding web browser for the feed reader. (Just found out that there is a last.fm player for text-mode, so maybe that will change again. :-)

Another thing which changed my virtual desktop usage was the switch from a classical tabbed web browser (Galeon, Kazehakase, Opera) to the buffer oriented Conkeror. With a tabbed web browser I have either no overview over all open tabs (one row tab bar or truncated tab menu) or they occupy too much space of the browser window. That was another reason for more than one browser window and therefore more than one virtual desktop with fullscreen web browser windows. With Conkeror tabs are optional (and not even enabled by default), Conkeror uses buffer like Emacs and if you want to switch to another buffer, you press C-x b and then start typing parts of the buffer’s name (e.g. parts of the URL or the web page title) to narrow down the list of buffers until only one is left or until you have spotted the wanted buffer in the list and choose it with the cursor keys. So the need for more than one browser window is gone.

For a long time I didn’t need any task/menu/start/whatever bar on my desktop. But since neither NetworkManager nor wicd have a comand-line interface (yet) and bluetooth seems also easier handled from the system tray my laptops also use either gnome-panel (big screen, long sessions with FVWM) or lxpanel (formerly used trayer; use it on small screen, short sessions with ratpoison or matchbox) on my laptops. It’s sticky and always visible. (No overlapping, remember? ;-)

The panel is usually at the bottom on the screen as by default with Windows or KDE, not at top as with GNOME and MacOS. Only on the OpenMoko, I have the panel at the top to be close to what I’m used from Nokia mobile phones.

Things I tried …

… but didn’t survive in my setup:

• Desktop icons – nearly always covered if you use a tiling window manager. (I though use root window menus – mostly for starting applications later occupying that space where I clicked. ;-)
• A button to minimize all windows. Only sissies without virtual deskops need that. ;-)
• Automatically scrolling logfile content on the desktop (root-tail, root-portal, etc) – the space was too precious to not use it for xterms or web browsers. ;-)

Systems without Virtual Desktops

Anyway, there are systems where I don’t use virtual desktops at all. On systems with a screen resolution so small that there’s not enough space for two non-overlapping, fixed font 80x25 xterms on the screen (e.g. on my MicroClient with 8” touch screen, the 7” EeePC or the OpenMoko) I do not use virtual desktops at all. On such systems I use all applications in fullscreen, so switching between applications is like switching virtual desktops anyway. My window managers of choice for such systems are ratpoison for systems with keyboard and matchbox for system without keyboard. With ratpoison you treat windows like terminals in GNU screen, so there are no new keybindings to learn if you’re already used to screen (which I use nearly daily since more than a decade).