Slashdot Mirror
Linux 2.4.16 Released
tekniklr writes: "They just released Kernel 2.4.16. Download it
here, and you can read the changelog here. This hopefully fixes the error that 2.4.15 had of corrupting filesystems on unmount." Update: 11/26 14:14 GMT by T : p.s. Don't forget to look in the mirrors.
for those who are brave enough to immediately try out fresh kernels that may break one's system so I don't have to - and for those responsible for putting the fix out so quickly.
"...today consumers have been conditioned to think of beer when they see a bullfrog..."
Although I like to be as "leading edge" as everyone else, I've held back on migrating to the 2.4 kernel because of the sorts of things that have been happening to this release.
Although the 2.4 kernel seems to be overall a major step forward from the 2.2 kernel, there have been too many major changes with too little testing to make it a 'stable' kernel yet. It was only a couple of 'mod levels' ago that the VM was entirely rewritten to fix a performance problem that the original 2.4 VM (rewritten from 2.2) introduced. And, the 2.4 kernel (finally having been pronounced 'stable' by the kernel team) is discovered to have a major file corruption problem (now, apparently fixed in the +1 mod).
Not to disparage the kernel team (whom I think have done a wonderful job in giving us the next generation kernel), but I think I'll wait until this 'stable' kernel stabilizes a little more.
"values of beta will give rise to dom!"
It's time to admit that most people don't need the newest kernel, and should just run whatever their favorite distro has properly tested. Unless you enjoy pain and you have no data of consequence, chasing kernel versions is a losing proposition.
> What is the most stable of the latest kernels?
IMO the most stable kernel release is 2.2.20. Some people say that 2.4 is still testing, not stable.
At least with FreeBSD I never had to worry when I cvsup'd to the latest sources in the -stable branch and built a new world and kernel. If the Linux kernel people are going to bother to have separately labeled stable and development versions, they should do at least some rudimentary testing before slapping a stable version number on some code and pushing it to the mirrors. Sure, there's no rules to this game...nothing says they have to do that...but they better do it, if they want Linux to ever get anywhere.
And yes, using new stuff on production machines is a bad idea...doesn't change the fact that if Linux ever wants any sort of market respect, showstopper bugs like this can't be allowed to make it into versions that are indicated to be "stable".
"That's Tron. He fights for the Users."
--PEK
Kick back, relax, take it easy, and run some automated burn-in tests for the kernel. Releasing code doesn't need to be a strain, or rushed. Remember, you're not doing it for "them". There is no "them", except in Sci-Fi, or paranoid extremist literature. Rushing is a self-inflicted injury. If you need to do self-harm, use a rubber razor-blade or something.
Many of the major shifts in the kernel have been the Right Thing To Do(tm), but those are the times you need to relax -MORE-, not less. Anyone with a penguin as a mascot understands cool. Cool is good. Cool is exactly what that penguin needs. Cool is what YOU need. You can't run at top gear, indefinitely, and expect to be even close to 100% of your ability.
As I recall, we went through something in excess of 120 pre-releases for one early kernel, and other early kernels often went through 20-30 pre-releases. (Oh, for the days of using a-z for the pre-release number! Sometimes the kernel fell off the end of z, and I think that was part of the incentive to switch to numbers.)
When Alan Cox maintained his series, he would often get into the tens, I suspect much for the same reason. A kernel is a complex thing, and the interactions can be hideously obscure. It takes a lot of testing and validating to work even just the worst of these glitches out.
If we reach 2.5.0-pre100, with the understanding that 2.5.1 will be solid enough to do new work, without forever struggling to figure out if a bug is in new code or a cold kipper from 2.4.x, nobody is going to complain. Well, nobody with any sense. The rest we can secretly smuggle into Afghanistan, where nobody'll care what they think.
I'd rather see 2.5.1 for Thanksgiving -NEXT- year, than be unable to do any serious development work for it. A solid foundation and a late, but perfect structure, is a billion times better than a sky-scraper made from twigs and built on straw, even if the sky-scraper is built on time.
You, like anybody, are undoubtably feeling all sorts of pressures - from work, to the family, to the economy, etc. Many of those pressures are bogus. Worrying about job security won't give Transmeta a greater profit. If it itches, scratch it (just be careful what you scratch in public), and if it doesn't, forget about it. You don't need to go creating problems. We have a Government to do that for us.
None of what I've written is new to you. Little, if any, is probably new to anybody. But it's all stuff we need to hear, from time to time. And when I see someone who is no idiot repeatedly making some very basic coding errors over a relatively short time, I think it's not unreasonable to think that there's a guy who is burning themselves out in the hamster wheel of life, and that that guy might benefit from kicking back & kicking the wheel over. Sometimes we go the furthest by making the least effort.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
What's the best way to tell which kernel is best? Run it for about 2 months on a wide variety of hardware, with a wide variety of software loads. Record incidents and map those against known problems, apply available patches for those that will impact you the most. Re-test.
Then again, your distribution vendor already does this, so why would you be grabbing the latest development release (don't let the term "stable" fool you, that refers to interfaces, not field performance)? Red Hat is now up to 2.4.9 . I know that there's a lot of work going on in the VM world, and it seems to have been sorted out, but as you are noticing, there are other things in the kernel besides VM. If you want a kernel whose performance charactaristics are known, and whose primary bugs have been addressed, you have to sacrifice bleeding-edge fixes.
Not an easy pill for the "I want my tarball now!" world of Open Source, is it? Look on the bright side, 2.4.9 updates from Red Hat on 11/2 beats the heck out of the too-little-too-late geological updates from any closed-source proprietary OS vendor. Q/A is hard work and cannot happen in zero-time.
Since 99% of Linux users get their kernel from their distributer, who patches it and tests it thoroughly before giving it out, this unstable kernel business has zero with Linux's popularity or lack thereof.
If it ain't broke, you need more software.
You know what? As Linus posted to LKML[1], it doesn't matter if there are a million pre releases, as long as it's a pre release, most people don't download it and run it on their hardware and workloads. Not to mention the fact that Linus doesn't like to maintain kernels and turns them over to other maintainers (Alan and Marcelo) for maintenance.
Hence, bugs don't turn up until after real releases are made.
Anyone who goes out and runs a shiny new kernel on a mission critical machine which was released 20 minutes ago is just asking for trouble. These kernels simply don't get the QA they need to be determined to be stable for a number of days after they're released.
If you want a QA tested kernel, go to RedHat, Suse or any of the other Linux distributions, shell out whatever they charge for bundling it up and use their kernel. When that kernel breaks, go whine to the distribution maintainers. (I've done this personally with RedHat, and found them to be very responsive to bug reports.)
Its either that, or fix it yourself, it's that simple. What, you want something for nothing? That's not how free software works.
Whining about the problem will not fix it. Going out and fixing it yourself, will.
1. See posts about Linus and maintaining stable kernels here and here.
"Like I'm going to try this kernel! I used to grab kernel sources nearly right away, but with the latest releases, I'm going to wait until any serious bugs are found."
Just wonderful!!! It's exactly this type of attitude that causes these problems. We all need to help. This is a community effort. If we all shy away waiting for the perfect kernel, nothing gets tested. If nothing gets tested, bugs prevail and the kernel never advances.