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)
I'm still using 2.4.18!
ftp.us.kernel.org and ftp.ca.kernel.org aren't updated yet, so I guess we're free to slashdot the main kernel.org server back to the stone age? :)
Because some ppl are still running 2.4 in production environments...the headline is actually kinda wrong...the kernel will actually have new releases...they will just be maintanence releases...only, no new drivers, etc...just bug fixes...
For instance, there was a new release of the 2.2 kernel as early as March of this year.
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.
Some of the changes in 2.6 are keeping me from upgrading right now. :)
- change in mouse behaviour (speed, access to extra buttons)
- some 3rd party modules not updated (nforce2 nic drivers, vmware)
- I've heard cd burning has issues
- I can updated the 2.4.x kernels without any huge worries that my remote server will blow up and require me to get some co-lo monkey to try to fix it
I don't want to sound like a troll, but does anybody else this comment is wholly inappropriate to be included in the text??
If I had written that as a post, I'd get tossed into -1, Flamebait before you know it. Yet the editors are seemingly bigger flamebaiters and trolls than the readers.
Seriously, if michael has such a problem with Debian, write a comment, and face the moderation and the replies. If he can't do that, then don't bother creating shit like that.
That's why you're not in charge of a mission critical production environment. Those who are know that an increase in performance is not worth a decrease in reliability. 2.6.0 is not going to be as stable and reliable as 2.4.23 is, just as 2.4.0 wasn't as stable as 2.2.18.
It's hard to be religious when certain people are never incinerated by bolts of lightning.
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...
Did you miss the early 2.4.x kernels? The 2.4 kernel was nicknamed "the kernel of pain" for a reason. The VM madness was so horrid where I work -- it could be relied upon to clobber MySQL every time the load got moderately high -- that we immediately rolled back to whatever the latest 2.2.x kernel was at the time.
The fact that Linux is the product of an open development process certainly improves code quality, but it doesn't mean that all of the major bugs have been worked out before it's been subjected to the full power of real world production use.
Proud member of the Weirdo-American community.
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.
You've already been advised but let me add more weight.
:-)
You see that third number in the release? 2.4.x? It keeps going up, and the main reason for it going up is to fix bugs.
When the speed of increment slows, I can feel confident there are less bugs! Other people have suffered them, found them, and fixed them! Call me a freeloader...
Actually I have reported bugs in kernels before and got them fixed. But I don't find kernel bugs on production machines, I find them on test boxes.
Of course, if your don't care too much about stability on your box, that's fine, do what you want. But in that case, what is the point of your post?
Yours Sincerely, Michael.
- 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 it wouldn't. Most of the developers would sit there with a calculator converting the hex to decimal just to understand what the hell is going on. This would be a huge waste of time and productivity.
.h and .c files from the server and upload the assembly files instead. But, even that is not the best solution, we should just upload the binary files and let the true hackers continue on in straight 1s and 0s. I bet development would increase at an exponential rate then. Oh wait, no it wouldn't.
But, if you're so hell bent on your idea, why stop there? Run all the code through gcc and have it generate assembly output. Then remove all the
Humans like things they can understand, computers like things computers can understand. Since it is humans developing the software, it is the compilers job to understand how to translate (and the people who write the compilers.)
-- Fighting mediocrity one bad post at a time.
>Your assumptions here seem to be more like guesses.
No it's right on the money. Unless you are waiting for some specific feature, a business with mission critical application/services will not upgrade to a newly released OS.
The Apache Software Foundation found this out when they released 2.0. After six month, very little sites were running Apache 2.0. It wasn't because it was bad product, it was simply because 1.3.x worked pefectly for them.
Why upgrade when your site is running perfectly? When our site is down, we have to refund the customers money. That was about $10,000 a day. So is it worth upgrading productions site, when your current site is working perfectly, at a risk of $10,000 a day? I'd wait until 2.6.12+ or so before I'd even think it.
Now 2.6 on a development site ( mirror of production) is another issue. That's where 2.6 starts it life in our company.
Heck, Solaris 10 is about to come out, who's even upgraded to Solaris 8?
I should not imagine even mission critical production environments sticking with 2.4 after 2.6 is released.
Nope. There is no way we will be moving to 2.6. The boxes we have running 2.4 now will be running 2.4 untill the day they die. I imagine any mission critical environments will be doing the exact same thing as we are.
With new servers you put into production, you may consider 2.6 depending on speed/feature requirements. But existing mission critical machines will never be upgraded.
Think about it, you have a machine and a system that is working. What exactly are you trying to fix? Make it faster? If it was too slow for you, you would have already bought more hardware. So, its not too slow, its been working fine and has been tested. You would have to be mad to upgrade the thing.
Mission critical boxes usually always keep the same kernel version until the day the die.
But The general pattern seems to be:
- "2.6 is almost here!"
- "2.4.23 is out!" Remember that tree? It's still there!
- "2.2.25 is out!" complete with people bitching about how much stuff 2.4.x broke (insert VM whine here)
- "2.0.39 is out!" with people posting about how they haven't rebooted their linux box since 1996
...
Pretty soon, we'll be seeing:- "2.7 branch created! Let's have a look at what's to come
..."
- "2.6.1 is out! 2.6.2! 2.6.3!"
- "2.4.24!" It makes my head hurt....
Really, it's no surprise. Each time a new X.Y.0 release is coming, Slashdot shows the same repetitive behavior...If you want kernel news, I suggest you read LKML or LWN.
His intention was to point out that this should not be done, that is, make a (front page) headline about every minor release.
Why?
I'll agree with you that the kernel version are generally NUMERICALLY "Minor" versions, but the changelogs say different. A ton of stuff usually happens in these "minor" releases which generally turns them into quite "major" releases (though not NUMERICALLY.
I'm not a prophet or a stone-age man,
I'm just a mortal with potential of a super man.
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.