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."
A lot of times, the old debate of Windows Vs Linux covers how often the OS fails miserably. Yes, we all know the famous "blue screen of death" and I think that that single concept connected with Windows makes it unappealing. 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. Granted, I don't know enough about the inner workings of Windows or Linux but let's face it, Win95 & Win98 first editions would crash if you looked at them wrong.
Here's a possible horror story:
While the debate rages on, Linux gets more complex. Linux gains more bugs. Linux begins to aim for more end-user features. Developers get sick of maintaining other developers code and focus on making new features (asked for or un-asked for) because it gives them pride to make something new. The Linux kernel hits the same pitfalls as the Windows kernel.
If it takes an entire developement cycle to simply improve the current version's bugs, I'd gladly accept and encourage that.
My work here is dung.
"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.""
I suggest we have some more unemployed kernel developers to correct this problem.
Its about time this was recognized by the Linux developers. Every time I've tried to upgrade from 2.4.26 over the past few years, my system has become unstable and I've ended up reverting. Hopefully I'll be able to upgrade at last.
Although I am not very fluent when it comes to kernel development [read: don't have a clue] I really don't care what they decide to do. So far it works fine for my needs. :-) Have no intentions of ever going back to the big W. Ever.
Within the next few weeks here, I will be converting this system to Gentoo... we'll see what problems may be around the corner. :-)
I guess Andrew has come to the same conclusion.
I'm happy about that!
Here's a thought:
Old hardware is going to become more important as Intel/AMD work to shut out non-Windows OSes.
One problem is that few developers are motivated to work on bugs
Yeah, this is one for the "no shit sherlock" column. What did you expect to happen when you eliminated the stable/unstable cycle? At a minimum the individual parts of the kernel would achieve stability at different times so that the kernel as a whole was never stable.
This frustrates me immensely at work. I hung on to 2.4 as long as I could. Hardware compatibility pushed me to 2.6 and it just isn't as reliable.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
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
I think at some point you need to draw the line regarding support for older hardware and peripherals. I mean, excessive backwards compatability has retarded advancement of the industry IMHO.
End of Line.
In the words of many an open source advocate, fix it yourself. You don't need to rely on anybody else. You have the source yourself. Quit whining.
Anyone whos been playing with the newest kernels might of noticed that the option to compile drivers not expected to compile cleanly has been removed from the kernel
This is from memory, hehe i think thats hte right option.
A friend and I noticed this and at first thought it was a bug in the kernel (2.6.16?) but appently linus has "hidden" it so that only the devs can use it as he belives they need cleaning up more.
Im wondering if the two are connected...
- http://www.milkme.co.uk
If a free software developer doesn't want to do something, like fix old bugs, they won't. If this is made to be the only way they can contribute, they probably won't contribute. It's better to get some shiny, unasked for features than nothing at all in my opinion, even if it is not as good as added stability.
When Argumentum ad Hominem falls short, try Argumentum ad Matrem
that the reason IE failed miserably is because the authors eventually STOPPED fixing bugs. We don't want Linux to take the same road, do we?
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?
The number of bugs. "Bug" is a countable noun, like "chair", not an uncountable noun, like "salt".
# cat
Damn, my RAM is full of llamas.
So, there are two relevant aspects to it. Probably more.
The 2.6 Kernel has been plagued by bad bugs. On the other hand, one way or another you need it for a multimedia-enabled desktop on more modern hardware (compared to 2.4). From that point of view, the proposal is fantastic. Otherwise we see the quality of the kernel of our beloved OS going down.
2.6 has never seen a phase of consolidation, really. Therefore, the proposal is almost overdue.
It would be badly short-sighted to think of quick ROI (as the IT companies usually aspire), since the troubles only multiply with further advances.
Yes, please, Andrew, get stability back into 2.6 - Though I have no single word of say in this, I thrust up both hands in favour !
Maybe there are some thumb-screws needed for the contributors: As long as the bug level stands above a certain threshold, no enhancements will be accepted.
There is also a political aspect to it: we have always argued about re-use of legacy hardware. This becomes even more important with Vista on the horizon. The kernel must not lose the 'caring' attitude. It must be trustworthy and trusted by the general public to care for more than greedy hardware manufacturers and their sick quest to replace functional hardware with most recent hardware.
Neither the article summary nor the article itself mentioned Windows. The article is about bugs in the Linux kernel, yet you use the first post to launch into a 'debate' about Linux vs. Windows, and state that despite all its failings, Linux still 'fails' better then Windows. if Linux is so much better than Windows, why do you (as in the Slashdot readership) feel the need to discuss and compare Windows at every possible chance, even when the article itself has nothing to do with Windows?
"Developers motivated by self interest"...? Isn't it
amazing what radical subversive thought can slip
though the open source ff (man -k filosofy filter).
What is the need for backwards compatibility anyway?
The Dosification of Linux?
Anyway, why not have a rarely updated, minimal branch
for ancient hardware, like anything over 3 years old?
Man, it's crazy but we have this thing where I work. Uh, what do you call those things again?
... I think they're called 'leaders.'
They are very good at convincing people to do things regardless of what they get out of it
If Andrew Morton doesn't have leadership skills, I suggest he step down and let another manager step up.
If I were in his position, I'd get everyone who's even mildly important in a room (or, failing that, an e-mail) and:
"Guys, remember back to the reason you first joined in the contribution to develop a free operating system. Now, think of all the hard work you've put into it and other people have put into it. Now, that's all in jeopardy and here's why..."
Spend some time reasoning with them and pointing out the bugs that are really really hurting the kernel. In the end, wrap up with:
"Look, I know this sucks and you're going to have to tangle with a lot of bugs that aren't even your own. But what have got if we haven't got a stable operating system? We've got another Windows, that's what. You just don't have to pay for our piece of malware. Just see this one development cycle through, I promise we'll make it as quick and painless as possible and after all is said and done, we'll have another meeting like this were anyone can suggest any crazy-ass feature they want to add. Once we pick out what we want, we'll spend the next development cycle letting our imaginations run wild. We'll make a kernel so unstable that the user'll have to re-flash their BIOS when it crashes! Then maybe we'll work on solidifying that. Right now, we just owe it to ourselves and our fans to give them something that's 100% stable and reliable."
If you can't reason with them like that, maybe you just have to accept they can't be persuaded and let them do what they want but prune their work if it detracts from your goal end system.
My work here is dung.
Maybe this is the time for a group of kernel developers to go over the code looking carefully for those long standing bugs and more important look for security problems. Do what OpenBSD did back during the 2.0-2.1 release. Even if it takes much longer (6months - 1 year) to make a new release wouldn't that be for the better. If that time period is too long then at least start to do the major audits and start putting them in on a 4 week release cycle. Granted a complete audit will probably take one or two years.
The security and stability of the Linux kernel could be greatly increased. Isn't that what we all want?
Nice house. Did you build it yourself?
No one knows what's wrong with that machine. Well, I do--it has a Windows operating system installed on it. Installing Windows is a gamble, it always was and it always will be.
My work here is dung.
In a way Linux as a whole (the kernel) is now suffering from the same problems as Debian stable once was, at least from my perspective. Do you guys remember the previous Debian stable? It remained stable for such a long time that eventually you simply needed websites like Backports to be able and run some current software since everything included with Debian was way ancient. Naturally you could run Unstable but it wasn't exactly the best approach for servers. I eventually ended up running Testing and keeping a close eye open for bug reports, exploits, etc. while not updating the box every time something new came out.
/usr/X11R6, so why couldn't they add /usr/X11R7 ?
And that is what I see happening here as well. The last really stable kernel is IMO 2.4.32. There are no new features being added, only bugs being fixed. Which is IMO exactly what is needed for serious usage since every beginner programmer knows that when you add new features to your software you will also increase the risk of more bugs popping up. These could be bugs resulting in the addition of new code and the way it cooperates with the existing code, or simply bugs which only manifistate themselves in the new routines. Unfortunatly the kernel developers don't see this or they don't care resulting in a rather stable kernel 2.4.32 which unfortunatly lacks some hardware support and certain features when compared with the rather unstable 2.6.x kernel branch.
Personally I'm worried about the future. When looking at the 2.6.x kernel I don't like what I see. When looking at the current Debian Sid and the rather rough way they implemented the new X environment I also can't help wonder if there aren't more bugs than "usual" popping up.
Anyway, this is all moot now since I have lost fait in Linux all together when it comes to server usage for quite some time. I think that Linux is suffering from its own success and it may well proof fatal in the end, although I really hope it doesn't. I still enjoy running Linux on my workstation and I'm not planning to stop. But when it comes to serious work, like my server, my trust is now put into Sun Solaris 10. While Solaris is also moving into the Open Source environment Sun still uses their common sense and as such split their software into 3 parts: Open Source, Unstable and Stable.
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.
Of course it's more rewarding to create a new feature. First of all, no coder enjoys working on foreign code. It just doesn't "look right", doesn't "feel right", simply because everyone has his own style.
... zip.
And don't forget bragging rights. Hey, I invented some feature. Sure, some guy debugged it, but I get to slap the label to it. I might even name it after me (Hello Mr. Reiser, if you should read this...). The guy who debugs it gets
This has to change first if we want people to put in time to hack through other people's code. Appreciate the work done to get it fixed. After all, appreciation, bragging rights and "making a name" is everything you get from writing free software.
Few people do it out of generosity or because it "feels good". They want to be known. Linus might not have gotten much out of writing that Kernel, but he sure as hell has a killer paying job now. I doubt the people who wrote the original implementation of iptables/ipchains are worse off. But the debuggers? Lot of work, no name.
Pull the debuggers in front of the curtain, and you'll see people debug. If we only appreciate the people who wrote a feature in the first place, even if that feature doesn't work 100%, we won't see people debug.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Although the kernel in its current state may have some problems, much of the code also has had years of testing and works very well. That goes for most large pieces of software. While progress should not be hampered by an old codebase, it is also often a very imprudent idea to throw out years of well-tested code.
Of couse, that's ignoring all the difficult work and the time it'd take for such a rewrite.
Speaking of rewrites, would you consider rewriting Gorm? Actually, a more comparable (size-wise) rewrite would be Gorm, all of GNUstep, and X11. Frankly, I'd have to hope that you wouldn't support throwing away a lot of good code that works, just to fix a few minor issues.
The painful truth is that very few developers, in open source or otherwise, like fixing old code or old bugs. This is very true if the bug fix isn't going to be noticed by a great number of people. Face it, most of us like to write new code or improve on something that isn't working the way we want it even if it is working right.
This is what separates professional developers from the rest. We work on it regardless of how much it benefits us. We might gripe a bit but in the end we do what is asked. Sure that backend has flaws and is going to be replaced down the road but it does not excuse us from making it work now.
When you go look at some of the bugs listed in even current applications you start to see the age some have accrued. Some are rightly passed over as 1 in a million occurences but too many are skipped because it just doesn't have any allure. Note, I am not singling out people who work on Open Source, I am pointing out that the article fails to touch an area that exist but most don't want to acknowledge.
* Winners compare their achievements to their goals, losers compare theirs to that of others.
Yes, it's a good idea.
But don't waste time on bugs that only affect legacy hardware.
It would also be a good idea for some effort to be spent on consolidating, corrrecting, and updating the various lists of "Hardware supported by Linux". There are lots of such lists on the web, for example:
- not to mention the distro-specific compatible hardware lists maintained for Redhat, Mandriva,Suse, and others.
We need one correct, maintained list, not dozens of nearly-correct, usually out-of-date lists. And it seems to me that the list should depend only on the kernel version, not on the distro.
We should call the guys who write "features" Buggers. That should get them some respect for the Debuggers. I mean who wants to be called a Bugger?
My experience is that stability is dropping, even on modern hardware. You can no longer take the latest '2.6' stable kernel and expect it to keep your server running stably.
Now, you can take a Redhat or SuSE packaged kernel and find those are pretty stable.
But there is a problem; if you report a bug in a Redhat/SuSE kernel on the lk.ml you get a
'that's Redhat/SuSE problem - speak to them'.
As the 2.6.x stable tree becomes less stable, less people use them on production servers and instead
use packaged kernels. As less people use them, they get tested less - and less bugs are actually reported for them.
It is also not just a case of old hardware; in the last few kernels I've had leaks that make
a simple firewall die repeatedly after a few months, I've got a machine with a slow RAM kernel leak
that makes a simple DHCP server fall over every few months, and I've had a 2.6.1x kernel that couldn't
run an NFS server for 24 hours without falling over.
It ain't nice - but these are my experiences.
Dave
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.
At least so I thought, ie. once 2.6.17 is out, there will be a separate branch based on 2.6.16 (2.6.16.y, continuing past the current series) that would constitute as a "stable" branch where no new features would be added, and focus would be on fixing bugs and stability..
So, is the problem already solved?
well they should finally fix outstanding bugs. Wasn't the whole point that OSS offers a faster responce time for bug fixes because so many people are looking at the code? I think that the comunity leaders should step in and let the big corporations know that while the door is open for anyone to contribute, there are some standards and principles. Otherwise you might see linux highjacked in a couple of years and that would be a damn shame. Oh and Linux is just the kernel and NOT some gui based software so pls stop with all the bs. I really though that this issue was cleared up by now but I guess there are always dumb people. One thing that I still can't belive that hasn't been fixed is tha fact that a poorly written application can lock up xorg which in tern can lock up the whole system. And unfortunatelly this goes for any process. The kernel need some kind of fail safe that works a little bit better than what is currently in place for cituations like this one. Relying on the software developer's skills is just asking for trouble. The problem though is that I haven't seen anything being done in that particular direction in a very long time. Maybe the linux developers should look at what's happening in some other *nix communities and maybe imulate.
About a month ago this blue screen appeared on a Windows 2003 Server Appliance Edition NAS BOX. Attempt to mount an NFS share served by the windows NAS, and boom blue screen. This is a commercial NAS box running a supposidly ultra stable version of windows for such devices. I would have picked the linux powered box but it wasn't my choice.
Day 1 - Andrew's kernel is "stolen" under strange circumstances.
Day 2 - Chip Foose draws up a design for the kernel, the coding commences.
Day 3 - Andrew receives a call from a "kernel repo man". Apparently his kernel was taken by mistake.
Day 4 - Coding like mad. Fake repo man stalls Andrew. The crew is running out of Doritos.
Day 5 - The pressure mounts. Token pretty face "helps out" by typing "make" in a staged moment of tension.
Day 6 - We're never gonna get the kernel done in time!!!! Oops and panic. Fake repo man stalls again.
Day 7 - The reveal. A shiny new kernel is handed back to Andrew. You've been OVERHAULED!
Anybody want a peanut?
A big part of what made OSS get off the ground outside of its core area was the belief that it'd lead to better bug fixes, delivered faster because of all of the eyeballs looking at the code. Well, that's a little hard to argue if 90% of those eyeballs are dedicated to looking at new things, not fixing outstanding issues.
Here Here! Seti at home had a gazillon(tm) people contributing cycles to the effort (many times in teams) to see who could place highest on the list of contributors.
How about a BFoD - Best Fix Of the Day? Each day, post the name of the submitter and some details about the item debugged and fixed:
This could be further improved by posting a Bug Of the Day (BoD) where there is a daily bug that is to be fixed. The first fixer gets recognized as well as anyone who provides an especially elegant solution. Award bonus points for fixing related bugs in the area so as to promote more complete fixing in that area.
Post these prominently for all to see and I'd be willing to bet that there would be a groundswell of support.
This is just off the top of my head - please post any suggestions for enhancements or (gasp) any problems you see in it!
Mr Moreton is a very, very wise and informed gentleman, and "leadership" skills aren't the only useful ones -- in fact, they can easily become crippling handicaps as every rational response is knifed in favour of a justifiable "leadership response", effective or not.
If you see a need for a leadership character, please engage them in addition rather than in place, else Linux will overall lose even if a relative genius is so employed. There is much comment in this post WRT Linux vs Microsoft development models; if y'all want to be as vulnerable and inconsistent as Microsoft products are well-reknowned to be, then you will need to make many of the same mistakes are they are making, and the-leader-wins-all is their primary fubar.
Got time? Spend some of it coding or testing
So, there are lots of bugs in Linux! Good thing I'm using Windows.
w00t
As a counterpoint, the last time I had a BSOD on XP, my hard disk had failed (or at least was in the process of failing).
Anything else?
By summer it was all gone...now shesmovedon. --
> Er.. I hate Windows as much as the next guy
Yeah, right. What a hypocritical disclaimer.
maybe they should go on with the old version release but at a more detailled level.
...
before it was:
linux 2.0 => stable linux 2.1 => development
linux 2.2 => stable linux 2.3 => development
it changed at 2.6, 2.6 is stable AND development at the very same time. to get new features in faster. so that the 2.8.0 (or, 2.4.0, 2.6.0) which are the first releases of the dev kernel, does not get a load of untested bugs (due to the nature of being a previously "development" kernel)
So what about that:
2.6.17 => new features, standard, current release cycle. "dev".
2.6.18 => bugfixing only release. no new features allowed. stable.
2.6.19 => new features, etc...
2.6.20 => bug fix only.. stable..
Let me see... The last time I remember was October last year, when I got my Philips 200W6 monitor and tried to install it in XP. I went through ten or so blue screens, after following the instructions in the included CD. Having no success, I did a few driver downloads, the closest I could get was a 1600x1024 resolution. I gave up and never tried to boot in XP anymore.
In the Linux side, it took me about two minutes to add "1680x1050" in
Of course, you have first to learn what is all this, but every minute you spend studying Linux you recover later from a smoother operation. All the time you spend downloading drivers and rebooting Windows is wasted by the time the next bug arrives.
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.
As an application developer, it really irks me that I have to release software that I *know* has bugs, choosing instead to complete whatever features were supposed to be in the release. As a consumer of applications, sometimes I wish that instead of adding all the new wizbang stuff, someone would devote an entire release to fixing *all* known bugs and improving performance. Maybe this will finally happen w/ the kernel.
MkLinux has been around for years. I once ran it on a PowerMac 6100 until the monolithic kernel was ported to the architecture with driver support for the hardware in the machine.
Granted, the hardware was older, but the performance hit was massive compared to the monolithic kernel that followed. I'd hate to think of losing that many cycles regardless of the speed of my CPU.
STOP . AMERICA . NOW
With just one phrase: The difference between Linux and Windows would just be that with Linux, the admin knows the bugs at the same time as the hacker, instead of after being hacked.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Check for third-party things with kernel drivers. Firewalls and virus checkers are particularly bad for this.
Sorry, the reply button somehow was too tempting. :)
This page would be the page to go looking for "debuggers". People with good debugging skills. Now, today you usually don't need coders for "new stuff". More often you need coders to maintain projects. Projects that have been running for years, often handed down through a few teams, with code written by a dozen different people, often with very different skill. I've seen quite a few very good coders that simply are unable or unwilling to maintain foreign code.
And as good as they may be, you can't use them for continuing an old project.
In that list, you have the creme of our world's debuggers. It would be a perfect tool for your HR department to find people who have VERIFIED skills in maintaining, enhancing and most of all debugging code written by others. It saves you time and money looking for them.
Somehow, I could see MS sponsor that. At least, considering their often ancient code base, they definitly should.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
As I replied to your post's parent, dodgy drivers are often the culprit. Firewalls and virus checkers in particular often install really weird kernel drivers which are often just buggy. The same thing is probably possible with things like spyware and so on, especially if they use rootkits and the like. It's not so much a problem with Windows as it is a problem with unreliable third-party stuff, in my experience.
Of course, if it's spyware, Windows should have at least prompted the user before they installed something so fundamental to the system. On the other hand, even if it did, many users will just click past.
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.
I know it's supposed to be since it is Mach and all, but Mach hasn't been a microkernel in a long time.
The filesystem is in the kernel.
Networking? In the kernel.
Address space management? In the kernel.
The pager isn't in the kernel though I don't think.
Drivers aren't compiled as a unit with the kernel, but are dynamically loaded at boot into the kernel context.
Basically, the NeXT/Apple guys migrated from a microkernel to a regular kernel because of performance and general feature bloat.
http://lkml.org/lkml/2005/8/20/95
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
So, you are telling us you hate your job but you do it to make a living? Sounds normal, but that's sad to hear from one of the lucky few people who actually get paid to write commercial code. Few people live to work, most work to live. It's not really so painful and it's not special to free software. It does not make the stuff you make better than free software either.
The reality is that free software is better than non free software at meeting user needs. Free software has turned my garbage into fine working machines and I've never lost a piece of hardware or software function because the software dissapeared. Free software is still growing in breadth and depth in a way that non free can never meet.
Free software never expires like non free does. When your company decides, for whatever reason, that you will do X, others will be able to do Y if Y is free. If your company makes non free software, Y will only be worked on by people who may or may not really care. The result is apparent in code quality, where free code time and time again is judged much cleaner than non free code. It's also apparent in how long software and device support hangs around. Free software lasts as long as there's a real economic need for it, sometimes longer. Non free software is routinely extinguished by greedy companies.
If you really need old hardware support, you can fall back to older kernels and distributions that still support them. Debian Etch, for example, has a 2.4 kernel line. More often than not a better piece of hardware can be found to do the job. I you absolutely, positively must run that old 150 MHz Cyrix Media GX someone gave you, you can always install Woody but why bother when people are throwing away 1GHz P3s? A machine that's been running continuously will have been upgraded when needed. Free software makes that kind of thing as easy or easier than setting up a new box.
I use all sorts of old hardware that would be useless under non-free software. I've got a 90MHz P1 for a network gateway and storage appliance. My best laptop is a P3 and I still regularly use P1 and P2 models. My best desktop is a 1 GHz Athlon. I could use a little more storage space. Many of my desktops are still using 5 GB hard drives. I may go buy a $50 250 GB hard drive one day. In the mean time, I've saved thousands of dollars in software and hardware costs and gotten more function from it than I'd ever have with non free stuff.
Free software, as usual, has fewer problems than non free. The 2.6 kernel bugs are a non issue for most people.
Friends don't help friends install M$ junk.
I agree that you cannot support old hardware indefinately. At some point you've got to say that this new version of the kernal just isn't going to run on a 486 or a pentium 1 computer.
BUT
That should be a decision that is made not just the result of accumulated bugs. That way when the decision is made code specific to the old hardware can be scrapped. Also people will know that kernal fu.bar.fu must have this minimum hardware to run, instead of learning by installing it and running into endless instabilities.
-- QED
Yes, Linux has a lot of drivers that I just can't believe anyone really cares about these days. Like, drivers for CD-ROMs attached via parallel ports and the like.
Perhaps it's time for something like the Debian popularity contest, but for drivers. The unpopular drivers would still be available, they just wouldn't be part of the main kernel distribution.
I mean, has anyone tried custom-configuring a kernel recently? Ugh...
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Bug may be a countable noun, but the concept it describes surely isn't. If I change two lines in the code did I fix one, two or three bugs?
Or you could use nooks. Nooks will protect the OS from driver crashes and restart failed drivers transparently.
Even if that's true, so what? Kernel maintainers are free to look at and use Red Hat, Suse, Debian and other distribution's kernels and mailing lists. Information shared is never lost in free software.
It is also not just a case of old hardware; in the last few kernels I've had leaks that make a simple firewall die repeatedly after a few months, I've got a machine with a slow RAM kernel leak that makes a simple DHCP server fall over every few months, and I've had a 2.6.1x kernel that couldn't run an NFS server for 24 hours without falling over.
Is there a reason you need a new 2.6 kernel instead of a 2.4 kernel for DHCP or NFS servers? You could use an older, more stable 2.6 or 2.4 kernel if you need uptime. I'm lazy and stock Debian Kernels work for me. When they don't, I use one that does.
Friends don't help friends install M$ junk.
Here's an idea. Why not handle debugging in the various programming courses throughout the world? The benefits should be obvious: enough eyeballs looking at the code and students seeing a sampling of good/bad code while learning how to debug what they write.
So how about moving to Minix3? That looks better and better.
If only Linus would have listened to Tanenbaum....
'hurding' cats?
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.
The big overhaul is a good idea, Andrew. Dotting the i's and crossing the t's should be an obligatory part after architectural changes, like the kernel has seen recently. It's often forgotten, just like management forgets to do it after reorganisations.
:-( ), and encounter few problems. Most of those concern reverse-engineered drivers like that puta broadcom bcm43xx crap :-(
Anyway, users have some resposibility, too. If they use old, scarce hardware and encounter bugs, at the very least they should
submit bugs somewhere. Better yet, fix it, too, and submit a (proto-)patch. Hey, I am as lazy as the next guy, and my code doesn't aim for correctness, just fixing problems, so I don't submit it. But at least I help myself, and people nearby.
People, for the kernel dev's this is a lose-lose situation. If they don't fix new hardware, they get complaints. Lots of complaints. If they don't fix the old stuff, they get lots of complaints, too. Strangely, even kernel dev's are only human, and have only 24h/day. They need us, to spot the bugs, and to fix them.
Andrew, for moral support, I maintain 70+ boxes, from early 2.4 to the latest and greastest, on lots of different generations of x86 hardware (PII to latest opteron; since OSX no more PPC
may the source be with you all
Theo may be a royal PITA at times, but his personality is a good match for the goals of the OpenBSD project.
I've ran the Linux kernel since the 2.0 series. In 2.0-2.4, I'd run into one minor bug (a corner-case in which something in /proc was misreported). In 2.6, I run into bugs regularly. If you configure up a kernel, most of the time it doesn't even compile. Calls for 2.7 have been rejected, so what I'd suggest is the following:
We tag 2.6.16 as "stabilizing." We keep developing 2.6, but backport bug fixes to 2.6.16.x. Once 2.6.16 is stable, we mark (at that point) 2.6.45 as "stabilizing," and continue to maintain 2.6.16.x. One 2.6.45.x stablizies, we mark that as stable, discontinue support for 2.6.16.x, and make 2.6.98 as stabilizing. That way, at any point in time, there's at least one stable kernel.
Still, our servers seem to work fine with it, so far.
"I love my job, but I hate talking to people like you" (Freddie Mercury)
C doesn't offer enough abstraction to deal with new levels of complexity. It is now far from the best language available for systems programming: bitc and prescheme are especially worth looking at if you haven't heard of them.
"It's not so much a problem with Windows as it is a problem with unreliable third-party stuff, in my experience"
So if you develop a gun that shots out each time someone hickups, it is not the gun designer's fault but the people's hickuping all the time, uh?
Windows is a design nigthmare, thus is no surprise that "third parties" are producing unreliable code that brakes windows all the time. Were it designed in a safe manner, not even buggy third party code would crash it.
lol. Absolutely right. Imagine what will happen otherwise - we'll get "Andrew Morton suxors big time. We need to get rid of him and replace him with a real leader, someone like Mr Stallman".
:-)
Just imagine...
Want to know what's wrong with it? Turn on Operating System Error Reporting in System properties Advanced tab > Error Reporting.
Next time the crash occurs, visit http://oca.microsoft.com/
They'll tell you exactly what program is causing it, and exactly which procedure it's occuring in.
But I imagine you'll just reinstall Windows and end up reinstalling whatever driver is causing this behavior, or using whatever faulty hardware is installed, and you'll continue blaming it on the OS.
hello dear sirs my name is jamesh i are india (bihar) can u guide me install red had linux 9?
I think bugfix cycles should be a part of the development process. For example, the current versioning is
2.6.x (all even) is supposed to be stable. (1-2 weeks per release)
Whereas
2.6.x (odd) is a little more edgy, but still a stable release (1-2 months per release)
2.x.x (odd) possibly breaks lots of stuff (1-2 years per release)
x.x.x everything broke. Oh. My. God.
So maybe once every 6 months (I prefer) or at least once per year there should be a cycle completely dedicated to bug fixes. This could simply be a longer 1-2 month 2.6.x (even) cycle. Especially now that there is no 2.7 release and they are dumping new functionality in 2.6 like it's nobody's bizness.
If anyone's interested in patching the kernel, a good place to start learning how is here. They have HowTo's on getting started and have a list of bugs that need to be fixed and another list for bugs that should be fixed.
The bug lists are out of date though.
my linux server has been up for 4 years (if you ignore power cuts, which I don't expect any OS to deal with...)
Here's how an OS can deal with loss of power: It could warn the user on boot or login if the PC's power supply doesn't have a battery (e.g. a laptop running off pure AC or a desktop without a UPS). Then the OS could use its existing ACPI (etc.) support to enter sleep mode once the mains power fails.
If you put resources into making the newest kernel compatible with old peripherals that resource could not be used for bugfixes and new features.
The new kernel probably will not bring anything new to the old hardware, either. So why don't just use the stable 2.4 kernel with security patches?
This is more the case where the person attaches a "silencer" to the gun, bought in some shady shop, which actually causes the gun to backfire every so often. Is it the manufacturer's fault that you could attach it?
An equivalent Linux driver could easily take down the system in a similar manner, in any case. There should be no need for drivers for things like this to run on that sort of level, at least for most things, though. This is a problem that affect Windows and the Linux kernel, although generally Linux drivers are essentially part of the kernel, and go through some form of public auditing.
The only system which I know of which is specifically designed to take care of problems like this is Singularity, and it's just a research project. This is by no means a solved problem.
Perhaps a better link is here. The sole purpose of this site is cleaning up kernel code and has links to various projects that have tools that can scan kernel source files looking for common bugs.
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.
Obviously, the professional developers will mostly work on issues their customers care about. Which is a good thing. Sure, bugs should be fixed. But hey should be fixed because users care about them. Otherwise, the only reason to fix them is the professional pride of the programmers, which is fine for hobbyists, but not professionals.
The only time my XP ever bluescreens is when I turn on or off my MOTU828mkII firewire audio interface. The MOTU drivers don't have that "Windows Certified" logo or whatever they call it, and Windows throws up a warning when trying to install the drivers telling you as much. I guess that driver approval crap is worth something after all. *shrug* Now, if only MOTU would get off their asses and release some Linux drivers, I'd never have to boot into Windows for recording work. All I ever get back from their tech support is "we're working on it." WTF, how long do they need? They had new drivers for the Intel Macs almost as soon as they were announced. I shoulda went with Presonus or Yamaha for mLAN. Bleh.
kurzweil_freak
5th Kyu Genbukan Ninpo/KJJR student
Be the darkness that allows the light to shine.
No OSS drivers then, I take it? That sucks. It's not gonna be ideal if their Linux drivers are of similar quality to their Windows ones. The worst drivers are the ones whose installers simulate a mouse click to dismiss the driver warning screen (which is categorically something they should not be able to do, although I believe this is "fixed" in Vista with their whole framework for privilege escalation — let's call it "sudo" ;) — which they've added in). I don't believe some companies produce software of such low quality, particularly when it essentially cripples the hardware they're selling. Gah.
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 see a lot of hand waving about how buggy 2.6 is but I do not see any references to bug databases or particular reproduceable bugs. How about some data?
So far 2.6 has been just as solid for me as previous kernel versions but I try really hard to avoid using bizarro hardware and drivers that probably do not get much testing, and rightly so.
I think we need to distinguish between bugs in the core kernel (code that everyone runs) and bugs in drivers. The vast majority of the Linux kernel code is drivers.
Now I know that Linus wants to leave the stability issue up to the distributions. But I fear they neither have the infrastructure nor the manpower for a big, stable kernel.
I think the reason for this is that it always took way too long for a stable release and Linus got sick of the wait, anticipation and pressure. But instead of mergin stable and unstable developement maybe he should just overhaul unstable developement to focus on a faster release cycle into stable. Maybe a new stable version every 6 month.
And a third, rock solid kernel that only gets security issues fixed. So for each 6 month period there would be the current developement kernel, the current stable (but bugs still get fixed) kernel and all the others would still be maintained for security issues. So there would always be a third "current" kernel that went through 6 month of bug fixing in the last cycle.
Just a thought. Fill in better ideas please.
It's been a long time since i was actively following kernel developements, but I believe someone of some importance once said that the kernel.org kernels would be for developers and adventurous users, and that it was the distros job to fork off stable versions. Anyone with a better memory?
I think the fundamental difference between windows and linux, is the community. Linux is subject to this kind of scrutiny where I don't think window's gets nearly as much. So you will hear the occasional outcry about there being too many holes or this gaping security flaw or this critical error in linux kernels and distrobutions but it's something the community will take care of and fix themselves where we don't have to wait on Apple or Microsoft or IBM or anyone to come up with a fix. Another thing that gives linux the advantage in this kind of debate is the degree to which it can be customized for the user. The user does not have to install each and every single component where in windows it can be fairly difficult although not impossible to leave things out.
There will always be people that care about open source around to take care of their favorite distrobution and if you think your favorite distrobution needs a little bit of a change and you can't write the needed code theres always a place to suggest it and then discuss why or why not its a good/bad idea. Personally I try to donate whatever I can to my distro of choice because I think its that good and it fits. In my attempt to quit smoking I've started donating what I would have spent on patches or smokes to slackware. If you like your distrobution donate and I doubt it will become an issue.
If this kind of thing is a concern of yours there is always something you can do to pitch in even if a simple hello world! is beyond your ability.
I would expect that if an end user was willing to help with debugging the problem you would find several kernel developers that would find this a most interesting problem to solve.
But does the person having the problem have the motivation and time to feed bug reports and run tests so the deveopers can isolate the problem?
I have often wondered if RLL drive support is at all close to usable in the 2.6 line, just because I can't imagine who still has one of those disks. (what were they 10-60Meg in capacity or so?)
Work bio at MMWD
I've said this, here and elsewhere, over and over and over. Quality is something that has to be in software FROM THE START. It's not something you can retrofit.
As soon as the kernel dev team decided that Linus' kernel didn't need to be stable anymore, as soon as they started waving their hands in the air and expecting 'the distros' to magically fix their problems, OF COURSE quality took a dive. One of the kernel devs said that it was okay for only one out of three 'stable' kernels to actually be stable! Stability takes a long time... they now refuse to support a given kernel for more than a couple of months. The 2.4 kernel still has a few problems, and it's been around for, what, six years now? Supporting a given kernel release for only a couple of months is impossibly stupid from a stability perspective.
They're doing it this way because they're tired of doing the painful, annoying, tedious task of making sure the kernel always works. And the 2.6 kernel has, as a result, been a steaming pile of crap. Features don't matter if the fucking kernel doesn't stay up. No kernel since about 2.6.8 has worked in APIC mode on my ASUS KT333 board. 2.6.15 crashes my Intel 865 chipset servers randomly; they rarely stay up more than an hour or so. 2.6.14 broke traceroute. And with the constant stream of patches to their security fuckups, my system uptimes rarely exceed two weeks. Remember being proud of your kernel uptimes?
The social contract with Linux for many years was essentially: "The official kernel tree is as stable as we know how to make it. You can trust this code." And that is what got Linux as far as it has gotten... the fact that you could TRUST IT. It NEVER fell over. The 2.2 kernel was one of the finest pieces of software I've ever run. 2.4 took a huge dive in terms of stability, and was a total mess until Linus branched off to 2.5 and let the poor harried 2.4 maintainer, Marcelo Tosatti, take it over. He finally whipped it into shape. He has done an outstanding job.
What Linus et al need to do is GO PLAY IN THEIR SANDBOX IN 2.7. Let 2.6 fucking stabilize. They're shoving new features down our throats so fast that it's a part-time job just keeping up with the new stuff... and obviously NOBODY understands the security implications of moving this fast, or we wouldn't have so many goddamn security patches. We're gonna be having those security patches for YEARS because of this bullshit. The number of possible interactions in a system goes up exponentially with the number of features... so adding features should slow down over time, not speed up.
Go BACK TO THE OLD SYSTEM. People crying about 'too slow release schedules' is a HELL of a lot better than people crying about Linux being unstable. Linux *owned* the word stability for many years, and it's in very real danger of losing it, right at its height of popularity. The old system worked. It got Linux where it is today.
A simple 'bugfix release' won't do shit... it's the process that's broken. It'll fix some of today's bugs, but what about next week?
If I have old hardware that doesn't run 2.6, I can and do drop back to an older kernel. Hell, 2.0.40 came out in 2004. And note the size! That kernel boots as fast on my 133MHz machine as 2.6 does on my 1GHz frankenstein. New features on a new kernel mean nothing on hardware that can't use it. If you want to keep running a new kernel on old hardware, obviously you're going to suffer plenty of bloat, as evidenced in the Windows world. And speaking of that, if MS had kept their old version on the market. They could have slimmed down the new versions considerably. Of course, most of us know that older versions are MS biggest competition, so that's why the lockdown, all made possible by our gracious IP overlords. So be it. I don't need them anymore. Even Apple put up their old old versions for free. But it doesn't run on new hardware. And their new software doesn't run on old hardware. And furthermore, wouldn't it be easier to troubleshoot and fix bugs in the older, smaller kernels? My general rule is to use a kernel that is approximately 6 months to a year newer than the hardware it's running on. We shouldn't try to make a single kernel to run on all hardware. We have lots of them, one for each specific time period. This also applies to the distros. The older ones are still available for your old hardware.
FTA: 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.
Am I supposed to be surprised by this? Even the most altruistic of us are generally motivated by self interest. We all want some kind of return for our efforts....even if it's a simple "Thank you".
What?
That's because it is.
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Use XP drivers using some sort of emulator or write a better program to reverse engineer them.
Quite frankly, I think this is a great idea. Smart people (like kernel hackers) can be very competitive and will fight tooth and nail to win the smallest of awards. Case in point, back in my senior year AP Biology class, the teacher would hand out an award, referred to as the "Big Boy Award", to whoever got the highest grade on the last exam. Short of destroying the othery guys' notes, we'd do whatever possible to gete those damn pieces of paper and then proceed to strut them around until the next exam. Applying something similar to kernel development would have the same effect.
This might hurt my karma, but here goes:
Yes, imagine. But imagine seriously. Would it really be such a bad thing? It would be different, for better and for worse. Not just for worse.
Face it, there have been lots of kernel problems surfacing lately, and not only bugs, but design features. There's more and more kernel options that are incompatible with each other, and harder and harder to make the correct choices for a given system. A bad side effect of the feeping creaturitis that's been allowed to take place after the odd/even cycles were abandoned, and people were allowed to add things almost unhindered. Perhaps someone in the lead who isn't afraid to kill off someone's babies and say "heck, no" wouldn't be such a bad thing.
Regards,
--
*Art
Any true microkernel has the drivers running in userspace as services - so your apparent complete lack of knowledge would encompass little known OSes like QNX or the Hurd. You know, stictly minor stuff that nobody on /. would ever have heard of.
"To any truly impartial person, it would be obvious that I am right."
My excuse was that I was hungover :). The Hurd still isn't finished, and QNX isn't really for desktop systems, the last time I looked at it, though. Good point though.
If he is constantly getting BSODs, it's hard to believe it isn't physical. I've run XP at home and at work for years, and the only BSOD I can recall seeing was on my wife's machine when some of her hardware died.
> If he is constantly getting BSODs, it's hard to believe it isn't physical.
No, if they reinstalled his system from scratch and he still got them, then it's hard to believe. He's got kernel-mode code going wonky, that's all we know. He could easily have a virus or rootkit. Why they haven't bothered scraping his machine's install is beyond me. And if he has critical data that won't stand it, then why they're keeping that critical data on a machine that BSOD's all the time is also beyond me.
really, when was the last time you saw Windows bluescreen?
I've rebooted a locked-up windows box twice today. It seems to be connected with hitting the "disconnect" button in hyperterminal (to pause the display) while lots of data is coming in. I know that hyperterminal is a flaky piece of crap, but it locked up the whole machine.
I'm running a Freenet node on Ubuntu 5.1 with an old Athlon 850. I had uptime since February until I just updated yesterday. I had to reboot it since the kernel was just updated. It never goes down or crashes.
>but really, when was the last time you saw Windows bluescreen?
A month or two ago, and I actually read the text. Having it blow up in third-party code is a pretty common pattern. At least a few years ago, video card drivers were roughly half of the BSODs.
In the last couple of weeks sometime. On XP Pro. Granted, I don't see that screen nearly as often as before, but it does occasionally give me the blues still.
Yesterday. Kid was playing Sims 2, winkeying in and out to check something or other, it worked a few times, then bluescreened so hard the text was garbled and unreadable. XP/SP2, clean, secure and up to date.
As always, all IMO. Insert "I think" everywhere grammatically possible.
These days there are two causes for BSODs. Hardware failures (and including bad drivers) and users/admins with low IQs.
I suspect this is as case of both.
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.
I think now many people are at the point where things are: you have what you want, or do you want more?
,functional based usercycles in the linux kernel we could configure a basic install to ~ 60M or less than that.
/proc overhead, more symmetric processing and examining what shared libs can actually do. We got to move more toward allowing for demand inputs to enable application functions FOR homo sapiens sapiens TASKS, away from centralized dependency package suckage. From a purely o.s. level this evaluation and exercise has got to be compatible and maybe staticly linked to commercial enterprise frameworks, say ibm {s,z}Series or SunOS 10.x. ( .x meaning the chance of a more open SunMicrosystems sometime soon )
I can get a 122M mandriva/mandrake install running, but that is only system and basic X. The single list move in terms of configuring & verifying hardware a slashdotter before me wrote of is a good approach. Using service Oriented Architecture, registries and better pipelining of demand based
Drop some libc, maybe import the diet libc or specifically call trimmed c+ inline checks post-assembly(?) I can definitely say Linux needs less
Let's take up M.i.t. Nicholas Negroponte's challenge to trim the penguin fat. If a linux or more lean linux hybrid can operate on the O.L.P.C./little green laptops or display portables or whatever they're called what does this say about that architecture while, concurrent to the linux activity, developers and hackers assess what hardware registers talk to what software components. Speaking of which, ruby could be the next java for many such tasks or is it just an extension and we need that personal, modal element plus a more transparent, better defined framework?
It is time for moi to brush up on assembly and bit. [\]\/\/
First off, I use Linux on all my systems (BioTech) - except for the Sun kit (and some of that, too). I've been using it since the early 90's and I believe that it's a great O/S. BUT...
The real killer is that in one important sense, Linux is now like Windows for me... I'm locked in. Windows won't do what I need, Open/NetBSD would be OK for firewalls, file servers and the like, but not for the workstations.
I have to say that I'm getting rather uneasy about its stability/usability recently. The real crunch came when we updated some of our workstations to SuSE 10 (2.6.13-15). It simply ain't as good. Our opteron/X86-64 systems have *big* problems with 32/64 bit issues and our SATA systems have *awful* performance under load. Added to this is my gut feel that something is going wrong somewhere (backed by 25 years of experience with UNIX/Solaris/Linux/Whatever). AND solving problems by reconfiguring the kernel isn't half as easy as it used to be.
I remember my reaction when Linus announced the change to the versioning system. It was "Uh-Oh!"
I know that Linux development isn't a democracy as such and that I and many others are in a weak position because we don't contribute much except for the occasional bug report. But is there any formal(ish) way we, as end users, can make our feelings felt? And, if not, how can we set it up?
I had BSOD on login with Windows XP when I had a too big file (an iso image) in the trash.
I hope that it could help...
I'd rather have a manager with no stats who keeps his eye on the ball, than one running around with OLAP cubes and similar that doesn't understand what he's analyzing.
Of course, combining the two may be a better solution. Still, I don't know how much time is in Linus' day.
IMHO
I changed the graphics settings in WoW to turn off all the pretty stuff in an attempt to go quicker, what I got was a few BSODs instead. Now maybe it's Blizzard's fault or maybe it's ATIs fault or maybe it's about time the world's biggest software company made it possible to avoid crashing the damn thing on anything but a hardware failure.
That's one of the more satisfying parts of being a support programmer.
:-)
Yeah, the actual process of reproducing a problem and finding the root cause can be a real bugger, but if that process is more difficult the end result (finding and fixing it) is usually that much more satisfying.
I also love designing and writing new stuff, but the support function can be a lot of fun if you have the right mindset.
(I've been doing it professionally since 1988, and I still love it).
Mainframe/UNIX Bit Twiddler and long time Windows/Linux Hobbyist.
The Theorem Theorem: If If, Then Then.
I know Linux doesn't really "do" *cohesive documentation* or anything like that but a table of { kernel versions vs. hardware drivers (with both module name and an actual descriptive name, and author/contact person/website) -> status (not supported; present but experimental/untested; available from a third party patch/module; present but bugs outstanding; stable) } is one of the most basic and most useful things that could be placed on http://www.kernel.org/ and actively maintaned by the driver authors and other developers.
I haven't seen a posting point this out, but there is a bugzilla site setup for kernel bugs. http://bugzilla.kernel.org/. Some of the bugs in there look pretty old, but there does show to be active entries in there also. AFAIK, the site has been up for a couple of years or so.
As another poster pointed out, people who can identify and fix bugs that they didn't create should be in higher demand than who can't. Don't know if it generally possible, but I don't see it being unreasonable for developers to point to specific bug entries that they closed out on their resume/portfolio.
Developers get sick of maintaining other developers code and focus on making new features (asked for or un-asked for) because it gives them pride to make something new. The Linux kernel hits the same pitfalls as the Windows kernel.
Thankfully, the people who actually do this development couldn't care less about your little opinion here. Its the "I'm gonna do THIS because its FUN for me" spirit is the LIFEBLOOD of F/OSS. It is what gives us nine-to-fiver's the spirit to keep coding even after putting in a whole day for The Man. Its the source of CREATIVITY that makes a GNU/linux stuff feel so much more... fun, and inspired.
And if you think that development model will result in Linux falling in "the same pitfalls as Win95/98", you've _completely_ missed the important points of the FOSS movement.
Why stick up for big business?
Not quite.
.y, and labeled as stable.
Well, okay, not close.
The 2.6.x.y series is indeed called "stable".
This only means that it will have 100% critical bug fixes in it that must be pushed out now. They're not a seperate branch, unless you count a patch or two as a seperate branch. It's basically 2.6.x with a single, typically small patch,
I was not referring to 2.6.x.y, but to specifically 2.6.16.x, as per this bit of news: http://kerneltrap.org/node/6386 - in effect a "Stable" branch based on 2.6.16 started as soon as 2.6.17 is released.
Without going as far as far as DBSD's threading it would appear you could reduce the number of locks currently used in the Linux TCP stack at the expense of adding a bit of the TCP stack to userland. Take a look at these slides on Van Jacobson's Net Channels where Linux's TCP performance is improved by implementing channels (seen via Dave Miller's blog).
Things like the O(1) scheduler and general scheduler improvements, kernel pre-emption (good for audio), ipv6 stack improvements, major changes to the USB subsystem including increased robustness, udev and better hotplug support, VM improvements, major SMP improvements, adoption of ALSA for improved soundcard support (e.g. surround and software mixing), improved build procedure, FAR better ACPI support, suspend to disk support, samba filesytem performance improvements in CIFS, TCP/IP stack improvements...
The Wonderful World of Linux 2.6 page has a more comprehensive list of Linux 2.6 improvements over Linux 2.4 than what I have just mentioned above. Just because the machine I am currently sitting at is fairly old I would not want to be stuck with an old 2.4 kernel because I still benefit from 2.6's changes.
To counter the people who keep saying "No stats! Where are the stats?" (which is a very fair point) take a look at this diary entry by Dave Jones (one of Red Hat's kernel hackers) talking about bugzilla numbers when rebasing kernels.