Slashdot Mirror
Kernel 2.4.23 Released
MikeCapone writes "As if we didn't already have enough articles about Linux kernel releases, Marcelo Tosatti has released the final 2.4.23 Linux kernel. Check out the changelog at Kerneltrap."
← Back to Stories (view on slashdot.org)
Hopefully, this fixes some nasty kernel oopses that occur when using the pl2303 usb-serial driver. I've had a lot of trouble with this when using my Deluo GPS.
2.6 isn't 100% userspace-compatible with 2.4; there are a number of utilities which need to be upgraded to deal with 2.6, and a few cases where 2.4 stuff isn't supported at all. So I wouldn't expect all 2.4 installations to be able to go to 2.6 when the time comes. For that matter, 2.4 still has the better ACPI support, and probably still will when 2.6.0 comes out.
As for when 2.6.0 will be out, Linus is turning that over to Andrew Morton, and we really have no idea what his style of stable kernel releases will be like. I'd actually expect to next see a relatively long 2.6.0-rc series before 2.6.0; maybe even a 2.6.0-pre series before that, depending on what he thinks of the seriousness of the remaining "should-fix" and "must-fix" lists and the reported bugs.
Is your graphics card a 9x00 Radeon by any chance? If so, you're in luck, sorta. You'll need to pull XFree from CVS and build it by hand (no big deal), and then use the "radeon" driver. That supports all currently released radeon cards. I'm running a 9600 in FreeBSD with zero problems.
TODO: Something witty here...
Any mission critical environments should run a stable version of the kernel.
In this sense, they are more major than the 2.6 beta kernels.
- 0.8% using 2.0
- 8.9% running 2.2
- 86.5% running 2.4
- 3.5% running 2.6.
There's every reason to believe many people will continue running 2.4 for a LONG time still.(Statistics based on 4503 machines that choose to send in updates. The method is obviously biased.You have been warned.)
But... just because this release is going much smoother that doesn't mean your critic doesn't have a point. Regardless of how long 2.6 retains backward compatability with some aspects of 2.4's presentation to userland, there are some fairly fundamental things that are going to have to change for a system to be fully 2.6-ized. Devfs is being dropped for udev, swaths of proc are being moved to sysfs, and modules get a whole new userland tool. Now, I can boot 2.6 on my desktop and even run X with those unofficial nvidia module wrappers, but hde's performace is degraded despite hdparm's report of increased functionality and I can't run it on my powerbook without a hack to fix the keyboard. The userland stuff for udev hasn't even been written yet. If you've got anything under /etc that touches /proc you may have to rewrite it. Does your server hardware have the ability to monitor fans and temperatures? If so is that important as a failsafe for your uptime? Better check everything between i2c-foo.ko and whatever sends you mail 'cause sysfs has made it a whole new ballgame. Understand, I'm not saying that this kernel doesn't look born to win. It does. But look at your conf files for devfsd. Unless you've rolled your own distro odds are you've got all sorts of wierd tweaks to support a namespace that's lingered since 2.2. Raise your hands if you can boot your machine without "MKOLDCOMPAT"! (I especially love the "original 'new' devfs names or the really new names".) My point here is simply that 2 years after 2.4.0 made a better way of handling devices official the change is still being absorbed. That's not a bad thing. It just illustrates the conservative, one-step-at-a-time way that the whole system moves forward. Most won't stick a prerelease or even a 2.6.0 kernel on a machine that pays thier rent because they don't want to fix something that isn't broken.