Linux Vs Hurd

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

Screw kernels. I get along fine with two or three API calls and zero syscalls.

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

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.

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


CategoryLINUX


EditText of this page (last edited November 12, 2014) or FindPage with title or text search