I had to patch the driver to build with a 2.6.26 kernel, as neither versions of the code would build against that version. Lenny ships with 2.6.26, so that would have meant no dgap drivers on Lenny. I’ve tested the patched driver and haven’t noticed anything obvious while doing so.

The drivers are now built for Lenny; if you need them on Etch, a simple rebuild from source will do. Previous versions are still available in the pool, under the old/ directory.

APT source line, now changed:

deb http://debian.technologeek.org/ lenny non-free

Feedback at the usual address.

The server-side counterpart, mt-daapd (Firefly Media Server), on the other hand… not so much. Feature-wise, it works and does what it’s supposed to do, so the issues aren’t there.

The first issue was with the crappy, below-average packaging of mt-daapd in Debian. I’ve fixed that since I think, at least now it’s in a state where I’m not looking away from the screen while typing apt-get install mt-daapd.

The second issue came after looking at the code, while writing patches for Debian. Eek. It’s horrible in about every aspect you can think of. No coding standard, outdated comments, cruft everywhere, either #ifdef’d out or not, useless code left lying around inside functions, obvious memory leaks, and way more levels of indirection than is actually needed, let alone sane. Also, someone is clearly in deep and urgent need of taking “Pointers in C 101″. My eyes still hurt.

Well anyway, I’ve been contemplating either fixing it or rewriting it because I can’t stand such crappy code. Also, mt-daapd has been unmaintained upstream for something like 2 years, given that the upstream developer just pretty much disappeared.

So, with way more time on my hands than I’d like these days, I’ve finally jumped in, pulled the whole SVN into a git repository and started cleaning things up then rewriting it piece by piece. Good way to keep myself busy, producing something useful while doing so and playing with a couple new things.

This rewrite is called forked-daapd, for lack of a better name at the moment, it’s GPLv2+, and the code is available in a git repository at

git://git.debian.org/~jblache/forked-daapd.git

It’s not a feature-for-feature rewrite. I’ve tossed out a few things.

It’s Linux-only for a start, and then I’ve thrown out the web interface, the XML-RPC interface that goes with it,  the iTunes XML playlist support (only useful on Mac OS X) and the smart playlists. Maybe a couple other minor things I can’t think of right now.

It’s Linux-only because it uses signalfd and inotify. It’s built on libevent and pthreads, but doesn’t abuse threads either like mt-daapd does (spawning one thread per HTTP request … seriously). Parsers for the RSP and DAAP queries are built with ANTLR v3. Media handling is mostly done by ffmpeg, though ffmpeg suckiness in parsing metadata in some formats had to be compensated by dedicated metadata parsers. It’s a shame ffmpeg can’t handle raw FLAC streams with VORBIS comments, that is, bog-standard .flac files, while it goes to great length to support proprietary formats (though I should note it fails miserably on WMA too).

So, new things I played with: signalfd, libevent, threads, ANTLR, ffmpeg. Threads aren’t really a first, but I did some new things. inotify isn’t a first either, but it’s the first time I use it to watch events other than IN_CREATE or IN_MODIFY; that leads to quite some unhappiness towards the inotify API, which has some real shortcomings. I’m still shaking my head in disbelief.

It will happily support multiple concurrent clients, even when decoding media files to WAV, without abusing the machine it’s running on. I thought of adding more threading, especially in the decoding case, but I doubt this will be needed by anyone. Unless you’re streaming to hundreds of clients at the same time, which doesn’t look like a plausible usage scenario to me.

I don’t know where I’m going with this project. Right now it works for me and covers my needs. I’ve tested both the RSP and DAAP protocols with my SoundBridge, and DAAP with iTunes. I’m not an iTunes user so I may have skipped on the complicated things with iTunes, although I looked hard.

If there’s enough interest in this project, it can become a full-blown project on Alioth (it can even have a name that doesn’t suck!).

The patch you submitted has 0 chance of getting applied, and you know it. It’s nothing more than a bad joke.

The best solution for this issue is most probably to provide a xserver-xorg-nohal package that is a duplicate of xserver-xorg minus the HAL dependency.

#515214, currently wishlist/wontfix.

It has been decided that, in order to not slow down the development processes, D-I SVN should be branched when the work on preparing a release starts. Even if SVN doesn’t make the process very easy, changing the VCS we use is currently not an option we prefer.

SVN, branching, d-i. There’s no word to describe how painful it is to work on d-i using SVN. d-i is big, SVN is slow in about everything it does. Now add branches to the mix.

That mail left me very disappointed; first because I thought switching to git was sort-of planned for after the release of Lenny, and now it’s off the table, second because some things in this mail are just wrong.

Oh well. No d-i for me, I guess, then.

• support for the new mini external keyboard,
• the keyboard backlight idle timer now only takes keystrokes on the built-in keyboard into account,
• move away from using /dev/mem to access PCI memory, use sysfs resource files instead.

There are a couple of ideas floating around, we’ll see if any one of those lands into a future release.

While the effort is laudable, they’re not quite there yet. Let’s have a look.

First of all, and contrary to what a few people believe after reading the press release, the drivers themselves aren’t OpenSource, let alone Free Software. They’re all proprietary; read better, the press release clearly mentions that only the frontend application is GPLv2.

Now let’s look at what Kodak offers in its drivers packages. I’ve downloaded LinuxSoftware_i1200_v3.5.tar.gz from the Kodak website, these are the drivers for the Kodak i1200 series.

The archive contains a set of RPM packages, one Debian package corresponding to one of the RPM packages, and a setup script.

One of the packages contains the OpenUSB library, which is released under the LGPL; sources aren’t there, I haven’t asked for the sources, don’t plan on doing so, and am not implying anything regarding license compliance whatsoever. I’ll note that I haven’t seen any written offer for the sources, though, be it in the archive (there’s not even a README in there) or on the website.

So, although Ubuntu is listed as supported, we can say that no Debian packages are provided.

The setup script actually relies on alien to convert them if it thinks it’s running on a Debian-based system, which is determined by the availability of dpkg in the PATH. Using alien is far from ideal.

The packages ship libraries and components under /usr/lib, /usr/local/lib and even /opt, pretty randomly it seems. Let’s repeat here that /usr/local and /opt are strictly reserved for the local administrator and packages must not install anything here. There are other oddities in the paths used by the software stack, like /var/kodak.

It looks like the SANE backend is only a bridge to Kodak’s TWAIN data source, so you’d actually need the whole stack to use it.

All in all, Kodak does no better, I’d even venture to say it does worse, than Epson (Avasys). At least part of Epson’s backend is Free Software, even if it relies on proprietary libraries for some scanners, though unfortunately most if not all of the recent ones.

I also have to mention that Epson is offering both RPM and Debian packages, and by that I mean proper Debian packages. Kodak are far from that, even the RPM aren’t that great (I think the RPM packages even lack dependency information, based on what I’ve read in the setup script, though I haven’t checked).

What Kodak offers here is a GPL frontend for TWAIN that not many people will be using, while keeping the drivers proprietary. Unfortunately their SANE backend isn’t a backend so to speak, and even if it was OpenSource it’d still rely on the rest of the TWAIN software stack.

So, in a nutshell, while I’m very happy to see yet another vendor go down the road of Linux support for its products, I am immensely disappointed by the proprietary nature of the drivers and the low quality of the packages.

I was, of course, investigating the drivers to possibly package them for Debian; as you’ve probably understood, it’s not possible, both technically and legally.

And I kept a little gem from the setup script for the end:

# We need to create a link for the libdbus-1 requirement for openusb,
# but only on Fedora.
if [ -f /etc/fedora-release ]; then
    ln -s /lib/libdbus-1.so.3 /lib/libdbus-1.so.2 2>> /dev/null
fi

As we all know, sonames and soversions are useless and they just keep getting in the way. Duh.

First, I was reported a segfault of mt-daapd when reloading web pages too fast. Surprisingly, it turned out to be a stupid omission in a simple routine and it is hard to hit without disabling the cache in the browser.

Now, I just fixed something that’s been bugging me for a while: mt-daapd did not handle Avahi daemon restarts, leading to mt-daapd becoming invisible to clients relying on mDNS until you restarted it.

And, wow, that went a bit further than expected. As I expected, the simple piece of code needed to handle that wasn’t there. But still it did not work, as it turns out the event loop for the Avahi polling wasn’t being run. Replace stupid code reinventing the wheel by the Avahi-provided wheel and there, it works. But not when run as a daemon (aka foreground only). Well yes, starting the thread before daemonizing isn’t going to work well, so fix that. EPIC WIN \o/

As mt-daapd’s upstream is not active anymore I’m accumulating fixes for mt-daapd in the Debian package, to the point I’m starting to consider setting up a git repository somewhere with those fixes and possibly some more code rework if I feel like it.

git://git.debian.org/git/pommed/pommed.git
http://git.debian.org/git/pommed/pommed.git

The SVN repository will disappear shortly.

For years, I’ve been struggling to keep my machines quiet. I’ve miserably failed for years, and pretty much gave up once I realised that the quiet parts I was looking for just did not exist. Last year, I finally found what I was looking for:

• big, heavy, quiet case from Chieftec (with room for 8 HDD and their own dedicated 90mm fans (up to 3) and room for 2 120mm case fans);
• über-engineered fans from Noctua (finally some guys took a shot at engineering fans, happiness \o/);
• fanless (except for the emergency fan) PSU from Antec (Phantom 500).

I’ve been very happy with this hardware for both my workstation and my filer. Well, until today. No need to mention that this hardware is not exactly cheap, but the price is right for the quality.

So, wake up today, do random things, grab my TomTom, unplug it from the workstation it’s sucking its power from, do things, plug it back in the USB port so it won’t draw its battery. This is how it went:

• plug TomTom into USB port;
• notice the LED is blinking, and it should not;
• erupt a mental “WTF?” and simultaneously hear *clac* *pffzziiouuuu*;
• unplug TomTom;
• replug TomTom, notice the LED is blinking again;
• look at the machine, notice it’s gone down;
• check the PSU and erupt a verbal “WTF?!” noticing the LED on the PSU is not lit.

Check machine temp, PSU temp, attempt to restart PSU, check UPS, check cables, replace power cable and bypass UPS. Admit defeat for this round and accept the PSU as dead. Pull out the machine, rip out the fscking damn PSU.

Grab the tools, crack the PSU open. Notice bulging and leaking capacitors.

Yes, this PSU is anything but cheap, yet it uses el-cheapo chinese capacitors. Antec, you suck, big time. For the past decade everybody in the industry has known that el-cheapo chinese capacitors manufactured after 1999 are total crap, using an electrolyte that isn’t actually one because its formula was stolen by industrial spies who got totally PWNED and ended up stealing a bad formula.

(If you need a reference, google for “singing capacitors”. Note that singing capacitors can also happen with good parts used in a crappy electronic design. Like that 100 Mbps D-Link switch over there, or that Sony-Ericsson mobile phone charger. Hmm. Not everybody can hear it, I do.)

A healthy, young capacitor should not bulge nor leak. A capacitor that leaks, bulges or sings is a crappy capacitor and needs to be replaced with a quality part ASAP. I’ve been routinely replacing such capacitors on my older motherboards (manufactured between 1999 and 2001) in the past years. I’ve not had the problem in ANY of my el-cheapo PSU, and did not replace any capacitor in any of them to date.

Fortunately, the machine did not suffer any further damage, nor did the TomTom. Everything is up and running again with a spare PSU. I’m now going to replace the fscking capacitors on this PSU, replace the fuse, probably R&R a couple of high-voltage transistors too (they have a tendency to fry before the fuse blows out) and get it back up and running.

Then I’ll do the same with the other PSU in the filer, because that machine has 8 disks attached, so draws more power and hence is much more vulnerable. Fuck you Antec.