Slashdot Mirror
2.6 Linux Kernel in Need of an Overhaul?
toadlife writes "ZDNet UK reports that Andrew Morton, the head maintainer of the Linux production kernel, is concerned about the amount of bugs in the 2.6 kernel. He is considering the possibility of dedicating an entire release cycle to fixing long standing bugs." From the article: "One problem is that few developers are motivated to work on bugs, according to Morton. This is particularly a problem for bugs that affect old computers or peripherals, as kernel developers working for corporations don't tend to care about out-of-date hardware, he said. Nowadays, many kernel developers are employed by IT companies, such as hardware manufacturers, which can cause problems as they can mainly be motivated by self-interest."
This may look like flamebait, but I'm actually serious. Microkernels are more reliable because of drivers running on userspace. If a driver crashes, it can't take down the whole system. Also, given that some microkernels are only about 3500-6000 lines of code (as opposed to Linux's million or so) it's relatively easy to make certain that the code is bug free (given that the average number of bugs is 16 bugs per 1000 lines of code according to some recent studies).
So, if the kernel needs an overhaul, the why not do it right this time? Now some may say that microkernels have a performance hit, but todays machines are certainly fast enough to render any performance hit negligible.
GJC
Gregory Casamento
## Chief Maintainer for GNUstep
As someone who is resbposible for many of those bug reports I can tell you it's not the fetures that break things. It's things like driver API cleanups that don't get all of the older drivers.
The result is that if you have reasonably common hardware the kernel is getting much more stable but for things like my non PCI sparc(compile problem with some options) or my 21 ethernet port firewall (needs special options to boot or it crashes) it has gotten more buggy.
I'm not sure a freeze will do much to fix it as a large part of the problem is that all these somewhat rare things need testing.
I still find these things get fixed rather quickly when I report them even without the freeze.
Yes, we all know the famous "blue screen of death" and I think that that single concept connected with Windows makes it unappealing. [...] Win95 & Win98 first editions would crash if you looked at them wrong.
Er.. I hate Windows as much as the next guy, but really, when was the last time you saw Windows bluescreen? Perhaps you could make your point by comparing Windows and Linux versions that aren't 11 years apart.
I believe that Linux has the ability to handle internal errors more elegantly but that's only because I've only seen it fail from hardware errors.
Yes but it handles hardware errors gracefully too: for example, one of my 24/7 machines's hard-disk died last week. I came back and found out that I couldn't write anything to it at. A quick look at the console showed a message saying "root filesystem, too many errors, remounting read-only" or something like that. The result is that data corruption was minimal *AND* the machine didn't hang. How's that for graceful? You wouldn't dream of having that in Windows.
"A door is what a dog is perpetually on the wrong side of" - Ogden Nash
Agreed. I have been forced to upgrade to 2.6 on a few computers for features that I needed that are only in the 2.6 series, but everytime it has been a problem. All of our production machines are still built with 2.4 and we purposely use hardware that is supported by the 2.4 series.
Linux has caused Microsoft to improve their products, and I have found myself removing Linux servers to replace them with Windows 2003 Server of late. On the desktop, it is not even close. I sit next to a guy who runs 2.6 on his Ubuntu machine and I laugh everytime he has to reboot. My Windows XP box only goes down rarely for updates and it does it at night when I am not there. Last time, I had over 100 days of uptime (this is a desktop machine). I rarely ever see the BSOD anymore and if I do it is almost always caused by a hardware problem. That is what I *USED* to be able to count on with Linux - if it crashed, there was a hardware issue. Now, with 2.6, I've lost that.
There are coworkers of mine who would have fainted three years ago if they heard me say something like this, but Linux just isn't the lean, reliable operating system it used to be.
--If you don't test it, it won't work. Guaranteed.
I follow Ubuntu with the latest kernel updates and I tell you with every update performance increases.. .When I booted Windows I used to feel the difference, but not anymore. I think the quality of the kernel is fine. There other people that need to improve in quality, e.g. the rest of the free apps, esp packagers who have to make the thing to just work.. What will I do with stability if nothing works? Am I going to just look at the computer while its all stable doing nothing?
Some of the above posts say "I don't notice any problems". I'm guessing some of the bugs nobody has fixed are somewhat obscure. There is a well known bug when Linux mounts large XFS file systems via NFS that bothered me regularly - large directories could not be searched, deleted, etc. Now I have a Mac working with that flawlessly. These are the types of bugs - annoying, but non-fatal - that few people want to fix.
Add a "highscore list" and it's already hitting home.
No, don't mod me funny. I mean it. Make it a page every halfway important person in the OS-community wants to read, make it the place to go looking of you're headhunting for a person with fixing skills.
Today, you rarely if ever get to start a new project. Most of the time, you're hired for a project that's been running for ages. And there, you don't need a coder who can pull fast algos out of his rear, you need people who can deal with alien code, understand it quickly and debug it. And there you'd have those people, listed. The top debuggers of the world.
Just make sure HR gets to read it and they know their applicant list.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
- Split the buffer into segments that can fit in a packet.
- Add TCP headers.
- Add IP headers.
- Add Ethernet headers
- Send to the hardware's output buffer
On DragonFly, each of these steps could be performed by a separate thread, passing the processed buffer between them, and if it worked at all then you could guarantee that it was correct. On Linux, the amount of locking required would mean that a system this complex would be likely to create locking bugs. Looking through the Linux bug database, it seems that a significant number of bugs are currently lock-related.I am TheRaven on Soylent News