You are going to love Linux 2.4.

I've been using it since the release of 2.4.0-test4 (though test6 regressed its support of my chipset due to a bug I hadn't encountered, so I skipped that one; I'm now happily using test8). There has been a lot written about the great technical advances (there are many) and when it will be released (I have no idea), so I'm not going to write directly about either of those things. Instead, this will be about what I've noticed as a user. I'll not consult the documentation as I write this. The impressions here are the ones I have from building and using it in several configurations over a couple of months.

I wasn't drawn to the new kernel out of the desire for a preview. As Eric S. Raymond has famously noted, programming in our sphere is done because the programmer has an itch he or she wants to scratch. I'd like to extend that--pre-release software is installed by itchy users. My itch had to do with direct rendering in my video card, and the only effective Calamine was Linux 2.3.99 or better. But now, after weeks with the new kernel candidates, the video stuff has paled into the "oh yeah, that, too" category.

A note for anyone who seeks to give the new kernel a try, or, actually, for anyone upgrading kernels: as soon as you open the source tarball, before you do anything else, go to the /Documentation/Changes file in the kernel source tree. Read it and do what it says. (And pause to marvel at the genius behind it. Without pandering to newbies or trying to impress advanced users, it states in a way anyone can understand the packages you need for the kernel to compile and run as desired; tells you how to determine whether you need to upgrade those packages; and provides the locations where the upgrades can be found. If all Linux documentation were this good, it would be the best-documented operating system in the world by an order of magnitude. Ah, that someone were to do this for Docbook.)

Taking a Look

When time comes to configure the kernel, much of what's new won't be available to you unless you choose to see the experimental stuff, which is the first configuration question you'll answer. It's up to you; I have done this (and used some but not all of the experimental features) and nothing is broken, or at least nothing important. I've always liked the xconfig configurator, but the menuconfig version has been rewritten and is now a lot easier to navigate. It is the obvious choice for those who don't want to configure the kernel under X (if you have a low-resource system, you can still use xconfig and then dump out of X to do the actual compile). I'm not going to give full instructions here, because I think anyone burning a kernel for the first time should read the docs and because they are so simple that anyone who has done it won't need them. Just remember that while it's very simple, it is also exacting. Take time in the configuration and you'll have no problems. Make frequent use of the truly excellent help system (which is also very funny in some places, as in "If you don't understand any of this, say 'no'").

It's a good idea to have your motherboard manual by your side as you do the configuration. Among the things encountered early on, for instance, is a new power management regime, and there's a good chance that you haven't paid much attention to whether your motherboard supports AGPI or not. There are a lot of new acronyms that seem like mysteries. Nor need one necessarily compile everything that the motherboard manual says you have, unless it's something you need--my motherboard supports IR and USB devices. Good for it. I don't have any. Why unnecessarily complicate things?

(Of course, the kernel developers, under the leadership of Linus himself, along with Alan Cox and some other bigtime heavyweights, have provided the option of kernel modules for many, maybe most, of the optional things that you don't use all the time. A module is loaded if it's needed--presuming you've opted to allow them, and their loading and unloading, which do--but otherwise does nothing but consume a little space on your drive. I tend toward monolithic kernels, but have come to the decision that anything I use regularly I'll build into the kernel; anything I use occasionally, such as support for MS-DOS, FAT-32, HPFS, and the Joliet [Microsoft] CD extensions, I'll build as a module. It's possible, too, to build a chiefly modular kernel--just don't make support for your boot drive modular, or you'll never boot far enough to get to the module!)

Next: The Kernel's Growing Sphere of Influence »