The Kernel’s New Recipe

The 2.6 branch of the Linux kernels is fast approaching ‘release’ status — the current version 2.6.0-test8 is essentially a release candidate, even if they don’t call it that specifically. I was curious just what was new in it and the latest version of Slackware I installed is supposed to be 2.6-ready, so I gave it a whirl.

What difference do kernel changes really make though? Well, here is a summary of the major changes between 2.4 and 2.6, and there’s a lot of them. Most are fairly subtle and arcane, so I’m just going to focus on the ones that really matter to me:

1) Preemptible Kernel

The 2.6 kernel is supposed to be more ‘responsive’ when under heavy load; all too often when the system started swapping, windows would take forever to redraw, you could type but the screen wouldn’t update for seconds or even minutes, etc., and this is supposed to help with that. My main Linux server doesn’t get that heavily loaded so I haven’t been able to judge this properly yet, but I have noticed one difference: before, flipping between desktops often made MP3s playing in XMMS pause slightly, and although it still happens now it occurs much less often than before.

2) Built-in Cryptography

Various crypto ciphers and the loopback support for creating encrypted filesystems are now built into the kernel. They had been available for a long time, but as separate packages that were always a pain to have to patch in, configure, recompile user tools for, etc. Everybody’s got their secrets…

3) POSIX file ACLs

The standard user/group/other permissions system has usually been good enough for my needs, but it’s nice to know that I can go a bit more fine-grained than that if I want to. It’s one less thing for NT users to gloat over, anyway.

4) Threading improvements

Threads under Linux have always been a bit controversial — they were implemented the way Linus et al felt was the technically proper way, but which didn’t necessarily correspond with the way standard POSIX threads were expected to work. Fair enough, Linux is often about doing things a better way, but it did make things tougher for those of us trying to write multi-platform threaded apps. A whack of changes to threads in the 2.6 kernel might help achieve better standards compliance while retaining the technical benefits.

5) ALSA

ALSA is now the preferred sound driver instead of OSS. What’s the difference? Not much to the end user that I can tell, aside from ALSA continuing to be supported and improved while OSS won’t be. I do see a whole lot more options in the mixer now though; I can now adjust things on my SB Live like surround sound depth that the OSS driver wasn’t aware of.

6) NTFS write support

Previous kernels could read NTFS partitions but not write to them. Writes are now allowed, though with strict limitations (can’t create new files, file size cannot change). I still won’t enable it though — without proper documentation from MS (yeah, right), I’m still wary of trusting the reverse engineering of something that complex with important data.

7) CD burning/ripping

Burning to a native IDE writer device is supposed to work now, so I don’t have to use the ‘ide-scsi’ module to make it pretend it’s a SCSI drive anymore. And ripping and burning CDs are now supposed to be able to use DMA for better speed and reliability, though I haven’t had a chance to test it yet.

8) Networking

There are a few new options here like IPSec and SCTP and other stuff I dont care about, but the most important thing to me was the relief that they didn’t totally replace the freaking firewall code yet again. Yay for stability.

There have been a couple problems though. When I went to load the driver for my network card, it failed to detect it. After a little research I discovered that the support for the older chipsets like this one had been replaced by a new driver, so I went and loaded that one instead…and my system froze solid. Every time. Fortunately a different driver was compatible with this card as well and it loaded without trouble, but it’s still annoying that they’d take a perfectly stable old driver and replace it with a new, buggy, untested one for no apparent reason.

The 2.6 kernel also really didn’t like my Radeon card, though that’s more ATI’s fault than the kernel’s. I originally bought the Radeon since it was apparently supported under Linux, but it wasn’t until later that I discovered the support is somewhat lackluster. They release drivers infrequently, and they often have to be fiddled with before they’ll even compile. Their latest one claimed to work with 2.6, but I had to fix a couple minor problems before it would stop panicking the kernel, and it still generates a few warnings.

Overall it seems stable enough that I’ve put it on as the main kernel on my server for now.

2 thoughts on “The Kernel’s New Recipe”

  1. I’m so out of touch with kernel upgrades since I became “it-can-wait-until-the-distro-updates” lazy, it’s scary…

  2. I haven’t been keeping up with the minor changes much either. I have no idea what the real differences between 2.4.22 and 2.4.18 or 2.4.15 or 2.4.11 or whatever are; they all seemed to work the same for me, so who cares…

    I was mainly curious as to what they’d been spending all their time over the last year or two on that supposedly makes 2.5.x and 2.6 any better. Gotta make sure Linus isn’t slacking off… :-)

Leave a Reply

Your email address will not be published. Required fields are marked *