Kernel 2.4.23 Released 236
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."
Only through hard work and perseverance can one truly suffer.
Re:Kernel Release (Score:3, Informative)
Woohoo!! (Score:4, Informative)
Re:Is there.. (Score:5, Informative)
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.
Re:No cryptoloop? (Score:5, Informative)
Re:how is work done simultaneously (Score:1, Informative)
Re:No cryptoloop? (Score:2, Informative)
Re:Is there.. (Score:3, Informative)
Re:Dumb noob Linux question (Score:4, Informative)
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.
Re:Is there.. (Score:3, Informative)
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.
Re:Is there.. (Score:4, Informative)
Re:Kernel Release (Score:5, Informative)
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.
Re:Woohoo!! (Score:3, Informative)
It took me a while to figure out the problem. I finally worked out that it thinks the data stream is a serial mouse and dutifully interprets it that way for a few seconds before bringing down the whole machine!
Re:"DRM Support for Xfree?" parse error... (Score:4, Informative)
TWW
Re:Any reason to update? (Score:1, Informative)
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.
Re:Dumb noob Linux question (Score:2, Informative)
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.
Re:Dumb noob Linux question (Score:1, Informative)
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.
Re:Is there.. (Score:5, Informative)
(Statistics based on 4503 machines that choose to send in updates. The method is obviously biased.You have been warned.)
Re:No cryptoloop? (Score:3, Informative)
Re:Is there.. (Score:1, Informative)
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 [minion.de]
Re:don't feel so bad, fellow dark ages inhabitant. (Score:3, Informative)
Re:No cryptoloop? (Score:2, Informative)
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
Re:I'm in the dark ages... (Score:3, Informative)
cp
then add this to
image=/boot/vmlinuz.backup
label=backup
read-only
optional
Re:Is there.. (Score:5, Informative)
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.
Re:Why aren't pre-emptive and low-latency merged? (Score:2, Informative)
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.
Re:Why aren't pre-emptive and low-latency merged? (Score:4, Informative)
Re:Intel working on x86-64? (Score:4, Informative)
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.
Re:Why aren't pre-emptive and low-latency merged? (Score:2, Informative)
His name is Marcelo Tosatti, not Mario or Luigi
(/offtopic)
Re:Kernel release. (Score:3, Informative)
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.