In Debian, it’s just a quick
apt-get install iceweasel-vimperator
away!

whatever.

People keep sending me links to them. People keeping making them. They show up in my RSS feeds with frightening frequency.

I have to admit, however, that these were pretty funny: http://blog.rominet.net/2008/05/debianopenssl-debacle.html. Mmmm…antropi….

Also, did you know that apparently there can be improper lolcat grammar!?

nmudiff is a program to email an NMU diff to the Debian Bug Tracking System.

I often make quick little changes to debian packages to fix bugs or typos, and it’s always been a bit of a pain to generate a patch to send to the maintainer.

nmudiff uses debdiff (another very useful command I just learned about) to generate the patch, and email it to the bug tracking system with the appropriate tags.

In kernels prior to 2.6.24 I used the bcm43xx driver, and let NetworkManager handle connecting to wireless networks.

I’ve since had some time to play around with 2.6.24 a bit more, and I’m happy to say wireless is working now!

Here’s what I did:
- Install b43-fwcutter
- Add b43 to /etc/modules
- Add ‘, ATTR{type}=”1″‘ after the MAC address to the line in /etc/udev/rules.d/z25_persistent-net.rules that contains your wireless device. This ensures that udev will assign the same interface name to the wireless device as it had before, which means you don’t have to reconfigure your firewall!

Anyway…after a short ’sudo m-a a-i -l 2.6.24-1-amd64 nvidia’, I could reboot into the shiny new kernel!

New kernels always seem faster, so I was getting excited after booting up. After logging in though, I couldn’t connect to my wireless network. I had previously been using the bcm43xx driver, and looking through the changelog, I discovered it had been deprecated in favor of the new b43 / b43legacy drivers.

Ok, no problem, just load the new module…wait for network-manager to pick it up…wait for it…wait…wait…Screw it. Edit /etc/network/interfaces, uncomment the stuff for the wireless device, and then ‘ifup eth2′. Kernel oops.

Well that sucks. Back to 2.6.23 I go.

Incidentally, it’s not just this oops in 2.6.24 that has me disappointed. Everything since 2.6.18 has been a bit risky. It used to be that upgrading a kernel within the same major.minor release was a relatively safe thing to do. I actively use two different kernels on my machine at home:
- 2.6.21 since it supports the raw1394 interface that dvgrab requires to download video from my camcorder, but wireless is very flaky
- 2.6.23 since wireless is more robust

I still occasionally get lockups, forcing a hard reboot. Maybe this is my fault, I am running the proprietary nvidia driver, and I do use suspend to ram quite a bit, even though it thinks my hardware isn’t supported.

Maybe too much is changing too fast between kernel releases, not allowing userspace to keep up? Not sure, all I know is I’m doing much more rebooting in my Linux machine than I used to.

So to scratch this itch, I wrote kexec-chooser. It’s a small Python script that will allow you to easily warm-reboot into any of the stock Debian kernels installed on your system. It’ll probably work with custom kernels as well, but I haven’t tested that yet

Downloads and more information can be found on the kexec-chooser page.

And there was much rejoicing.

Linus Torvalds has just been accepted as a Debian Developer, which means that, “Debian will have the advantage of being the distribution with the most official Linux kernel.”

World domination is one step closer….muahahahahahaaaaaaa…

(seen on Planet Debian)

I just realized that my laptop supports 1600×1200 resolution! And I’ve been running it at 1024×768 all this time!

So after fighting with the fglrx drivers for Debian, I can finally surf the web and read e-mails without having to scroll left and right all the time!

Setting up fglrx was less than painless to put it mildly. For future reference, I had to do something like this:

aptitude install fglrx-kernel-src
cd /usr/src
tar jxf fglrx.tar.bz2
cd modules/fglrx
export KVERS=2.6.16-1-686
export KSRC=/usr/src/linux-headers-${KVERS}
debian/rules binary_modules

I would have hoped that m-a a-i fglrx would have worked, but alas…

Oh, and other thing. ATI: it isn’t cool to lock up the machine just because your driver doesn’t support 16 bit colour. I had set my default colour depth to 16bpp previously in an effort to get higher resolution with the radeon driver, but when I started using the fglrx driver things would just lock up.

Success!

I’ve packaged up the result for Debian (with some small changes) and put it here on my site (check out the Software section).