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
This is why projects like Debian's kFreeBSD are important - so that if the Linux kernel does run amok completely (or at least degenerate significantly), we can continue using various Linux ~distributions~ - just with a different engine room.
When most people think "Linux", they're usually thinking of all the commonly associated open source software bundled as a distribution. If you can swap out the kernel but keep the same GUI, the same traditional *nix shells and CLI tools they're used to - will people really care that much?
OTOH, maybe it's time Linux looked at going microkernel. Maintaining a monolithic kernel that just keeps getting bigger and bigger can't be an easy task. At least a microkernel would allow a degree of separation between the kernel proper, and the various hardware drivers, networking stacks, filesystems etc.
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.
There may come a time very soon where a project will form to develop an unencumbered, DRM free, computer system. Perhaps using an embedded CPU or even discrete components, if necessary. Doesn't seem so outrageous these days, does it?
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.
You don't do Windows Update very often, do you?
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.
Use something that cares more about quality than new features, like the *BSD.
10 year old drivers written for Windows NT 3.1 still run on Windows Server 2003 today. The Windows kernel API is stable, and Microsoft puts a lot of effort into maintaining backwards compatibility. Windows has many faults -- this is something it does right.
10 day old drivers written for Linux may need tweaks as soon as the next kernel is released. The Linux kernel API is a moving target. The freedom to improve the kernel API with each release has benefits, but it also has costs. Nobody should act surprised that old Linux drivers without active maintainers are failing on new kernels.
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.
The Linux Maintenance team lead was quoted in a recent CNET article that he htought 2.6 was getting buggier. What was even more disturbing was that he based this on an impression of more bug reports coming in, that he didn't have stats.
No Stats!!!
How can you manage a project like Linux and not have a system with solid bug stats for tracking trends. Its wasy to realease software on schedule if you are not tracking the quality of the release.
A software project without regular bug trend reports is a diaster waiting to happen. This short of development by interest rather than by job assignment has been an OS weakness.
A manager without stats of his repsonsiblity should upset anyone counting in the product.
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.
I can't tell you how many times the exact opposite has happened to me. I have had to spend hours getting X to work with the hardware that is on my machine at the time. Some hardware is easier than others, but you have to admit, getting video up and running is much easier in Windows than Linux.
I have a P2BD motherboard with two 500MHz P3 processors. This was state-of-the-art in 1999, but is obsolete nowadays.
... is the best way to catch odd race conditions and timing-related issues, which is what my problem probably is.
Running FC5, I get random system lockups, usually when the system is running a light load (X, a few desktop apps, maybe a compile in the background).
The system is solid-as-a-rock when running FC4 and Windows XP -- so I know I don't have dodgy hardware.
Will this bug show up in a dual Operon server? Maybe not. The critical section (or race condition, or whatever is triggering the bug) may only show up on CPUs with certain timing intervals. So maybe folks running "modern" hardware won't see it. But maybe when folks upgrade to the new quad-core Megillah processors, the crucial critical section may be exposed.
Debugging and testing on a variety of hardware -- old, new, fast, slow
Why don't I knuckle down and debug it? I'm a father, and all of my spare time is spent with Disney characters, My Little Ponies, and Dora the Explorah. Are you a dad? If not, you won't understand.
We used to have two trees being worked on concurrently. Where (x.y.z) if y was even it was the stable branch (just bug fixes and occasional new code for important hardware) and if y was odd is was the unstable/development branch. It might be a good idea to return to this development process.
Actually I'm in favor of just forking the unstable/development Linux tree into seperate trees maintained by different people. This is somewhat being done now as huge patchsets. Have Linus work on the super-tree or the official tree. Then maybe have Alan Cox have his own tree, Morton has his own tree, Kolivas have his own tree.. and etc. With git this is actually pretty easy.
The best education consists in immunizing people against systematic attempts at education. - Paul Feyerabend
If it takes an entire developement cycle to simply improve the current version's bugs.
Why would you spend a cycle to _improve_ bugs instead of _fixing_ them ?
----
http://www.engrish.com/
I'd tell you the chances of this story being a dupe, but you wouldn't like it.
"Honestly 2.6 is an absolute disgrace"
I'd say this has to be a surprise to anyone. For all what I can say, 2.6 is exactly where Linus Torvalds wanted it to be (though I can't say what his deep motivations are).
The very moment Linus said "we'll abandon the odd-inestable even-stable release cycle; I want the distributions fixing the kernel while we work on new features" is the moment current situation came to live.
Big distributions (the ones that pay most of those kernel development hackers) are motivated -surprise, by money, and they work mainly on:
a) Engaging deals with hardware vendors (thus, no surprise older hardware is going into oblivion; hardware vendors want you buying new hardware, not squeezing all power from your older one).
b) Gaining relative advantages against competency (other Linux distributions), thus less and less stable code goes to the main kernel branch and more and more patches go into each distribution's kernel. It's open source, true, but it is becoming more and more difficult each day to integrate any given patch on other kernel branches (and "true" "lone star" developers are less and less motivated to engage their own projects if only because the increasing dificulty on staying up to date with an ever-changing kernel to integrate their patches against). Thus only "barebones" new functionality goes into main kernel branch while the "fine tunning" stays within ie. redhat's or suse headquarters (and try to cleanly extract them from their source, if you dare affront the task).
All in all, this is a situation that favour the most the big companies which can affront the costs of dealing with the current situation, while the true self-motivated hackers that made Linux what it become are relegated to minor tasks (if they want to work on them, which is becoming more and more uncommon due the overwhelming difficulties).
So, to a certain degree the end result is that corporations have found their way to "tame" Linux, making it from the hacker's proud it once were into another money cow.
I see a XP blue screen every day on my machine. I have tested the hardware and it's perfect. If only happens when I run a particular software over an extented period of time. I decline to name it, but its not a display driver or such and its not even a resource hog. It basically writes to te registry a LOT and the registry size becomes 200+MB. After which I might see an error or find the blue screen. .avi files. The same files on the same drive that Linux has no problem with.
In Windows there are NO logs, no clues, NOTHING to indicate what the problem might be. You're completely blind. The errors are different every time. Don't ask me to re install, I've done that several times.
With the latest reinstall, I'm getting another Windows lock up: it only happens randomly with
In free software, the line is drawn when needed and it never retards anything. ALSA, for example, has OSS driver support so lots of really crusty old sound cards still work and work well. That has not kept people from making or working on newer cards. Old free binaries that no one maintained work about as well or better than old non free binaries. Typically people make "old libs" packages to support both, so you might still be able to run that ancient non-free copy of Word Perfect for Linux. Chances are that some newer package, like KWord, will do the same things for you and you don't need the old package afterall. In the case of a free package, you can fix the source yourself if you really need it an no one else has the same need, but that's really rare. One of the reasons free software works is because enough people need the same things done to make cooperation possible. A free package only really dies when no one really needs it.
Friends don't help friends install M$ junk.
There is code auditing project going on within the Linux project. It's mostly for security auditing and works in obscurity mode (vs security). There have been hundreds of vulnerabilities fixed silently with just "ohh it was ugly, had to fix it" or something similar in the patch comments. That's the modus operandi for Linux people it seems - especially Linus is notorious.
The worst part is that you can't get without horrible amount of work (reading all the patch code and evaluating the impact and patching yourself) the bug and security fixes without getting also all the new bugs.. Erm, features.
The *BSD projects seem to work a lot saner. Sure their kernels lack a few things that would be nice (v4l2 equivalent for instance) but the basics are just rock solid and way more secure than what 2.6 kernel series can ever offer.
- 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
I actually had a job working on such an OS.
First of all, glue isn't free. You have all these "simple" parts with complex interactions. Those interactions can lead to nightmarish bugs.
The glue also makes things slow, so you'll probably bypass it. NT and NeXT did.
Second of all, the big problem is getting the hardware into some screwy state. You can freeze up the PCI bus. You can cause a "screaming interrupt", which is when an interrupt just keeps coming and won't stop. That sucks 100% CPU time doing nothing useful, and does even worse if IRQs are shared. You can cause a DMA engine to write to the wrong memory. Consider what happens when USB traffic gets written over top of the microkernel's scheduler. Memory protection won't save you from DMA.
I strongly agree with Linus: microkernels come from foolishness or fraud.
I thought it was satire also until I searched a little more and read the non-tech items. Unfortunately, I have met people like this. People who believe anything they are told as long as the people doing the telling are from their church or share their beliefs. The fact that there are so many holes in the logic on so many levels apparently does not matter.
"Saying that Linux is inferior to Windows because more people use Windows is like saying that all restaurants are inferi
You are a newbie! Linus and the other kernel toilers have for years had the attitude that making the kernel stable and secure was the job of the distributors. Saying that stability and security has been put on the back burner is being quite generous indeed.
It has nothing to do with the people reading the page as much as it has to do with the fact that there are -in the real, non-satirical world- actual right-wing nutjobs ^W pundits who make shelly look like a democrat. For instance, read the comments at either little green footballs or free republic and you'll see why it's hard to distinguish a parody of right-wing rhetoric from the real deal.
Hell, for that matter read Ann Coulter's material (though a lot of people think she's merely a professional troll herself).
My laptop is 8 years old. It can't run many new apps no matter what. Oh, it probably could, if I don't mind 5 minute boot times or application launch. 133MHz. RAM is maxed out at 144mb. Hard drive, 4gig. I'm not going to try to run XP or Office 2003 on it. Photoshop CS? don't think so. Premeire? Yeah, if I got 50 years to render a 10 second clip. What new apps are you going to run on a perfectly functional MMX or 486? A lot of new software requires new hardware. They're getting just as bloated as the kernel. There's nobody out there trying to make their latest and greatest work on all hardware, old and new. Linux is the only one trying, and it's doing pretty well considering what it's trying to do. I'm just not sure it's a good strategy. There will have to be a point where you can only go so far back before you start losing control. It seems we are reaching that point. Hey, I would love to try to run OSX on my old Mac IIx(if I still had it), but it ain't gonna happen. It'll just have to live with "buggy" old OS9(and I'm not sure if that would run on a 68K) and Office 4.3. All those new features you want look great on a 2GHz P4. I would love to see how well they work on a 300MHz PII. You need the patience of a monk to launch Mozilla. Open Office gives me time to make a three course dinner before it's ready. Slight exaggeration, but I hope you see my point. Quick question, what's "old" hardware? PII? MMX? 486? To me, I would guess anything before P3. This ssems to be the minimum for today's stuff. So for 2.6, why don't drop support for anything older than the P3 and go from there? Why does a new kernel need to support a 386? What new programs will run on it? Then I don't have to work so hard whittling it down to make a boot floppy. We could probably cut support for the floppy now that we can boot from USB sticks. My first kernel source was a little over 5 meg (2.0.34) Now it's 48 meg. I would think it's time for a new direction.
:-)
Suppose I buy a new laptop. Now I have to wait "6 months to a year" before starting to use it?
No, of course not. It's a suggestion to help minimize hardware support problems. When something new like USB or firewire or wireless networking comes out, it takes a while for the kernel to catch up. What good is buying a machine with SATA drives if the kernel can't support it? Obviously, for developers and hackers and experimenters, it's a completely different story. To me, that's what Linux is still about. It's the experimenters who got it this far, and I want to see that spirit stay alive, [OT rant] but now it's getting bogged down in business with all the inherent BS. [/OT rant]
Now you got my curiousity up. I gotta see how long it takes to compile and boot a 2.6 kermel on the laptop, and play with Open Office 2.0.2. and Cinerella. I wonder if I'll live long enough to see the results
What?
So true, this combined with the fact that by the time you get to test a "new" kernel release, there is already a new release. Then everyone starts bitching about how no one is testing each others patches. I'm with you. so i'll throw in my vote for the old system infact again, this should be officially addressed. The old system was indeed, melded for stability. This new "stable" just really means. It compiled on MOST platforms, not all.
Initially I knew it would eventually devolve into this but everyone was saying extremely large or new features would be able to get alot more testing. That's not happening though, the amount of people testing each release is different and then you have people like me who have to sit around and deal with or work around bugs, which you'd never suspect lead back to the kernel but low and behold, its becoming more and more common, especially with new chipsets. Then the effort involved in diagnosing and reporting takes time, sometimes weeks and in extreme cases months. By that time we are on a new release already.
FreeBSD certainly doesn't have the cutting/bleeding edge hardware support that linux enjoys, but I think the whole "18 months till FreeBSD supports it" is a little off. I have a new A64 dual core machine with the absolute latest and greatest MB from ASUS, a GeForce 7800GT, and a Areca 1210 PCIE SATAII Raid controller and FreeBSD 6 supports everything.
:(
You mentioned "audio, movies, and 3D graphics". Well....
Sound:Yeah, sounds come out of my speakers - check
Video: I have AMarok/mplayer/noatun/Realplayer installed here, and they work fine. - check
3D Graphics: 80FPS at 1280x1024 in the linux version of America's Army 2.5 - check
The one thing I don't have is support for my TV Tuner card. There is a driver for it that uses a wrapper around the binary Windows driver, but it's broken in FreeBSD 6.x (works in 5.x).
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.