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 Linus put about to be released kernels through any tests in attempt to avoid bugs like these? Does anyone else remember the brown paper bag bug at the begining of the 2.2 series?
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
Users, doing the QA in Linux for over 10 years!
----- One piece short of Legoland
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.
Off the top of my head, Mozilla is the only large Open Source project I can think of that has a reliable testing process. I'm sure there are others of course, it just seems that Linux is not one of them. Saying "Release early, release often" and wait for your users to find your bugs is nice in practice, but for large projects you need to have a more structured approach to testing, at least IMHO. Obviously there is some small Unit & Intergration testing done when the code is written and the patches applied, but that won't catch things like this in general. Whats needed is an overall testing plan.
Maybe it's about time the Open Source world started paying more attention to testing?
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.
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
I suppose your article should be moderated as "cynical" - or is that option unavailable? Currently, Linus "stable" kernels look pretty unusable (including a basically untested VM, which is just a bad joke in a "stable" kernel, and including near-daily releases of so-called stable kernels which include new bugs). On the other hand, current -ac kernels look like they work nicely, with a usable VM, without crashing the system or part of it. This is just a bad joke of a development model.
Frankly, I'm starting to consider *BSD the better option.
(I've been a Linux user since somewhere in the 1.1 kernel series, but this is really starting to frustrate me.)
...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.
Nowdays we get a newkernel spit out every second day and people instantly downloads it.
thenthey start to complain about lackof testing.
YOU are the ones who should testthis folks.
if you dont like it, why change kernel.
my main machine still running 2.0.30
why ? well i dont need any of the newthings.
just because its new and shiny, it doesnt have to be better folks.
with 2 yearsof uptime, i would never even think of swapping kernel.
andif i find i abug, i dont complain, instead i fix it, that is the way of open source.
learn to code before complaining people, it really isnt all that hard.
my main question is why download a new "release"
if you arent prepared for bugs orto sort them out?. No one, and i mean nooo one who codes can make a totally bugfree product.
/ J.Thorsell Sysadm.
[toasters ? we don't need no stinking toasters!]
First of all, let's all remember that the amount of money we are paying for the linux kernel is $0.00. Secondely, if you are bothered by the testing process, download some pre-releases and test it yourself. Thirdly, this kernel was not included in any linux package that I know of, and we all know that Mandrake, Redhat, and all the other linux packages, do testing themselves, and usually don't release the bleeding edge kernel in their releases, so the amount of exposure is minimal. Should 2.4.11 been released, well no, but it was and it was fixed quickely, and you can always revert back one version if something is not working. So everyone take a deep breath, and remember, IT'S FREE, a lot of these guys are submitting these patches on their spare time. What have you done to help out?
KidA
"Karma can only be portioned out by the cosmos." -Homer Simpson
Whethor or not it's free has nothing to do with it. If you want to compete with Windows, you can't say, "We have more bugs but hey it's FREE!". The whole argument FOR open source is that it's better software AND it's free (as in purchase price), not that it's free and "almost as good" software. So, yes, you must hold Linux to the same standards that you hold OS X or Windows too.
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.
In my opinion something like this should not, but can happen. Improving quality is a reasonable goal for the Linux kernel, but really, we are not supposed to scream at the developers because it happens. (I don't mean the parent's author has screamed... some others have here.)
I couldn't agree more. Testing is incredibly important for software projects and automated tests makes sure that certain test are not forgotten.
GCC has a test suite: http://gcc.gnu.org/testresults/ and uses the test suite as a formal release criterion. The GCC team also uses those tests as benchmarks for the compiler.
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
Linux isn't in competition with Windows. Linux isn't an operating system. A GNU/Linux system can compete with Windows, and it might even *gasp* not use the latest release of the Linux kernel. If you want an operating system, install a distro and use the distribution's current, tested kernel. Don't follow the Linux kernel development and install the latest and greatest kernel unless it's Linux, not a replacement for Windows, you're interested in. There's no reason for most users to always use the latest kernel.
I do agree that the latest releases haven't been tested as much as they should have been before being released as stable, but the competing with Windows point is moot.