I think I'll cut down on ranting just once per year about how daylight savings time wastes time, money, and even lives. So instead of pointing to new indicators of that, I'll post some daylight related code today, since daylight just got very scarce.

Here's my old sunrise/sunset program. Install under either name and it'll print the time of sunrise or sunset. Implemented as an insane remind script.

Here's my new version of the same thing, featuring a spiffier output and saner implementation:

sunset at Sun Nov  4 17:29:00 2007   (1 hour and 23 minutes ago)

Both versions have the latitude and longitude hardcoded.

Keeping /etc in git and other version control systems has been talked about and attempted by lots of people. I tried it with CVS, but that was a joke, with svn, but it sucked, now with git I actually have something I think I'm happy enough about to use.

There's already a tool to do this, but I was not really impressed with isisetup. After considerable pain to find the source code (download links that resolve to 192.168. addresses are niice), I found that it was pretty old and had lots of weird hardcoded things like server names, and it wants to be a git porcelin with its own set of commands for manipulating the /etc repository. I don't want that, I just want a simple setup procedure that lets me use regular git commands to manage the repo.

So instead I followed the lead of these blogs combined with David Härdeman's metastore for solving the metadata storage problem. I also hacked in a solution to the empty directory storage problem, and a few other issues with trying to use git for this thing that it was not really designed for.

I'm very happy with the way it works, you just run "etckeeper init" and then can commit etc as usual with the file permissions etc included in the commits. Clone the same repo to elsewhere and again "etckeeper init" is all you need to restore those permissions (be sure to not clone the repo to a world readable directory, as there is a window when files would be readable).

Automatically committing changes at the end of apt runs is also a handy feature. :-)

etckeeper is currently only available from git. ftp-master is down so I can't upload packages, but both it and metastore can be built from git easily enough:

git clone git://git.hardeman.nu/metastore.git; cd metastore; dpkg-buildpackage
git clone git://git.joeyh.name/etckeeper; cd etckeeper; dpkg-buildpackage

(Update: Now uploaded to unstable.)

discussion

I don't think such a gallery exists, but it should. Here's a my first contribution, found in a website background.

discussion

This is another case of a udev rule that took over an hour to figure out, and now seems very clear and obvious. Which probably means it won't next time I need it.

I have a bunch of USB to serial adapters, all using pl2303, all so cheap that there's no product ID or any way to tell them apart. This is cheaper than buying actual console server hardware nowadays. So how to know which ttyUSB* device is hooked up to what? The solution is to use the USB bus ID, which corresponds to the usb port the device is plugged into. My /etc/udev/rules.d/z25_persistent_usb_serial.rules:

SUBSYSTEMS=="usb", ID=="3-2", KERNEL=="ttyUSB*", NAME="ttyUSB_front_upper"
SUBSYSTEMS=="usb", ID=="2-2", KERNEL=="ttyUSB*", NAME="ttyUSB_front_lower"

The ID numbers can be found in dmesg.

First try at learning blues harmonica. So far I'm concentrating on learning to play single holes. Hard enough for now, although I think I managed to bend a note once.

I have found my happy sound though. Just draw through hole #1 on my C harp and I get that nice lonesome train sound. This is the easiest hole to draw, too.

of the season..

This presentation makes me insanely happy. Artificial lifeforms designed by genetic algorithm, brought to beautiful walking life on the beach, with skeletons and legs made of plastic tubes, wind vanes, 2 liter bottles for storing energy, and simple hydralic brains and sense organs.

I've used the Quod Libet music player since 2005. Mostly happily, despite the occasional really weird bug. The core of Quod Libet for me, the thing that no other player has, is the album list, just a big list of all available albums, with cover icons, and an easy way to limit the display to ones matching a search term. (I'm not one of those people who does complex, detailed playlists; I tend to play one album at a time, in order.) Quod Libet has lots of other nice features, including a great metadata editor, but the album list is the only thing I use daily.

I mostly run Quod Libet on relatively slow machines (with decent speakers), with the display fed to my laptop. Lately it's been feeling a bit slow to scroll around in the album list with hundreds of albums and album icons being displayed over the network and everything running on an old laptop, or an overloaded server. I've known about mpd for a long while, and it's clearly a better fit for how I use servers to play music, but I could never stand to use any of the clients for long.

Today I hit the triple cocktail of evil bugs in Quod Libet described in Debian bug #413284. This is a potential last straw type bug, that's been open since March, and which I'd read before and hoped I'd be lucky enough to escape.

This motivated me to try the Sonata mpd client again. It has a very clean looking and generally good interface, though like all mpd clients, it annoys me by being based around a playlist, and not making it easy to just select an album from the library and immediately start playing it.

But there's a trick that makes it usable for me. I added all my music to the "playlist" (using the mpd command line) and ignore the hard to use library. Since Sontata does have an excellent type-to-limit-display feature, I can just type the name of an artist, album, or track, press enter, and it jumps to it and starts playing.

The idea of replacing the auto tools with GNU make code could be a good thing. I tend to just write simple Makefiles, and avoid using autofoo in new projects at all. That's not good for portability, but it's excellent for sanity.

But, what caused the auto tools to become such a mess in the first place? Part of it was the design, which from 30,000 feet is to write a code generator for some not ideal, but lowest common denominator language, and ship a copy of the (generated) code with every project.

The new design is to write an include file in some not ideal, but almost lowest common denominator language, and ship a copy of that with every project. This avoids many of the pitfalls in the original design, such as having to deal with, and avoid editing, thousands of lines of nasty generated code when a build fails.

I'm afraid it doesn't avoid other pitfalls we've seen with the auto tools. One being that all these copies of code need to be kept up to date. Another being that the interfaces between such an include file and the Makefile that would use it tend to be very broad, and, if not very well defined, can make upgrading the include file break things. As happens when you try to use the wrong version of the auto tools on a project that was written for an earlier version.

Maybe smarter people than I can get around these problems. And there's probably, sadly, truth to the idea that to get a system like this really widely adopted, it needs to distribute build code that uses only lowest common denominator tools.

(I was going to talk about how I started off using a similar include file but redesigned and sidestepped these problems while still getting wide acceptance for a build tool in the Debian community, but I see I already blogged about that earlier, in debhelper autoconf grudge match.)