You say that the problem with linux is that it tries to be a jack-of-all-trades. Presumably, this means you must sacrifice server performance to gain desktop performance.

If performance is such an issue, then why are you willing to overlook the performance costs of a microkernel in the first place? You’re confusing the argument — the added stability does NOT address the same problem as branching up the kernel into embedded / server / microkernel.

If anything, linux is an argument AGAINST microkernels. It shows that it’s possible to scale to production-quality without show-stopping stability issues and *still* retain performance. Moreover, the overwhelming majority of kernel bugs reside in device drivers. This can be addressed with the new userspace linux api (as mentioned above by someone else).

[As an aside, just because device drivers are in userspace doesn’t guarantee they can’t cause havoc. Consider, for example, DMA transfers that bypass virtual memory.]

Lastly, ACPI and inotify have both been merged into the mainstream kernel. I don’t know that Linus was ever blocking 3D drivers from mainstream. Although ck’s SD scheduler never made it, CFS took ideas from SD, and has been incorporated into the mainstream kernel. So as long as the needed patches eventually make it in, is this really an issue?

Thom do you ever follow lkml?
I doubt it.

Essentially the vanilla kernel is the core for all the stuff you mentioned.
It need to be stable and running.

Once it is up and running, you can always tweak it to your choice(s).

Distros give you heavily patched kernel for desktop performance, isn’t it.
They are at liberty to make changes, build a new kernel and release.

Maybe sometime in the future Linus may include it in the official tree too.
If not, it will still reach to the users through distro.

e.g DRBD worked out of the kernel for years,now it is being consider a rc for future releases. Does this makes sense?
I guess it does.

There is a lot more in life than blogging.
Try hacking the kernel than pointing fingers at developers.

Thanks!!!

With the userspace driver API comming up in Linux, the uKernel “advantage” of every driver living in userspace is also mute.

Yes, that’s the thing about microkernels that I’ve always found appealing.

“By keeping the kernel smaller, you can decrease the chance of bugs occuring. Now, a *desktop* user can be bothered by a *server* bug. If you split the kernels up the way I described, you reduce the amount of code in each kernel, and thus decrease the chance of bugs.”

Perhaps I’m misunderstanding your POV here. If you’re saying that a microkernel with modules A B C would be for a server, and the same microkernel with modules X Y Z for a desktop, and the same microkernel with module N for embedded, then yeah, I can agree with you 100%. But to have three completely different kernels? Yuck.

“It’s so simple, I’m actually wondering why Linus hasn’t thought of it himself, yet. ”

He’s a much better coder than I plan to ever be (sooo boring!), but he’s a terrible software architect from what I see.

By keeping the kernel smaller, you can decrease the chance of bugs occuring. Now, a *desktop* user can be bothered by a *server* bug. If you split the kernels up the way I described, you reduce the amount of code in each kernel, and thus decrease the chance of bugs.

It’s so simple, I’m actually wondering why Linus hasn’t thought of it himself, yet.

You’ve been at this longer than I have, so I’m going to trust your judgement here in the case of Linux.

I suppose it all boils down to limitations of the architecture, and the stubborness of it’s maintainers ;^)

But I remain unconvinced that a kernel cannot be designed to work well at any given task, so long as it has both well thought out and stable KPIs, and is designed such that various components are truely hot-swapable (like in the case of schedulers, drivers etc.).

I don’t follow the LKML nearly as often as I do the various BSD lists, so could you perhaps fill me in a bit? Are these patches scheduler related? If so, could they not do what various other groups are doing, and implement swapable schedulers? IIRC, both NetBSD and DragonFly for example are working on the ability to do so on the fly, and IIRC, Solaris has had this ability for ages.

I don’t know enough about inotify to ask anything inteligent about why it isn’t good for a server.

Actually there are cases where this is needed. For example, Linus has consistently refused to include on his mainline kernel some changes from Robert Love that fix multimedia and audio performance (for desktop/workstation usage) because it messes up with the server performance. Additionally, other stuff like ACPI, 3D GL drivers, inotify etc are things that a desktop needs but a server or an embedded one doesn’t really need.

It might be a good idea to split it up, and it might not be a good idea at the same time. But the bottomline is that neither the desktop or the embedded version of Linux get as much love and attention as the server-friendly patches do. It makes sense to focus on the server more as it makes more money and it’s the strong point of Linux. But there are gains to be made on other market areas too and Linus does not put lots of weight on them, despite OSDL’s efforts to help the desktop via a number of ways.

Linus just doesn’t care much about the desktop. If he did, he wouldn’t break API and binary driver compatibility so easily.

I’m not sure that this is really needed. Personally I think that one of the biggest issues with say “desktop Linux” is the countless DEs, and packaging formats, and the lack of consistency between the various Linux distributions, as opposed to being a fault of trying to make a kernel that can work well in all three of the situations you’ve cited (embedded, desktop, server).

That’s not to say I don’t have issues with Linux or some of the decisions that were made by it’s developers. Breaking driver compatibility between point versions IMO is a terrible failing on the part of the developers; leaving the users to mess around with binary drivers, spending hours to make something work. If the developers had just been a little more thoughtful when they designed the driver interfaces, we’d not have this problem.

I do like the idea of microkernels, I always have. The idea of everything living in one address space has always seemed to me like “building a castle on a swamp” and in many cases, I’ve been burned because of it. Buggy drivers happen, and as much as the fan boys would like to have us all believe, Linux isn’t immune to them.

Unfortunately, Linus is a stubborn creature, and I seriously doubt that he would ever allow his tree to become based on a true microkernel. He’s even dead set against maintaining driver compatibility.