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
I would think that this is the testing plan. Let people who are interested in working with the bleeding edge do just that. If you're running a production environment, use a stable kernel. If your working on the bleeding edge, expect to find and report bugs. The bug was only out for one day, and its already been fixed!! You wouldn't see that with most commercial software now, would you?
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.
Personally I'm sticking with 2.4.9 until 2.4.12 hangs around for a while. I like to see open source developing things quickly, but having 2 kernel releases in 2 days is a little absurd. I think Linus should slow down a little and make sure to hammer out glaring errors like having something defined incorrectly in a file. We'll see if things improve once the 2.5.x series comes out though.
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.
2.4.11 wouldn't even compile for me with either
the old or new Adaptec 7xxx driver enabled. This is the 3rd or 4th 2.4.x kernel that would not compile "out of the box" for me. 2.4.9-ac18 compiled and seems OK on that particular box.
On the bright side, 2.4.11 does seem to have decent VM. And the firewire support seems to be better than before with my Digital 8 camcorder.
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.
But unless an upgraded kernel has something that you need or desire, why would you upgrade at all? Once a version is running, just stick with it.
I'm of the belief that one of the greatest assets to open source is the fact that all older versions are still available for the vast majority of projects. This means that if you think your system was better off with the 2.2.14 kernel, the 2.67 gcc and libc-5, you can still get those, and load them onto a system built fairly recently (OK, no USB... but that's kinda what I'm talking about here.)
Try doing this with any microsoft product. Go to a store and ask for Windows 95. It's getting hard to find 98. Try asking to buy office 97. Or any older version tha might work really well on a super fast system.
So, to get back on topic, if you have a kernel that works, why would you even think about upgrading unless you are testing/comparing/a hobbyest.
I demand a million helicopters and a DOLLAR!
Hey, i wrote it, and i don't get the joke :)
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 -------------------
On Thu, 11 Oct 2001, Linus Torvalds wrote: ;)
> Not a good week.
>
> On the other hand, the good news is that I'll open 2.5.x RSN, just
> because Alan is so much better at maintaining things
On Thu, 2001-10-11 at 07:54, Alan Cox wrote:
> > And will Alan release 2.4.13 asap with Rik's VM? - (sorry, couldn't resist)
>
> I think 2.4.13 will be a Linus release
Napster-to-go says "Fill and refill your compatible MP3 player", which is a lie. It's not MP3. It's WMA with DRM.
Since the beginning, OSS users pay their software doing testing, documentation and, if they can, code.
You know what? Many people are happy with that. Because they discovered that they stll end up with a better product that most commercial stuff, at a lower price.
The reason for this is that, given current software complexity, alpha-level tests,done in laboratory, can only do so much [and often not even that because smart managers cuts test budgets to save their ass].
That is wy _every_ commercial company does beta-testing (e.g. asks user to test their product for them).
In OSS, beta testing is simply done putting out a new release (sometime dubbed 'beta' or 'unstable', but you shold always expect potential troubles).
Whoever don't like this is free to pay whatever company they want for doing their own Test or QA on whatever software they choose to use.
Ciao
----
FB
And remember - while some vendors drag out beta testing with sub-par software (the rest of the bugs will get flushed out in beat they say), MOST of the time the Linux kernels are usable the day they come out.
But be realistic - anyone who downloads, builds, and installs a new Linux kernel within 30 days of its release is a defacto beta tester. No sysadmin in their right mind would install a new kernel on a production server until its been run for a bit. SO all of us who love to grab the kernel and put it on desktops, small non mission critical servers that can go down, etc are flushing out any remaining bugs so that mission criticla server admins can sit back and see which kernels to move to (plus other factors like existing bug fixes, new device support, etc)
So those of you faulting Linus for releasing this kernel with this bug - give it a rest. It was an obscure bug that only cropped up if the software did something it really shouldn't have (ie bad design). I can't imagine a commercial vendor would have caught this bug in testing either - they'd have found it in beta just like Linus did. After all, I bet 99.9% of you who are already running 2.4.11 thought it was great till you read /. this morning :)
I for one think the current system works well. Yes, Linus may put stuff in faster than Alan and there are pros/cons to both - for all the folks saying Linus was putting too much in others would say AC is waiting too long. But step back and think about how great we Linux users have it. Stable kernels with many fixes coming out monthly from Linus with bigger more feature rich kernels available from -ac How awesome is that?
Top Most Bizarre/Disturbing Error Messages
Um, you should use "make oldconfig" when you're upgrading kernels and using the same config file. It'll prompt you for any new options.
Windows for games
:)
Personally, I call it Wintendo.
On the flip side, look how many patches and service packs come out for Windows, but they don't make the Slashdot home page. Good to see we're covering the bad as well as the good.
What are you talking about ? Seems like Slashdot is constantly running stories about this or that bug in Outlook, or Powerpoint, or IE, or....
If WinXP had as big a showstopper flaw as this one in 2.4.11, you can bet the criticism here would be loud, ridiculing, and vociferous, even if MS released a patch for it in the same timeframe. As it is, there is really no criticism, just a big mutual love-in. You are deluded if you think Linux flaws are covered with the same scrutiny here that Windows' shortcomings are.
It is the right constant. Tim Waugh has released a linux-booboo.patch that corrects the constant in ieee1284_ops.c to IEEE1284_PH_ECP_DIR_UNKNOWN.
Linux 2.4.12 compiles nicely for me now that I've integrated that patch.
No, you have it completely wrong. Of course you do pre-relese testing, and better pre-release testing is always a good thing if you can manage it.
Open source is a paradigm shift. The standard way of thinking about releases, which never was very practical, IMHO, is misleading.
There are two outmoded connotations to the word "release" which you need to free yourself from. First, is that "release" is a indicator of some absolute level of quality: that the number of bugs is small and their severity is low. Second, that the "Current Release" is the best version for you.
I don't think the idea of "release quality" was ever realistic, except in some limited circumstances. Another way of putting this is that the true test of a product is when it is put into actual widespread use. What a release represents in most case is a slowing of velocity of change, at which point more testing benefit is gained by putting the product into use than by our contrived tests. This slowed velocity is sometimes a sign that the bugs are few and not very severe, but it is always a sign that the developer's ingenuity or energy is exhausted. There are always more bugs. You have to be re-energized and refocused by reports of needs or problems by people in the field.
Sometimes this comes quickly. I personally have "released" software which I almost immediately retracted because of a severe flaw I missed. In any case, more energy and ingenuity in testing is always better, but the marginal value of internal testing at some point is always outweighed by real world tests.
The second mistaken idea is that the "current release" is always best. This idea was never very credible -- it's more of a fiction which enriches the software developer. Ask a common user, and you will find they often favor older versions of the tools they use.
To bring this back to testing, one benefit of open source or free software for something like an operating system is that I can get a better tested product (in real world terms) by being selective about which release I choose.
And, the level of testing for a complex product like the kernel is not a single metric -- it depends on your exact configuration and requirements. Thus for some embedded developers, versions of the kernel in the 1.x range are the best tested alternatives to use. For most users today, late version of the 2.2 tree are the best alternatives. For people with multiple processors, their best bet may be somewhere in the 2.4 tree, although it may not be ready for mainstream use.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
...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.
This is the stable-series kernel.
I really feel that 2.3 was turned into 2.4 because of marketing reasons, since it is obvious that 2.4 isn't ready yet.
2.2->2.4 was supposed to go faster than 2.0->2.2 took (ages). As the release of 2.4 was postponed and postponed the pressure got (too) big to give in and release it.
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.
[
This is only the second kernel I will have built (just installed Slackware 8.0 for the first time, and built 2.4.11)...Can I reuse the configuration file created by "make menuconfig" with 2.4.12, or should I try and re-select all the options I had previously?
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
I get the impression that Linus is "rushing" releases of 2.4.x in an atempt to get it mature. Perhaps then he can say, "it's stable/it works" so that development on 2.6.x/3.0.x(?) can open up full swing? He mention in the interview posted yesterday that he wouldn't really jump into that until 2.4.x was a little older.
:)
*shrug*
It just seems that the patch on this tree are coming out faster than any of the other branches before it. And many more "issues" slipping through the cracks including controversy and laziness. I don't know about the rest of you, but I would prefer slower progress in favor of more careful, more tested releases.
Why bother.
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.
This is easy: download patch-2.4.11-dontuse.bz2 AND patch-2.4.12.bz2, rename the former to patch-2.4.11.bz2, and run the patch-kernel script. It will see that it needs to apply both patches and will then sing all the magic songs for you.
Linux user since early January 1992.
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
The Gnu Compiler Suite has an extensive regression test. See for example "GCC Automated Testing System" or "GCC 2.95 Regression Test Strategy"
If you need to write a regression test for your own software check out DejaGnu.
--Andre
Stanford already has a test suite for linux kernels, and it fixes hundreds of bugs that Alan Cox incorporates and passes along.
The checker lives here