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)
/. has always announced minor kernel releases. Where've you been?
It's hard to be religious when certain people are never incinerated by bolts of lightning.
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...
Features are often backported from the development kernels, especially by distributors for use in their own packaged kernels.
You could just apply the patch yourself.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
Regarding 2.6.0, it's a little late to speculate on the pre-releases. 2.6.0-test11 is out now, and it will be the last test release. In two or three weeks, after the bug reports subside to a dull roar, 2.6.0 will be out. It will, however, be interesting to see how Andrew Morton takes care of 2.6.x (x > 0) releases.
Litigious bastards
Yeah, kinda strange.. they were saying 2.5 is supposed to be the development, but now it seems the devel versions as the ones with -preX affixed to it.
:)
Anyway, the way the Linux kernel works, it's x.y.z. For the stable version, x is currently 2, y is 4 and z is 23 (I guess). If y is an odd number, it's "development", and may be unstable, might not compile and should interest only programmers. If y is an even number, it's production and should work. So 2.5 was there, but the general public probably wasn't really interested in it. Of course, now they have -preX's at the end, so that's another paragraph to the rules, one which I'm not really familiar with.
What time is it/will be over there? Check with my iPhone app!
Some people don't really feel safe enough with latest stable kernels. Sometimes this means running a few weeks behind the latest kernel.org stable release, sometimes this means running a point release behind (unless something serious is uncovered). Sometimes it means basing your entire distrobution on a kernel from the previous stable branch (the Debian installer defaults to 2.2 still... though that will change soon)!
Myself I don't think I'll be upgrading immediately to 2.6. I know the developers feel confident in the 2.6 tree, but quality release needs stress testing, in the kind of volume you might find in a point-oh release. Save any show stoppers, I'll probably join in the 2.6 fun in 2.6.1 or so. I know that its not a safety guarentee; 2.4.18 or so had a vulnerability in pthread I hear.
I Browse at +4 Flamebait
Open Source Sysadmin
VMWare works fine in 2.6, given that you install the updates at http://knihovny.cvut.cz/ftp/pub/vmware/. Just get vmware-any-any-update45.tar.gz and run the install script. Then re-run vmware-config.pl. Make sure that your 2.6 kernel doesn't have preempting enabled (this crashes for me) and you're all set. I've been running VMWare on 2.6.0-test10 and test11 with no problems at all.
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.
TWW
"Encyclopedia" is to "Wikipedia" what "Library" is to "Some people at a bus stop"
For me there appears to be an important bugfix WRT the usb serial driver. It's the driver that would have let me use my serial dialup modem as a USB device. ATM the driver dies when my modem fails to dial the first time (which is almost always given my ISP's congested connection).
There are also fixes WRT various esoteric "memory" issues, so upgrading wouldn't hurt. At least that's the better "alternative" for me than upgrading to a realtively untested kernel.
2.x where x is an odd number are development versions for a newer kernel (2.5 was the development version for the 2.6 kernel). Once a newer kernel is release, such as 2.6.0 then you will see 2.6.0-pre whatever, which will be the prelude to 2.6.1.
They still maintain older kernels such as 2.2 and 2.4 because some servers, such as the ones I run can not afford to take our chances with a brand new series kernel which might still have bugs lingering, and where there might be compatability issues, so we still need updates to the older kernels.
2.5.x is now 2.6.0-testN, which will eventually become 2.6.0.
2.3.x went through the same deal back in 2000, when it became 2.4.0-test, which eventually became 2.4.
This article is about the 2.4.x series. No "cutting edge" development is going on in that tree right now; it's just a maintenance release. All the new stuff is going into 2.6-test, and just beyond 2.6-final will be 2.7, the next experimental branch.
- 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.)
No, 2D only. Still, that suits my needs. What few GL apps I need once in a blew moon aren't too horrible with Mesa. I don't use this machine for games at all, so it works for me, but it's not really a gaming solution. Of course, one could question wether ANY *nix is much of a gaming platform. I'd rather play on a console hooked to my big screen anyways...
TODO: Something witty here...
$ grep nvidia /proc/modules
nvidia 1532588 10 - Live 0xf8b30000
$ uname -a
Linux sparky 2.6.0-test11 #6 Fri Nov 28 17:59:07 CET 2003 i686 unknown unknown GNU/Linux
Check out www.minion.de
You probably won't ever see a newer kernel in Debian stable/woody. Bugfixes will be backported to the current kernel. If you want a newer kernel, you should probably upgrade to testing/sarge or unstable/sid.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
You need to apply the cryptoloop-jari patch on top of the 2.4.23 kernel.
:-(
Some people reported that you need to use updated userspace tools and the "hashalot" tool as well, but for me applying the patch above did the trick.
I agree that it's disappointing that the cryptoloop support is only partially integrated, since the correct instructions on how to get it working are hidden among a lot of no-longer-accurate descriptions
-Klaus
easy fix for that.
/vmlinuz /boot/vmlinuz.backup
/etc/lilo.conf:
cp
then add this to
image=/boot/vmlinuz.backup
label=backup
read-only
optional
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.
Pretty simple. There will be NO new features in 2.4. All that energy will be spent on 2.6. Only bugfixes and patches etc will be done in 2.4 for those users that are running very critical servers and have already found all the features they need in 2.4.
Say you have a bunch of volunteer programmers, will you divide them between 2.0, 2.2, 2.4 and 2.6? Both the programmers and the vast majority of users will want them working in 2.6. In fact if Linux wasnt so corporate-conscious, there should be no work done at all in 2.2 and 2.4.
"Give orange me give eat orange me eat orange give me eat orange give me you." -Nim Chimpsky
Because a patch like preempt makes intrusive changes into the kernel, and that is unacceptible in the "stable" line.
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Len Brown is the ACPI System Maintainer. He receives many patches from many people. Puts them together, reviews them and incorporates them in his ACPI oriented kernel. They are then tested by the ACPI interested people. When Len is happy, features that are suitable for 2.4 (e.g. maintenances is preferred over completely rewrite etc). are sent to the 2.4 kernel maintainer - Marcelo Tossati.
I suspect it is simply an inaccurancy in Marcelo's logging system - all the ACPI changes have been ascribed to Len Brown - rather than the people who sent them to him.
(offtopic)
His name is Marcelo Tosatti, not Mario or Luigi
(/offtopic)
!
^_^
The latest 2.0 kernel is 2.0.39. It was released in 2001, years after the 2.2 kernel came out.
The latest 2.2 kernel is 2.2.25. It was released this march, years after the 2.4 kernel was released.
I don't see any reason to assume the same won't be true with the 2.4 series.
At my work, we are still running 2.2 systems. 2.4 kernels in our production system are a pretty recent occurance. I don't see us running 2.6 for quite a while, so it would be nice if 2.4 continue to run on new hardware as it comes out.