Messages in this thread |  | | Date | Wed, 3 Oct 2001 20:36:01 -0400 | Subject | Re: kernel changes | From | (bill davidsen) |
| |
In article <07f901c148b8$720a6230$1a01a8c0@allyourbase> dmaas@dcine.com wrote: | > The answer is to treat all linus/ac/aa/... kernels as development | > kernels. Don't treat anything as stable until it's been through | > a real QA cycle. | | I definitely have to second what you guys are saying here... 2.2.x is the | stable kernel series, 2.4.x is for caffeine-fueled developers who read the | LKML at least once every day...
Not really. I have found that 2.4 kernels are usefully stable if you pick them carefully.
| e.g. I consider it extremely embarrassing that fundamental drivers like | aic7xxx, emu10k1, tulip, etc. are breaking regularly in the mainline | kernels. I haven't had any trouble with things like this in Windows for | several years now... Sure the Windows drivers are probably a few percent | slower, but as Nathan Myers once wrote, "It is meaningless to compare the | efficiency of a running system against one which might have done some | operations faster if it had not crashed."
Again, given the choice of the o/s failing every few months or not using your hardware, where do you go? I haven't found a 2.2 kernel which like running multiple NICs at 85% of max most of the time, while several of the 2.4.kernels, most recently 2.4.6 will.
| I think we all owe major thanks to Alan Cox, who does his best to keep the | house in order amidst the chaos of kernel development (kudos to Mr. Cox for | holding on to Rik's VM design long enough for it to stabilize!). If anything | I wish there were a third primary maintainer who would take an even more | conservative stance, hanging maybe 2 minor versions behind Linus and -ac, | and only picking up changes that have been tested widely. Hmm, the people | working on distro kernels are probably just about doing this already... | Maybe if they could combine efforts somehow?
A quick look at the c.o.l.development.system will show I said ages ago that we should QA "stable" kernel releases before sending them out. I offered to set up a group to do that for each release candidate, but there was no interest.
The VM work is really needed, but I wish the development was in "pre" kernels, not releases. I've been playing while on vacation, and 2.4.9-ac14 looks much better, 2.4.9-ac16 has minor problems on a machine I won't see until I "get back to work," and I haven't deceded if I want to try 2.4.9-ac18 or not. Sadly, horror stories on 2.4.10 have suggested that I let others try that.
Given the load of totally new VM stuff dropped in, I admit I'd like to see useful stuff which only takes effect if configured (the so-called Athlon patch) in the kernel, since many systems simply will not run an Athlon kernel without it. I only wish the preempt was being pushed as hard as VM, it looks really good on loaded machines.
Perhaps it's time for 2.5 indeed.
-- bill davidsen <davidsen@tmr.com> "If I were a diplomat, in the best case I'd go hungry. In the worst case, people would die." -- Robert Lipe
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |