The Fugue

sendxmpp in Debian Lenny doesn’t work properly with Pidgin or Adium. I don’t know if it’s a libpurple problem or a sendxmpp problem. sendxmpp can talk to Psi ok. Upgrading sendxmpp to the version in Sid fixes the problem. The difference seems to be that now sendxmpp is sending messages of type “chat” instead of type “message” or “normal” (by default—now you can specify which message type to use). But Psi can send “message” messages to libpurple clients ok, so it doesn’t seem to be quite that simple.

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?)