The Fugue

I have two soundcards in my desktop: the built-in soundcard which uses the snd-via82xx module, and the nice soundcard which uses the snd-cs46xx module. Naturally, the speakers are plugged into the nice card.

When I installed Ubuntu 8.04 from scratch, the VIA card started showing up as the first card, and therefore the default card. (You can tell by looking at /proc/asound/cards.) I created the following /etc/asound.conf to remedy that problem:

pcm.!default {
  type hw
  card CS46xx
}
ctl.!default {
  type hw
  card CS46xx
}

Ok, so now all programs using ALSA's default device automatically go to the right soundcard. But apparently using the default device is too much to ask of some software, which apparently hardcodes hw:0 or (even nuttier) hw:0,0.

So what I really wanted was to fix the order problem, so that the VIA card doesn't steal index 0. On Ubuntu at least, the fix is:

echo 'options snd-via82xx index=2' >> /etc/modprobe.d/alsa-base

Now my /proc/asound/cards always looks like this:

0 [CS46xx         ]: CS46xx - Sound Fusion CS46xx
                     Sound Fusion CS46xx at 0xfb122000/0xfb000000, irq 20
1 [UART           ]: MPU-401 UART - MPU-401 UART
                     MPU-401 UART at 0x330, irq 10
2 [V8237          ]: VIA8237 - VIA 8237
                     VIA 8237 with ALC655 at 0xec00, irq 21

Back in the day, I cared about having my kernel as a Debian package. I used kernel-package, and I was happy. Then I started wanting to compile vanilla kernels and eventually the overhead just got to me and I stopped using it. I was not using kernel-package, and I was happy.

Recently, I revisited kernel-package for some reason I can't now remember. Wow, it has come a long way. Now it works with vanilla kernels, no fuss. Now it builds initrd images with a single command line option, no fuss. Now it is even easier than just building the kernel by hand (because I don't have to reconfigure the kernel from the stock kernel after make oldconfig due to the lack of initrd (no, I will never even try doing an initrd by hand)).

Here's all you have to do:

# download kernel source
cd linux
make oldconfig
# make menuconfig 
fakeroot make-kpkg --initrd kernel-image kernel-headers
sudo dpkg -i ../linux*deb<tab>

This started out as a comment on Redbeard's Musings on Ubuntu, but grew into something worthy of being an article in itself. Enjoy!

As a Debian enthusiast and package maintainer, I feel qualified to comment. I am not one of the Debian elite, you'd have to pay me (or at least reimburse me) to go to a Debian conference, and I don't have the title "Debian Developer" which means not only do you maintain packages but you jump through hoops too.

Debian has a very rigid policy. All package maintainers have to maintain their packages in accordance with this policy or face the wrath of their peers. It is widely believed (and I share this belief) that the high quality of the Debian distribution is directly proportional to the adherence of packages to policy.

Now all of a sudden here's this upstart Ubuntu that builds on Debian. That's fine, and while there might be the occasional DD that feels jealousy that Ubuntu is building on Debian and getting all the credit, if you look around you realize there's dozens of projects built on Debian. It's a common thing, and encouraged. There's even infrastructure and packages in place to make it easier to roll your own Debian-based distro.

The irritation to the Debianistas is that Ubuntu doesn't always follow policy. They cut corners. They package nonfree software. They do all sorts of things that break policy. This is on the one hand annoying to the debian maintainers because they can't cut corners, but also because they can't just import the changes wholesale back into debian. They have to modify ubuntu's changes to fit policy. It's like someone not-quite-forking your project and sending you a deluge of patches that don't fit your coding style. You're thankful and you're annoyed. It's a love-hate thing. In some cases it causes real problems, not just annoyances.

So the Debianistas who think Debian is all that and a bag of chips naturally get annoyed when Ubuntu comes and does all this, which of course it does in the name of THE USERS and all that is high and mighty, but the Debianistas are perfectly happy with the state of usability in Debian, it rubs the wrong way. Ubuntistus gets mad because Debianistas are heartless elitist pigs, Debianistas get mad because Ubuntistus are busybody carelesss l33t hax0rs, secretly allied with the evil Gnome conspiracy to take away our user interface freedom.

It's not a matter of either Debianistas or Ubuntistus being right or wrong, or better or worse. It's just that common thing called differing viewpoints and priorities in close contact. The people wearing those shirts are immature socially-inept geeks. What's new here?

For the record, I like Ubuntu and although it has annoyed me on occasion (it annoyed me as a Debian user because it doesn't follow The Debian Way all the time), it has also made sharing Linux with others much easier and more worthwhile, and it has given Debian a kick in the pants which can only help. And I love the color scheme. Here's to a continuing symbiotic (if not entirely friendly) relationship between Debian and Ubuntu.

In case you haven't heard, Debian is planning on renaming Firefox to Iceweasel in its upcoming December release, codenamed Etch. The argument between Debian and Mozilla has been raging for quite some time now, and it appears they've reached a stalemate and so they will be doing the only thing they can do.

To recap, Debian won't distribute the Firefox and Thunderbird icons because they're copyrighted with a non-free license. Mozilla won't permit the use of its trademarked names if the official icons aren't used. Also, Mozilla wants complete control over the software, meaning Debian can't apply any patches of its own that haven't been approved by Ye Olde Mozilla. This is free software we're talking about right?

This phrase is repeated over and over when discussing the disagreement: "Mozilla understandably wants to maintain control and blah blah blah blah." Well I'm sorry, but while I can understand Mozilla's reasoning I can't agree with it and I do not have sympathy for them. Firefox and Thunderbird are big projects, but there have been a lot of bigger projects that have gone before who have not had issues with quality control and have not resorted to trademark bullying. Like, oh, the Linux kernel itself. Firefox will simply not ever have the variability that the Linux kernel has from distro to distro, no matter what distribution starts patching it. You don't see Linus throwing around his weight forcing people to distribute sanctioned vanilla kernels with Tux bootsplash images, or else.

Is Debian being anal? Well, yes. That's what Debian does, so people who need that assurance of utter freedom can sleep well at night. Debian has been around for a long time, and its guidelines haven't changed. They're like laws of nature. Mozilla is being a prick. Mozilla doesn't have to be a prick, but it certainly is being consistent with past behavior (I'm thinking of the Adobe SVG plugin scandal). It looks like Iceweasel is here to stay.

I'm divided on what happens next. I want Iceweasel to be released and be the name of the browser on Debian and Ubuntu for the next two years, because it will serve Mozilla right for being pricks. But, the responsible side of me says that can only be bad for everybody and hopes that Mozilla and Debian can come to some sort of agreement. Besides, I really like the Firefox and Thunderbird icons.

Read more at LWN

Or more specifically, huzzah for the Debian developers involved in finally doing what I would have done years ago in their place: forking cdrtools and showing Jörg Schilling the door.

Jörg has caused me endless troubles because of his antics. My burner works, then doesn't work, then works partially, then doesn't work at all. The only change is the kernel version or the cdrtools version, and the only reason is that Jörg is on some loony ego-stroking crusade. Good riddance.

Thank you Debian, and thank you Sun for giving Jörg the rope to hang himself with.

It's all Evan's fault, but I decided to give runit another gander. The last time I tried it I was struck by two problems: runit used really stupid names and directories, even more stupid than the daemontools conventions I had grown used to, and that there's no easy way to replace init even though it claims there is.

This time I was struck by a couple of completely different things:

• runit is very obviously inspired by daemontools, yet it is not mentioned anywhere on the runit site. odd
• runit starts stuff in parallel. cool

I wonder if the daemontools nonmention is the result of some flamewar between the author and djb. It does not stretch my imagination one millimeter to think that djb might have got mad and told him not to use daemontools to promote runit.

runit's sv program actually looks a bit more powerful than ol' svc so I'm willing to let convention slide. I thought about replacing my init with runit, but decided it's just too much work to babysit service scripts for all the silly daemons that I may or may not install or have installed. Like wesnothd. When I'm installing wesnothd, I don't want to have to set up a run script, and now that it's installed I really don't want to set up a run script.

Since migrating involves porting everything over anyway, I figure the better approach is to only port stuff you care about over to runit and let it run as a child of init. Nothing new and exciting here, but I think it's worth mentioning.

Debian's runit package was kind enough to copy over my existing daemontools services and I think it even set up a symlink from /var/service to /service which was very kind (or maybe I did that the last time I was investigating it...).

So in summary, if you've never given daemontools or runit a try, do try one. Try runit if you're normal, or try daemontools if you're a djb fanboy. In either case, you'll find peace of mind in the assurance that your lousy daemons will be brought back up when they die, the simplicity of the supervise scripts, and the euphoria brought on by watching visiting admins try to figure out how the @#$! to stop those daemons. (Actually, runit can be used to simulate those /etc/init.d scripts and provide expected behavior, but where's the fun in that?)