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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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

[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?

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!!

[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!!

[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!!

[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!!

[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!!

[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!!

[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!!

[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!!

[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!!

[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: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

[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: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?

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.

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...

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: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: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: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: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: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: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?

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

[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.

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.