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.
> 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.