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)
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
Certain large vendors often test things before they go out though.
I'm aware that this is not the KernelCrisis hotline; however, since it doesn't appear to be offtopic and it really bugs me and there's a heap of wizzards in here, I'd like to find out more.
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. It doesn't anymore since 2.4.10. From aborting compilations for strange missing files, up to USB race conditions and kernels which if they boot at all, sputter all sorts of gibberish, I've seen it all.
Any suggestions where to look ? Could it be that gcc 2.95.x is really too buggy and why suddenly.
I don't really have the expertise to up/downgrade the compiler and the related libraries. So, I'd be really thankful for each and every hint.
ich bin der musikant
mit taschenrechner in der hand
kraftwerk
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.
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.
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!
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.
Myself, I doubt vendors would release KERNEL
/.
;)
code without regression testing. (Userland
applications are another story; and don't
get me started on the GNU userland formal
verification process.)
Look, it's a damn bug that says more about
the linux development model (one guy, lotsa
of little chefs), than it does OSS. This says little about OSS; it speaks volumes about Linus'
flexibility in releasing "stable" code.
Now that more folks are using Linux for mission critical stuff, it would be nice if more testing would take place. This kind of bug was common and even OK in the Usenet days of linux; right now it just generates bad press... and probably even some flame wars on
Speaking of which, switch to FreeBSD for stability.
I think you have to ask the question that when Linus releases a new kernel, who is that aimed at?
While thinking about who a kernel is aimed at, we've really got to consider our role as users of the latest kernels.
On any project, regardless of size, the developers are often too close to the code to test it completely. They know too well the right thing to do. They are, in effect, well programmed users for the system that they are building, and this makes them bad testers. This is why so many companies have quality assurance departments that never interect with developers except through bug reports.
In this Free/Open community, where the entire user base is the `company', it suddenly becoms apparent, that we, the users of bleeding edge kernels are this qa department. It is we who do the final testing, it is we who write the reviews for people who stick to old kernels until they get these reviews.
Some may argue that there is already an unstable branch in which to do these things. Sure, but there are other testers for those. Often those testers aren't suitable to test stable kernels because they are now too close to the bugs that they first reported. I hope I'm making sense here.
Anyway, this is one instance where this huge qa team found a bug real fast, got it back to the developers, and they fixed/undid it in equally quick time.
Philip
Do not underestimate the value of print statements for debugging.
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
I never said "Alan Cox" kernel. By that I presume you mean the -ac series. When 2.4 was still 2.3, 2.2 was the stable tree - and it wasn't "-ac", it was just 2.2.x.
I consider 2.2.x the "stable" kernel, until 2.5 is out, and until then, I urge others to adopt the same attitude.
I don't think it is fair to complain about changes and breakages until the developers have somewhere else to make them.
Yours Sincerely, Michael.
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.
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?
This means that if you think your system was better off with the 2.2.14 kernel
2.2.14 has a number of security problems. So no, it's not always prudent to pick some kernel at random and use it, just because it's old. However, it probably is wise to grab the latest 2.2.x kernel, and go with that.
And yes, you can still find older versions of Windows, so don't pull that typical zealot FUD...It was only about a week ago that MS finally discontinued NT 4.0, which has been out for ages.
No sig is worth reading.
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.