A view from the hill

When I upgraded lately, my old fbpanel configuration was broken. I basically stumbled over Debian bug #288594, my old configuration as well as the system default pointed to a no longer existing /etc/fbpanel/menu file. So, my fbpanel no longer showed a menu. Sure enough, my WindowMaker has its own menu, so it was not much of a hassle. The broken menu entry (I just edited out the reference in my .fbpanel/default) annoyed me nethertheless, so I gtfn[*] today and found the missing info: in order to include the system menu, you just have to include a systemmenu entry. My menu referencing section now looks like this and I have a working menu again.

Plugin {
    type = menu
    config {
	image = /usr/share/icons/gnome/16x16/places/gnome-main-menu.png
        systemmenu {
        }

	separator {
	}
        
        item {
            name = terminal
            image = /usr/share/fbpanel/images/gnome_terminal.svg
            action = /usr/bin/x-terminal-emulator
        }

    }
}

ObTitle: The Mighty Mighty Bosstones, "Let's face it"

[*] gtfn: googled the friendly net

So I finally bought a new desktop computer in order to replace my old and loud one. The new one should fulfill two more or less conflicting requirements: it should be fast and quiet. "Fast" mainly refers to cpu and disk speed, for the gpu I only had the minimal requirement that it would be possible to see videos (non-HD) and show some basic 3d effects. I left most of the details to a local dealer, but I verified that the components would work with Linux, which actually means I only needed to ensure that the board, an Asus P5Q-VM, which is based on the intel G45 chipset, would work. A little digging showed that there might be some problems with X11 if the distribution didn't provide new enough drivers but I found enough success reports to be optimistic.

Well, I finally got the new workstation. It's an impressive black box with a Silentmaxx ST-11 tower which is really very silent -- it's so quiet that they provide large blue leds on the box to that you have a reminder that the system is on -- this was one of the details I wasn't aware of when ordering the system. I started installing Debian Lenny on the box, as I always followed the rule that buying a new computer is a good point in time to install from scratch and get rid of old software cruft. So I did nothing to carry over my old installation which I had regularly updated at least since Sarge. That was actually a quite pleasant way for me as it was the first time I've got to see the "new" graphical installer. There were some minor obstacles, though. First, this time I wanted to have both an LVM setup and encryption running. I was pleasantly suprised to see the installer providing an option for such a setup, but quite less suprised to see it fail with a segmentation fault during wiping the (500GB sata) disk. Fortunately, the manual partitioning option provided enough easy guidelines to quickly rebuild the setup of the automated partitioning scheme while allowing to leave out the unneeded step to clean the disk, so this was not a big issue. Another point that I think is interesting is that hibernation worked out of the box even with the LVM/crypto setup -- I had thought that hibernate or better said, suspend to disk, would requre the swap to be unencrypted but apparently I was wrong. Very nice.

I went on to install a very minimal system without any desktop setup. I went away from Gnome back to WindowMaker some time ago, but I had seen the LXDE as an install option which is a much smaller "desktop environment" with OpenBox2 as the central window manager. Now, compare the list of packages for Gnome with the list of list of packages for lxde -- that's quite a difference. But soon enough I realized how difficult it has become to avoid the larger environments. There are quite a lot of applications which I am used to using right now (having installed Gnome on my older desktop as well as running Ubuntu with Gnome on several other installations) which depend on Gnome. Evolution, for instance, which I privately mainly use as a glorified calender, depends on Gnome just as Rhythmbox does. This may hardly come as a suprise, but I've simpy not thought about it in advance. So I'm now looking for replacements for some applications.

Of course, in order to run any desktop environment you have to have a running X11 installation. This failed at first: I had connected my 19"-TFT (an old Benq one) via VGA to the on-board graphic chipset from the G45, which resulted in the monitor proclaiming to get out-of sync timings. After replacing the VGA connection with a DVI one, the vesa driver provided a working X11 setup. However, I soon discovered that I would not want to stick with the vesa setup, as for instance there is no xvideo extension. Unfortunately, the xserver-xorg-video-intel package in Lenny is version 2.3.2, which is too old to support the G45, so even though I specified the intel driver in the device section of /etc/X11/xorg.conf, I didn't get a usable screen. However, packages for Xorg in version 2.8 had entered unstable some time ago -- as I had quickly installed kernel 2.6.30 from backports.org and the packages doesn't have to broad version requirements on other packages, this seemed like a viable option. So I know have an up and running intel driver for X11, but it remains to be seen how stable it really is over time. And, of course, I've got to keep an eye on security updates.

ObTitle: Björk, "Post", (more info)

Some time ago I updated my trusty old workstation from Debian Etch to Lenny. As always, there were some minor glitches, not necessarily all of them were due to Lenny itself, though. Here's a rough list.

One really annoying issue was that my trusty old Matrox G400 suddenly behaved unbelievably slow under X11. I could nearly watch the pixels going by. I could tell by the X server log that some things had changed (like Xrandr now running) but I couldn't tell what was responsible for the problem. Explicitly setting the option "NoAccel" to "false" and "NoHal" to "true" (I have a single screen setup) finally settled the problem. I also tried "UseFBDev" "true" but this only works for me with a Depth of 24, which in turn screws my screen whenever I switch to the console (for instance on hibernate), so I'm back to not using the framebuffer device (and a depth of 16).

The Postgres update didn't work for me. I guess that this was mainly due to a lack of disc space. It took me some time to figure out that no default cluster had been created, which was the reason that the manual restore of the DB backup I had made failed.

I took the chance and finally updated to Iceweasel (firefox) 3. Some of my extensions were lost this way, but I managed to replace or update nearly all of them. Only Hit-a-Hint required a manual intervention directly in the install.rdf of the extension.

One typical annoyance of updates is that user settings are often not updated. This time I experienced that mainly with FBpanel in which all icon settings were broken.

Of course, the update broke some of my proprietary programs because of library problems. Korrektor, BMM, all are history now. As are some trusty old programs I still used, for instance xmms is gone, too. I used to stick with xmms mainly due to the Windowmaker mini app wmusic which allowed control of xmms via the dock, but as I've been using Rhythmbox for quite a while now, which has a NETWM compliant panel control, I could finally let it go.

ObTitle: Amy Whinehouse, "Back to black"

I can't believe it: Debian really misses out on it's own records. Lenny was released this weekend although the usual two years since the previous release are not over yet. Congratulations. Now, I just have to go and check how old the packages of interest to me are out of the box this time ...

Debian just published an update to their stable distribution etch dubbed etch-and-a-half. The big news here for everyone not accustomed with Debians release cycle anyway is that it's the first time that it's not only a point release that fixes security issues but it's an update to the stable release that gasp adds support for new hardware, too. It even brings important fixes for some applications.

First of all, that's a tremendously good step in the right direction. In the past I've been bitten more than once by the long release cycle of Debian, outlasting all care taking of hardware compatibility. It's the primary reason that the only machine under my direct control running Debian is my rusty private workstation at the moment, all other machines needed newer drivers and hence are installed with Ubuntu. So, if Debian finally realizes that it has to change something to support newer hardware that's more than welcome.

However, it's not really etch-and-a-half. It's not much more than a new kernel which I would compile regularly from kernel.org myself anyway. Admittedly, there are also two new xservers (for nv and intel), but that's still not very helpful for people with newer ati hardware, for instance. But I'm a developer and much more than any hardware hassle I'm much more bitten by really outdated development tools. I've written only one blog entry about the issue, but it's a topic that most developers could write books about -- or maybe not, most of them probably just compile newer versions as needed and are done with the issue. This looks like the easy way out but it doesn't really solve the issue: if you've got to deploy your software you'll need to ensure that what you need is there. But using newer versions of base libraries forces you to deploy them yourself, which also means that you got a problem whenever a security issue will be found in those libraries. On the contrary, with system libraries you don't need any manual deployment of libraries you're only using and you can hope to participate of all system updates. So, in my eyes that's clearly a big advantage for using system libraries. But with Debian (and etch-and-a-half doesn't change this) you're stuck with older libraries which a) might lack long wanted functionality and b) are incompatible with versions from other vendors, which is a pain if you need to deploy on different platforms. Now, granted that the latter problem is not only tied to the age of libraries, but it would be a lot smaller if Debians general release cycle wouldn't be that long. I know of software vendors who have thus decided to develop for Ubuntu but not for Debian, in order to minimize portability issues due to library/functionality mismatches between platforms. To me, that looks like quite high a price to pay.

I've tried Compiz with Metacity again and switch it off after a day -- again. I'm not willing to do without working software suspend just for some graphical whizz. I've been using Metacity for, I think nearly two years now, on my work computers and have somehow accomodated to it's various glitches (for instance the unusable keyboard settings). On my trusty home workstation, however, I've stuck with WindowMaker, which I think I've been using roughly since 1997 (I can't remember the version number, but it was fairly low). Unfortunately, development seems to have stopped -- since quite some time there is no sign of activity on the webpage and the mailing list archive is dead.

Yesterday, out of a current frustration about Metacity, I installed a naked current version of WindowMaker on one of my machines, under Ubuntu 8.04 (don't try to make WindowMaker work under Gnome: While WindowMaker does "work" under Gnome, it is really crippled. For instance, the keyboard setting know nothing about WindowMaker but still override your keyboard settings via, say, WPrefs.). Nearly everything worked as expected, but there were two glitches: the menu didn't reflect the installed software. Having customized the thing under my Debian system, I knew that this was supposed to work with the update-menu script, but that was missing. Some web-searching revealed that for some reason or other Ubuntu no longer installs the menu(-xdg) package. The other glitch was a very old complaint: That WindowMaker doesn't ship with a virtual desktop switcher or pager. You don't need to tell me about the different philosophy of WindowMaker, I know all about it. However, I've been using Fvwm and OpenLook (OLVWM) too long.

I could use gnome-panel (which I've done before in the past), but of course that brings me those two panels that make sense for Metacity and besides it also means that I would still depend on gnome. I've did quite a bit of looking around to find out what all the cool Fluxbox, Openbox etc. users are using and finally found fbpanel (the trick was to search for "taskbar" instead of "pager"). So, finally thanks to netwm support (which I think is in WindowMaker since 0.90), the one missing bit from WindowMaker is finally there without Gnome. Oh my, I'm finding this out really late.

Dell is selling Ubuntu equipped systems since about a year now and seems to be quite happy with it. Whatever that effectively means, at least I can tell that I'm quite happy with Linux on Dell systems, too.

Through the last five years, I've been using Linux on a number of Dell systems. Under my personal control there have been three laptops (Dell C610, D610 and a Latitude 640) and a desktop (Optiplex 755), on which I have been running Debian Sarge, Ubuntu Dapper, Feisty and now Hardy. We also had several Dell servers at work running more or less smoothly with Debian (sarge, etch). Using Linux wasn't always without problems: I had trouble with built-in modems, PCMCIA ISDN cards and acpi/hibernation. For example, on my private Latitude 640, I have trouble suspending at all, because of the ipw3945 driver for the wlan. But the important thing to note is that basically all problems were really small and never of a size requiring me to use some other OS in the first place.

The only real issue is not with Dell per se, but more with my favourite OS, Debian: over the years, and especially with the ever-lasting sarge release, getting Debian to run on a recent system got more and more difficult. That's the main reason why I've been using Ubuntu on all recent hardware I had contact with: it's more or less (more so than less) a Debian system but does run on modern hardware. Main issues here were graphics adapters, sata/scsi hostadapters and network/wifi cards, or to put it otherwise: too old kernels, too old X.org. Both problem sources can simply be solved by using a recent version of Ubuntu. Sorry, Debian, but your release cycle is just too long to be acceptable. Granted, all these problems are mostly an issue when installing a new system, but it's not always possible to plug in some old disc with a working version of Linux.

Like I mentioned in a previous post (here), I hadn't looked closer at those modern distributed revision control systems like Git, Darcs or Mercurial. This was mainly due to two facts: As I'm currently neither involved in any major open source project which uses these systems nor in a project at work which requires the facilities offered by such systems, and as there was no easy access for them in XEmacs, the more traditional systems like Subversion, CVS and RCS are fine for me. However, there was this nag that I might miss something and as revision systems always have been somewhat of a pet peeve of mine, I eventually spend some time reading up more on them. I've read quite a lot of discussions on the web, and gathered that mercurial might be worth a closer look, as it claims to be quite easy to handle, comparably well documented and quite fast. And then finally I've read on xemacs-beta that the new vc package (in Pre-Release) would support mercurial as well.

Well, that's where I am now: I have several pieces of code lying around which I sometimes develop on my main machine and sometimes on my laptop when moving around. This is the scenario where a server-based approach to revision control is not what you want: you won't be able to access your server while you're on the road and hence you can't commit. Now, with RCS that's not a problem, as there is no server involved. But of course, since RCS is a file-system local revision system, syncing is a major problem and you have to go to great pains to ensure you don't overwrite changes you made locally in between syncs. I hope that a distributed version control system like mercurial will solve the problem, as I no longer have to decide which version is the current head version, instead cherry-picking change sets at will.

But of course, for this to happen, I have to convert my RCS repositories to Mercurial. This doesn't seem to be a common problem: there are a lot of tools for conversion from CVS or Subversion (see Mercurial Wiki, e.g. Tailor for instance), but not from RCS. I ended up following the instructions given in the TWiki Mercurial Contribution page. I have some minor corrections, though, so here we go:

-1. (Step 6 in TWiki docs) Ensure all your files are checked in RCS. I won't copy the advice from the TWiki page here, because I believe in meaningful commit messages and would urge you to do a manual check.

0. You'll need cvs20hg and rcsparse which you will find here. You'll need to have Python development libraries installed, i.e. Python.h. For Debian systems, this is in package python-dev. Installation is as simple as two "./setup install" as root which will install the relevant libraries and Python scripts.

1. Create a new directory for your new mercurial repository (named REPO-HG, replace that name):

    mkdir REPO-HG

2. Initialize the repository:

   hg init REPO-HG

3. (Step 4 in the TWiki document) Create a new copy of your old RCS repository (named REPO here, replace that with the name containing your old RCS files), add a CVSROOT and a config file (mistake one in the TWiki docs: As with all CVS data, the "config" file needs to go to CVSROOT, not to CVSROOT/..). Of course, if you're no longer interested in your old data, you may omit the initial copy.

    mkdir tmp
    cp -ar REPO tmp/REPO-old
    mkdir tmp/CVSROOT
    touch tmp/CVSROOT/config

4. Inside your directory with the old RCS data, move everything out of the RCS subdirectories
(mistake two in the TWiki docs: the double-quotes need to go before the asterix):

   find tmp/REPO-old -type d -name RCS -prune | while read r; do mv -i "$r"/* "$r/.."; rmdir "$r"; done

5. Run cvs20hg to copy your old repository to mercurial. If you don't follow the directory scheme shown below, you'll end up with your new mercurial repository missing the initial letter of the name of all top-level files and directories.

   cvs20hg tmp/REPO-old `basename tmp/REPO-old` REPO-HG

6. Check that everything looks like you would expect:

   cd REPO-HG
   hg log

7. If you had files in your old directory not under version control that you'll like to keep, copy them over. This might be a good time to think about whether they are worth having them under revision control. Afterwards throw away any old directory you no longer need (i.e., your original REPO, tmp/*).