The Fugue

Openbox 3 is a pretty nifty window manager. What I like about it is that it is simple, has a powerful but simple configuration (even if it is XML), ICCCM and EWMH compliant, and works well in Gnome.

Now that I can dual-boot my iBook without the bother of a USB wireless card, I took a few minutes to set up my desktop environment. I used to periodically spend way too much time doing this. I was always on a quest for the best window manager and desktop systems, and I mostly steered clear of Gnome and KDE. Maybe I'm getting boring, but my list of must-haves for window managers has shrunk recently (maybe I should blame OS X). As I'm no longer the primary user on falcon (my wife is), we've been running Gnome there for awhile, and I've gotten used to it for casual usage. I used it for a few months at my last job too, and with a decent window manager (I used FVWM then) it can be quite nice.

So openbox easily displaces metacity with a simple openbox --replace and saving the session. Once you find a theme that doesn't use itsy bitsy fonts it looks fine too (I like the Serenity theme, although the colors are a bit off).

Openbox has the *box feature I love dearly: the dock. gkrellm -w and WindowMaker dockapps I love dearly.

The keybindings and actions are not quite as rich as FVWM, but still quite good. On the other hand it does do MRU-style window switching (e.g. alt-tab), which is a feature mysteriously missing from FVWM.

Here is my ~/.config/openbox/rc.xml file. It matches the OS X keybindings I use most, and some others I made up which have proved quite useful in the past. Here's a preview (mentally replace cmd with meta or win, as appropriate):

• cmd-m to minimize (cmd-h doesn't offer anything more in the Gnome desktop, which is good because vi key emulation always trumps)
• cmd-w to close
• cmd-q to kill (use sparingly, this isn't quite the same as cmd-q in OS X)
• cmd-tab and s-cmd-tab (in addition to the more windows-like alt-tab and s-alt-tab)
• cmd-[hjkl] navigates desktops
• c-cmd-[hjkl] maximizes vertically or horizontally
• s-cmd-[hjkl] moves the window in that direction to the nearest edge. Openbox is the first WM I've seen with this action, and I anticipate that it will be very useful.
• cmd-t to spawn an xterm
• cmd-(up|down) to raise/lower a window

At least on Debian, when I upgraded ruby to 1.8.4 (from 1.8.2) I got the infamous Logger::Format not defined error when starting up instiki. My other rails apps work fine, since I have a recent version of rails installed, but instiki ships with its own rails, which is apparently not new enough. Solution:

cd instiki-0.10.2/vendor
mv rails rails.foo

Voilá, you're now using your own rails install and it works great. This is where we cross our fingers that this doesn't introduce any bugs...

This was not at all obvious in the documentation, so I thought I'd give a real-world confirmation that if you want to specify a tftp server in your dhcpd.conf, this is what you do:

option tftp-server-name "192.168.1.5";

Are you sick of the screensaver kicking in at all the wrong times while watching a video with mplayer in full screen? The mouse doesn't work. The now-not-fullscreen window is all distorted. Sometimes the keyboard is unresponsive until you type the magic incantation (hint: alt-tab). Well I'd had enough.

Just to show how lazy I was, the answer is right in the manpage. You just need to specify the -stop-xscreensaver option. But that's a pain, so what you really want to do is this:

mkdir -p ~/.mplayer
echo "stop-xscreensaver=yes" >> ~/.mplayer/config

I had a hankering to organize my music collection, so I went out on the prowl again. I came across The GodFather and had gotten excited enough to try it out when I realized it was a Windows program. It just goes to show I'm not used to 'shopping' for freeware that is useful to the masses, that I automatically assumed a program with a cool name and icon must be a Linux project. (Although, the icon farm at the bottom should have tipped me off)

I was feeling real adventurous, so I wandered over to the MusicBrainz website to check on the status of Picard. Picard looks like a very cool program, or at least one worth trying out, but I have not yet succeeded in getting it to work, which brings us to the subject.

The problem is dependencies. Picard relies on very specific versions of programs and libraries, most of which are not in Debian. I gather from the INSTALL file that they're not in any distro. Add to that stale instructions and build errors in some of the dependencies (perhaps due to the stale instructions), and you have a real nightmare. Picard is still in development, so I can understand that easy installation is not yet on the radar, but I have to wonder how he expects people to use this program when he is done. Is he expecting development to take long enough that distros will catch up with the dependencies? Will he distribute statically-linked binaries? What about Windows users (his primary target, thus far) that aren't used to command lines and compiling stuff?

I think we simply have different philosophies, and I'm not saying his is wrong. I just was thinking about it and decided to blog it. If I am writing something that I'd like people to use, I go out of my way to minimize dependencies. My rule of thumb is, if it's in Debian testing or stable, I'm pretty safe. (Insert dinosaur jokes here.) This isn't always possible, especially when using less-mainstream languages (e.g. ruby) or libraries (e.g. a lot of audio stuff). It becomes even harder when you want to use cross-platform GUI toolkits, but hopefully that will stabilize soon. But then I see projects like Picard which are living on the bleeding edge and I see that my philosophy is not the same one held by others. I can only hope it works out for them, and that eventually I can run the software they produce.

My MIDI controller (read keyboard) is an M-Audio Radium 61. I love it. Although it has standard MIDI jacks, I use the USB connection for computer use. It works great in linux, with the hotplug scripts from http://usb-midi-fw.sf.net.

That is, it did work great until udev decided to replace hotplug.

I like udev, I really do. I liked devfs too. I like superior technical solutions, so although I had no issues with devfs, I welcomed our new dynamic /dev overlords. But udev seems bent on world domination, and seemingly has no desire to maintain compatibility with previous configurations or older kernels. This would only be annoying, except as a Debian user I also have to deal with Marco d'Itri's attitude if I have a problem. Sigh

udev decided that hotplug was unnecessary and that it should do hotplug's job. That's fine with me, really, but I just wish I had a little more warning and a little bit better instructions on migrating my configuration. There, I've ranted, and the rest of this entry will be technical details on what I did to get my Radium working again.

The problem was simple, if not simple to diagnose: the firmware wasn't getting loaded. The solution was not so simple. There's lots of posts on the web about loading firmware with udev, but most of them give a udev rule that looks like this:

ACTION=="add", SUBSYSTEM=="firmware", RUN+="/sbin/firmware_helper"

There's two assumptions here that will do you no good if you're trying to get your midisport firmware loaded: udev has no reason to think this device has a firmware to be loaded, so SUBSYSTEM=="firwmare" will never be matched. Secondly, /sbin/firmware_helper does not get distributed by Debian (but it wouldn't do you any good if it did).

Luckily we can rely on the good ol' midisport_fw script that we used before, we just need to make a udev rule for it. Here is the rule for my keyboard:

$ cat /etc/udev/rules.d/013_midisport.rules
ACTION=="add", SYSFS{modalias}=="usb:v0763p1014d0001dcFFdscFFdpFFic*isc*ip*", RUN+="/usr/local/sbin/midisport_fw"

Let's dissect this. ACTION=="add" means match when the device is being added. SYSFS{modalias} means match when modalias, found in sysfs, matches. This will likely be unique for your keyboard, or at least for your model of keyboard. You can do cat /sys/bus/usb/devices/1-1/1-1:1.0/modalias to get this. You will need to replace 1-1 with the appropriate identifier in your situation: watch syslog when you plug in the keyboard to discover it. Finally, we tell udev to run the midisport_fw script.

For the udev smarties reading this: if you use idProduct and idVendor instead of (or in addition to) modalias, the script will be called thrice, and only the middle instance is wanted. However, the other two will fail to run and so the net effect is two more lines in syslog complaining about an unknown product.

And finally, if your keyboard is recognized by the ALSA sequencer after loading the firmware, but no MIDI is sent, and you see the following in syslog:

kernel: usb_submit_urb: -28

Try using a different USB physical configuration. e.g. unplug other things from the hub, or bypass the hub, etc. I spent hours fighting udev (so I thought) when in reality the problem was an overloaded USB hub. Incidentally, -28 is -ENOSPC (No space left on device), which is why I chased firmware issues with udev for so long.

And finally, here's what a normal, working plug of my keyboard looks like in syslog:

Nov 21 07:15:20 falcon kernel: usb 1-1: new full speed USB device using uhci_hcd and address 2
Nov 21 07:15:20 falcon /usr/local/sbin/midisport_fw: load /lib/firmware/midisport//MidiSportKS.ihx for 763/1014/1 to /proc/bus/usb/001/002
Nov 21 07:15:25 falcon kernel: usb 1-1: USB disconnect, address 2
Nov 21 07:15:26 falcon kernel: usb 1-1: new full speed USB device using uhci_hcd and address 3
Nov 21 07:15:27 falcon kernel: usbcore: registered new driver snd-usb-audio

A current thread on asterisk-dev reminded me that I hate autoconf/automake almost as much as I hate packages that don't use something like autoconf/automake. Yeah, it's a conundrum.

As a system administrator and user, I like packages that adjust themselves to my environment and my preferences. That is, they detect where libfoo's headers are installed and generate an appropriate makefile, and I can specify --prefix=$HOME or --prefix=/usr/local if I want to, and the package won't pollute my /usr/{bin,lib,include} directories. What I don't like as a user/sysadmin about autoconf is the overly-lengthy ./configure sessions that check a million things that you know are not in this code, only to tell you two minutes later that you don't have dependency X. But that is a minor inconvenience compared to the benefits.

As a developer who once upon a time took the plunge and learned autoconf/automake (and promptly swapped it out), I feel the pain of the hordes of developers screaming for release. It's too complicated, too fragile, too undocumented, too overdocumented (I don't understand that either), and just plain ugly. But it does the job better than anything I've seen, and I've given a cursory look at alternatives. Plus the users demand it because they like the things I listed in the above paragraph.

So what is needed? Why has nothing overthrown the beast? We need something portable with essentially no requirements (because sane developers hate adding unnecessary requirements to their requirements list: each requirement is a class of users that will never try your software). We need something that works at least as well from the sysadmin's viewpoint. We need something simple to understand and use from the developer's standpoint.

Portable with no requirements is a two-edged sword. If you try to write it in shell you will end up with something at least as ugly as autoconf, no matter how good your start. Perl without modules might be a good choice. But I think you could write it in whatever language you want with whatever dependencies you wanted, if only the developers are required to have them. Developers don't mind installing a bunch of stuff for a good tool, but they don't want to have to ask their users to install it to use their program. Observe that this is how autoconf works, the generated configure script is portable shell code. This is good, and it obviously works. So the thing could be written in whatever language (you would choose ruby, of course) and output shell and makefiles.

Works at least as well from a sysadmin's viewpoint means simply that it's easy to tell it where libfoo headers are, and where you want things installed. Get in touch with your inner sysadmin. Familiarize yourself with their pet peeves. Google should help there, or feel free to email me for a piece of my mind.

Simple and easy means several things, but more than anything it means KISS. It should be dead-simple in the common case. It should allow you to make custom tests. Telling the user what to do about failures should be easy. Getting configuration information (e.g. big-endian or little-endian?) should be easy (config.h-like should be fine). If you're going to implement this, you're a developer right? So just think through it and you should be ok. What's that? Autoconf developers are developers too and look how they messed up? Well, remember that they wrote this thing back in the era of sendmail.cf. I forgive them because autoconf is a product of its age.

I just had a battle with OpenLDAP about TLS, and I lost miserably.

If you search google for this error, you will get a lot of hits and almost no intelligent answers:

ldap_start_tls: Connect error (-11)
        additional info: error:14090086:SSL routines:SSL3_GET_SERVER_CERTIFICATE:certificate verify failed

My certificates are perfectly valid certificates, signed by my own CA (not precisely self-signed, but you'd have the same problem with those). OpenLDAP clients apparently default (at least on RHEL, SLES, and Debian) to require that LDAP server certificates be valid, including the "check against my local copy of the CA cert" step.

There's two ways to get it to work, and they are both options that go in your ldap.conf file: TLS_REQCERT and TLS_CACERT. See the OpenLDAP Administrator's Guide for more information.

And a word to the wise: don't set your RHEL system that is authenticating with LDAP to require TLS and then log out, until you've verified that it actually is working. Why RHEL won't let root log in if LDAP isn't working is a bug I still have to chase down, but it's sure made my afternoon stressful.

When devfs first came out, it was cool and neat, and I liked the idea of not having to wade through 1000+ entries in /dev so much that I jumped on the bandwagon. Then udev came around and devfs bashing became the popular thing to do. Eventually I was convinced of the technical merits of udev, and so converted to udev.

Or so I thought. It turns out I had never quite done that on my desktop, although I had deluded myself into thinking that I had. So when kernel 2.6.13 came around and ripped devfs out from underneath my feet, I fell flat on my back. It turns out I had not only been running devfs all along up through 2.6.12, but somewhere along the line I had lost the real, static /dev. The error I was getting was something along the lines of "Unable to open initial console."

After some head scratching, googling, and false starts, it turns out the best thing to do was to boot a rescue disk, mount the root partition, and copy over /dev. (I did rsync -a /dev/ /mnt/tmp/dev).

One of my false starts was MAKEDEV std hda hdb hdc hdd. In retrospect this should have worked, but my delusion was so complete that I thought udevd was being started at boot when indeed it was not, and only those devices were not quite enough to get me booted. At that point I lost interest in just how minimal a set of devices I needed, and copied them all over.

At least, that's what it seemed like. Actually it looks like they just changed the name to Pioneers and conspired with Google and SourceForge to make it nigh unto impossible to find. But find it I did: http://pio.sf.net/