Time for a Linux Bug-Fixing Cycle

AlanS2002 writes "As reported here on Slashdot last week, there are some people who are concerned that the Linux Kernel is slowly getting buggier with the new development cycle. Now, according to Linux.com (Also owned by VA) Linus Torvalds has thrown his two cents in, saying that while there are some concerns, it is not as bad as some might have thought from the various reporting. However he says that the 2.6 Kernel could probably do with a breather to get people to calm down a bit."

Comments

I preferred the old odd/even split

[WillerZ]

As a user, I preferred the old odd/even unstable/stable code split; I'd run .even at work and .odd at home.

I suppose if you buy your linux off the shelf you can complain to your vendor, but for home users looking to do some DIY kernel building the new way is a bit worse. However, I suspect we're a dying breed...

Re:I preferred the old odd/even split

[lostlogic]

The current system facillitates this as well -- I run 2.6.anything.somthinghigh on my servers and 2.6.anything at home and it works quite well. The -stable team are really providing an excellent service with their work beyond the 3rd dot, and they let the main line kernel move at a quicker pace than having the alternating odd/even system.

Re:I preferred the old odd/even split

[Anonymous Coward]

As a user, I preferred the old odd/even unstable/stable code split; I'd run .even at work and .odd at home.

As someone who doesn't really keep up to date with Linux politics, I was wondering could someone explain to my why this (IMHO) good development model was abandoned in favour of continuous feature-adding in the 2.6 kernel? Was it something Linus wanted to do, or was he pressured into it?

Re:I preferred the old odd/even split

[Anonymous Coward]

As a user I prefered the old system of publishing dupes and letting the users complain about it.

I think it's a PITA when the dupeness is mentioned in the article itself.

Re:I preferred the old odd/even split

[gowen]

I was wondering could someone explain to my why this (IMHO) good development model was abandoned in favour of continuous feature-adding in the 2.6 kernel?

It was very, very slow, (ironically, even Andrew Morton complained about this). This meant that desirable new features would be backported to the stable branch anyway, either in mainstream or vendor kernels (with all new bugs), which kind of defeated the object.

So it increased the workload, didn't seem to offer massive stability benefits (although, maybe it did, in retrospect), it reduced the amount of testing the new features got, and limited the workloads on which they were tested.

Personally, I find the present -stable branch of non-bleeding edge kernels to be as solid as 2.4 and 2.2 ever were. I do think we've a tendency to look back at that dev-cycle with rose-tinted glasses. It's not as if 2.4 or 2.2 were reasonably bug-free until the twentieth cycle or so.

Re:I preferred the old odd/even split

[WillerZ]

The main difference was that if 2.4.x was good for you there was a very good chance that 2.4.(++x) would be good for you as well. Now, however, nothing is off-limits; so that is less true.

(Yes, I recall some times in the 2.4.x era when this wasn't true either.)

Re:I preferred the old odd/even split

[Skuto]

2.6.16 fixed a critical vulernability over 2.6.15. It also breaks several network drivers.

There was a time when you could grab the next stable kernel, for example when there was an exploit and you really had to, and you'd know you'd only get *more* stability. Now it's exactly the opposite. If you have to upgrade, you're just screwed.

This started around the time they added reiserfs in the stable series although it was far from stable yet. It's not new in the 2.6 series, really. It's a wrong philosophy.

Compare this to FreeBSD release engineering with RELENG, STABLE and CURRENT. FreeLinux anyone? :-P

Re:I preferred the old odd/even split

[richlv]

It was very, very slow, (ironically, even Andrew Morton complained about this). This meant that desirable new features would be backported to the stable branch anyway, either in mainstream or vendor kernels (with all new bugs), which kind of defeated the object.

well, i think that was referring to 2.4 being the latest stable for a looong time.
overall i enjoy 2.4 for some simple production servers where a custom kernel is needed - it's life cycle is quite long.

it seems to me that branching 2.7, but trying to reach next stable faster could be used as a middle ground - this way we get a stable version and a development version that isn't development version for several years.

hopefully new rapid development scheme will pay back with nice features. maybe a "breather" release should be made each 5 or ten releases apart ? :)

Re:I preferred the old odd/even split

[s31523]

I wouldn't so much say we're a dying breed... Rather, I would say that the numbers of people that do their own Kernel building is growing, but the number of people that just buy a distro and install and "hope everything just works" is growing much much faster, which can be viewed as a good thing, since the more people that use Linux will cause commercial Vendors to take note and support Linux more readily. Although, I will miss being that nerdy guy who doesn't run Windows...

Re:I preferred the old odd/even split

[Anonymous Coward]

The current system facillitates this as well -- I run 2.6.anything.somthinghigh on my servers and 2.6.anything at home and it works quite well.

Hmm, aren't the 2.6.x.y releases the development versions and 2.6.x the releases? Whoever thought up this scheme is a fucking idiot. Go back to the even/odd system so at least we don't have to fuck around with unstable buggy kernels. I'm halfway tempted to switch to FreeBSD at this point with all these problems.

Re:I preferred the old odd/even split

[Mr Z]

No, the 2.6.x.y are patch releases of 2.6.x. The development releases are 2.6.x-preY. The release candidates are 2.6.x-rcY.

Makes sense to me at least.

--Joe

Re:I preferred the old odd/even split

[diegocgteleline.es]

The "stable/unstable" development model does not work so well with huge projects like the linux kernel is.

With the old model, the linux kernel would start a unstable release and people would start adding stuff which not the care you'd put into merging something in a stable tree, is not tested a lot, etc...

Now keep this for one, two years. When you decide to release the unstable tree as the next stable version you realize that your unstable tree is full of crap, and you need to waste months or years (Vista) trying to stabilize it. Even when you release the .0 version it's still unstable, so people has to wait even more months to start using it.

The "new" development fixed that. In the current linux development model people is allowed to put new features in the kernel even if they're invasive. But programmers are not allowed to put crap in the kernel, they need to be VERY WELL tested (in the -mm tree) and reviewed, show numbers that back your words if neccesary, document things, etc. Of course no code is free of bugs, so the released version will not be 100% stable as current 2.4 is, but it's QUITE stable.

Because the features are merged progressively, it's MUCH easier to find and fix bugs. Even if there're new features in every release, there're not a LOT of new features - it's much easier to find out what feature broke something between two releases. Compare it with a stable/unstable development model: People keeps adding things for years, when the user switches from 2.4.x to 2.6.0 his kernel doesn't boot. How do you find out who broke that with so many changes?

IMO, from a Q/A POV, the new development model has more sense than a pure stable/unstable development model. It's about "progressive" vs "disruptive", and for projects with several millions of lines and so many contributors it may have sense. Of course, because new things got added there're always some bugs, which is what people is bitching about today. Maybe this could be fixed by leaving the current tree as "stable" and start a new tree - but instead of a "unstable" 2.7 tree, a 2.8 "stable" tree. A pure unstable release doesn't works that well with huge projects like the linux kernel. Remember the hell that FreeBSD 5.x was and how much has affected to the FreeBSD project, remember windows Vista. Maybe it works for some people, but I don't thing it's the best development model for such projects. Solaris is also using this model to some extent - they release things into opensolaris, but what you see in opensolaris is not the "official stable release", it only becomes "stable" after a while.

Re:I preferred the old odd/even split

[Brunellus]

I know we're talking about the kernel, but isn't this sort of the same thing as Debian's Stable/Testing/Unstable versioning scheme?

Re:I preferred the old odd/even split

[moro_666]

it depended on the machine you had.
my ide/ata interface was broken 3 times in the 2.4.x series ... but at least alan was a good fellow and fixed it quickly with the -ac patches ;)

i started to use linux quite late, on the 2.2 series ... and the 2.4 seemed rather unstable at times.
2.6 ... the dev. model has changed so much that there isn't really a possibility for a comparision here

i miss -ac series, i miss the stability and i welcome my new freebsd overlord for now, after all it's a choice of a tool that lets you do the work. everyone should pick what they like. if you want to be rock stable, look at 2.2, if you want to bleed the edge and the stability out of it, sit on the latest 2.6, if you are tired of all that mess, you can try freebsd aswell.

ps. tannenbaum, where is your post about how microkernels would prevent all of this ?

Re:I preferred the old odd/even split

[Skuto]

Yes, it's pretty much the same thing. You can pick a specific RELENG version, though, like RELENG_6_0, which puts you on FreeBSD 6.0, and you will still receive all critical vulnerability patches, but no changes to anything else (which prevents regressions as in the Linux example).

Re:I preferred the old odd/even split

[Mr Z]

it seems to me that branching 2.7, but trying to reach next stable faster could be used as a middle ground

I think that's been tried, or at the very least discussed and ruled out.

--Joe

Re:I preferred the old odd/even split

[Rattencremesuppe]

2.6.16 fixed a critical vulernability over 2.6.15. It also breaks several network drivers.

Stable driver APIs anyone?

Oh wait ... stable driver APIs promote binary drivers ... EVIL EVIL EVIL

Re:I preferred the old odd/even split

[richlv]

hmm. haven't read about it anything. any links ?

Re:I preferred the old odd/even split

[Skuto]

>The "stable/unstable" development model does not work so well with huge
>projects like the linux kernel is.

I think FreeBSD is nice proof that you are wrong. See below.

>Remember the hell that FreeBSD 5.x was and how much has affected to the
>FreeBSD project, remember windows Vista.

With FreeBSD 5.x, if you had a working system (be it 4.x), you could choose not to upgrade until the mess was sorted out. Such things are mostly impossible with Linux, because critical fixes are intermigned with new bugs.

The system is harder on the developers at the benefit of giving the users much more stability and security. I think Microsoft understands this very well.

Re:I preferred the old odd/even split

[diegocgteleline.es]

With FreeBSD 5.x, if you had a working system

I'm not saying you couldn't choose a stable FreeBSD version - you can run a 2.4 kernel if you don't like 2.6, aswell.

I was talking about development models. 5.X was a disaster, and this is something that even the core FreeBSD developers have accepted (they have changed a bit their development model to avoid the 5.x disaster again, you know): Too many time, too unstable, too many time to stabilize. 6.1 (which was released today, BTW) is great, sure. That doesn't means the development model is the best

Re:I preferred the old odd/even split

[thenerdgod]

Not just that, but 2.6.16 also broke LVM2 for every distribution that uses the 'stable' lvm2 toolchain. Basically, you can fix your vulnerability, or you can hose your machine every time you try to back up. Good job.

Re:I preferred the old odd/even split

[Mr Z]

I did go looking for links but it's been hard going. One reference at Linux Weekly News that Linus wanted the 2.3.x dev cycle to be "half the length or less" of the 2.1.x dev cycle. (In reality, 2.3 took 18 months vs. 2.1's 27 months--shorter, but only by a third.)

Then, when 2.5 kicked off, they said they wanted to shorten 2.5.x over 2.3.x, and, well, 2.5.x took 25 months.

BTW, you can look at kernel.org if you don't beleive me on the timeline.

--Joe

Re:I preferred the old odd/even split

[Mr Z]

Oops, botched the LWN link.

Re:I preferred the old odd/even split

[Anonymous Coward]

"Oh wait ... stable driver APIs promote binary drivers ... EVIL EVIL EVIL"

Stable ABI *does* promote binary drivers. Stable API promotes a stable platform to develop against. It might favour binary drivers too, but only on the developer's side (an end user still should compile the driver again against the new kernel version) and only as a colateral factor, avoidable if really needed/wanted (per GPL license).

Re:I preferred the old odd/even split

[towsonu2003]

...I suppose if you buy your linux off the shelf you can complain to your vendor...

Otherwise complain to Linus? He'll bite your head off and give it as bait to the kernel. :-)

Re:I preferred the old odd/even split

[LWATCDR]

Actually there is supposed to be a stable API for drivers. What you are thinking of is a stable binary interface.
And yes I would like to see both.

Re:I preferred the old odd/even split

[markus_baertschi]

I don't, the new model work much better for me (and my customers) because:

• My customers want a stable, certified environment where their applications work reliably. Commercial linux distros (RedHat, SuSE) provide this very nicely. The kernel used there is usually quite old, but remains the same over years.
• At thome a want the leading edge stuff to play. Stability is less important, but support for the latest gadgets is. The kernels I use tend to be the latest from kernel.org or gentoo (if I'm lazy...).

  I'm ready to suffer, otherwise I'd use Ubunto, Debian or something similarly maintained.

Markus

Re:I preferred the old odd/even split

[Hal_Porter]

Which will lunge at the head, miss and maul him badly.

Re:I preferred the old odd/even split

[Kjella]

Perhaps they should make the development cycles shorter then - no "throw in crap and see if it stabilized in a year or two", maybe to the tune of 3-4 point releases. That'd at least give you some assurance than the "stable" branch isn't the one they decided to make some stoopid changes in because well, at some points in the 2.6 branch they are going to eat some pretty big changes, but to us that don't read changelogs you don't communicate that at all. If you're telling me that you're going to make development & 100 rock stable happen in parallel and in the same branch (so mostly), well let's just say it doesn't sound very credible.

Re:I preferred the old odd/even split

[the_womble]

You can keep your prized nerdiness by switching distros. While the rest of us use Ubuntu to get work done, you can have fun compiling Gentoo, or even better LFS.

Re:I preferred the old odd/even split

[Leadmagnet]

This is why I run WinXP-SP2 and I NEVER have any viruses, crashes, or spyware. Rock solid and recognizes all my hardware, and all software runs flawlessly

Re:I preferred the old odd/even split

[MadJo]

You could always switch to a BSD version (or pure *nix)? If you want to stay that nerdy guy that doesn't want to follow the masses.

Re:I preferred the old odd/even split

[Anonymous Coward]

Inverse-elitism, I love it!

Re:I preferred the old odd/even split

[K9-Cop]

Currently we have a single branch. Some of the kernels in this branch are considered unstable, simply because they still require testing. However, at some point, they are considered 'stable enough' to be released as a stable version of the kernl. Hence, you end up with, for example, 2.6.13-rc1 and a stable 2.6.12. People interested in kernel development will grab 2.6.13-rc1 to mess around with it, while most everyone else is grabbing 2.6.12. As has been mentioned, however, the problem is that this stable version of the kernel, 2.6.12, still contains bugs. Whats more, many of these bugs have been introduced to the kernel through new features in recent versions of the kernel. This is a problem for some end-users, as while an upgrade may fix some bugs, it also introduces new ones. Here's my suggestion. Continue with the unstable/stable system as we have now, but with one addition. When a bugfix is discovered for a bug found in a particular stable version of the kernel, update that stable version of the kernel. By example: According to kernel.org, the latest stable version of the kernel is 2.6.16.14. If while working on 2.6.17 we discover a bugfix for something in 2.6.16.14, we should go back, fix the bug, and release 2.6.16.15. If we also discover a bugfix for something in 2.6.15.7 (the last patch in the 2.6.15 branch), we should fix that too and release 2.6.15.8. What this means is that if a user does not require new functionality available in recent versions of the kernel, they can stick with a slightly older version of the kernel and still get all the bugfixes. They don't have to potentially break something new just to get a fix for an older bug. Of course, the only problem with all this is that its significantly more work, but perhaps its worth it.

Re:I preferred the old odd/even split

[gowen]

These days, if 2.6.x works for you 2.6.x.y will almost certainly work better. That's the bug fix branch for 2.6.x.

2.6.z might work, but your mileage may vary.

Re:I preferred the old odd/even split

[SpiritusGladius1517]

Although, I will miss being that nerdy guy who doesn't run Windows...

You could always do what everyone else does and brag about how long you've used Linux, or what obscure distro you use (usually a dubious length of time and a distro so obscure that even Google hasn't heard of it):

"I started using Linux in 1972, back in college. Of course, in those days, you had to compile the kernel from stacks of punchcards. Yep, then I helped fix a bug in the Fogeyware 4.2.1 release in 1983 and I've used it ever since."

Re:I preferred the old odd/even split

[Anonymous Coward]

There's already a phrase for that: Inverted snobbery.

Re:I preferred the old odd/even split

[Anonymous Coward]

Look up the difference between API and ABI... moron.

Re:I preferred the old odd/even split

[sydb]

But FreeBSD is a complete operating system, whereas Linux is a kernel. If you run Debian GNU/Linux, then critical (security) fixes will be issued for your current kernel, without backporting bugs. That is the job of the distro maintainers, not of the Linux (*kernel*) developers.

It's about time people realised that the distinction between Linux the kernel and GNU/Linux the operating system is a real and important one, not just RMS whinging (although I agree with his whinge anyway).

Re:I preferred the old odd/even split

[iabervon]

Any critical vulnerability fixed in 2.6.16 should also be fixed in the -stable series for 2.6.15, because they keep releasing patches to the previous version for a while after the new one comes out. If you mean that 2.6.16.x fixed a critical vulnerability after they stopped 2.6.15.x, and they hadn't figured out the bug that nobody seems to have reported to the list, -stable patches generally apply (except for the part that sets the version) to a wide variety of kernels. Chances are that you can make a 2.6.15.8 that fixes the vulnerability without breaking the network cards (and LVM2) just by applying the 2.6.16-stable patches to 2.6.15.7.

Re:I preferred the old odd/even split

[cronius]

As others have commented on already: You're thinking about a stable ABI, not API.

And there's a reason they don't have a stable ABI: Having that restricts the freedom and creativity of the kernel hackers to choose the best possible solution to every problem.

They choose innovation over a stable ABI, and if you don't like it just switch to closed source OS.

Re:I preferred the old odd/even split

[morgan_greywolf]

Mod parent up!

Exactly. I run Ubuntu, and between the Debian patches and the Ubuntu patches, I've got a very stable kernel because they're constantly backporting the bugfixes from newer kernels and releasing them into the apt repositories.

Stability and polish are up to the distro maintainers -- on everything. Not just the desktop, not just the apps, but on the kernel, too.

Re:I preferred the old odd/even split

[soldack]

So are you saying that the APIs used by drivers have not changed at all between 2.4 and 2.6? I had thought that a bunch of things had changed. I had also heard that in some cases drivers that worked in 2.4 broke in 2.6 due to API changes. Am I totally off base here?
-Ack

Re:I preferred the old odd/even split

[grudgelord]

Not a completely dead breed. I used to follow the experimental/stable convention myself and wish it was still that way. Now it seems to be the experimental/experimental convention.

In the past I almost always compiled the kernel for the specific need. Nowdays, however...

err..okay, maybe we are dying.

Re:I preferred the old odd/even split

[shmlco]

"And there's a reason they don't have a stable ABI: Having that restricts the freedom and creativity of the kernel hackers to choose the best possible solution to every problem." If it changes that often then it sounds like they're not thnking about the the ramifications of their decisions and designing their code, thery're just hacking whatever comes to mind.

Re:I preferred the old odd/even split

[Anonymous Coward]

All that said in the discussion, maybe it's good to use even/odd minor releases for evolving/bugfix:

2.6.odd add a few new features
2.6.even bugfix, exercise the new code

but once we get multiple bugfix releases, it becomes same as 2.6.x.y so current 2.6.x.y scheme is all fine. hehe :)

Re:I preferred the old odd/even split

[Skuto]

>Stability and polish are up to the distro maintainers -- on everything. Not
>just the desktop, not just the apps, but on the kernel, too.

I think the point of the main article is that this really is becoming an unmaintainable situation.

Re:I preferred the old odd/even split

[cronius]

Perhaps, but I think the linux kernel (like all open source projects) is continously moving and evolving, and the engineer in charge just wants to make good code, and not get caught up/delayed in bureaucracy and restrictions.

It's a typical windows/linux debate argument: Windows has a stable ABI, vendors are happy, but the OS is crippled by legacy code that can't be thrown away because of ancient decisions (can't change the ABI).

Linux developers on the other hand are free to do whatever they want with few restrictions to create the best kernel, but vendors pay by having to keep up with the changes (which is time consuming and hard).

Local kernel code shouldn't break itself of course, but as the article for the previous slashdot article pointed out: Some drivers broke because of a API clean up, it happens.

Re:I preferred the old odd/even split

[petermgreen]

right then a feature you require doesn't work.

you contact people who know your distro but get no response. You contact the upstream of the peice of software in question and get back a canned "upgrade to x.y your distros version is ancient" response. So you don't have much choice but to move to the upstream version of the software.

If a software team can't make thier own stable releases decently stable and avoid breaking stuff too often there is something wrong with them!

Re:I preferred the old odd/even split

[killjoe]

"While the rest of us use Ubuntu to get work done"

I hear this a lot but it goes against all my experience. Usually the people I met who compile their kernels and do other geeky things tend to get way more work done then the people who want everything dropped on their laps.

Am I hanging out with a different crowd then you? The people I meet who use computers while not understanding anything about them tend to be some of the least productive people in any business. It's always the savvy guy/girl who can use the tool properly that gets all the work done.

By the way, that applies just as much to windows as linux. In any office you always have three or four people who really know how to use a computer and can use excel and access to get things done while everybody else just putters along.

Who gave you the idea that people who compile their kernels don't work as hard as you do and are unable to get as much work done as you do?

Re:I preferred the old odd/even split

[Anonymous Coward]

I think the majority of us have known this for years. "Breaking news: water is wet..."

As you add more functionality to a project you increase the chances of introducing new bugs as well unless you have excellent coding policies/standards/reviews/etc.

Re:I preferred the old odd/even split

[madhippy]

I first used Linux over 10 years ago ... something like the ygdrassil (???) oct94 release ... my main machine is currently XPSP2 ... and it gets rebooted less often then when it was a linux machine, has never had a virus, there's no spyware on it and it last crashed a few months ago ... it's on 24x7 ... runs all my software flawlessly and recognises all my hardware ...

I love linux and look forward to the time when I can boot it as my primary o/s ... but at the moment ... there's not a lot of point ...

Re:I preferred the old odd/even split

[Anonymous Coward]

LFS is for losers. Real men install an OS by typing "dd of=/dev/disk0" and typing in the machine code for the boot loader.

Re:I preferred the old odd/even split

[Nevyn]

The main difference was that if 2.4.x was good for you there was a very good chance that 2.4.(++x) would be good for you as well. Now, however, nothing is off-limits; so that is less true.

You are, of course, forgetting about the (at least one) huge VM change. And then that even though it was somewhat "true", it also meant that the huge pile of people who needed/wanted, one of the many year+ old features like O1 scheduler, NPTL, epoll and AIO you were just screwed (although it was somewhat fun speaking to the newbies who wanted to run NPTL on their debian stable 2.4.x and refusing to be told the truth).

2.6.x is much like 2.4.x, you either need a team of highly skilled Linux kernel developers following vanilla ... or you hope/assume/outsource it to Red Hat/SuSE/Ubuntu/etc.[1] If you aren't doing one of the above you are just playing russian roulette with your boxes.

[1] Anyone with arguments of the form "*BSD is better as they have a real stable" is referred to fig. 1 ... Red Hat etc. are providing the stable branches, and having choice isn't a bad thing.

Re:I preferred the old odd/even split

[phayes]

Try upgrading your RAM to 2Gb & then trying to hibernate. XP SP2 currently has an unresolved bug that prevents it from entering hibernation. I'd been procrastinating for years. I was using Windows as my main OS & running Linux under VMWare. Once MS made it impossible for me to only reboot when updates made it neccesary, I finally jumped to Linux as my main OS.

Re:I preferred the old odd/even split

[the_womble]

Of course its better to know more, but sometimes the urge to mess around and get everything perfect can get in the way of real work.

question

[mapkinase]

I thought since it is open source the bug level should be more or less constant. More bugs, more people willing to fix the bug, more fix submissions - problem solved?

I understand that the kernel code grows, it is natural for any software code, so does it mean that open source community is lacking developers now to handle existing corpus of open source code?

Re:question

[tomstdenis]

Part of the problem is experience. Projects like GCC and the Kernel are split along two problems.

1. The underlying technology is non-trivial

2. The implementation often is dirty, quick and without consistent method.

In the case of #1 it's the case that the technology is not trivial. How many people understand paging?

In the case of #2 the code in many cases lacks comments, uses cryptic variables and the documentation [even doxygen style comments] are just not there.

Those two issues fight against anyone willing to throw in a weekend to help out.

Tom

Re:question

[zootm]

As the previous article pointed out, there's no lack of developers, just a lack of developer interest in fixing the bugs. Many of the larger contributors are paid by companies to ensure that specific features are put into (or at least developed for) the kernel. And let's face it; bug-fixing is not fun. Regardless of how hard-working the people are on average, bugfixing is generally the sort of thing that people shy away from unless the bugs directly affect them, especially when working voluntarily.

All large systems have a danger of bugs creeping in over time, and it can be easy to let their numbers get out of control as time goes on. The fact that the people in charge are point it out now is basically an example of good management — attempting to address a concern before it becomes more serious.

Re:question

[WillerZ]

bug-fixing is not fun

Some people find bug-fixing fun. Well, not the fuxung so much as the hunt. You need to stalk your bug through the dense undergrowth of your source tree until you find its lair. Then you excise it with surgical precision.

At its best, bug-stalking can be more fun than development.

Re:question

[tadmas]

I thought since it is open source the bug level should be more or less constant. More bugs, more people willing to fix the bug, more fix submissions - problem solved?

This is a common misconception. In my experience, developers rarely want to fix bugs; it's often tedious to track down what is causing the bug, and the fixes can have a ripple effect where you end up creating yet more problems that you have to fix. It's much more fun to write some kewl new feature. Would you do something boring and tedious without getting paid? :)

Proponents of open source often claim that more eyes == fewer bugs, and this can be true for really obvious problems, but with respect to deep-rooted bugs I would expect it to be about the same. Proprietary vendors don't see it worth the money spent to fix every single bug, especially the rare ones -- you don't get much return on investment. Open-source generally won't fix everything either since it's tedious.

I work for a proprietary software company, and I don't look over everybody else's code except when I'm working on a particular module. Why would this be any different in open source? How many open source developers out there actively audit other people's code?

In general, bugginess is more a function of the quality of the developers (and the pace of development) rather than whether the project is open source.

Re:question

[Vo0k]

yep, the previous poster is right.

I thought I know C until I tried to fix a bug in the kernel.

It was a simple syntax bug. Somebody put xxx[...]->yyy instead of xxx->yyy[...] in one line, and the compiler was protesting about type mismatch. One single line. But it took me 4 hours or so and I figured out only what the correct syntax for that piece of code would be, by analysing types of the variables used. I have no idea if the fix really corrected the problem, it just made the line lexically correct and let the compiler go on. In the meantime I had to crawl about 4 levels of header files for each of the variables/records used in the line to reach primitive types of given variables and macros, from which the structures, pointers etc were derived, and generally was totally dizzy. And I was doing it the code monkey style, I didn't really understand the workings of the kernel, what was the line I edited meant. I was purely checking that a pointer to float isn't directly assigned a value of float, just pointer to it etc.

Kernel is too difficult for us average coders. Only the elite can fix these bugs for us.

Re:question

[tadmas]

bug-fixing is not fun

Some people find bug-fixing fun. Well, not the fuxung so much as the hunt.

Yeah, some people do -- I do most of the time. But in my experience it's the exception, not the rule. In general, I've found that people like fixing easy bugs, but the really bad heisenbugs and deep-rooted design bugs are a PITA. And these are a lot more common as the size of the codebase increases.

Re:question

[zootm]

Yeah, but as the sibling post points out, this only applies to some bugs. With many bugs it's a long, infuriating process to find and fix them, and a lot of people just don't have the patience to do this.

Re:question

[bhima]

This is nearly the same as my own experience... which makes me enjoy using, in my case, OpenBSD. I use C professionally but it's an order of magnitude (or two) less complex than the Linux kernel. It's just amazing to me it all comes together despite how many people are working on it.

Back to the point what can spending some time and having a bug fixing cycle hurt? I don't see a downside...

Re:question

[CastrTroy]

It's not necessarily the point that everyone is looking at the code, it's the fact that everyone is able to look at the code. How many times have to encountered a bug in MS software, or any closed software app, and wish that you could fix it yourself. Think of how many developers use windows on a dialy basis. I'm sure that if they had access, most of the bugs would be fixed by now, or at least, it wouldn't be as bad as it is. There's only a small percentage of developers who use open source software. Out of my graduating class of around 50(?) I think that maybe 5-10 of us knew about Linux, and maybe 5 of us used it on a regular basis. I know one guy who does open source programming. But it's not low level kernel stuff, just user apps. I think that as Linux starts being used by more large organizations, there will be many more people who are given the time to fix bugs. Just because it isn't your code, doesn't mean that it isn't your job to fix it. If a bug is plauging your job with problems, and you have the power to fix the bug, most likely you will.

Re:question

[Anonymous Coward]

floats in the kernel.....you must be mad!!!

Re:question

[Emil Brink]

Ick, sounds painful. But ... floats in the kernel? I thought that was forbidden, but perhaps that rule has been relaxed?

Re:question

[Vo0k]

'kay, there were no floats. I just said what I meant, compiler says type mismatch so I check if all types match.

Re:question

[eraserewind]

Well, I have to disagree. I need to fix kernel bugs all the time as part of my job (not in Linux), and it's no big deal, even though I am far from being a kernel developer. There is nothing magical about kernels. They are just C with little bits of assembler thrown in here and there. Of course there is easy to read code and hard to read code, but that is largely unrelated to whether something is in a kernel or not.

Re:question

[spun]

Well, if you do something all the time, of course there's going to be no magic to it. I'm a middle of the road coder myself, kernel code scares the bejezus out of me, but it I worked with it every day I'd get comfortable with it right quick.

The point is, some projects are straightforward. Jump right in, the water's fine. Others, not so much.

Re:question

[Anonymous Coward]

if get_a_one() - 1 < 0.001
{
  do_stuff()
}
else
{
//probably a math error do it anyway.
  do_stuff()
}

Re:question

[Politburo]

Think of how many developers use windows on a dialy basis. I'm sure that if they had access, most of the bugs would be fixed by now, or at least, it wouldn't be as bad as it is.

While I'm sure some things would be fixed, do you really think that the problems with Windows are so easily fixed that a developer in their spare time would be able to do it? Remember, MS isn't Linux. There are thousands of full-time employees working on these products. It just can't be that simple, or it would have been fixed by now.

IMO the problems with Windows are fundamental and come from the way Windows is built upon many different layers with compatibility hacks at every step of the way. Yeah, I'm sure there are some buffer overflows or other relatively minor bugs that might be caught, but in terms of 'fixing windows', open source probably isn't going to do it without a ground-up rebuild.

Re:question

[Dan Ost]

For those who don't know, the Kernel Janitor
project is dedicated specifically to fixing the bugs that are largely considered unrewarding
or uninteresting to fix.

It's a great way to learn about kernel hacking. It's educational to just lurk on the mailing
list before you're willing to actually get your hands dirty.

Re:question

[shmlco]

"I thought I know C until I tried to fix a bug in the kernel."

High-level isn't about knowing C. It's about being able to hack a five-level-deep macro created so you can inline a function used three times in your code.

Re:question

[reed]

Welcome to the world of working on large projects. Figuring out how they work when you've only just started peeking at a little piece of it is a skill you have to work on over time. Almost all large projects are like this to one degree or another.

Re:question

[Vo0k]

Oh, but that's exactly what KNOWING C is about. So that you spend 15-30 minutes on fixing said macro (...by replacing 1 wrong character), not 4 hours.

Re:question

[shmlco]

Actually, if it's the first time you're looking at that particular code it's more like spending 4 hours breaking down the macro so you can understand it enough to fix it. And then changing it and hoping you didn't break the 54 sections of code that use it.

Macros are to C what operator overloading is to C++: unsually abused beyond belief.

Re:question

[jnelson4765]

On the other hand, I enjoyed my time doing kernel programming. It does take familiarization - any codebase that big requires time to learn how the software works, even ones less complex than modern kernels.

I just think it's great that there's an opportunity for mere mortals to play in one of the biggest games on earth for OS geeks - and of all the OSS kernels out there, the Linux kernel has the fastest pace. And there's a lot of room to grow, especially in the microcontroller area.

Re:question

[crulx]

Nah.

Microsoft has 10,000 employees making the NEXT version of Windows. Your current Windows OS is being maintained by the people who couldn't manage to get into the incredibly large "cool team doing fun stuff." Not a recipe for OS success, I think. Script Kiddies with code scanners find more bugs than the entire MS team does. What does that say to you?

But that plan does sell software well. The basic argument of the GNU people says that software monopoly has a fundamental, RIDICULOUSLY EVIL quality to it! (All caps makes it even more ridiculous and evil. *grin*) Few wish to face that fact.

But you have to eat too.

So we used to have this idea of a "natural monopoly." Anytime that you had to build a business around maintaining something that everyone needed, "we the people" would stop by and make sure you were not screwing "we the people". It typically ended up being a bit costly and slow, but the process worked better than the alternative. However, "we the people" made ourselves retarded by watching MTV and now we don't do this anymore.

So I think this brings up an interesting point. At what level do we require a company to submit to inspection because they control a "natural monopoly?" Microsoft has proven that it HAS to be at the level of the Operating System. But then we look at Microsoft Office and we find a "natural monopoly" based on the file format. So by reason, "we the people" must check out these companies as well. I think you can apply this argument inductively without invoking a slippery slope form.

All commercial software forms a natural monopoly by virtue that it "lays tracks" on the universal machine. And by "universal machine", I mean the laws of reason. Alien races, probably right now, infringe on many patents filed in our lovely Earth Patent Office. Computer Scientists really mean Universal Turning Machine. Tis no joke!

So I think it very reasonable for "we the people" to have the following on every proprietary software company.
1) Access to "track design" to ensure reasonable safety tolerances. (read no spy ware, permanent record of the source code, protection in special circumstances (Take the medical field for an example, though they do this already themselves.))
2) Oversight of revenue
3) Oversight of business acquisition

And we pretty much have every law in place to set this up already, except "we the people" have to catch the next American Idol so we don't have time to set it up. It seems very beneficial to set up a new department for registering, tracking, and taxing software monopolies. It could fund itself via required processing fees or proportional taxes. And Free Software would be exempt, as it isn't a business, has no revenue, and comes with no warranty of purpose.

In short, it has nothing to do with "compatibility hacks." The system works that way for a universal reason. "We the people" should step in and stop these monopolies from screwing us, but we don't. Uncountable billions are lost and people endure great suffering to enrich a few. It seems very sad to me.

Re:question

[crulx]

Or maybe they mean Universal Turing Machines, with overzealous spellcheckers. Ha! Mocked myself first!

Re:question

[zootm]

Sounds like a very good project. :)

Standardize the Kernel API!!

[mlwmohawk]

I have been using Linux since the early 1990's and I've been a software developer for almost 30 years. The one ting that concerns me, and I think this recent indictment is just a symptom of a larger problem.

The problem is that the drivers have to remain in constant flux because the kernel API is always changing. Now, when there are a limited number of drivers, this means that you can move quickly on the kernel. As you add more and more drivers, you add more and more work to keep the drivers updated. Eventually, there is more work needed to update the drivers than modify the kernel, and the drivers become your sticking point.

This is where I believe Linux is stuck. Linus and the kernel team has to look at the various kernel APIs and standardize them with the next release.

Sorry guys, time to grow up. Linux *is* mainstream!

Re:Standardize the Kernel API!!

[Anonymous Coward]

HI2U JEFF MURKEY WE KNOW IT'S YOU!!!

Seriously, for fuck's sake, the stable API argument has been hashed to death on linux-kernel at least twice in the past three years. The primary drivers for these arguments are almost always people who want to make GPL-incompatible (usually closed-source) kernel modules. Pretending it's about stability of the mainline kernel is even more dishonest than the usual arguments in favor of out-of-tree modules.

Re:Standardize the Kernel API!!

[Whiney Mac Fanboy]

The problem is that the drivers have to remain in constant flux because the kernel API is always changing. Now, when there are a limited number of drivers, this means that you can move quickly on the kernel. As you add more and more drivers, you add more and more work to keep the drivers updated. Eventually, there is more work needed to update the drivers than modify the kernel, and the drivers become your sticking point.

No - The kernel API (whilst not set in stone) is quite stable & doesn't change often. The kernel ABI on the other hand... well, changes alot.

But really - that only affects close source kernel modules - and why should the linux kernel team care about people who want to leverage the linux kernel without contributing their source code back.

Sorry guys, time to grow up. Linux *is* mainstream!

Time to grow up - pay for a kernel if you want it the way *you* want it.

Re:Standardize the Kernel API!!

[cortana]

http://lxr.linux.no/source/Documentation/stable_ap i_nonsense.txt

Re:Standardize the Kernel API!!

[John_Sauter]

As a software developer whose experience goes back more than 40 years, to the Stanford Time-Sharing System on the DEC PDP-1, I can assure you that the only way to keep the kernel API from changing is to kill the project. Just as you wouldn't expect a driver written for Microsoft's MS-DOS to be effective on a modern NUMA machine, you shouldn't expect any driver interface standardized today to be effective 10 or 20 years from now. An attempt to freeze the driver API would hamstring the kernel developers, making the kernel less interesting to work on. Somebody would fork it, to lift the compatibility restriction, and the new kernel would work much better with modern computers, causing everyone to migrate to it.

The only way to keep Linux relavent it to let it evolve. Yes, that creates a burden on driver writers. Linux has a partial solution: keep your drivers in the kernel source tree, and test each kernel to be sure your driver still works. When it breaks the cause should be obvious, and easily fixed. If you are lucky, the person who changed the API will also update your driver, but you can't count on that, which is why you must test.

Re:Standardize the Kernel API!!

[xtracto]

So, if you have a Linux kernel driver that is not in the main kernel
156 tree, what are you, a developer, supposed to do? Releasing a binary
157 driver for every different kernel version for every distribution is a
158 nightmare, and trying to keep up with an ever changing kernel interface
159 is also a rough job.
160
161 Simple, get your kernel driver into the main kernel tree (remember we
162 are talking about GPL released drivers here, if your code doesn't fall
163 under this category, good luck, you are on your own here, you leech
164

No, this sucks, I respect the GPL and other open source licenses (BSD) as well as closed source licenses. If nVidia or ATI or any other hardware manufacturer do not want to license their software as GPL it is their decision. The operating system MUST provide a standarized API.

Whoever agrees with this does not have the right to whine that X or Y company does not provides drivers and support for Linux. It is a design flaw IMNSHO.

Re:Standardize the Kernel API!!

[diegocgteleline.es]

The problem is that the drivers have to remain in constant flux because the kernel API is always changing

Well, this is just a consequence of what people is discussing. In the current 2.6 model you're allowed to merge new features (ie: things that break the kernel API). What you're proposing is to go back to the stable/unstable development model.

But I don't think the "changing kernel API" is the source of problems - if a driver doesn't work, it's because it doesn't have a good maintainer. Releases take around 2 months currently in the linux kernel, if a driver maintainer can't take care of a driver in a two months timeframe then the driver doesn't have a good maintainer. Is not that because the kernel api is not stable, driver maintainers need to rewrite drivers in every release, either; and when a "invasive" change is done to introduce a new feature, its not rare that the guy who breaks things and introduces the new feature is forced to port the drivers to the "new api" to get his changes in. But you can find tons of drivers that have not been touched deeply in more than 6 months. And the ones that have been patches recently have probably been patched because the maintainer was working in something related to the driver, not "trying to fix kernel API breakage"

Re:Standardize the Kernel API!!

[oliverthered]

I can assure you that the only way to keep the kernel API from changing is to kill the project.

You don't have to stop the API chaging, you just have to stop it changing all of the time. Doing that also give you the added benifit that third party vendors don't keep pulling their hair out because the kernel API keeps changing so they may be more included to actually release drivers in the first place.

Re:Standardize the Kernel API!!

[Anonymous Coward]

click

Re:Standardize the Kernel API!!

[mlwmohawk]

I have read this piece before, and while I think it is very good, it and I both agree that a "binary interface" is a bad idea. I am not suggesting that at all. I am suggesting that, as part of the kernel, define a stable API.

Look at the current APIs, augment or "bless them."
Don't access structures, use macros.
Bless tried and true interfaces, and make damn sure no one changes them without keeping backward compatibility.
Assign temporary status to "experimental" interfaces.

Maybe create a synthetic API layer analogous to Windows NDIS sort of thing, where common peripherals can just code to that and be done. That way, the vast majority of simple devices will just come along for the ride.

There are lots of steps that can be taken. At issue is a fact of life people ignore: The strategies and skills used to attain success, are not the same as those needed to maintain and continue succeeding.

To use a marathon metaphor, Linux is no longer sprinting to catch up, we are in the game. As such, we need to recognze and understand we can't sprint forever, we need to settle down and pace ourselves, this is a long race, and the winner will be the one that plans ahead.

When the Linux kernel was small, changes could be made to the whole source tree easily. As it gets larger and larger, one obscure change in one section of the kernel may not generate an error or even a warning, but may break a driver you didn't even know about. That is exactly what we are seeing.

Linux is no longer a small and simple kernel.

Re:Standardize the Kernel API!!

[Nicolas MONNET]

No, this sucks, I respect the GPL and other open source licenses (BSD) as well as closed source licenses. If nVidia or ATI or any other hardware manufacturer do not want to license their software as GPL it is their decision. The operating system MUST provide a standarized API.

If you really respected the GPL so much, you'd have read it. Binary kernel modules are forbidden by a strict interpretation of the GPL; kernel developpers have merely tolerated them. Notice the warning in dmesg when you insert nvidia.ko. (dmesg|grep taint)

Re:Standardize the Kernel API!!

[tonigonenstein]

Just as you wouldn't expect a driver written for Microsoft's MS-DOS to be effective on a modern NUMA machine, you shouldn't expect any driver interface standardized today to be effective 10 or 20 years from now

You are right. It is not realistic to cast the API in stone. But what we could imagine is fixing an API for 2.2, 2.4, 2.6, 2.8, ... and then provide in every new major release optional compatibility wrappers for the old APIs (if we can write ndiswrapper, this is certainly possible).
That way either you are commited to work on a driver and update it to the new API or (if it is older and for less used hardware) you keep it as it was in the previous version and rest assured it will work.
This remove the burden to fix old drivers not many people are interested in and doesn't force the ones who are interested to stick with an old kernel that may be unusable because it doesn't support necessary new features.

Re:Standardize the Kernel API!!

[mlwmohawk]

OK, nice strawman. Yes, you are right, it has to change yada yada yada.

At issue is the frequency of change. Think about the C file I/O API. It has not changed in almost 30 years. Why not? Because it didn't need too. It was designed up front. Everything under it changed, of course, but it didn't.

It is not impossible to standardize certain APIs and continue to grow. That's the point of an API it is an "interface," not an "implementation. "

Re:Standardize the Kernel API!!

[IAmTheDave]

No, this sucks, I respect the GPL and other open source licenses (BSD) as well as closed source licenses.

Agreed. Open source is a choice, and not chosing to OS a driver code package does not immediately or synonymously make a company evil. Most people want Linux to start playing in the same space as Windows (well, at least OSX) in terms of user numbers. This will never happen unless hardware vendors are allowed to create binary drivers for their products.

Look at the video card space - drivers can sometimes mean a 20% boost in performance. Allowing the competition to get a look at these drivers means that you don't have an awful lot of IP to keep the business profitable.

If anyone ever wants Linux to be more than a hobbyist desktop OS, it will have to allow for the use of binary drivers. It's too late to put it into a hardware lock-in cycle like OSX (which does allows binary drivers) - Linux on the desktop will have to run on comodity hardware, and so for anyone to ever consider it seriously, it will have to be allowed to play with whatever hardware I want to purchase - and in order to do that, it will have to play with binary drivers nicely.

My two cents (and parent poster's)... but pretty rooted in logic.

Re:Standardize the Kernel API!!

[tomstdenis]

What about loadable module support? What if you want to add a probe detection callback, etc, etc.

There are many reasons to change the module interface format. Many of which include the ability to do things we take for granted today.

What the kernel really lacks is a good standard for coding practices, like say adding comments and indenting at least somewhat sensibly [yeah I know for some of you "elites" you can take reading a complete lack of consistent indentation but for the rest of us ...]

Tom

Re:Standardize the Kernel API!!

[MROD]

I disagree.. mostly.

There needs to be a stable API for drivers PER MAJOR RELEASE so that the driver maintainers can keep stable, well tested and debugged drivers.

The API should be allowed to change with every major kernel revision but any change should be made with a great deal of thought and, unless it's very difficult to do, the old API should be supported for backward compatability.

Not only this, but I would argue that it would be good hygene to separate the core kernel from the drivers. Doing this would make developers think hard about the bounderies between the two and not have one polluting the other. It would also make the developers think long and hard about whether changing the API for something is such a good idea just because it would be useful for the "ACME USB SLi Graphics card programming port widget" interface.

The the kernel is the kernel, the drivers are merely plug-ins to virtualise the hardware, the two should be as separate and distinct as they are logically.

Re:Standardize the Kernel API!!

[just_another_sean]

The operating system MUST provide a standarized [sic] API.

People who code free software MUST not do anything unless they feel like it. Sure some of them might get paid by Company X to develop Driver Y or Application Z but they do so on the shoulders of what's already been put in place by free software developers.

If Linus and the rest of the kernel developers decide at some point to provide an ABI that proprietary companies can use to build their drivers, all the while clinging to their dated business methodologies and obsession with "IP", then great, that's their choice. It might take a Herculean effort to get all those copyright holders to agree and do it but if they can then that's up to them.

Conversely, if they choose not to, they under no obligation to provide anything. Nobody on the kernel team, IMHO, ever got together and said "we need to start coding and provide some free software so companies with no interest in participating in the process can take our free software and make some money selling hardware". They do it for themselves, their friends and family, their community. Whether or not ATI and NVIDIA want to be a member of that community entitles them to exactly nothing.

Re:Standardize the Kernel API!!

[CaptnMArk]

But I'll take the card without that 20% and open source drivers any day.

Your +20% card will be -20% card in a year anyway.

Re:Standardize the Kernel API!!

[EvilGrin666]

What the kernel really lacks is a good standard for coding practices, like say adding comments and indenting at least somewhat sensibly [yeah I know for some of you "elites" you can take reading a complete lack of consistent indentation but for the rest of us ...]

The kernel includes a document detailing the coding style to use. It lives in Documentation/CodingStyle.txt You can read the current version from Linus' Git tree here. If you spot anything in the kernel that doesn't follow CodeingStyle.txt you should submit a patch to the kernel janitors to fix it up.

Re:Standardize the Kernel API!!

[ratboy666]

Thank you.

I would like to modify this slightly. I don't think a single DDI (device driver interface) will work, but several DDIs can be defined:

A low level SCSI DDI
A low level audio DDI
A low level network DDI

and maybe others. Factor the drivers, and extract common parts into the appropriate DDI.

Now, a vendor would write to that DDI, and the Linux team would have to promise that the defined DDI would have a lifespan of (?, but as long as possible). Any drivers needing a custom kernel interface would be planted into the source tree as is now done.

All drivers under the DDI can be checked for conformance. The DDIs would not have to be "officially" introduced until they are ready.

Putting fences like this into the kernel would be (in my opinion) a very good thing.

Ratboy.

Re:Standardize the Kernel API!!

[DarkOx]

I am with you except for supporting the old API. When a new major relase comes out it should not be backward compatible at the driver level. If it is we will just end up with a bunch of unmaintained drivers sitting about; which will lead to problems. The other thing is all that backward compatibility would add tons of cruft to the driver layer which would eventally just slow down development. People can wait for the drivers they need to be ported to the next major version, before they upgrade.

Re:Standardize the Kernel API!!

[LordOfTheNoobs]

Point 1 - Your post contradicts its own supposed respect of the GPL.
Point 2 - Linux is FSF free, share and share alike by license. BSD is not. You can't generalize them together on this issue. If you don't get the difference, you don't know what the hell your talking about.
Point 3 - The operating system doesn't _have_ to do shit. If the companies want their shit to run in Linux, the should submit GPL'd drivers or suffer their rightful hell for being miserly with their code in a project based on sharing. To hell with them.
Point 4 - There is a fairly standard API. And when they change it they fix the GPL drivers. There is not an ABI, `application binary interface' since you obviously don't know, which is not require or desired as Linux runs on many different types of hardware. Should we instead suffer to create an ABI for each hardware platform that each driver must uphold? There is more than x86 out there. Hell, even in x86, should we make all drivers have to suffer to a 16 bit driver interface, or create different ABIs for 32 and 64 and the future 256 and 1024 bit systems?
Point 5 - Cry more noob.
Point 6 - If a hardware manufacturer wants to sell their hardware to us, they will either suffer intolerably or they will give in and release some GPL'd code. If coders want it bad enough, someone will reverse engineer it and create free code on their own. It's not like we're going to start using our DVD-Rs to burn off graphics cards. Well, not until my chinese GFX-RW comes in anyway.

Re:Standardize the Kernel API!!

[just_another_sean]

Most people want Linux to start playing in the same space as Windows (well, at least OSX) in terms of user numbers.

"Most people" meaning all the people that want Linux to just work without giving anything to it to make it better. The folks who want a free (as in beer) Windows. Don't get me wrong, I love that fact that my Mom uses Linux and she doesn't give anything back to it. And I honestly can't say I am a major OS contributor other then advocacy and local support for my community but I also have no interest in "commercial" Linux. If my primary source of income was based around the future of the kernel you bet I would pay to contribute. And I would do so on the grounds laid out by the kernel developers.

As far as I'm concerned Linux is already successful because a lot of people use it, as is, and get a lot out of it. Hell if Linus continues to use it and no one else in the world does I would still consider it a success. He wrote it to use, not to sell.

No, non OS drivers are not "evil". Expecting a bunch of developers to support you, as in "stabilize your ABI, you owe it to us", is not really evil either. I consider evil to be too strong a word when talking about drivers. But it is inane and idiotic for these companies to expect anyone serious about software development to give a rat's ass whether or not their closed source drivers work with an open source kernel. They know how the Linux development model works and they are invited, nay *encouraged*, to participate in it. They choose not to, instead trying to keep one foot on the shore of their old "IP" business and the other tentatively placed on the OS side hoping that somehow people will respect them as part of the community. If they choose not to join the project and play by the rules that were established by the project members how then are they entitled to, in any way, steer the future of that development model?

Re:Standardize the Kernel API!!

[swillden]

Defining, documenting, maintaining and verifying consistency of those DDIs would be a lot of work, taking time away from other tasks, and constrainig the pace and direction of development.

Where's the benefit of all that effort? Enabling closed-source drivers that destabilize the kernel in difficult-to-debug ways? Creating a situation where more and more users are running kernels the kernel developers refuse to debug?

I don't see why it would make any sense at all to put all of that effort into creating and maintaining a structure that merely serves to destabilize the kernel and make debugging harder.

Re:Standardize the Kernel API!!

[m50d]

As a software developer whose experience goes back more than 40 years, to the Stanford Time-Sharing System on the DEC PDP-1, I can assure you that the only way to keep the kernel API from changing is to kill the project.

I refer you to solaris. Still very much alive, and backward compatible as far as version 5.

Re:Standardize the Kernel API!!

[CaptnMArk]

Note, I don't mind binary drivers for 20% extra (some might even pay for them).

Re:Standardize the Kernel API!!

[gowen]

Really, besides games, what do you actually use that extra performance for?

Re:Standardize the Kernel API!!

[Anonymous Coward]

Use Solaris. This is exactly how Solaris has always been. There are stable "external" interfaces (e.g. libc, kernel driver API/ABI, /usr/xpg4 and so on) and "internal" private interfaces (e.g. deep in the kernel) that may change without warning at any time.

This is how Solaris achieves reliability, portability, maintainability and 15+ years backwards binary compatibility.

Hopefully, now that it's open source and free beer, it will take on a new lease of life and more people will find out its benefits.

Re:Standardize the Kernel API!!

[maxume]

Point 2 - Linux is FSF free, share and share alike by license. BSD is not. You can't generalize them together on this issue. If you don't get the difference, you don't know what the hell your talking about.

Only because the FSF lives in a la-la land where the only way to protect a right is to exercise it to its full extent all the time. Everyday, adults all over the place sacrifice their right to free speech because they see an advantage to biting their tongue that outweighs the benefits of speaking freely in that instance. They do the same thing with non free software.

I am glad that the FSF takes an aggressive position on legislated DRM, which is an actual threat to 'software freedom' rather than a choice, but even if there is a generation or two of crap hardware, people will revolt and things will go back to as-they-should-be.

Re:Standardize the Kernel API!!

[pkulak]

Oh God, that coding standard is terrible. I'd hate to have to deal with that all day.

Re:Standardize the Kernel API!!

[Builder]

I fully agree with this, and I see this as one of the biggest barriers to enterprise adoption.

Vendors such as Red Hat and Novell attempt to give the client this - in fact they both guaranteed no API / ABI changes within a version (e.g. RHEL 3). This was difficult but feasible under the old model, but from what I can see it is impossible with the new development model.

They either have to stick with one specific kernel version for the entire lifetime of the product, backporting the things they need from new kernels, or they have to break this deal.

The whole threads change in 2.4 is STILL biting me in the ass today.

I agree that you can't freeze Linux forever, but an attempt should at least be made within major versions (e.g. 2.6).

Re:Standardize the Kernel API!!

[KarmaMB84]

They let it go because they don't know if the driver is a *derivative work* until they sue for the details. A judge might not think a patched Windows driver with a compatibility layer is a derivative work of the kernel...

Re:Standardize the Kernel API!!

[Anonymous Coward]

This is what I don't get: why should we be upgrading hardware so often?

You see, this puts me in a difficult situation. I like the challenge of building older systems and I like to keep computers (which were built to very specific standards) for several years. And, yet, this shuts me out of Linux almost entirely. I just can't see frequently buying more and more new hardware to replace that which your lot has chosen to de-support.

Which is part of why I run Windows, in addition to a Mac (which has its own problems), and not a single Linux distribution. Yes, I concede 98SE doesn't get much, if any, updating these days and that XP would crawl on a Pentium Pro. On the other hand, Windows'll run just about any software and recognize any hardware from that machine...and, face it, KDE and Gnome are no strangers to crawling (they brought a K6-2 500mhz to its knees in RH7).

From a softwareengineering side, I don't see what's so difficult once you get over the hurdle of understanding the kernel. I write and maintain software too and backward compatibility isn't some arcane ritual prone to catastrophic failure. You just have to be willing to do it, either as a precaution to recover from your changes or an acknowledgement that somebody else might rely on what you're changing.

Sure, for a free project, it's tough to complain but it's not baseless by any means.

Re:Standardize the Kernel API!!

[MobyDisk]

Doesn't ALSA effectively do this? I thought ALSA was a kernel module that provides an API for other kernel modules. That way, when the kernel API changes, the developers only need to modify ALSA, not every driver. Can't they just make something like that for each type of driver?

Re:Standardize the Kernel API!!

[drew]

The current situation is ridiculous, though, regardless of whether or not you believe that binary drivers are acceptable.

First of all, I don't believe that Linus et al refuse to provide a stable kernel API merely so they can snub companies who only release binary drivers (although obviously it is perceived by many as a nice side effect).

Providing a stable kernel API would provide substantial benefits for open source drivers as well in terms of reduced maintenance. This would especially be true for hardware that was once common and well supported but is now aging and not actively maintained, but there would be many other benefits as well.

IMHO, the kernel developers would do well to realize that their antics are hurting themselves far more than they are hurting any hardware company that refuses to release GPL drivers.

Re:Standardize the Kernel API!!

[rufty_tufty]

But she does give something back to it.
For a startoff their is mindshare - might not get you many geek points, but that fact that the average person on the street is starting ot hear of and use linux helps everyone, especially those who develop.
Second if she chooses hardware that is supported under linux, then she is helping the case for more people supporing Linux hardware - the more money people make from selling compatable hardware, the more companies will put effort into drivers.
Third, with any luck it's money that MS won't see, while not directly helping the linux cause, it's $200 less that MS can spend on SCO...

Re:Standardize the Kernel API!!

[rufty_tufty]

"why should the linux kernel team care about people who want to leverage the linux kernel without contributing their source code back"

Because most companies in this position make hardware, not software. Until the open source hardware movement takes off (and there's good reasons why it never will), they make their money from their hardware and doing anything that gets in the way of this is a bad thing.

It's not about not giving anything back (the company i used to work for released closed source drivers, and had closed source projects built on linux, but did submit bug fixes and features to the Kernel - nortel contributed a LOT to real time linux) it's about protecting your revenue stream. So things that weren't part of how they made money (the OS) they gave to the community; stuff that they made money from (the hardware architecture and services) they kept to themselves.

Perfectly allowed by the GPL, and as far as I can see a perfect case of community and buisness working together. But this requires binary drivers to be allowed and even encouraged.
Just because someone doesn;t have exactly your values doesn't mean you shouldn't try and help him out.

Re:Standardize the Kernel API!!

[rufty_tufty]

Ok I'm building a new network card with uber hardware protocol assist.

I've invested $30Mill on this thing. I release the source code. What do I get? Well some people might find bug fixes, but at $10 Mill per spin of the masks, I'm not going to get very rapid development cycles. The kid in the backroom that is good at re-compiling the kernel isn't going to be able to do the same thing for this chip as he can in the Kernel.

Meanwhile my competitor and all my partners now know every trick I have. and can take the best bits and I'm in trouble.

I agree closed source has some problems, but how can you call closed source "dated". Can you propose another way that silicon development could work? Consider what would happen to Intel if tomorrow they released ALL of their IP (all processors, all their network card IP, everything!) Would many people submit bug fixes to Pentium 4, or would they loose out as a buisness because AMD now knew all their secrets?

Re:Standardize the Kernel API!!

[UnknownSoldier]

I used to think so at first, but that's not going to happen, because it is un-workable. It is un-workable because Linux supports more and more devices over time. It takes a while for the common API to perculate up.

If we could "freeze" what devices the kernel supported, then I would agree, 'stabalizing' the kernal API would be a great feature, for each of the 2.x series independently. But that is just not going to happen when the _hardware_ itself changes. i.e. new buses (PCI Express), etc.

In fact, there are only 2 reasons I see to upgrade an OS (or parts of it):
1) To support (new) devices
2) Bug-fixes - usually either security, or performance.

Cheers

Re:Standardize the Kernel API!!

[Dan Ost]

Except for the 8-space tabs, I find it very reasonable. In fact, except for the
8-space tabs, it's pretty much what I do now (I use 4-space tabs).

What, pray tell, are your issues with it?

Re:Standardize the Kernel API!!

[NutscrapeSucks]

Binary kernel modules are forbidden by a strict interpretation of the GPL;

There is no such thing as a "strict interpretation" of the GPL, it's not a biblical text. There is only the accepted legal intreptation of copyright laws. When copyright lawyers state that Nvidia is totally within their rights to release a binary driver, you can't make GPL angels dance on the head of a pin and change things.

Re:Standardize the Kernel API!!

[just_another_sean]

Agreed. And I didn't mean for my post to come across as another typical "it's free damn it, if you don't like it build your own kernel" rant.

I just don't understand where people come off dictating what should or shouldn't happen to free software based on the needs of ATI, NVIDIA or any other commercial entity that tries to reap the benefits of free software all the while snubbing the development model that makes it possible in the first place.

Now you could argue that ATI and NVIDIA don't really get much out of providing open source drivers with their hardware. That the Linux community doesn't amount to enough of a market to change their numbers, one way or the other. But if this is so why provide drivers at all? Clearly their is enough demand that they felt the need to shut people up by giving them something. Is that all it is? A "fine, here, now leave us alone". Or do they get something more out of it? A "works on Linux!" sticker on the side of their packaging? I just don't get the need to provide something but do so in a way that pits one Linux distro against another or locks people into a single version of the kernel and the long wait until the next version comes along.

I've used both ATI's and NVIDIA's binary drivers in an effort to appease new users who felt they were missing out without them. But it sucks. It sucks on so many levels.

The conspiracy theorist in me posits that ATI and NVIDIA put these binary messes out there just to make the Linux community look fragmented and behind the times. Rather then acknowledge that they don't want to participate in this type of development model they throw a half hearted attempt at supporting Linux using "my way or the highway" type tactics. And time and again I hear "Linux sucks because I can't use X with it".

Anyway, your point about stability and maintenance for true OS developers is quite right and a hell of lot more on topic then my rants. Mine is a knee jerk reaction to someone saying "they MUST do x, they owe it to us". Nobody owes anyone anything, this is the beauty of free (as in freedom) software.

Re:Standardize the Kernel API!!

[ratboy666]

I didn't say a thing about open vs. closed source drivers. Indeed, I think that that open source is the way to go.

The purpose of building the DDI is to allow the drivers to be abstracted away from the kernel. This already occurs, but is not an official policy. If the drivers are so abstracted, kernel development can push forward at an accelerated rate.

The reason is simple -- instead of having to check hundreds of drivers against a change, the interface can be checked. As long as the drivers all conform to the interface, they should also work. This makes introduction of new kernel features safer, and allows safer introduction of new drivers as well.

An unintended side effect is that it would be easier to produce binary only drivers. I don't wish to encourage that behaviour, though.

Ratboy.

Re:Standardize the Kernel API!!

[just_another_sean]

Granted you have some valid points here and I don't claim to have all the answers. And for what it's worth AMD seems to be competing fine on the merits of their product without having to steal from Intel. Free hardware is a tough issue to handle, especially bleeding edge, revolutionary stuff. But how many features of a modern graphics card are really that secret? I'm asking, I'm honestly ignorant on this. It seems to me that if you can write a software interface that provides an API to commonly used graphics methods (Open GL for example) then there is an awful lot about graphics cards that are similar. The vesa driver for X is another example. Is there no way for ATI or NVIDIA to put out open source drivers that handle most of what their cards do but stop short of releasing a code interface to their latest, greatest super secret method for displaying bits?

Using your network card example; in the name of interoperability are you unable to put out a driver that makes your uber sexy network card behave like a plain old Ethernet card? Maybe I want to standardize on your hardware for purchasing purposes but will need to run it in a mixed environment. So I want your binary drivers for Windows but I have a Linux Bind server and a FreeBSD firewall that I would like to be able to outfit with your card as well. Is there nothing a shop can do to accomodate me, provide source so I can upgrade my OS when needed and still hang on to thier precious IP?

I just want something from ATI that is a) portable (source included that is) and b) gives a little better performance then the vesa driver. If the SuperBitBlt function of the card is just too juicy to give away then don't include that functionality in the driver.

Maybe I'm being naive here and making it sound easier then it is. Alternatively I just wish that if ATI and NVIDIA don't want to participate in open source development that they just wouldn't bother at all. But since they have a virtual duopoly on the video market right now I guess we wouldn't be able to run OSS on anything without them.

Re:Standardize the Kernel API!!

[pkulak]

Well, the first thing is the 8-space tabs, that's just excessive. Then there's right justifying multi-line strings and function calls: what's wrong with a tab? The differnt brace style for functions and conditionals means that my editor can't help me much there anymore. But all that's just from a cursory glance, I obviosly haven't put a lot of time into this assesment, and don't really feel like doing so. :D

Re:Standardize the Kernel API!!

[Anonymous Coward]

> so that the driver maintainers can keep stable, well tested and debugged drivers.

I honestly don't believe there are any well tested or debugged out of tree drivers.

I've used nvidia, aacraid, bcraid, bcm5700, sk98lin. They were all pretty horrible. aacraid redifines current. nvidia is crash prone. bcraid was the most wretched of all more than the others. bcm5700 was the best, but it was still crashy. sk98lin has numerous problems but in particular bonding is messed up. Sk98lin code is amusing actually, which is a probably a bad quality in a driver.

Which drivers are decent from your experience?

Re:Standardize the Kernel API!!

[rufty_tufty]

I can't argue with any of that really.
However some points:

Until Friday i worked for the company that did make graphics IP (PowerVR if you remember them from when they did PC graphics cards - videologic) and can answer that there were 2 main aspects. Firstly it was no secret that the performance advantage we had was that we were tile based rendering which although very difficult to make work in hardware give a massive performance advantage. So to release the drivers to most of that was no problem. However, because doing it is _so_ difficult (we were the only company ever to make it work) some of the none patented tricks we used to make that work would be discoverable from the code. i.e. yes some graphics stuff was very secret, as we were the only company that could/can do it.
So to specificlly answer your question, 90% of the time no there is nothing much magic in there; however details about how you set up the pixel shaders for example, or the internal formats you use in your texture compression can tell your competitor how to reverse engineer your deisgn, that 10% of the time however is enough to make the managers nervous :-)
The other issue is we partnered with other using bits of their IP too. (e.g. the LCD panel interface was a common one to buy in) Were we to accidently give their secrets away we'd be liable. many interefaces to hardware are at least covered by license agreements - try and get a copy of the PCI spec legally without paying for it! This is an issue shared with pure software too though. (I suppose most media players hit this one)

If I understand you correctly, you're saying you're happy with an open source driver that is low performance, and a binary driver (possibly windows only) that is high(er) performance. This would imply to me then that the high end servers (in the network card case) perform much better under Windows. Not a situation I'd like to encourage. I'd prefer a standardised binary interface to the kernel that although none ideal, gives a compromise most of the time.

The reason i used a network card example has nothing to do with the company i just moved to at all...

FWIW I'm just comming from the perspective that I believe there is a place for open source and closed source in all fields. I'm as happy to have a mobile phone running BSD or Symbian, they have different advantages, I'm as happy to use winamp as I am XMMS. It's VI vs Emacs if we're not careful though ;-)

And while we're bashing people for not giving back to the open source community, consider google who apparantly run everything on Linux, but don't release the source code to their search engine :->
Ok I've just got modded flaimebait haven't I :-)

Re:Standardize the Kernel API!!

[mlwmohawk]

You can't build a house on sand. Apply the 80/20 rule, 80% of the drivers could be supported by a standardized kernel API.

I/O, Memory, interrupts, DMA, device slots, and etc. are not rocket science. Most devices would benefit from a standardized API, be it done in macros or function call-outs.

Personally, I don't thing a pure binary API is a good idea, but a mix of macros, structures, functions, and a bit of abstraction would make a HUGE impact on driver development and maintenence.

Re:Standardize the Kernel API!!

[swillden]

I didn't say a thing about open vs. closed source drivers.

Indeed. Sorry, I projected others' arguments on you.

The purpose of building the DDI is to allow the drivers to be abstracted away from the kernel. This already occurs, but is not an official policy. If the drivers are so abstracted, kernel development can push forward at an accelerated rate.

My impression is that this level of abstraction is already in place, that the source code-level APIs are established and don't change much, at least for common device classes, and at least as long as other architecture changes don't require driver changes (e.g. APM to ACPI). Perhaps there could be a bit more, but my take is that the developers think that additional standardization would bring diminishing returns.

I am not a kernel developer, though. I've tweaked a little kernel code, made tiny fixes to a handful of device drivers and used to read LKML fairly regularly, but I'm far from an expert. If you know more, please elaborate.

Re:Standardize the Kernel API!!

[ratboy666]

Sure, I can elaborate. The idea is that drivers are constrained in the interfaces they use. The idea is NOT to produce a "universal" DDI, but to formalize the current driver classing. Indeed, formalize it to the point that a source tool can examine the driver source and determine if it is "compliant" to the class which it belongs in. All such compliant drivers can be considered "class DDI clean" and a kernel change can then be tested against the interface.

Drivers which are not completely "class clean" need to be checked (more) carefully against kernel changes. This encourages drivers to be migrated into the "clean" class. If a kernel change occurs which affects the entire class, it is likely that automated tools can handle the change to the drivers (hopefully, the bulk of the work).

I don't consider the interface to be off limits to kernel developers, but the extra isolation should make things easier from both the driver and the kernel perspective.

Initially, such "DDI layers" should be imposed on isolated parts, where a great deal of abstraction already exists. Later on -- we (Linux) should remain flexible enough to reject such ideas if they don't work, or extend them.

Ratboy.

Re:Standardize the Kernel API!!

[just_another_sean]

Hey thanks for getting back to me. The questions I was raising concerning graphics cards were genuinie and you've enlightned me somewhat. I guess the bottom line here is we are in somewhat of a transitional era with regards to Open Source. As it gains traction and is used in new ways it will almost always cross paths with closed source software, licensing restrictions, patents, etc.

One thing I'd like to clarify though; you're pretty close to hitting on what I meant about providing a low end, open source driver vs. high performance binary but not quite. I don't want to see all the "good stuff" come out for just Windows either. Another post in this thread said something along the lines of "if you want a stable ABI, buy Red Hat Enterprise". I think that's a good point. I would not mind seeing ATI/NVIDIA or any other hardware vendor continue to provide binary only drivers for products like Red Hat Enterprise or SUSE Server. Heck, charge for them if it helps cut down on their own costs. People need to run a business and I'm not all altruism and do it because you should.

I just want them to provide a simple OS driver that could live in the base kernel tree as provided by kernel.org and could be used and toyed with by a simple home user like myself. I beleive it is the Red Hat's and Novell's of the world that should respond to demands from hardware makers for a stable ABI/API to base their products on, not the guys working for free on the kernel. Then it becomes business A and business B working symbiotically for their own benefits, similar to how it works in the closed source world now.

Free software developers do what they want and do it because they like to. No amount of success or interest by end users should force them to change that. I'd go so far as to say that the minute you put demands and obligations on these same coders you will see a serious drop in both quality and quantity of code. Does that make for a good business model? Hell no. Does it make for great software? Definately yes!

Re:Standardize the Kernel API!!

[14CharUsername]

Holy double standard, batman!

You're comparing an old version of windows to a modern version of linux in terms of supporting older hardware. You do realise kernel 2.2 is still available, right? You can still get FVWM. Hell, you could even get the latest version of fluxbox or xfce. You could get the code for the old drivers and update them to work in kernel 2.6. You can contact the manufacturer of your hardware and ask them to update the driver, though they probably will just recommend you buy a newer model.

Or maybe you just prefer win98SE over fluxbox or xfce. That's fine, but don't piss on me and tell me its raining. Linux runs fine on old hardware. You just prefer windows, that's all.

Re:Standardize the Kernel API!!

[Blakey Rat]

Ok, but if we've established that a stable driver interface is good both for open source coders and for corporations looking into porting to Linux, uh, why *not* do it? Sounds like a win-win to me. And yet this bone-headed lack of a stable interface has persisted for years and years even after the problem has been made perfectly clear.

Saying they "must" do it is obviously wrong, but saying that not doing it is stupid is perfectly right, at least from my point of view.

Re:Standardize the Kernel API!!

[killjoe]

"Whoever agrees with this does not have the right to whine that X or Y company does not provides drivers and support for Linux. It is a design flaw IMNSHO."

It's not those peple who are whining. The people who are whining are the ones that never lift a finger to do anything. You know the people who want a free version of photoshop, autocad, quickbooks or whatever. Those people won't ever stop whining anyway though. They just want free copies of the software they stole on windows. They don't care about anything else.

Re:Standardize the Kernel API!!

[killjoe]

"IMHO, the kernel developers would do well to realize that their antics are hurting themselves far more than they are hurting any hardware company that refuses to release GPL drivers."

Hurting themselves? Did I miss the news? Is the adoption of Linux slowing down or reversing itself? What do you mean hurting themselves? Last I checked linux was growing like gangbusters.

Re:Standardize the Kernel API!!

[Lord Ender]

In the era of copy-and-paste, using "[sic]" has no value. Nobody thinks you screwed up your typesetting. We all know the use of "[sic]" is just an attempt at an ad hominem by pointing out someone else's irrelevent mistakes.

Re:Standardize the Kernel API!!

[erikdalen]

if it's indented with tab-characters you can set your tab-width to 4 in vim with:
:set tabstop=4

so using tabs lets everyone choose their own preference for indentation while using spaces is just stupid.

Re:Standardize the Kernel API!!

[Nimey]

I agree with this post.

Re:Standardize the Kernel API!!

[LordOfTheNoobs]

Your rant on the FSF being in a ``la-la land'' is quite irrelevant to the point I made, which is only that one should not group BSD and GNU/Linux together in discussing driver license issues. Frankly, I do not know BSDs binary driver policy, though I must believe that they do not care if anyone links in proprietary binaries. They, after all, are the choice to give away ones work. Linux, is the choice to share and by license ensure that the recipients will share back.

This forced sharing is the very basis, the fundamental mentality behind the operating system I am writing this comment from. Behind many of its tools. To label something that has acted for so many years as an enabling and protective factor for the developers of such software as being crafted from "la-la land" seems telling.

I do not know if you are speaking out of ignorance of the matter, or fear of it, should you believe that such Free softare will somehow leave programmers, possibly yourself if you hold such a position, out of work. It is possible that you believe that gnu, linux and the rest of the Free software out there is somehow a great failure, despite its continuous worldwide usage gains since the inception of the license which acts out the intentions of the FSF.

It is obvious, regardless of your motivations, that you see the GPL as limiting your freedom. I point out, however, that this is not the case. You are not forced to use the GPL, nor software written under it. It is not mandatory use, nor is it tied to anything fundamental in computing. There are choices of platform for writing code expecting only credit, writing code expecting sharing in kind, and obviously closed source systems as well.

The only possible restriction it has on you is that it disallows yourself to take the work of others and then never share your changes with the community from which you benefited. It is a guard against leeching, forcing those that choose to use the work done under it to do any work they base off of this work under the same license. It is protecting not the rights of the current author, as does BSD, but specifically it is ensuring the rights of previous authors who gave to the project by ensuring they will receive also those changes made by others.

Re:Standardize the Kernel API!!

[maxume]

I think free software is great. I use it all the time.

As I see it, the Stallman position is that using non-free software reduces my freedom to use free software. This isn't at all obvious to me. The way I see it, as long as I can legally run free software, I have software freedom and if running closed software is more beneficial to me than running free software, well, I am going to. Perhaps I am an idiot. This is why legislative drm is bad, it actually hampers software freedom.

As far as 'forced sharing' goes, isn't that a bit of an oxymoron? There has to be a better description than that.

Re:Standardize the Kernel API!!

[drew]

When did I mention adoption rate?

To use your argument as a counter to my statement requires one to make two very strong assumptions.

1) Linux' adoption rate is not just the primary, but the only, concern of the kernel developers. What was this article about again? Oh yeah, the kernel maintainer has suggested feature freezing the kernel for at least one realease because he feels too many bugs are being added with each release and not enough are being fixed.

2) You have sufficient reason to believe that Linux adoption rate would not be what it is (or higher) if the kernel were maintained differently. Just because Linux is doing well now doesn't mean it couldn't be doing better.

Of course, as I said, this is just me opinion, and I hardly consider myself an expert on the matter, but it certaily seems to me that stabilizing certain key kernel interfaces could certainly make many people's lives a lot easier. Your argument, on the other hand seems to have almost nothing to do with either what I said or what is being discussed in this article.

Re:Standardize the Kernel API!!

[killjoe]

I still don't see how the kernel developers are "hurting themselves". Your point was that freezing the API would help the developers because it would provide more proprietary drivers. That argument was shot down very handiliy by other people. Then you went on to say that they are hurting themselves but not freezing the API.

Sure you are entitled to your opinion but it's nonsensical.

Re:Standardize the Kernel API!!

[drew]

Either you completely misread my post or you are attributing somebody else's words to me. I never said, or implied, that freezing the API would help the developers because it would provide more proprietary drivers. Proprietary drivers are a peripheral issue. My point was that freezing the API would help the developers because it would encourage stability in the kernel and reduce the amount of work that goes into making sure all of the drivers in the kernel stay in sync with the kernel proper.

Of course, this would make things easier for those who release binary drivers as well- the point is to make less work for everybody who has to maintain drivers. By making things easier for themselves, they would also make things easier for other driver maintainers. Conversely, by making things more difficult for other driver maintainers, they are making things more difficult for themselves as well.

Perhaps actively discouraging the efforts of companies that insist on releasing binary only drivers is a priority to the kernel developers, and they are willing to go through a little extra work themselves to achieve that goal. If so, then more power to them. If not, I don't really see why they would be unwilling to adopt a more stable kernel API. But again, IANAKD...

Re:Standardize the Kernel API!!

[eldorel]

One thing that most of us seem to be forgetting is that the ones who suffer aren't companies like ati or nvidia, It's the end users, and those of us who want to see linux become a major player in the desktop market. As long as Joe User can't install linux and play his games, we don't stand a chance.
Most design firms are going to look at linux, see the major performance problems that we have with the major hardware vendors, and decide that there is no reason to bother with multiplatform releases. Even games that were written in opengl and were ported to both windows and Mac are not released on linux. (Diablo2 anyone) Why? because theres a really good argument against it.
Programmer1 "Ok, lets see, What operating systems are we going to support?
Programmer2 "Hey, why not make a linux port?"
Programmer1 "No way, if we do that we can't use "SuperPixelTrickOfTheDay tm", cause the drivers suck.
Programmer2 "Oh yeah"

One thing that a stable ABI would do is increase the likelyhood of vendors writing drivers for more uncommon hardware. The ABI being a moving target makes development harder, as the programmers can't just learn how to format the driver one time. They have to play catchup every time theres a change.

Re:Standardize the Kernel API!!

[eldorel]

Why can't there be a stable ABI compatability module? Basically have the ABI remain fluid, but have an optional module that provides a stable layer for use by closed source drivers. Similar to ndiswrapper, but without all the dll dependancies that windows drivers tend to have. This way we have the best of both worlds, Closely linked drivers in the kernel, and a separate layer to prevent binary drivers from breaking things, while allowing companies like nvidia and ati to provide us with fully functioning drivers without having to release proprietary information.

Re:Standardize the Kernel API!!

[MROD]

The main problem is that there are so many different drivers in the kernel tree, each of which has to be tweeked every time there's an internal API change with each tweek giving the possibility of a typo or some other bug creeping in. Large numbers of drivers in the kernel tree will currently either not compile or won't work properly because their maintainers either can't keep up or aren't there any more.

If the API is stable then the overall number of edits to the kernel source will go down with the consiquence of the number of potential new bugs being introduced going down as well. Not only this, but a driver, once fully debugged, need not be messed with until the next major release of the kernel which adds to both stability and the lessening of the workload on the kernel maintainers.

Commercial, binary-only drivers (which this wasn't about) or even open sourced drivers are the least of the worries.

Slow!

[Anonymous Coward]

It's funny that not so long ago Andrew thought 2.4 development was too slow. That was one of the reasons for the versioning scheme change (the other beeing getting more people to test new stuff).

I think all this means that the new versioning system is working too well.

Extermination cycle

[digitaldc]

"Kernel developers will need to reapportion their time and spend more time fixing bugs. We may possibly have a bug-fix-only kernel cycle, which is purely for fixing up long-standing bugs."

Sounds like this approach will benefit everyone in the long run, instead of constantly playing catch-up later?

Re:Linux is BUGGY so it IS about TIME !

[mlwmohawk]

Oh please, this is total BS. The only way you could have a dozen or more panics in a year is if you have a VERY BAD device and driver and have not looked at addressing the problem.

I've been running Linux since 1994, and exclusively since 1996. I have seen two panics, having to do with an old 3Com card and an old Promise IDE driver.

When you get any sort of prolem, in Linux, Mac, or what ever, you look for the updated driver and get it, or if there isn't one, troubleshoot the system. Unlike Windows, crashing on UNIX is not normal, and a sign of a problem that won't go away on a reboot.

For the record, I have a couple servers using 2.6.x that have been up for almost a year with no issues. The last reboot was because of a power failure at the colo.

Re:Linux is BUGGY so it IS about TIME !

[Anonymous Coward]

and the wife hasn't been at the neighbors in a long while.

Is it because your 'panics' had scared them all away? Or is it that mobile tech support are doing her 'house calls' now?

Re:Linux is BUGGY so it IS about TIME !

[tobybuk]

>> Unlike Windows, crashing on UNIX is not normal

You're as bad as Microsoft! Windows (XP/2003) does not crash unless there is a buggy device driver. If you think it does state your verifiable, FUD free source please. Otherwise take your Windows FUD elsewhere. What's good for the goose....

Re:Linux is BUGGY so it IS about TIME !

[TerminaMorte]

While I'm not sure if he meant it this way, it sounds to me that he's saying that it's not considered terribly odd for Windows to crash; not that Windows constantly crashes.

If a desktop user sees a blue screen of death (device driver, bad hardware, what have you) it's nothing incredibly shocking; we've grown used to it over the years.
 
Linux has certainly crashed on me (mostly when trying out drivers that arn't exactly stable), and when it happens it is a much rarer (and stranger ;)) occurance.

Certainly you agree that Windows (he didn't specify XP/2003, remember, just Windows in general) is known for problems like that more than Linux is?

Dying breed?

[Anonymous Coward]

That's the entire reason a free kernel exists, some folk really should just stick with Windows. That said, every time I come to upgrade (and I do track releases) there's a bunch of new configuration options that are never going to be relevant to anything I'm going to be involved in. 2.6 has been reasonably stable for me but there's just too much crud bundled with the mainstream release that ought to be split off into patch-sets.

Re:Linux is BUGGY so it IS about TIME !

[Skuto]

>Certainly you agree that Windows (he didn't specify XP/2003, remember, just
>Windows in general) is known for problems like that more than Linux is?

Maybe because Windows is just more well-known in general?

Re:Typical monolithic kernel problem

[Anonymous Coward]

...so that we can have a buggier and slower operating system because writing efficient code is more challenging, due to intrinsic issues like message passing?

Re:Typical monolithic kernel problem

[tadmas]

Any kernel with upwards of 2.5 million lines of code is going to be incredibly buggy, perhaps it's time to rethink and go back to the microkernel

Splitting any software into external pieces is exactly the same as splitting the software into internal pieces. Microkernel is not the answer -- encapsulation is the answer.

Besides, converting the kernel will not get rid of the bugs; it will just make different ones. 2.5 million lines is a lot to rewrite, and any rewrite will lose all the bugfixes already in place.

Dave Jones take on the story

[greppling]

can be found in a post in his live journal. He reports that with every new kernel release, the number of kernel related bug reports in the Fedora bugzilla goes up substantially.

(Davej is a long time kernel hacker and currently the Fedora kernel maintainer.)

Re:Lack of standards + arrogance

[xtracto]

...standards and this time STICK with them instead of dropping whatever you build simply because you don't feel like it anymore.

The main problem with open source software is that the basis of its development is Because I feel like it, when someone gets bored of doing it they just leave it there. If there is something boring that needs to be done, then it won't be done (like documentation).

Some of the wonders of open source ;-)

and yeah I know this is the wrong place to post this :)

Re:Typical monolithic kernel problem

[diegocgteleline.es]

Any kernel with upwards of 2.5 million lines of code is going to be incredibly buggy

You mean that a microkernel is magically going to implement the same funcionality than linux, with all the thousand of driver, with its support for docens of hardware platforms, in less of 2.5 millions of lines of code?

Sure, a "microkernel" itself doesn't takes a lot of code. But BECAUSE it's a microkernel, drivers, filesystems, networks tacks etc. need to be implemented as servers. Implementing servers that implement the same funcionality than linux has today would take more of 2.5 milliones of lines, for sure. And those servers can have bugs, you know. And hardware bugs exist - it's completely possible (too easy, in fact) to hang your machine by touching the wrong registers no matter if you're using a microkernel or not.

Also, I don't understand why a microkernel would be magically more maintainable than a monolithic kernel. As far as I know, software design is something that doesn't depends in whether you pass messages or not. Sure, a server running in userspace can't take the system down. But that's completely unrelated to modularity and mainteinability. Microkernels were in fact invented because people though that hardware complexity wouldn't allow to continue running monolithic kernels, ignoring the fact that it's perfectly possible to write a mainteinable monolithic kernel with modular design - which is how Linux, Solaris internals etc. are today - just like it's completely possible to write a unmainteinable, non-modular microkernel. It all boils down to software design. And guess what: Current general-purpose monolithic kernels (linux, *BSD, Solaris, NT, Mac OS X - no, a operative system that implement drivers, filesystems and network stacks in kernel space it's not a microkernel) have had a lot of time and resources ($$$) to become mainteinable and modular, extensible, etc.

It's fun how when a monolithic kernel has a bug it means microkernels are better, like a microkernel model magically makes coders bug-free, or like it's not possible to write a microkernel server with a bad API that forces all driver developers to patch their drivers to fix a security bug. I'd love to hear what development model would use the Hurd/QNX/whatever guys to maintain six millions of lines of code, be it driver for a monolithic kernel or drivers implemented as microkernel servers.

Good ol' Pat...

[zenmojodaddy]

Does this mean that everyone who has complained or criticised Slackware for sticking with the 2.4.* kernel for the sake of stability will apologise?

Not holding my breath or anything, but it might be nice.

Re:Good ol' Pat...

[tomstdenis]

2.6.16 has had a lot of bug fixes [from 2.6.16.5 to the current version is pretty much fixes].

I've been running 2.6 since 2.6.10 [or so] without any significant problems or stability issues. x86_64 support was better initially with 2.6 than 2.4 as well.

Perhaps they should spend a few months fixing bugs but I wouldn't favour 2.4 over 2.6 any day.

Tom

Re:Typical monolithic kernel problem

[Anonymous Coward]

Fantastic idea. Why don't you write one! Or somebody. Write a microkernel kernel! This is great. We are waiting. Yawn!

Re:Typical monolithic kernel problem

[Jessta]

That will probably be the future. We are not there yet. The Message passing overhead is still large and makes coding difficult. eg. HURD is still not finished after 20 years.

Eventually with multi-core cpus with stupid amounts of threads the micro-kernel will make it's come back.

Re:Linux is BUGGY so it IS about TIME !

[mlwmohawk]

OK, here's the difference between Windows (DOS and NT) coding and UNIX coding, and you may feel free to check out the various Windows DDK examples and the Linux drivers to verify.

In UNIX a driver does not nuke the system unless there are no alternatives, and a great deal of effort is made to make sure this doesn't happen. In Windows land all the DDK examples in both DOS Windows and NT, upon encountering a problem, they are encouraged to issue a stop. (similar to a kernel panic) rather than fail to operate.

This means that a printer driver, in kernel space, will kill a system rather than fail to print. So, with Windows, you will lose work, with Linux, you will be able to save your work.

This isn't to say Linux is perfect, it does have bugs, all software does, but it has fewer and is more tollerant of them.

Re:Linux is BUGGY so it IS about TIME !

[Skuto]

>In UNIX a driver does not nuke the system unless there are no alternatives,
>and a great deal of effort is made to make sure this doesn't happen. In
>Windows land all the DDK examples in both DOS Windows and NT, upon
>encountering a problem, they are encouraged to issue a stop. (similar to a
>kernel panic) rather than fail to operate.

Uhm, it's not as if the Linux kernel won't PANIC (or was it BUG, there are multiple, IIRC) if there's a problem. Your statement has no base in reality, pure FUD.

Re:Typical monolithic kernel problem

[Skuto]

>Microkernel is not the answer -- encapsulation is the answer.

But encapsulation means stable interfaces. Not acceptable for the Linux crowd (GPL binary drivers blablalba).

Of course you are right though. One main reason why so many things get broken is that all drivers need a rewrite on each interface change.

Re:Linux is BUGGY so it IS about TIME !

[Architect_sasyr]

I hate to say it mate, but BULLSHIT. I work with Windows 2003 Terminal Servers. Let me tell you, those things crash for no apparant reason. Device drivers are good, can confirm that by looking at the manufacturers of the hardware alone.

Verifiable information: Sure, the passwords to access my VPN are... fuck off. Noone on /. is that stupid. The proof I give you is my word. Deal with that.

M$ ISA Server = Crash from 200+ users. Reboot it maybe 8 times per week. Linux Proxy = (Squid) = 300+ users (we grew) 88 days and counting.

Meanwhile, we need to schedule reboots on a domain controller that is DEFAULT. If it didn't come with Server 2k3 Ent. it isn't on there. This thing will lock up, and randomly crash/reboot if we don't kick it once a week.

Love to be giving you logs, but unfortunately, I practice some form of security through obscurity...

i will say this

[FudRucker]

i keep slackware-10.2 with the stock kernel-2.4.31 as my main os and keep an extra partition for playing and testing out other Linux distros, and the slackware is more smoother and stable than any of the disktros i tried with 2.6.xx series kernels...

i am sure the kernel dev people (Linus & co.) will iron any wrinkles out of the 2.6.xx series kernels soon :)

_i for one welcome our kernel hacking overlords...

Re:i will say this

[element-o.p.]

As a big fan of Slackware, I hate to say this, but the Gentoo laptop I use at work seems to be much happier with 2.6 than the Slackware desktop that I upgraded to 2.6. Two caveats here, however: first, I'm still running Slack 9.1, so perhaps that's the difference between my experience and yours, and second, I had the help of a very experienced Gentoo guy when setting up the work system whereas Google and I upgraded the Slackware host.

Still, XMMS (for example) throws up a lot of kernel errors on the Slack machine but works like a champ on my Gentoo laptop.

Having said all that, I have to admit that Slack with 2.4.31 works extremely well, so I'm content to wait a little longer for 2.6 support in Slackware on the rest of my hosts.

Re:Linux is BUGGY so it IS about TIME !

[mlwmohawk]

If you read carefully and verify this yourself, it is not untrue. It may cause FUD about Windows, but unlike Microsoft's "Get The Facts" nonsense, this FUD is justified.

FUD -- Fear, Uncertainty, and Doubt, like paranoia, is sometimes the correct response to the facts. Like Kissinger said, "Just because you're paranoid, doesn't mean they're not out to get you." In this case, just because it causes FUD, doesn't mean its a lie.

Re:Typical monolithic kernel problem

[Anonymous MadCoe]

Maybe Minix3 is an option.

Encapsulation is not the answer, that will just add more code, and therefor it will have more bugs (encapsulation needs an interface etc too).

I think a microkernel will indeed work better, be more reliable because it allows a limited group of people understand all relevant code of one component.

What you see happening in Linux is exactly Tanenbaum's point for a microkernel. But then again the man is often misunderstood and misquoted.

Re:Lack of standards + arrogance

[Anonymous Coward]

But if u set some standards there is plenty of room for "I don't feel like it nomore", simply because the next guy who will can easily pick things up again if he is familiar with the standards. It would seem that the only time certain ppl care about standards is when a company tries to set up and use an opensource license. Ofcourse then the only thing some ppl care about are their own standards, "nothing else matters" (ugh, I hated that song).

How "more eyes == fewer bugs" works

[mangu]

bugginess is more a function of the quality of the developers (and the pace of development) rather than whether the project is open source.

It's obvious that better developers should generate fewer bugs, but I think you don't get the point.

Open source has fewer bugs irregardless of overall developers quality, because it's the quality of the best developer that has access to the code that matters. It doesn't matter if 99.999% of the people who have access to the code are ignorant, or unwilling to debug it. It's enough that *one* competent developer gets motivated to fix that bug. The more people who have access to the code, the greater probability that among them will exist one competent and motivated programmer.

Re:How "more eyes == fewer bugs" works

[Skuto]

>Open source has fewer bugs irregardless of overall developers quality, >because it's the quality of the best developer that has access to the code >that matters. It doesn't matter if 99.999% of the people who have access to >the code are ignorant, or unwilling to debug it. It's enough that *one* >competent developer gets motivated to fix that bug. The more people who have >access to the code, the greater probability that among them will exist one >competent and motivated programmer.

Which in the real world never ever happens, because there's many more times crap open source code coming out than there are good programmers.

Proof: Just look at 99% of the projects on sf.net.

Re:How "more eyes == fewer bugs" works

[kilgortrout]

"Regardless" is a word. "Irrespective" is a word. "Irregardless" is not a word.

Re:How "more eyes == fewer bugs" works

[tadmas]

Open source has fewer bugs irregardless of overall developers quality, because it's the quality of the best developer that has access to the code that matters.

Only if the best developer reviews all the code and fixes all the bugs. In a large software project, this is not practical. That is precisely why the "more eyes" theory is flawed -- it makes the assumption that everyone looks over the entire codebase, which is definitely not true. If you want to talk about the speed of specific bugfixes or the general severity of bugs, that's one thing, but the quantity should be unaffected simply because the amount of code is large and time is limited.

Nothing wrong with this...

[ovit]

In the old days, when the kernel guys were working on an odd numbered kernel they would try out all kinds of stuff... Then, when they had a big batch of cool stuff they would go after an even numbered release and spend all their time solidifying what they had just done... So they used to operate with a built in (and regular) period that allowed them to focus on bugs...

Since 2.6, they've changed all this. I believe we will see the occasional "bug fix" only release as this is really what the developers are used to... and it just works... In the old days, this would be a 2.7 release...

        td

Re:Linux is BUGGY so it IS about TIME !

[Anonymous Coward]

why are your drivers good? usually this is the cause of most crashes, I run 8 ISA servers wth just over 10,000 concurrent users, our uptime is counted in months not days, So you either have dodgy hardware or drivers or simply incompetant admins.

Minix3

[LWATCDR]

I was going to suggest that Minix 3 might be worth taking a look at now.
It is free now. Well documented and now has performance as it's primary goal.
Can you put convert BSD code into GPL code? I know you can not take GPL and make it BSD but I wondered about the other way around?
The current problem with Minix goes back to drivers.
I almost want to download it and give it a shot.

Re:OT shelleytherepublican.com

[phasm42]

I am amazed by the sheer number of morons who are unable to immediately recognize that piece as satire. The very first sentence is a dead giveaway. Yet the comments section is filled with outraged idiots. WTF!

sky2 LAN support on Centrino Solo/Duo laptops?

[flowerp]

Speaking of Bugs,

how's the state of the support for the sky2 / Yukon Ethernet card that is usually shipped inside Centrino Solo/Duo laptops? Suse 10.1 RC3 did not properly perform a DHCP on my laptop's internal sky2 LAN - it just hung.

Is there any patch available?

Re:sky2 LAN support on Centrino Solo/Duo laptops?

[Anonymous Coward]

I had a similar problem with my Gateway WX6421 with Fedora Core 5 x86_64 (Fedora bugzilla 188283, https://bugzilla.redhat.com/bugzilla/show_bug.cgi? id=188283). DHCP works and I can connect, however whenever I put it under any type of load, the driver locks up and stops responding. I can recover by stopping the network, rmmod sky2, insmod sky2, and restarting networking. Under Linux, I can only use this laptop with wireless (not entirely a bad thing, but not as secure).

2.6.16 SMP also locks up on my Supermicro dual XEON box (Fedora bugzilla 188291, for now I'm just using the UP kernel).

These are the types of problems that must be fixed. An upgrade should not break known, working hardware especially causing a hard lockup.

Re:sky2 LAN support on Centrino Solo/Duo laptops?

[Anonymous Coward]

Not a very nice response. The original poster made a very valid point. Rapid changes ARE introducing new bugs such as breaking drivers or causing kernel crashes as mentioned in the posts. One expects the kernel to get better as time goes on (the higher the number, the more stable), not to break things and introduce bugs that crash computers. Linux has ALWAYS been more stable than Windows -- that is not always the case now and to me that is scary.

Your very rude response was obnoxious flamebait and totally out of line, but this is /.

LXR be with you

[alexhs]

I had to crawl about 4 levels of header files for each of the variables/records used in the line

You should consider LXR (Linux Cross Reference), it's a very useful tool. You can navigate through kernel source up to 2.6.11 here.

Now, it's not perfect because function pointers still are requiring hard work, and the tool can't understand macro-defined 'nightmare' functions like this one (in kernel/spinlock.c) :

#define BUILD_LOCK_OPS(op, locktype) \
void __lockfunc _##op##_lock(locktype##_t *lock) \
{ \
  [...] \
}

Please use fewer 'junk' characters. blah blah blah... 'were only spaces !

Re:Typical monolithic kernel problem

[swillden]

But encapsulation means stable interfaces. Not acceptable for the Linux crowd (GPL binary drivers blablalba).

I think your perception of the Linux developers' point of view is skewed. You say that they consider stable interfaces to be unacceptable and then imply that it's in order to deter the use of binary drivers.

That's not correct. If they really wanted to deter the use of binary drivers, they could simply file lawsuits against the developers of those binary drivers (and it would be easy to find funding to back such a suit). Under a strict interpretation of the GPL, no one has permission to create derived works that are not also published under the terms of the GPL. In the case of the video card drivers, the makers could probably argue that the drivers themselves aren't derived works of Linux, but the glue code they distribute clearly is. Linus et al could easily shut down all binary driver development if they chose to.

It's not that the Linux kernel leadership considers stable interfaces to be evil, and they don't really even consider binary drivers to be evil. They find binary drivers to be irritating, because they can create bugs which the open source developers can't debug. Stable interfaces aren't bad either, aren't even annoying, and are even mildly nice when they reduce maintainers' workload. But the current Linux ABI isn't designed to be stable. To create a long-term, stable binary interface you have to plan for the future and put appropriate structures in place to support new development, and then you have to maintain those interfaces and verify that new work doesn't change them, which probably means new code has to build in backward-compatibility hacks. That's a lot of effort. If it were effort that would pay off in terms of easing future development or debugging, it would be a good idea, and someone would probably do it. But the effect would be to constrain development and hamstring debugging.

The Linux developers' position on stable internal interfaces is that it's a lot of work with a mildly negative payoff. Why would they want to do that?

Thanks to everybody for replies. Summary and ques?

[mapkinase]

Seems like consensus is that there is

1) lack of motivation to fix bugs (boring and/or difficult)
2) complexity of the Linux kernel code

Given this observation I wonder if refactoring is needed for the kernel code to make it more readble and if it is needed then how open source projects are approaching it?

I would assume that the project leader would have to make some kind of a team to do that. What I have mostly heard about OS projects is that they are started by a single person who codes something workable then depending on the prospects of the future use and general interest more developers are joining it in a very free, relaxed manner.

Refactoring seems to be a different issue: one needs to redo a whole bunch of functions without getting any intermediate working results. How is OS community is dealing with the problem of refactoring or how would it deal with it?

Standardize the Kernel API!!-Musical chairs.

[Anonymous Coward]

I have a question here. What is it that needs so much change that the API can't even be solidified, let alone frozen? The hardware obviously isn't morphing. Are the kernel developers discovering new principles of CS and they need the flexability? 'X' has already shown us that if you chose wisely your design will have a long lifespan even if it doesn't cover every contingency.

Beating the source code out of proprietary vendors

[Anonymous Coward]

"But really - that only affects close source kernel modules - and why should the linux kernel team care about people who want to leverage the linux kernel without contributing their source code back."*

Like Nvidia, or ATI, or Broadcom, or...

Sorry but your going to have to wait for GPL 3 before you'll have a stick big enough to make people give you the source code to their hard work.

*OH and did I mention the GPL loophole that allows Linux users to keep their source code hidden from the RMS police, while gaining it's benefits? Oh wait, I alluded to that already.

Hurd

[ultrabot]

The Message passing overhead is still large and makes coding difficult. eg. HURD is still not finished after 20 years.

Speaking of Hurd, I had actually forgotten about the whole thing. You don't see it mentioned as often as you used to, even in jokes. Bad sign?

Chill.

[Qbertino]

Give me break. Everybody knows that BerkleyDB is an unstable, sorry excuse for a DB that makes MySQL 4 look like the god-sent of all DBs. And lack of standards and arrogance certainly isn't a thing of the OSS community. Especially not the Linux Kernel people. "My biggest Job is to say 'No.' to new features." Hits the nail on the head. And from what I can tell Linux is anything but a weedy mess maintained by daredevils who don't care about stability. Some commercial vendors would give their right arm to have a piece of software like the Linux Kernel in their stock. There are enough OSS projects out there that are very well maintained and offer the cream of software quality. Your rant is baseless.

Re:Chill.

[Anonymous Coward]

And what piece of software has put the whole OSS community in the spotlight and given it the fame it has today? This whole issue might very well go deeper than you want to realize.

As to BerkeleyDB: why compare a library used by certain software with a server product? Not only that, a server product which also considers it important enough to support it.

blah blah "Windows stable" blah

[blueZ3]

I get so tired of hearing MS fanboys running around yelling "it is too stable! is too, is too, is too!"

Quoting myself here:

I have four boxes here in my office, a six-month-old, high-end Dell Windows box, my Powerbook, a Dell 2800 running VMware ESX Server, and a Dell 2800 running Ubuntu (crazy, I know, but the 2800 was what was available).

* My servers only reboot when I need to document startup behavior. Since I'm doing work that involves explaining how to build drivers for ESX, which includes info on installing and starting ESX, that means an occasional reboot. Initiated by me. At this time, (after about six months) neither server has required a restart for any other reason.

* My Powerbook has been rebooted three times since I bought it. Each time was after installing a system update for OSX.

* The Windows XP box I reboot at least once a week. Sometimes this is because of an update. Usually it's because a progam locks up and refuses to be killed, and no, the Task Manager can't kill it either (sometime the application refuses to quit, sometime it's the process). When that happens, the only way to get the application to restart is to reboot, and since I can't do my job without email and publishing applications, I have to reboot. While this is obviously caused by the application, the OS should be able to kill any userland program completely.

Windows XP may have eliminated the BSOD that we all love to mock, but "stable" it isn't, IME.

Re:blah blah "Windows stable" blah

[Blakey Rat]

Hm. I've never seen a process/application that the task manager can't kill. Can you give some more details about what's happening exactly and what you're doing about it?

I'm not going to just call BS on this, I think you actually have a problem with Windows, however I'm willing to bet that your problem is not Microsoft's error, but the third party developer's whose product crashed.

The OS *can* kill a userland program completely. I've had many weird and unusual crashes, both from stuff like nasty spyware, plain buggy apps (usually IBM or Siemens apps) and stuff I've written myself and screwed up with, and I've never failed to kill the program with the task manager.

Re:blah blah "Windows stable" blah

[LoztInSpace]

I've had this too. Sometimes a process just snags 100% CPU and cannot be killed via task manager or anything else. In my experience it's always been Excel or Outlook - nothing the OS shouldn't be able to hose.
My Google searches have pointed to a dodgy driver not processing a cancel request from the process that is shutting down and it goes nuts. These processes keep running even when the user has disconnected (this is terminal server)
It's rareish but does happen - must reboot. Having said that, this is not a super-hardened server - just a desktop running ~30 users so it's doing remarkably well all things considered. Just hope moving the app to "the real thing" sorts it out.

Really now.

[bluefoxlucid]

A few comments have flown already, but let's be sane here and examine microkernelism.

File system crashes. Microkernel is going to panic because there's no way in hell it can guarantee consistency with running processes now; the FS driver might log-replay or FSCK, but all open file handles become invalid (this can be reduced though...). A monolith is also going to panic; the driver may be in a kernel thread and get flushed and re-initialized, but same problem with file handles.

IDE driver crashes. Microkernel can block disk reads, bring it back up and hold the file system's state, re-flush buffers that weren't confirmed, unblock disk reads. Monolyth may do the same if the driver is in a separate kernel thread.

Sound driver crashes. Microkernel re-inits it. Monolyth re-inits the thread if it wants to (Linux just says it's broke and sound stops working).

Video crashes. Hardware needs a re-initing. Microkernel means X gets killed! Monolyth means X gets killed! Although the video driver CAN be re-initialized, Linux is likely to panic; MULTICS was easily 70% error recovery code, UNIX we just had this routine called panic() where you yell down the hall to reboot it...

Network crashes. Our entire TCP/IP stack is blown out. Microkernel re-inits it, monolyth can too, most likely we let it die and you reboot. We got tired of panic()ing for simple shit, we call this "Oops."

What a microkernel DOES have that's nice is the ability to quickly and easily ensure that drivers with fucked up code don't stomp all over other kernel memory. I suppose some MM hacks can be done to remove writability but..

What Linux really needs is the 2.6 model for odd series, as "Volatile," on a set even "Stable" series release cycle where "Volatile" is pinned as "Stable." That way the "Volatile" is always as usably stable as 2.6 is now, while "Stable" is concrete. Everybody happy and no silly 2.6.x.y running trees.

Re:Really now.

[Anonymous Coward]

What Linux really needs is the 2.6 model for odd series, as "Volatile," on a set even "Stable" series release cycle

What Linux really needs, and I've said it before, is for someone upstairs to stop accepting submissions from folks who never clean shit up. If you don't have time to fix bugs, then we don't want your cool new feature. Bye bye.

Re:Typical monolithic kernel problem

[0xABADC0DA]

The real advantage of a *good* microkernel is that normal people can write drivers and modules to extend it. If you compare the filesystems available for FUSE compared to what's available by compiling into the kernel you get a good idea:

Kernel: ext2/3, reiser3/4, jfs, xfs, minix, romfs, cdrom, fat, ntfs, proc, sysfs, adfs, ffs, hfs, BeFS, jffs (flash), cramfs, qnx4 fs, smb, cifs, andrew fs, plan 9

FUSE:

FunFS: network filesystem,
KIO Fuse Gateway: mount anything kde can talk to as a filesystem
Bluetooth FS: bluetooth functions as files
mcachefs: caches files locally from another filesystem ie nfs/smb
Fusedav: mounts WebDAV shares as fs
GmailFS: uses gmail for storage
CvsFS: view a version as fs
SshFS: mount sftp as fs
WikipediaFS: edit wikipedia articles as files
FuseCompres: transparent compression
FuseFTP: ftp filesystem (written in perl)
GnomeVFS2: mount anything nautilus can view
archivemount: mount tar, cpio, tar.gz archives read/write ...

Notice any difference? In the kernel, everything is pretty much either some long-standing standard or developed by some large corporation. The user-mode ie microkernel-style ones are developed by single people because they saw a need -- and so they actually do something useful like mounting ftp or zip files, or using gmail. These things are useful and different whereas once I've picked the fs for my drives I couldn't give a crap about any other fs in the kernel. None of them do anything even remotely interesting.

So that's the real advantage of a microkernel. Somebody wrote a useable filesystem in perl for heaven's sake. Yes, you can get some of the same benefits by turning a monolithic kernel like linux into basically a big/slow/ugly microkernel in certain areas like fs for instance. But with a good microkernel or safe kernel you get these same benefits everywhere with the advantage that your "archive filesystem" is much, much faster.

Re:Linux is BUGGY so it IS about TIME !

[HaydnH]

"1. Start regedit 2. go to: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Servic es\i8042prt\Parameters 3. Create a new DWORD value and name it CrashOnCtrlScroll 4. Right click on this newly created value and click "Modify" 5. Enter 1 in the Value data field and click on OK. 6. Close regedit and reboot the computer 7. hold the right CTRL key and press "Scroll Lock" twice to see the BSOD on demand."

8. Remember to put breaks after each line or preview your message =P

Re:Typical monolithic kernel problem

[diegocgteleline.es]

Notice any difference? In the kernel, everything is pretty much either some long-standing standard or developed by some large corporation

Yes I notice a difference: The filesystems in the kernel tree are general-purpose, performance-critical filesystems, meanwhile a fuseftp filesystem is quite the contrary.

Noticed how FUSE is a linux thing that allows people to write filesystems in userspace *despite of being a monolithic kernel*, giving users all the advantages of a microkernel without any of the disadvantages? Did you already noticed how this same approach is already used for some driver, like all the usb drivers implemented in userspace in top of libusb, X.org 2D drivers or CUPS printing drivers?

"commercial = bad"

[Anonymous Coward]

It is not that "commercial = bad", it is that proprietary = bad.

prove it-ball is in your court

[Anonymous Coward]

You mean the thundering herds of "must have the newest" videocard buyers, the gamers and graphics guys, would stop buying video cards because of the status of the drivers as regards an open source or not status? Or that the OEM vendors making new machines would stop buying video cards and installing them if tomorrow the code that ran the cards was GPL?

I doubt that for some reason. I think the vendors arguments are..well, quite dubious at best. Go back and look at what you are alleging, business suffering means selling less cards. Do you REALLY think they would sell less cards?? That is LUDICROUS. Really, that is your claim, that they would stop selling cards (that's the whole point of their business, selling cards) or that sales would somehow almost immediately "drop down" or something. THAT'S HILARIOUSLY LAME.

What WOULD happen is the first company that open sourced would get a TREMENDOUS influx of neat code, a tremendous amount of increased user enthusiasm beyond whatever they had now, they would get code and coding help designed to run on THEIR cards which would really quickly make them work better and they would sell MORE cards from it..not less. MORE. Their competition would be scrambling to keep up with it. The competiton would ALWAYS be one step behind in their efforts from that point forward, given the two "rivals" were very close in size when this transition occurred..

Open source works because *everyone* benefits from sharing..EVERYONE is the keyword there. Not just this or that guy, EVERYONE IN THE WHOLE FOOD CHAIN benefits from it. The vendors are scared they won't benefit..on the contrary, their efforts at building nice little cards will benefit as more people HELP them with coding to make them even better. I don't care how big your private company is, it is NOT larger than the global open source coding community and NEVER will be. MS is the largest software company arguable, one of the main components that people use on computers are browsers. Now which browser has been advancing faster in this market since open source really took off globally as a mindset and practice a few years ago?

Whether or not it is better cannot be proven UNLESS the code is open to have other people look at it and tweak it, so you can't argue one way or the other about it until you try it out. All we have to go by is past examples, so let us look around. Hmm, the operating system itself-linux and bsds are not doing too shabby, are they? Use and enthusiasm increasing daily, all over the planet. Sure, not dominant..yet. It'll happen.

In other areas where it has been opened up it has proven to be quite effective.

If nvidia is worried about ATI "getting their code", well, ATI would be "worried" about the same thing, so it's a *net wash*. If both of them got a lot of free code and help, guess what? They both would be..getting free code and help, back to the same exact *net wash*, except for the "more help" part, which would increase development at NO cost to either of them. If only one of them got the help, THAT one would get better/faster, a net INCREASE in the "desirability to purchase this card" factor, from individual end users to the bigbox manufacturers who would want the best video bang for the buck.

Their closed arguments simply fail to take into account that "open" is not partially restrictive to "your" company, they are basing their decisions on not really understandinhg the concept fully, honest, they really don't "get it" yet, and past inertia in the industry, and fear.

Here's the bottom line, when you open something, it can no longer be stolen away from you, you eliminate that whole "stolen" concept completely, you can then STOP WORRYING ABOUT IT and get back to business, which in this example is selling cards, all that happens is that you still have what you had previously, you lose nothing, but now you get a lot more free help.

That's why the larger companies are going more and more to opene

Re:prove it-ball is in your court

[IAmTheDave]

Do you REALLY think they would sell less cards?? That is LUDICROUS.

Actually, I find your response ludicrous. Opening up proprietary drivers that a company has spent millions of dollars on R&D developing will not suddenly be helped by Joe Hacker. When MIT graduates and PHDs in EE and physics are working to make your drivers perform that much faster, the OSS comunity will contribute very little at best.

But put this argument aside for a second and let's look at the economics. OSS enables others to take the proprietary algorithms you have developed and use them in their own drivers. Since drivers are at least partially responsible for performance (I work at a company that saw a 30% boost in peformance of a commodity scanner from a driver upgrade) there is nothing to stop the market from becoming flooded with cheap knock-off cards that use the same drivers. Sure, that might benefit you, but it hardly benefits NVidia.

Step away from hardware for a second. Why do you think that Google so closely guards its algorithms? If they made their search engine OSS by your argument, they would benefit greatly from the code input of the community. Bollocks I say. Their mind-share is comparable to DARPA or NASA. The community would contribute very little. Instead, they fight the good fight against other search engines that want their revenue. Releasing their engine would allow the other engines to proport the same performance/search results as Google, thus instantly reducing their superiority claims to nothing.

Proprietary, closed source is necessary in business. OSS does a nice business too yes, in some markets. But in some, proprietary is what gives on company a slight edge over another, and that can mean millions of dollars in return.

Re:prove it-ball is in your court

[twistedcubic]

Nobody is asking to see these companies "valuable" algorithms, which are probably trivial and obvious anyway. They're asking to see the damn specs. A driver rewrite increased scanner performance 30%? Cool. Give me the specs, and I'll write one from scratch that improves performance even more. I don't need to see the anybody else's code. If someone erased all the labels on my DVD player, I can still operate the thing if someone showed me WHERE the play button is, etc... That's all we're asking for. Not the damn DVD internals, just the buttons to press to operate the damn thing.

What to do?

[IpSo_]

I prefer the current development model over the old one, upgrading from 2.4 to 2.6 was much more difficult then it should have been, mostly due to the learning curve though I think.

However the current development model does "seem" to have introduced more instability into the kernel then I remember. (My box at home seems to crash every 17days like clockwork.) Even with the 2.6.x.y releases, they are only maintained for a couple .x releases, so even those don't get a chance to stabilize much. I haven't NOTICED a new kernel feature in quite some time, so I would rather get the additional stability until I realize there are features available that I could make use of.

Why not something like every kernel that is evenly divisible by 5, (or 10?) is considered a "stable" kernel. 2.6.20, 2.6.25, 2.6.30, and commit to supporting 2.6.x.y releases on those versions for a minimum set of time, perhaps 6months. 6 months seems to be about the average cycle of distro releases, so that may work pretty well.

This should give the best of both worlds, longer "stable" kernel releases then we have now, and still the fast developement/test cycle that the current development model offers.

Re:a fix is needed all right

[Anonymous Coward]

So long as you don't care about performance or usability, OpenBSD is a fine OS.

Unstable Drivers == $$$$$$$$

[NutscrapeSucks]

If Linus and the rest of the kernel developers decide at some point to provide an ABI that proprietary companies can use to build their drivers, all the while clinging to their dated business methodologies and obsession with "IP", then great, that's their choice.

Here's what you guys are overlooking. There is a stable kernel ABI. It's called "RedHat Enterprise". Look at high-end storage drivers and the like and they only come in binary and only "certified" for certain distributions. If you want stability, you pay RedHat and the hardware vendor pays RedHat.

So, this isn't all about Free Software lovey-dovey. Much of the mainline kernel's instability is directly motivated by the fact that "stability" where the revenue comes from.

Re:Thanks to everybody for replies. Summary and qu

[shmlco]

The OS community is committed to refactoring... usually because some developer can't figure out how the previous developer wrote some unintelligible function, and decides the best way to "fix" it is to rewrite it in his own unintelligible style.

The 2.6 model works

[microbee]

I was skeptical when 2.6 changed its development model and ignored "stable" series, but I've now convinced it's a better model than before. It's simply more productive. Yes it destablizes stuff more, but the real benefit is what has brought Linux to success: motivation of highly talented developers around the world. It's human nature that people like to work on new stuff, especially for open source developers. You get fame, recognicion, and employment opportunity by working on high-profile code instead of bug fixing. For the old "stable"/"development" model, nobody really cares about stable anymore. This left an embarrassing situation there, and vendors would have to do a lot of feature back-porting work. Now the vendors just need to fix bugs, and bug fixes are generally far easier to port to mainline.

Worst /. Headline Ever

[Anonymous Coward]

Every /.er knows the Linux kernel is without bugs, as bugs and poor
code are only found in the evil mind controlling applications of The
Beast, or Mr. Gates as we lesser-nerds still refer to him, or His
Legions, or Microsoft as we lesser-nerds still refer to it.

Linux cannot have bugs. Just like hippies can't have ill feelings.
Anything else contradicts my carefully insulated hyperbolic assumptions
of the world and the Dark Forces raging against it.

Duh.

you haven't proven a damn thing

[zogger]

In fact, you have strayed into the compounded strawman argument fused with completely false assumptions, and gone from there somehow conviced that is "fact".

  Google WOULDN'T EXIST without open source. They wouldn't have a single dollar. There would not be a google as you see it now. That they only open some of their stuff means even there they still don't fully "get it", yet, besides that, they still managed to garner huge market share, PRECISELY BECAUSE OPEN SOURCE CODE WAS THERE FOR THEM TO USE. They kicked the shit out of MSN precisely because they came in on open source and that is the primary advantage they had.

You also make some utterly and arrogantly *lame* assumption (getting to be a habit with you, you might want to get that checked at the shrinks) that the open source community doesn't have MIT grads or EEs or Phds working in it. OMG OUR COMPANY HAS REAL SMART GUYS!!! NOBODY ELSE DOES THAT MAKES US THE BESTUS AUTOMAGICALLY!!ONE

    Ya, SO WHAT? You lose,you lose BIG TIME right there, demonstrably false directly on this board, there are TONS of high level superior brains working on open source code, you can see that readily.

    Now, back to a video card, PROVE that their hardware wouldn't get better with major contributions from the community, and come in faster than what the "closed source" community would provide for "the other brand". Prove it, that's your claim, so prove with some real world examples, give us the list of other type hardware vendors who lost major sales because their hardware runs on open source code. Give us THE BIG LIST, where is it? Can you point to serious LOST SALES?

Try again, PROVE some hardware vendor lost a sale-that's you ENTIRE POINT, LOST SALES OR NO SALE BASED ON OPEN SOURCE DRIVERS, because the hardware was running on open source and the competition wasn't, or could run on open source just as well as closed source and that open source was readily available. Give an example of lost sales, go ahead.

    I like nvidia cards, I purchased a what to me was an expensive video card. Not top of the line, I can only afford a couple of generations back, but certainly good enough for my purposes now. If nvidia had a truly open source driver, does that mean automatically I would NOT buy a card from them because of that, that I would just flee overnight to ATI because for some reason they just "must" be better now? Any "advantage' that ATI might have would STILL BE IN THE NVIDIA CARD DRIVER, now wouldn't it?

This is why you don't get it on open source, you flat out refuse to see this, you think by opening the code you are THROWING IT AWAY, you AREN'T, you STILL GET TO KEEP IT, no one has "stolen" anything from you. You are selling VIDEO CARDS, that's where the cash comes from. And you get the code first while you are working on it, so how does that change things with 'the competiton" again? they don't see it until you dump it on the market, you have a huge lead time then, and after that, you STILL have lead time because something as important as that WILL get serious major effort donated to it, because it is in the USERS-your customers-best interest now, even MORESO than previously. They now have a stake in your business to make sure it stays working correctly and makes good stuff, so not only do you still get the cash for the cards, you get fre help to make the cards better.

  I am just an average typical user, but we'll let some others chime in here, maybe someone in charge of purchasing a lot of desktops for their business, now would anyone "you" reading this NOT BUY A VIDEO CARD for those machines if there was a very good open source driver for it, direct from the devs at the manufacturer, with fully open contributions from the open source community? Or would you insist on the closed competition card?

This is a yes/no proposition, all things elsewhere take it as a near level playing field and considered, the hypothetical machines need video cards of some good qulity.

If yes, OK- that is understood, if the answer is NO, you WOULD NOT PURCHASE THOSE CARDS, why wouldn't you?

Re:you haven't proven a damn thing

[IAmTheDave]

Zogger - seriously - ALL CAPS DOES NOT A POINT MAKE. Further, speaking of seeing a shrink, I believe you have some anger issues.

I stopped reading your comment about a paragraph in. Your assumptions are base, your argument lacks merit. Google could have as easily written their engine to run on Windows as on Linux or UNIX or whatever they run on. They may pick up a performance boost from Python or whatever, who knows. As someone that has ported many a web and heavy app from one platform to the other, let me assure you that anything that can be done on one system can be done on any other system.

As for my arguments with NVidia vs. ATI, the argument has nothing to do with what card you buy because of your opinion of the card manufacturer. It's about allowing a particular protected method of manufacturing and running the drivers to their card to be copied, which waters down the market and provides more serious competition for a market which doesn't want any more. In business there is an understood fact - competition drives the market, but the optimal number of competitors for maxiumum profitability is two.

NVidia and ATI don't want others to know their secrets, and opening them up to the world will not automatically make their software better... but what it will do is eventually water down the market. This has nothing to do with you, but with ATI and NVidia, and them protecting their secrets and their profits.

Software like drivers are as much a protected business practice as any other. So they will never OSS their full driver package (or even their spec) but that doesn't mean I don't want drivers for their software on my Linux box.

Re:you haven't proven a damn thing

[zogger]

Hell ya I got angry with your veiled assertion that because some company had some brains on staff that other brains aren't out there in the open source community. I thought that was a real cheap shot and why I went with my name, to follow the response easier.

And you still haven't answered the main capitalist "bottom line" question, which is what this is all about, money. More money one way, or the other?

    Can you point to any other hardware sales LOST because the hardware ran on open source? This is a very simple question and gets directly to the heart of the argument. They have to "stay closed and secret" because they will "lose money". OK, swell, I got that part, I understand the argument, now, show me the beef, I keep being shown the bun, but where's the beef?

  ATI and nVidia *think* they might lose sales, they don't know that for a fact. They obviously believe that-I'll grant that-I just think they are scared and still locked into last century's business model and can't see the big picture cleanly or clearly enough (**AA's as well for that matter). i.e.; they just "don't get it" with open source, completely fail to see that the advantages outweigh the perceived "dangers" by a huge margin.

    I assert, which is an opinion and not data, which-ever one-right now, today-went to pure open source would actually pull far ahead of the other in a relatively short time span. That's easy enough to grok. That the combination of good hardware combined with greatly enhanced enthusiasm from a LOT more coders wanting to help make their cards better on the software side would magnify as a force multiplier their own in-house coders efforts and result in even higher sales. That's my posit.

  OK, we shouldn't confuse theoretical assumptions with hard data, yes? We can agree on that point? OK then, we need some examples to prove their's-and your's- point. Go ahead, be my guest!

    I need to see some examples of where a hardware vendor, previously using closed source only, went to open source and lost significant sales because of the fact, and that the decision to go open source was the primary reason for the lost sales. That's the closest we could have to a real world example. I'll wait for some examples, and I will accept their validity if/when I can see some.

    I am not aware of any, and nor do I know every single thing about all hardware business out there. I see a lot of counters to that though. I *have* seen that places like IBM have really gone out to try and incorporate more and more open source and it certainly hasn't hurt their hardware sales any, and they are significantly larger than either video card maker and in a competetive and similar market - "computer hardware". I have seen examples like FF pull completely away from what MS has in the browser arena. And so on. This is an oft discussed theme here, there are a lot of examples showing that open sourcing is being adopted more and more by more companies, and they all seem to mostly like it, they start seeing benefits and improvements. It is not the predominat case yet, I will grant that as well, but it is growing fast. Are all these innovators wrong? Are they lying? I don't know, I can only go on what I read and see and experience.

Really, show me an example someplace to make your
assertion of a higher probability of "lost sales due to open sourcing the code". If it is so probable, surely there must be a plethora-even just one real good one- of examples out there to use as references to affirm the counter.

I'll wait. Take your time, no rush.

-1 offtopic

[Sigg3.net]

Yes, but the net calms down when Windows boxes have been told for the third time to go to bed. That's when the small linux goblins peek out from their firefox holes, and resume their quest to reach the golden kernel.

The stable ones mostly come at night.. mostly...

Re:Typical monolithic kernel problem

[0xABADC0DA]

Nobody is going to go to the level of effort required to make anything but a general purpose file-system in the kernel. Can you even imagine what would be involved in making a .zip filesystem in the linux kernel? Even a read-only one would require maybe 6 months of study for an average developer. A read-write one would be extremely difficult if done in the linux kernel.

What you have not shown is that these filesystems are in the kernel because they must be because of performance. Take the FUSE's Captive NTFS filesystem for instance. Is NTFS not performance critical? Maybe a kernel-mode NTFS would be a bit faster but the problem is that after more than 5 years in development it still barely works even for reading.

The reality is that "performance critical" filesystem for a disk means that it has low fragmentation and few seeks for the index. It must be able to read multiple blocks at once. That's pretty much it. Whether it is running as a microkernel driver, or a monolithic driver, or a user-mode driver matters very little compared to this. Yes, linux can be used like a microkernel and this is being done, but it is far from "without any disadvantages". The overhead of making protected drivers in linux is about twice that of a fast microkernel (see wikipedia on l4 for instance).

Re:Typical monolithic kernel problem

[diegocgteleline.es]

Can you even imagine what would be involved in making a .zip filesystem in the linux kernel?

It's fun that you mention that, because such things have been already done.

Even a read-only one would require maybe 6 months of study for an average developer

"...data provided to you by 0XABAADC0DA research"

Is NTFS not performance critical?

No. Linux systems can't even boot on NTFS filesystems. Obviously, the main purpose of NTFS is compatibility. If FUSE had been there before, people probably would have used it to implement it, just like with the beos filesystem, etc.

The reality is that "performance critical" filesystem for a disk means that it has low fragmentation and few seeks for the index

The reality is that seeks and fragmentation matters....when things are not in cache. Real world does care about the real world, you know.

Re:Typical monolithic kernel problem

[0xABADC0DA]

It's fun that you mention that, because such things have been already done.

Yes, in FUSE, and within kde and withing gnome. Zip archive != zip disk.

The reality is that seeks and fragmentation matters....when things are not in cache. Real world does care about the real world, you know.

I guess that's why USB filesystem are implemented in user mode in linux, huh? They are memory and the moral equivalent of 'l2 cache' compared to disks, which is why Vista will reportedly swap through them. But in linux they are user-mode whereas disk filesystems are in the kernel for performance? Boggle.

No. Linux systems can't even boot on NTFS filesystems.

Earlier you said linux gets "all the advantages of a microkernel without any of the disadvantages" but yet it can't boot? Lol.

Re:Linux is BUGGY so it IS about TIME !

[Anonymous Coward]

"This means that a printer driver, in kernel space, will kill a system rather than fail to print." Windows Printer drivers don't run in kernel space. Since Windows 2000.

thousands of options to get right

[heroine]

It's not that it's unreliable. It's that if any one of the thousands of new options isn't exactly right, it crashes.

Re:Typical monolithic kernel problem

[diegocgteleline.es]

Yes, in FUSE, and within kde and withing gnome. Zip archive != zip disk.

No, filesystem compression has been done in linux (but not merged, because anyway not many people seems to ask for it)

I guess that's why USB filesystem are implemented in user mode in linux, huh?

WTF? Filesystems used for USB disks are exactly the same used for typical hard disks, and all of them are in the kernel, if that's what you meant.

Earlier you said linux gets "all the advantages of a microkernel without any of the disadvantages" but yet it can't

NTFS has been reverse-engineered. You can't even write or create files. Why would I be surprised that it can't act as root filesystem? As far as I know, linux can use more filesystems as root device as any other operative systems, including microkernels.

Re:Lack of standards + arrogance

[thebluesgnr]

The main problem with open source software is that the basis of its development is Because I feel like it, when someone gets bored of doing it they just leave it there.

Do you think it's any different with proprietary software? Microsoft works on what they feel like it. Same with Apple; they're not spending their money to make sure OS X 10.5 works great on the older Macs (one of the complaints here is that not enough people are testing Linux 2.6 on old hardware). Likewise, Red Hat, Novell and others vendors of Linux-based solutions work on what's best for their costumers.

The difference with Free software is that more people get to work on what they feel like working on. And if something's missing all it takes is a developer to change that.

distributed testing

[lon3st4r]

if the code is built at such a fast pace, and can only be debugged by "god-level" hackers, then the best way to ensure a bug-free linux is to provide the developers with a very good feedback mechanism.

what if a distributed system is built to test every patch/release of the linux kernel on most/all hardware configurations? i use the word distributed as it will be difficult to have one place where all the testing happens. people/coders who are interested in helping in kernel development, but lack the experience, can start with downloading diffs and patching their kernels and testing them.

some people could also work on a distributed testing system, ala SETI.

all of this would get a bug out soon and it might be possible to trace the bugs to which patch/release introduced the bug. hence resulting in a lesser bug-closing turnaround time.

what is the existing way bugs are discovered and closed?