This page is a discussion of the relative merits of the LinuxOperatingSystem and GnuHurd.
There is something about the monolith called Linux. I prefer a more plug 'n' playable OS. Also, a smaller OS will be more suitable for MobileInformationDevices. -- AndreBolle
Although GnuHurd may be architecturally superior, it is a long way behind in terms of stability, performance, features, etc. The reason for this is simply that it has less developer-time behind it. In order for it to catch up, it needs to have those missing hours put in. The problem is, where are they going to come from?
Maybe programmers will prefer working on the hurd due to its superior coolness, modularity and general panache. Personally, i doubt that this will be enough (if it was, programmers would be flocking to the hurd project in droves, which they aren't).
Perhaps the hurd team will exploit the fact that linux is under the GnuGeneralPublicLicense and just copy what they need, thus 'cloning' developer-hours that went into linux. That would be both effective and "fair," considering the huge amount of GNU software that went into making Linux. Let one hand wash the other, etc.
Personally, I think we should dump old-fashioned MicroKernels and go for NanoKernels and ExoKernels. -- TomAnderson
Well, perhaps the active port of the GnuHurd to the EllFour MicroKernel is closer to what you want. (Some say NanoKernel is just an Apple buzzword for portions of their 68k emulator ROM. EllFour is probably the most minimal MicroKernel out there with only seven API calls!)
- I can write a kernel with only one API call, it's called "ioctl" or "trap" or somesuch. The seven APIs of EllFour are big fat suckers with lotsa parameters to remember; this particular claim to fame is of rather dubious merit.
Screw kernels. I get along fine with two or three API calls and zero syscalls.
- What are they? :)
- primitive message send to a pre-defined but per-process relative object within the parent process (this is the standard #pass: aMessage to: aPath with: permissionFlags, just crossing a process boundary)
- primitive return along this thread back to the parent process (ie, threads cross process boundaries)
- save the execution context of this child process within the parent
(The parent process is the one which the current process is nested within, as in
NestedProcesses.)
They're not syscalls since every process in the system must implement these entry points. And what they do with them is entirely up to them. Everything else (including address space allocation requests and blocking of processes) should be implementable on top of these API calls.
The reason why GnuHurd is far behind Linux is that GnuHurd is really ambitious project while the architecture or features of Linux resemble those of other Unix provide, I think. Ambitious might sometimes be complicated and unrealistic. Development resources matter less than the difficulty. In fact, GnuHurd project started before Linus began hacking minix. And other GnuTools such as gcc are working quite well. -- TakuyaMurata
GnuHurd is a pathetic project whose architecture and features greatly resemble Unix. Linux on the other hand is a cobbled together BigBallOfMud trash heap with no architecture whatsoever whose feature set is identical to every other Unix out there. Well, this is a stupid thing to say.
- Aww, Richard, tell us how you really feel. LinuxOs has an architecture. It may not be a good one, in your opinion, but to say it has "none" is patently wrong. And given that writing device drivers and other services for Linux doesn't seem to be a task of great difficulty - there are many successful examples of such in production - claims that it's a "trash heap" because it doesn't do things the way you (or other researchers into OS design) like is putting the cart before the horse.
Ambitious is often an opportunity to
BurnTheDiskpacks and do something everyone considers impossible in a simple and elegant manner. Hurd does not do this. Any of it.
The idea of this page, the idea of comparing "Linux versus Hurd" as if there were a meaningful difference, makes me puke.
Shut up, child. You have no idea. No wait, I spoke too soon. There is a critical difference between the two. Linux is a popular and commercial success while Hurd is an abject and miserable failure and will
never be anything more. Let's examine why that is so.
Let's go do something worthwhile, instead.
Hurd will never be a success because it's been written in a bottom-up manner. That means it falls into the classic chicken and egg scenario of "how do you attract developers to work on the kernel without users" and "how do you attract users to a kernel that does nothing useful for them"? The FSF doesn't have the resources necessary to get out of this catch 22, and everyone interested in rolling out their own OS should heed the lesson.
- Hurd has more serious problems:
- For a long time, it was (to borrow ESR's analogy) a "cathedral" design; it didn't get developer mindshare because it wasn't interested in outside developers. GCC suffered from the same problem, until Cygnus forked the codebase - forcing the FSF to either open up GCC development or become irrelevant.
- Nowadays, it wants developers, but most developers are more interested in Linux or BSD.
- Many Linux developers are employed by corporations (IBM, RedHatInc?, Novell/SUSE, OpenSourceDevelopmentLabs?) to work on Linux; said corporations, who never supported the critical early development of the Linux kernel, have no similar interest in funding Hurd development.
- Hurd is too greatly identified with RichardStallman.
- Hurd disallows non-free device drivers (or at least it did). Linux allows them.
- Most users don't care a whit about the underlying architectural arrangement of the OS they use; they care about applications and hardware support.
The only solution is to write the OS
top down. So first you write GCC and Emacs which provide immediate value to users and become wildly popular. Then you leverage your total control over the upper layer to force everyone to migrate to your new lower layer. The trick is that you have to make users cease caring about the lower layer, you have to make the upper layer
incompatible with the existing lower layer, your new lower layer has to provide fundamentally new capabilities, you have to retain control over the upper layer and be able to sabotage it. The FSF did none of these things, and that's why Hurd will never be anything more than a failure. -- RK
- That solution won't work, as the FSF has no way (legally or otherwise) of disabling GCC/Emacs on Linux, Windows, or any other platform on which they run, and demanding users switch to Hurd. Most users, in that case, would switch to other apps.
- Microsoft has done this to some extent - the MicrosoftWindowsApi (Win32) is not the kernel interface; rather it's an abstraction layer on top of the kernel interface. This allowed the same API (for the most part) to interface to several wildly different kernels (95/98/Me, NT/2000, and XP). However, this strategy is threatening to bite MS in the butt.
- There are other solutions to this problem:
- Do what Linus did, and emulate an existing platform, preferably one that is stable, like the GNU tools. Hurd does this to some extent - you can compile most GNU apps for Hurd with little modification.
- Provide an interesting project for people to work on. Linus's biggest success is not as a programmer but as a leader. (Luck probably has a lot to do with it as well).
- The biggest stroke of luck for Linux was that it was gaining ground just as the BSD camp was stalled by the big AT&T-BSDi lawsuit. If AT&T had looked the other way and decided to let the UNIX trademark slip, the heirs of 386BSD would probably rule the desktop *nix world. Whether the desktop *nix world would be near as large in such a universe is an open question.
CategoryLINUX
Linux Vs Hurd