Slashdot Mirror
Kernel 2.4.12 Released
Whoops. A nasty bug affecting symlinks made it into 2.4.11, and Linus has ditched that "sorry excuse for a kernel" in favor of the new and improved 2.4.12. :) See the (short) changelog or list of mirrors, as usual.
← Back to Stories (view on slashdot.org)
2.4.12 has a new bug that crept in with the parport update that Tim Waugh did.
Check lkml archives for a patch to fix it.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Does anyone else remember the brown paper bag bug at the begining of the 2.2 series?
Yes, it was around 2.2.8 or 2.2.9 IIRC. What I do remember though is that after that happenned Linus decided it was time to fork to the 2.3 series around the same time.
Maybe now this has happenned he will start 2.5 and hand over 2.4.x to Alan who IMO keeps kernel series stable better than Linux does.
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
version x.y.odd_number aren't stable releases.
It isn't a bug with all symlinks. It occurs (if I understand it correctly) if you create a file via a dangling symlink, which is really not a good thing to do anyway. (but Suse's YAST does this)
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Read it here
Maybe it's about time the Open Source world started paying more attention to testing?
I think you have to ask the question that when Linus releases a new kernel, who is that aimed at? IMO, these days it is at the distributors, the kernel developers and enthusiastic individuals. It is no longer the case that most Linux users download and compile their own kernels. Because of this the release of the kernels to the distributers actually forms part of the testing itself. ie, don't consider a release to be stable just because its in the so-called stable series. Consider it stable when you either (1) get it from a distributor who will have tested it and guarentee (sp?) it's stability or (2) downloaded and tested it yourself before production use.
Yes, it would of course have been better it this hadn't crept in but it's not really a big deal. How many users do you see around you who have lost work because of this bug?
-- MartinG To mail me: echo kewyjlcxyzvjfxbqwh | tr bcefhjklqvwxyz
Wow, this is bad, but it doesn't appear to be the first time something like this has happened. Testing is something that is sadly overlooked, it seems, for Open Source projects.
Because releasing is part of the testing process. This is, unfortunately, true even for closed, commercial software -- there's always some bugs and some releases are always dogs. With free software the releases come frequently and you can pick which release you want to put your chips on. It's like the difference between having a single, conservative (but still not guaranteed) retirement plan at work, and having a choice of a diverse set of funds.
And I don't believe itis valid to compare a product with Mozilla with the a product like the kernel. You simply can't test them the same way. Nobody (or at least very few people) grab the source code off of CVS and change their kernels every night; and if they did it wouldn't be as useful because many problems only become apparent after you run things for a while on a kernel.
Not to minimize the good work that the Mozilla peple are doing, testing a kernel is simply much harder. This is why commercial operating systems are so slow in their releases. I actually think situations like this demonstrate a strategic advantage of the open software. Nobody in their right minds runs the latest, or even any recent kernel on any machine where reliable uptime is a consideration. I personally am using 2.2.19 on my production servers because it works for me. But lots of people do run every new kernel as it comes out on some machine, so when I switch to 2.4 there will be an excellent knowledge base, that will tell me for example to avoid 2.4.9 for VM problems, or to apply specific patches for 2.4.10 if I need.
This is what it is all about folks -- release early and often, and hang your dirty laundry up where everyone can see it. This is a great benefit, and the only people who this affects in any negative way are fools.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
There are errors in the bz2 images on ftp.kernel.org. They do not pass the gpg verification, and are basically corrupted images. the gz images work.
Philip
Do not underestimate the value of print statements for debugging.
Don't you think it might be about time to have a linux CVS and bugtracker. To my knowledge no such thing exists. Perhaps other people would have actually tried to compile some of this stuff and caught the bugs.
That way each new release can be a "tag" and every new 2.x+1 that occurs can be a branch.
FreeBSD (while not void of bugs) has had a great deal of success with CVS IMHO. The parport bug is that the author submitted something that can't even compile due to a #define constant name that was malformed. I think he forgot the ECP part of it. Someone else posted the patch here in the replies section.
My definition of a stable kernel is one that has been handed over to the stable kernel maintainer, Alan Cox.
The stable kernel has become ready for production usage once development has started somewhere else.
May I recommend this attitude to people who complain about the instability of the 2.4 series. It's called pragmatism.
Yours Sincerely, Michael.
Hey, Linus is only taking the responsibility for not having reviewed one of the incoming patches good enough. Having bugs in the current stage of the kernel is understandable - Linus' 2.4.10 and 2.4.11 kernels contain a brand new VM that already needs a lot of his care. What I do: I run Alan Cox' kernel series.
I agree this is an annoying bug, but to paraphrase a coversation between the comic book guy and Bart:
Comic Guy: Worst kernel EVER
Bart: Why do you get to complain? They've given you thousands of hours of entertainment for free?
Comic Guy:As a loyal [user], they owe me.
Admittedly, I'm probably off the actual text by a bit here, the point remain. Try not to be the Comic Book Guy when Linus makes one mistake.
----------------- "I have a bone to pick, and a few to break." - Refused -------------------
...im still running ol'trusty 1.1.59.....
...
but i cant figure out why my box keeps getting owned...
oh well
I lost my concept of community when my community lost all concept of me.
I'm a relative newcomer to the Open Source world, but what has struck me is how none of the big profile projects seem to have their own test harness or test suites. Maybe I'm missing something. Please let me know what test suites major OSS software ships with. (The only one I could think of was autoconf, which isn't a quality-management test suite but a build manager, and the Perl build process does a few demonstrations of terminal features.)
What I mean is something like "make test" integrated into the project. Running that generated test code would perform hundreds of sanity checks (or even thousands for complicated projects) on the code.
Perhaps Red Hat and SuSE have this kind of code locked away in their "commercial advantage" (and I could see the arguments for keeping those closed) but it would seem to me that Linux and Alan Cox and crew would be more open about test suite software for the kernel.
Install a kernel, run a battery of tests. Find systemic breakers really quickly. It's not hard, it's just a matter of discipline to write the tests. As code is written, write the tests for the code. Any time a bug is found outside the normal test suite, write the test that should have found it. Automatable tests wherever possible.
In the "eXtreme Programming" development paradigm, this is codified even more vigorously: write the test(s) BEFORE the code. In Eiffel, you program by contract; each method has a pretest and a posttest to ensure that the state of the world is correct. Part of the official build process for releasing the software should be a 100% compliance with the automated tests.
[
Actually... according to everything I have ever read about linux the unstable development tree is 2.odd.whatever. Everything in 2.even.whatever is called the "stable tree".
:-)
Close, but it's actually the 2.whatever.whatever that's the "unstable tree". The stable tree starts at "5.00.2195".
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
Usually, when a new kernel is out, I download the patch, apply it, use the most recent config file, which I go through some, but not necessary through all umpteen options and this usually worked just fine...I don't really have the expertise to up/downgrade the compiler and the related libraries.
./Documentation/Changes for the minimum version numbers required and how to get updates for these packages. Beware that using excessively old versions of these packages can cause indirect errors that are very difficult to track down, so don't assume that you can just update packages when obvious problems arise during build or operation.
From the kernel Readme:
SOFTWARE REQUIREMENTS
Compiling and running the 2.4.xx kernels requires up-to-date versions of various software packages. Consult
Many sources recommend that if you don't have a critical reason to upgrade your kernel, don't. I will follow in this recommendation, as the old adage, "If it ain't broke, don't fix it," is especially true if you don't know how to fix it. Installing/uninstalling a program is far more mundane than upgrading a kernel. If you're not comfortable upgrading (downgrading) gcc, and your kernel is performing well as is (or was working fine, as the case may be), you aren't a strong candidate for a kernel upgrade. Learn the basics and fundamentals of the OS before diving headfirst into something as critical as kernel patches. Distribution providers usually do extensive testing on the kernel version included to ensure stability and compatibility.
If you're determined to go ahead with this, Linuxnewbie.org has a decent amount of information, linuxdoc.org and linuxnow.com have HOWTOs on virtually any subject (including the GCC HOWTO, although I can't say with any degree of certainty that gcc is at fault here), and the website of your distribution is probably another good source of info. If you still have problems, and turn to the net for answers, make sure to state specifically each step you took thus far and try to detail the problems you encountered, providing logs and diagnostic output when possible. In doing so, you or someone else may find you skipped a crucial step. Kernel upgrades are not to be taken lightly and, as you have experienced, can quite possibly be more trouble than they're worth.
https://www.eff.org/https-everywhere
My pet complaint is documentation which is sometimes barely there at all. Saying, as some do, "Well, what did you pay for it?" implying that its "free beer" status excuses this doesn't cut it when we're also saying "Hey, ditch your proprietary commercial stuff and use this instead!" We should coin a new acronym. WITFM. Where is the F#%@#*@ manual?
We bash M$ when they turn out buggy products and declare that they don't have a quality software process. The same is true of open source. The problem isn't closed source and the solution isn't open source. Both sides simply need to use a stronger process if they're to produce quality software.
Install a kernel, run a battery of tests. Find systemic breakers really quickly. It's not hard, it's just a matter of discipline to write the tests. As code is written, write the tests for the code. Any time a bug is found outside the normal test suite, write the test that should have found it. Automatable tests wherever possible...Part of the official build process for releasing the software should be a 100% compliance with the automated tests.
There is a comprehensive testing suite in place for linux; in fact, we just saw it in action. It involves testing the kernel on thousands of boxes simultaneously, running ten of thousands of hours of tests, and getting feedback to the developers within a few hours.
To paraphrase pogo: "We've seen the test suite, and it is us."
Now, this may seem odd or broken, but it has a few charming advantages. First, the costs are distributed amongst those that benefit most, with zero accounting overhead. Second, the response time is very fast. Third (and, IMHO, most importantly) test coverage is maintained by the same laws of statistics that make sure there is air for you each time you take a breath; if usage patterns change, the new usage is included in the tests automatically--even if no one is consciously aware that they are doing "something new" it still gets tested.
-- MarkusQ