To read all comments associated with this story, please click here.
Instead of listening to him, how about listening to the real Linux kernel developers?
How about Andrew Morton?
http://lwn.net/Articles/285088/
Q: Is it your opinion that the quality of the kernel is in decline? Most developers seem to be pretty sanguine about the overall quality problem...
A: I used to think it was in decline, and I think that I might think that it still is. I see so many regressions which we never fix.
Or Dave Jones?
http://www.kroah.com/log/linux/ols_2006_keynote.html
"Last year Dave Jones told everyone that the kernel was going to pieces, with loads of bugs being found and no end in sight."
Maybe you have missed the discussion where Alan Cox quits as a developer because Alan argues that the Linux regressions should be fixed correctly, which may break user applications? And Linus says that if user applications breaks, then you should not fix that Kernel issue correctly. Instead you should preserve the old behavior so user apps doesnt break. Alan complains on the Linux bugs, Linus says he shouldnt mind them.
http://lkml.org/lkml/2009/7/24/182
http://lkml.org/lkml/2009/7/28/375
"Quite frankly, I don't understand why I should even have to bring these issues up. You should have tried to fix the problem immediately, without arguing against fixing the kernel. Without blaming user space. Without making idiotic excuses for bad kernel behavior.
The fact is, breaking regular user applications is simply not acceptable. Trying to blame kernel breakage on the app being "buggy" is not ok. And arguing for almost a week against fixing it - that's just crazy.
Linus"
Couple this with Linux constantly evolving API/ABIs and you have stability problems. Whenever Linus rewrites big part of the code (which he does frequently, "Linux has no design, it evolves constantly like biology") you introduce new bugs. Some say that it takes Service Pack 1 to iron out the most pressing bugs in Windows. What would happen if Windows were rewritten all the time? The bugs would never be squashed. You debug some code, and suddenly it is rewritten and you have new bugs, etc, ad naseum. So you have problems with Linux being buggy and scaling bad on Big Iron. Admittedly, a stripped down Linux with no luggage, scales well on large clusters, which is basically a bunch of computers on a network - like those on top500. But Big Iron is another thing, there Linux scales bad.
I didn't intend to sound offensive. I just pointed out some simple facts that come from my own experience.
I also don't think it's that much important what kind of OSs I choose to run my other machines, but if you're really interrested: mostly OpenBSD, FreeBSD and Haiku [it's in a very early stage of development and it SERIOUSLY lacks good security mechanisms for now, but I run it succesfully on one of my desktop machines, with couple of tricks of course and it's pretty stable, fast, cohesive and well written]. I used to run other OSs in the past, but I don't actually make any use of them anymore.
Regards





Member since:
2007-11-23
And that's what I always say [although I have one machine with linux, among other machines with other OSs]:
linux kernel is a mess and it makes it a real pain in the ass. You can't have a trust in a mess, unfortunately.
Code quality is something that should have the highest priority. That would eliminate most of the serious bugs.