A Debian Lenny status report for the $0 Laptop

I've been waiting ... and waiting ... for Debian to come to its senses and re-add the sound chip — the ESS 1988 Allegro — in my Gateway Solo 1450 back into the Lenny kernel.

Sound had been fine in Debian Etch (Stable) and in the first two kernels in Debian Lenny (Testing), but once the 2.6.24 kernel was added, I lost sound on the $0 Laptop.

Reverting back to the 2.6.22 kernel restored my sound, and I eventually hunted down the bug report, which — in grand Debian tradition — didn't solve the bug but instead provided a work-around.

Presumably the Debian team didn't like the fact that the ALSA sound module for this chip came in the form of a binary blob, which is non-source, undocumented code, and instead of providing any other way to use sound with these chips, elected to silence the PCs of those using Debian Lenny with this verboten sound chip.

Now if this were the only binary blob traveling in Debian's wagon train, I'd understand. But I'm fairly sure it's not. We're not talking OpenBSD-style religion here.

At least the system could somehow tell me that Debian removed sound support for my chipset and perhaps ask me if I'm OK with using a non-open blob to get the sound working.

No such luck. I suppose I should be so offended at my laptop's use of hardware for which the manufacturers decline to provide open-source drivers that I should soldier on without sound — and like it.

I don't like it. But the reality is that many if not most hardware manufacturers haven't seen the ever-lovin' light and don't know that open-source software in general, and Linux in particular just might take over the world, or at least the geeky portion of it.

Never mind that sound works on this laptop in any number of Linux distributions, including Ubuntu, Puppy, Slackware, CentOS/Red Hat ... as well as FreeBSD and NetBSD.

But Debian decided to get all high, mighty and just strip sound out of the kernel for what must be a whole lot of potential users who either don't know, don't want to know or don't care to track down the instructions for restoring audio on their machines.

I imagine there are a lot of ESS/Allegro chips out there. In Linux, as in OpenBSD and any number of other projects, a lot of really smart developers are very busy writing open drivers for the proprietary hardware we're stuck with. Sometimes they get cooperation from the manufacturers. Often times they reverse-engineer the whole damn thing. Still, there are a lot of "binary blobs" out there.

If the choice is between binary blob and open-source alternative, there's no question — take the code you can see, modify and distribute freely.

But if the choice is between a blog and ... nothing, it's nice to have the opportunity to take the blob. A project can — and should — let the user have a say in what they'll run on their machines.

I've stuck with Debian for awhile now on this laptop, even though I've been using Ubuntu more (blame it on Ubuntu's working suspend/resume ... and other stuff that just works better).

So far, here are the Debian Lenny problems I've had to solve to get things working:

• Change Gconf configuration so Epiphany browser doesn't default to "working offline" mode
• Download and install driver from the Foo2zjs Project to use HP Laserjet 1020 printer (to be fair, this is also an issue with Ubuntu)
• Tweak xorg.conf so Alps Touchpad's tap-to-click function can be managed (can't quite remember how I did this ...)
• Restore sound for ESS 1988 Allegro with firmware from the ALSA Project

It could've been worse, and in almost all of these instances I got the hacks from the Debian Bug Tracking System. But I'd prefer that at least some of these bugs actually get fixed rather that shuffled aside, with users left searching for the hackish fixes that will make their machines usable with a given distribution.

What most of us know is that users pretty much gravitate toward operating systems that work best with their hardware and the software they wish to use.

So if Ubuntu uses the same Linux kernel but supports my sound chip, properly configures my touchpad, doesn't think I'm working offline when I'm not, properly suspends and resumes, and offers a bit more in terms of functionality and polish (like the GNOME menu editor actually, say, working), I'm inclined to use it.

I still have Debian Lenny on the Gateway, although I might devote its partition to CentOS 5.2 for testing purposes.

Debian is still faster than Ubuntu. Many of the packages I use are better put-together in Debian, especially the educational games my daughter uses.

And I like the setup that Debian defaults to when installed. The fact that I can and have fixed most of the problems I had is a plus.

In Lenny, I'm having a few graphical quirks with GNOME. The top of the screen gets a little funky at times — and I'd love to figure out the suspend/resume problem, but otherwise Debian runs quite well. And as far as compatibility with this specific pile of hardware goes, Lenny has quite an edge over Debian Etch, the project's current stable distribution.

And since Lenny is still in the Testing stage, patches are coming through at a quick pace, and things are bound to improve on the distribution's road to "Stable" status.

I only wish I could know for sure if the things I fixed manually are being fixed automatically for present and future Lenny users.

Next: How exactly to restore sound for ESS Allegro-equipped PCs in Debian Lenny