Looking at the HURD programming progress shows up that there was some progress in 1996 and 1997. Please note that this was some years _after_ Linux became successful. For this reason, I cannot see that Linux should be responsible for the HURD desaster.

Looking from whose perspective?

The Hurd has been making significant progress in the few last years. Just take a look at Debian. Of the 7000 packages or so which are available in the unstable distribution, half of them are currently compiled for the Hurd. This includes important software such as gcc, XFree86 and LaTeX. A lot of the remaining packages have small errors or "Linuxisms:" no fault of the Hurd itself; developers just sometimes forget that Linux != POSIX. These can usually be fixed with a ten line patch, however, it is a matter of systematically going through the packages and producing these diffs, submitting them and following up on their merits of the those of just being portable.

The last major stepping stone to POSIX compliance is threading. With pthreads, at least another third of the Debian archive should be compilable. This work is currently underway -- in fact, it is being undertaken, in part, by one of the people that this flame is directed at. Although I cannot say when it will be finished, from my perspective, it is making steady progress.

But what about the fact that the Hurd has taken so many years to gather momentum and become usable? Here are the facts: Linux is, for the most part, a _reimplementation_ of Unix. The interface is essentially the same; innovation has been in the implementation. The Hurd, on the hand, is a _redesign_. Thomas, Roland et al sat down not to clone Unix, but, as in traditional GNU style, to take a look at what is available, find its faults and design a new system that is more flexible and more powerful.

In my experience, designing is never as easy as implementing. When you design, you need to think about the interaction between all of the components: you need vision. You must experiment with ideas, try them out and then throw them away and start of scratch.

But does Unix need a redesign? At least according to those who designed the Hurd, it does. But, if you do not need user flexibility and do not mind administration head aches, then, Unix is fine. And if you do not need security, Unix is fine.

On a standard Unix system, a normal user has no power. He can, of course, run his applications, gcc, bash, LaTeX, etc. But, he can do nothing _within_ the system. He cannot play with the vfs even if he can access the backing store; he cannot create subsystems nor chroots; he cannot run most daemons. Why is this? The Unix design philosophy has always been to put as much functionality into the kernel as possible. One of the main trade-offs is that changing these features becomes a privileged operation: if there is a bug in the kernel or it is given bad data, the user could cause a kernel panic, or worse, takeover the system.

Take a look at Bugtraq: on at least a weekly basis, there is a new dangerous Unix exploit available. One of my personal favorites are those for wu-ftpd. Although the programs are clearly to blame, perhaps, we should shift some of the guilt onto the kernel for not helping out.

The top targets of crackers are daemons running with root privileges and suid applications. But why are these programs running as root? In Unix, the user and group ids are an inherent part of the process and privileges may only be dropped -- never gained. The authentication scheme is just not flexible enough.

In the Hurd, this threat is brought to its knees. User and group ids are orthogonal to processes. You might consider them similar to id tokens. A trusted system server issues id tokens when e.g. given a user name and the corresponding password. In this scheme, a process may have one user id, many user ids, or even, no user ids. The first case is similar to traditional Unix. However, the others are more interesting. Having multiple user ids, allows each to be more specialized. For instance, I have a driver's license, a library card and my school id. If I am speeding and pulled over, neither my library card nor my school id will not help me. Only my driver's license. The final case permits processes to run with nearly no privileges on the system.

This model means that a daemon, rather then running as root and then dropping privileges, may run with no privileges. Then, when a user responds to the user name and password prompts, it may contact the authentication server and ask for a new authentication token. In Unix, attackers try to break the system during the authentication phase where they are almost guaranteed to get root access. In our model, if the daemon is compromised, the attacker gets no access: at least not anymore than he had from the outside.

Attack neutralized!

If you believe that Hurd is a good idea, then stop talking about hurd and start working on hurd. Once it becomes usable and has the features requested by the users it will be used by a noticable number of people.

We are going as fast as possible. And you could help, if only by helping to minimize the FUD.

On Sun, Mar 10, 2002 at 05:39:23PM +0100, Joerg Schilling wrote:

I am sorry, but I am only seeing weeny type arguments for HURD.

You spell it as "the Hurd", see http://www.gnu.org/software/hurd/faq.en.html#q1-2 for more information about that.

Second, what do you mean with "arguments for HURD"? Arguments for its existence? Arguments for using it? Arguments for developping it? Arguments why it isn't being used as much as it should?

Looking at the HURD programming progress shows up that there was some progress in 1996 and 1997. Please note that this was some years _after_ Linux became successful.

First try to look more careful before writing an e-mail. If you did that first you wouldn't spread such FUD and wouldn't make a fool of yourself.

For this reason, I cannot see that Linux should be responsible for the HURD desaster.

I also can't see that it's responsible. I only said that if GNU/Linux didn't exist probably more people would have been working on GNU/Hurd.

If you believe that Hurd is a good idea, then stop talking about hurd and start working on hurd.

I'm already working on the Hurd and I won't stop talking about the Hurd.

Once it becomes usable and has the features requested by the users it will be used by a noticable number of people.

The number of people trying it is already increasing because the want the Hurd's features.

Any OS that nobody likes to run cdrecord on could be considered dead these days....

You're a funny dude. And arrogant one, thinking that cdrecord is such an important program. I can name dozens of programs which are far more important than cdrecord and most of them already run on GNU/Hurd. I would recommend people who want to port programs to GNU/Hurd to port some of the more important and useful programs instead of porting cdrecord.

I know OSes with more potential than 80% of the OSes cdrecord is ported to. Also cdrecord runs on some really dead OSes (NT-3.5, BEos).

Jeroen Dekkers