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
version x.y.odd_number aren't stable releases.
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?
Certain large vendors often test things before they go out though.
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
No, version x.odd_number.y is unstable. Once you have x.even_number, they're all supposed to be stable kernels.
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".
Please correct me if I am wrong.
Read it here
Haha! I wish these people would learn how to code, people in my freshmen CS courses have written better OS's than this! I mean, really, was there no testing done on this? How many bugs don't we know about? What? This happened in Linux, not Windows? Oh, well you know, everyone does make mistakes. Look at the power of open source. Within days, service pack...I mean, a patch was out.
Funny! 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's your damage, Heather?
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
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 know that the odd numbered kernels are experimental?
When in doubt, have a man come through a door with a gun in his hand.
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.
Go on then. Which one are YOU speaking of?
Yours Sincerely, Michael.
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.
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.
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.
Well I don't see why saying "large-vendor" must apply to M$ all the time.
/.'ers can come up with other examples. Large vendor != thorough testing.
Neither do I. But I am sure that no matter what large vendor you speak of, they have released buggy products. One particular recent incident with an IBM ATM switch (MSS) microcode release (a "stable" release) comes to mind. The company where I work were advised to upgrade to this latest release; a week later we were downgrading because of the huge network performance problems it caused. IBM withdrew the microcode release.
I'm sure other
Yours Sincerely, Michael.
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
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.
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.
;o)
That's exactly what Linus said in his 2.4.12 annoucement. But I guess you knew that already
Black holes occur when God divides by zero.
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.
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.
[
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!]
Ya, and at least we don't have to patch Windows with crap like this: ;)
--- linux/drivers/parport/ieee1284_ops.c.orig Thu Oct 11 09:40:39 2001
+++ linux/drivers/parport/ieee1284_ops.c Thu Oct 11 09:40:42 2001
@@ -362,7 +362,7 @@
} else {
DPRINTK (KERN_DEBUG "%s: ECP direction: failed to reverse\n",
port->name);
- port->ieee1284.phase = IEEE1284_PH_DIR_UNKNOWN;
[ETC]
There is no longer anything that can be done with computers that is nontrivial and clearly legal. -- Paul Phillips
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
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
Maybe the next Kernel version should be called 2002 instead of 2.5
After all, I bet 99.9% of you who are already running 2.4.11 thought it was great till you read /. this morning :)
Offtopic, but I had some problems getting crypto kernel modules going with 2.4.11, and all those USB timeouts were being a pain, so I was back to 2.4.10 before 2.4.12 even came out.
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.
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.
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.
20 January 2017: the End of an Error.
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
Due to the massive changes in the recent Linus kernels, they haven't gotten around to pushing out ext3 patches for them. Apparently the -ac kernels were easier to create patches for, since Alan decided not to merge a bunch of the stuff from 2.4.10-12. I think they said next week we should see patches for the Linus kernels.
The whole life span of 2.4.11 was less than 8 hours! Alan was probably asleep the whole time.
Slow down, cowboy! It has been 4 hours since you last posted. You must wait another few hours.
Trek movies and Linux kernels are both flaky when the version number is odd...
There's a very easy solution: Just wait for a while before you upgrade. That way you can decide for yourself how long you think the code should be tested before want to use it.
There's just one problem with it. If most people did that, bugs would take a lot longer to be found, let alone squashed. And the problem we've seen in 2.4.11 is not some obscure, minor thing that would have not have hindered stable use of the kernel. (Before you argue that, consider how severe it is, this is a show-stopper bug. Bugs in the kernel that corrupt the file system, even if they are rare, are serious problems.) This should have been caught and the fact that the bug exists indicates that whoever made the changes that created failed to even test said changes. 2.4.x is a "stable" kernel tree, and there's no reason why anyone should have to wait a couple patch levels before upgrading to the latest. There should be more thought and testing done on such a branch before releases are made. Period.
Why bother.
"showstopper flaw"? It affected one part of one program that NOBODY, other than the ppl at SUSE who are building the distro, would ever rationally run under the new kernel. Yes, people upgrade their kernels all the time, but how many of them upgrade before they run the installer?
In any case, this pointed out something awkward that the SUSE installer was doing, and it will probably not do it in the future. I'm sure there are quite a few syscalls in XP that won't work right given a particular set of obscure options. On top of that, when has MS -ever- had a rapid turn-around on bug-fixes?
my sig's at the bottom of the page.
I've heard of "release early, release often" but this is ridiculous. (-:
Actually, I can't wait to see what 2.5 development will bring us. The fact that so much is changing even in the stable kernel likely means developers will really cut loose when 2.5 work begins. I think it's actually quite exciting. (As long as 2.4 gets all its holes patched up in the near future of course..)
So many folks get mad when Linux has bugs. Most of this is because they do not understand the model.
Let us compare the Linux development of a 2.odd version to a project branch in your average software company. That project branch will be unstable and used only for feature testing.
Then, you have the 2.evens. These are equivalent to a release branch or product mainline. You expect these to be *more* stable, but you still don't expect perfect code. When these are sent to your release egnineers and Q/A, you get several small rounds of bug-fixing as a result of regression tests, feature verification and so on.
This last step can be mapped to what distribution vendors do. So, for example, we expect Red Hat to go with something like 2.4.12, but to add the parport patch into their SRPM. They will doubtless also discover several other problems, or may be dragging along patches from previous kernels that have yet to be merged.
This is the art of release engineering. There's no such thing as a developer-released product. Never was. This is the value-add that distributions give us. They act as Q/A.
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
Ummm... Let me guess. You haven't even READ the MS help files have you? At least linux has FAQs scattered across the net (also free). You don't have to go purchase a $50-$100 book on the OS to get the most out of it. I don't mean to be making excuses. We (the linux community) could be doing better. I'm just saying that "evil corporate constructs" such as managers do not usable documentation make.
Yes I do sound like a linux zealot. That's my cross to bear. My message is no less poignant or acurate.
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
So M$ releaseing buggy software onto an unsuspecting public and fixing it's bugs via service packs later is is a-ok by you then?
If the service packs were released more often, and were more targetted so I could patch a single problem that affected me without introducing a host of new ones in different areas, yes that would be OK by me. It's not really a perfect analogy though because most of what is in a service pack is user space stuff.
THe linux kernel is by far the most buggy POS "kernel" that I have ever come across in 20 years of coding!
What can I say? I'm running several different versions of the Linux kernel; I have never had any problems related to the kernel; I think I've seen one kernel panic in several machines running for several years. Maybe it's POSIX compatibility isn't as good as some other OS's, but it doesn't seem to prevent lots of software, lots of cross platform software from working well on it.
Also, to be fair, Linux is a relatively new kernel; the BSDs and their derivants are much more mature and have a common history and so would naturally be more compatible.
It is *your* responsibility to do what it takes to prevent such unforgivable disasters as 2.4.1 and 2.4.11
2.4.11 an unforgivable disaster? Aren't you being a bit theatrical here? Nobody was affected by the problems in 2.4.11; even if it had taken a month or more to catch instead a day or so, it would only have affected a few kernel heads. Virtually everyone's still on 2.2, which is pretty much the standard production kernel that ships with most distros. If you roll your own kernel for production machines, well, you had better know what you're doing. Any recent kernel is still in testing. Most of them will never appear in any shrinkwrapped boxes, and when they do they'll probably be a year old or more and very, very well proven.
Every new kernel has to be seen as experimental until it has established a track record "release" or not.
If the development methodology offends you, ignore it. Just install older kernels with a track record.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
they get released into the "stable" tree.
Perhaps, then, it can be said that they follow the "Slashdot" model of development: Post first and correct things (maybe) later.
Is your company running tools written by ma
I had been bullish on the Linus+AA kernels (2.4.10 ran pretty well with week-long uptimes) but 2.4.11 had the symlink thing and only got 8 hours up before 2.4.12, which just locked hard under load after only about 4 hours.
I guess it's time to hit 2.4.10-ac11 and see what Alan+Rik can do for me. The 2.4 series so far has been a crap shoot... I wonder if they can save it before 2.4.15-20 or so?
My vote (I don't know these people so it's by no means binding): Linus starts 2.5 and leaves this 2.4 nonsense behind (sooner we get a 2.6 the better) and Alan makes a big, ugly change to allow user-select at compile time of Rik's VM vs. AA VM. Both Rik and AA then both get to keep going nuts trying to keep the 2.4 boxes up...
STOP . AMERICA . NOW
There are three issues in the case of the Linux kernel: (1) It depends on hardware. Nobody has one of everything, so nobody could do a comprehensive test. Sometime one driver will turn out to make one assumption, and another driver will make a conflicting assumption; either will work, but not together. (2) There are a lot of situations where the specified behavior is underdetermined, and, in particular, cases where you can do a set of things the original programmers didn't expect you to do together. There won't be tests for these sorts of things. (3) There are a lot of corner cases that are hard to make happen. It's very difficult to put the kernel into certain combinations of states, so, on most trials, the situation won't even get tested. This is particularly the case with race conditions between processors and things that depend on peripheral timing.
I agree that having a test suite would be good for catching a lot of simple bugs in places that are easy to test. Sometimes a new kernel will have something that doesn't work at all, and that should get caught. But there are relatively few of these, compared to things which aren't really quite safe, although you have to look at them carefully and think about them, understanding the code, for a while, and these are the more important bugs.
Fuck off and die.
Yours Sincerely, Michael.
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.
With bzip2, you should always decompress and compare byte-for-byte against the original data before trusting the compressed data, especially for large files.
Yes, it's a hassle, but it's necessary. I've seen this byte-for-byte verification fail a number of times, usually megabytes into the original data. I find it alarming that a "lossless" algorithm (or a buggy implementation) allows this to happen, when people are known to be trusting data to this program. I have never seen gzip fail like this, nor have I heard of such failures. However, I've witnessed it repeatedly with bzip2, so I won't trust it blindly.
It would be good if a version of bzip2 would automatically feeds the compressed data and a copy of the uncompressed data to an independent piece of decompression code (which sees only the compressed data, not the data structures of the compressor) and have this byte-for-byte check happen on-the-fly during compression. Whether the bug lies in the algorithm itself or the code for the compressor or decompressor isn't important; the important thing is that this "lossless" algorithm isn't 100% reliable, and 99.9999% reliable just isn't good enough.
(And what's with the brilliant idea of requiring ".bz2" as the extension?!? Would it have been so difficult to put the version number in the header of the file like gzip does??)
Deven
"Simple things should be simple, and complex things should be possible." - Alan Kay
There was this guy at Cisco, I forget his name who did a really excellent speech at OScon (which was webcast, though I cant remember where. The speech was entitled something like "Will the future of the interned depend on Open Source?"
;)
He brought up a few really good points and one of them is that few people run their businesses off of open source software they downloaded from the web because of compatibility testing and difficulty in support (because the system may end up with a non-standard setup which may be difficult to administrate). So instead they use commercial products. Commercial != proprietary, in this case, and definitely includes Linux distributions where everything has been tested together and has a consistant administration interface.
So for the most part, these "releases" are more like "beta products" which require further testing before they are released in the production system. So what you are talking about when you say "released" is really irrelavent anyway because the kernel IS NOT aimed at production systems initially. It is aimed at developers primarily. So if you are a developer, you will find the bugs and these can be fixed
Your concept of the procedure seems to be:
1: Kernel is developed.
2: Kernel is released with little or no testing.
In actuality the process is more like:
1: Kernel is developed.
2: Kernel is released with little testing.
3: Kernel is tested by developers and distributors. If distributors find that it works, they use it.
4: Bug fixes are developed into the kernel (go to step 2, add one to z where release number is x.y.z). Some times kernels with an odd-numbered y will be released as kernels with an even numbered y by incrimenting them when they become ready for real testing.
LedgerSMB: Open source Accounting/ERP
PostgreSQL has "make check". GCC has a regression test suite.
Most CPAN modules have tests, whether trivial or comprehensive.
And these are the ones I can think of off the top of my head.
Become a FSF associate member before the low #s are used
Is it just me, or does it seem like 7.2 is a little late? I recall downloading earlier fall RedHat releases in mid september rather than mid October. If it means that the code will be of a higher quality, so be it. I don't mind the delay, but I am curious if it is coming soon, and if anyone knows when.
I guess I'm also saying pick which side of the fence you want to be on. Are we saying don't whine about what you get because you didn't pay anything for it and should therefore be expected to work harder to get it to work, or are we saying Open Source is a viable alternative to commercial software? You can't have it both ways. More to the point, your potential customers (users, if you prefer) won't let you have it both ways. People have work to do and killing a day or two of work to figure out how to make the software do something is very often not acceptable.
That about sums it up.
Remember -- you have a choice about which kernels, and which kernel patches you want to run.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
2.4.11 : a kernel that will forever live in infamy.
my sig's at the bottom of the page.