The Fugue

I just finished reading this article on Upstart, a replacement for init.

I've long been dissatisfied with the System V init scheme. I've looked at file-rc, runit (which is similar to daemontools), and briefly at some others that have popped up from time to time (I think I remember one that had to do with purple cows, but my memory is hazy). None of them has really done anything for me. file-rc is a nice concept taken not quite far enough (it's almost as much a pain editing that file format as dealing with symlinks), and it's not an init replacement in any case. runit/daemontools are very handy, and I use them, but when I tried to replace init with runit I made short work of hosing my startup system. As easy as it is to write run scripts, I do not want to write one for each daemon that I do now or ever will install.

But upstart is very promising. Its coolness factor is higher than any of the others, and it has an upgrade path. In fact, Ubuntu will be using upstart in the upcoming release of Edgy Eft, and is already in use in Ubuntu testing, completely replacing sysvinit. Kudos to the Ubuntu folks for recognizing the need for something better and implementing it. I hope that replacing sysvinit with upstart (in an apt-get sort of way) in Debian becomes a reality soon. In any case, I'm going to give it a test on my laptop when I get some spare time.

My old Deskjet 712C bit the dust (it's probably still fixable to some degree if you're interested), and my wife has never been pleased with the partially-working scanner we got from who-knows-where, so we broke down and got a Samsung SCX-4100 monochrome laser printer+scanner/copier.

We didn't just pick this out of the blue of course, I did some research on what would be a good but affordable printer for linux. First stop, linuxprinting.org's suggested printers page. This printer wasn't mentioned by name, but they did recommend Samsung laser printers as a possibility. This printer was available and the price was right on NewEgg, so I googled a bit and found Shane's post and the many helpful comments. What a small world. The comments got more and more encouraging as the page (and time) wore on, and I concluded that it would be a good printer for linux.

It arrived maybe half an hour or an hour ago, and it's already working perfectly as a printer, scanner, and copier. Anyone who's fussed with printing in UNIX before will confirm that this is very good indeed. I ran Samsung's latest drivers for linux installer (dated 2006-07-19) and it installed without a hitch. I then replaced the /usr/bin/lpr symlink back to the original non-GUI version. That's it. No Qt problems, no messing with kernel modules (I'm using USB, parallel may be a different story).

I'm running Debian testing (etch) and a vanilla 2.6.14 kernel.

Kudos to Samsung for recognizing and supporting linux, and for providing good drivers (after some growing pains), and kudos to Samsung for making a multifunction laser that's affordable.

Have you ever wanted to know programatically which virtual terminal is the current one? You know, so that you can have lirc toggle between vt 7 (regular X) and vt 8 (Freevo). I couldn't figure out how to do this with available tools so I dove in head first and figured out how to do it with ioctl().

http://hans.fugal.net/src/vtcurrent is the code including Makefile, and utility functions from console-tools. vtcurrent.c is the meat, vtswitch.sh is the end result.

Once upon a time, I was a cheapskate without a 3D-accelerated video card. I couldn't play BZFlag, Scorched Earth, or Flightgear. I was deprived. Then one day I broke down and bought a 3D-accelerated card. I got a Radeon 7000 VE which was anything but top of the line, but it has perfectly sufficed my needs. It also has TV out, a fact I don't remember knowing until a couple of months ago when I was crawling around behind my desk.

We don't watch TV. We don't have dish or cable, and the reception is almost as bad as the programming. But we do like to watch a few choice shows, e.g. Good Eats, Smallville, Doctor Who (old and new), and whatever other interesting things turn up online, like the Pancake Mountain theme or _why's FOSCON and other conference videos. We also like to get movies from the library or Blockbuster, but that's beside the point.

So when we got our tax money we had enough cash to throw at an adapter cable (although we spent half as much as that listed price). I had done a little research that indicated it was possible but hairy to get TV out working with this card. I enjoy a good challenge, so I ordered the cable.

The cable came yesterday. I got everything working peachily last night. I'm good at wrangling Linux, but I think that it's safe to say this card is not hard to get going. It will be even easier if you found this post.

First things first. Plug in the cable so you're hooked up to the TV and restart your computer. You should see the console (boot screen, grub, etc.) on the TV. That will give you a jolt of excitement; capture it in a cup for later.

Now, when you've booted, switch to virtual console 1 (i.e. get out of X) and run:

mplayer -vo vesa:vidix /av/video/pancakemountain.mov

You should see a guy in a cape on both your PC screen and your TV screen. So you see, it works great. Now, when the movie ends, or you quit, you'll have a blank screen and not be able to see what you type. Or maybe you will be able to. In any case, if you can't see, just switch virtual consoles, the you can switch back.

Now, even I spend most of my time in X, so we want to get it working from X. X runs at a higher resolution and probably different refresh rates than your TV, so what you see on the TV will be just junk. No big deal, until you want to watch something. I tried xrandr -s 640x480 and got nothing but a messed up gnome toolbar to show for it, so let's steer clear of switching resolution in X. I tried to figure out how to get mplayer to switch video modes with -vo xvidix, but without luck. So I tried -vo vesa:vidix again and it didn't work so well. Well, it did work, although the brightness was sky-high. What didn't work so well was getting back to X. After running mplayer -vo vesa:vidix ... from X my USB keyboard stopped working, and I was stuck in limbo. Luckily you can ssh in and do sudo chvt 8 to get back to normal, as I found after a few frustrating reboots.

To make a long story less long, I ended up writing a script to do the following

#!/bin/sh
opts="-vo vesa:vidix -ao alsa:device=hw=0.1"
sudo chvt 1
mplayer $opts "$@"
sudo chvt 8

That works excellent. The -ao bit is to use alsa device hw:0,1 which is my rear output, where the audio part of the adapter cable is plugged in. If you've got sudo configured to ask you for your password, you might prefer to jump through lots of fun hoops as explained in the Linux Quake HOWTO.

The only other thing I could hope for is to somehow watch something with mplayer on the TV, and still be able to use the computer for other things. I don't have much hope (without getting another video card, anyway) but if you know how let me know.

Update

The above solution has a problem: I can't control mplayer with the keyboard. I can control mplayer from my laptop when I start it over ssh, which is why I didn't notice that before, but it's nice to be able to run it from the desktop too.

This is a much nicer script:

#!/bin/sh
opts="-vo vesa:vidix -ao alsa:device=hw=0.1"
sudo openvt -sw -- mplayer $opts "$@"

If you don't like the idea of running mplayer as root (it's probably suid anyway), you're going to have a fun time figuring out how to get "$@" inside of another set of quotes for the su -c command. If you figure that one out I want to hear about it!

I spent some time over the weekend with git yesterday, so I finally have an opinion about it.

Distributed revision control systems are absolutely fabulous. If you haven't given one a serious go yet, you really should. My favorite is darcs. This post will address git from the perspective of a darcs user, and I might throw some comparisons to CVS or Subversion in, too.

git is really a lot easier to use than I had anticipated. I read lots of warnings in the documentation about how git is stupid (by definition, this is one of its goals) and how unless your needs are a lot like Linus' needs, it won't be right for you. I've found that to be unnecessary modesty. git is very usable as a distributed revision control system for normal people on any size of project. It's not as nice as darcs, IMO, but it does have better performance for large projects, and it doesn't trail far behind anyway. It's a lot nicer to use than GNU Arch, even in its raw form.

git pretends not to be an SCM, but rather a "filesystem". Whatever. git was written to do what Linus needed from an SCM, and it has never had any other purpose. Although it is conceivable that git could be used for other things, as it is quite general and flexible, that doesn't make it not an SCM. It certainly is like no SCM you've ever seen (at the low level) but it's still basically an SCM.

Nevertheless, if you look too close at git you'll be either overwhelmed by the sheer volume of low-level filesystem-like commands, or thrilled by them. However you don't need most of them, and if you ignore them you can enjoy git usability, with the added security of knowing that should you need to doctor your repository (or have a git guru do so) all the low-level commands you need are there. That is a bonus in my book, but mostly theoretical.

I think originally git had fewer scm-like commands and so people wrote Porcelains, like Cogito. Cogito is supposed to be easier to use and a more perfect SCM built on top of git. Frankly, I can't tell the difference between Cogito and git core, except that git core has more commands and options. Cogito does use slightly different terminology and command names, which only confuses the game. I think I'd rather learn the git commands and options that I need from well-written documentation and ignore the rest, than confuse myself with cogito. After only an hour or two of experience, I may be really missing the boat, so you might want to check it out anyway.

Compared to darcs, git feels very familiar. darcs' UI is more polished, but git has a much richer set of commands. One primary difference is that git does branching, where in darcs a branch is basically a new copy of the repository. Both are valid approaches, but the git approach does take less disk space (and network bandwidth) which is important for 300-400 megabyte repositories, like the kernel. I think I will probably continue using darcs primarily, but I will probably try out git more in earnest when I get a chance to see if it might be time to switch.

One thing I do not like about git is the tendency people have for providing their driver for hardware X in the linux kernel as a git repository. Hello! Nobody wants to download 350MB for your 10k of changes to the kernel. Nobody wants to run your bleeding edge git repository just so they can get your driver. That's idiotic. git makes it easy to make patches against whatever revision you want, so make patches against the latest stable kernel, or whatever RC version if necessary, and call it good. Providing access to your git repo is fine for developers, but don't expect it of users.

In summary, I will be using git for my kernels from now on. It will be easier to move around between versions, save me disk space, and allow me to do minor hacks without worrying about them surviving the next kernel upgrade patch. If I didn't already know and love darcs, I'd start using git for my projects. If you have wanted to investigate distributed revision control, check out darcs and git and go with whichever your gut tells you to, I think either one will serve your needs well. For heaven's sake, stop using CVS in any case!

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.