[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: design goals vs mechanisms

From: ness
Subject: Re: design goals vs mechanisms
Date: Thu, 27 Oct 2005 16:08:36 +0200
User-agent: Mozilla Thunderbird 1.0.6 (X11/20050813)

Marcus Brinkmann wrote:
At Thu, 27 Oct 2005 09:33:39 +0200,
ness <address@hidden> wrote:

I don't agree with you this time. It is not out job to determine the visions of the Hurd. Other guys have done this, and not only for a short time, AFAIK.

Can you elaborate on that?  I have digged out Thomas' paper on the
Hurd design, which is the only public information about the Hurd
design goals that I know of.  The only other information is maybe the
announcement that the Hurd will be written as the core of the GNU
system, which is not very enlightening.

Now, I have done something evil, because I limited your options to
public documents.  If you look at internal discussions, you can find a
lot of very specific goals.  However, all this are about things in the
"POSIXish" world of the Hurd, and about certain usage scenarios, like
filesystem tricks (union namespace for package installation, etc).  If
I look for underlying operating system and kernel requirements, or
other technical discussions about security etc, I find very little
even in all the sources available to me.

What is the vision of the operating system _below_ the POSIX layer?
There seems to be somewhat of a gap right there, which we maybe can fill.

And if we don't do it, who else will?  When I came to the Hurd in
1997, it was essentially dead.  It was not yet officially declared
death, but it was pretty close.

What we first want is to iron out some of the Hurd's problems. If we _have_ a running Hurd and can say "no more large problems left", _then_ is the time to look further. Actually, the Hurd in it's current state is really poweful. When I came to the Hurd, I first tried to boot the actual one. There was, in fact, one unsolvable problem, no driver for my hd existed. When I later tried it in qemu, there were two things because of whom I'd not want to use it: it was damn slow and buggy. Of course now, as I'm more familiar with the internal problems, I see other issues. However, what I wanna say with this: it's not the time to look for visions - we need hard code, that's it.

Do you trust me if I say that Neal and I both have tried to fix the
Hurd's problems with hard code, and we think it just doesn't work out
this way?

I do so.

 (I didn't check with Neal, but I think he will agree with
this broad characterization).  I am only saying this to interest you
in looking a bit deeper and trying to understand the issues instead
ignoring them "for now".  They are not going to go away by ignoring

The reason is that the problems are not engineering problems, or even
labor problems.  We have these types of problems as well, and they may
cloude your view on the other issues.  The real problems are

Yes. That is right. I really don't have a problem with redesigning the Hurd's architecture. I see this is necessary. But I don't think whether refining the goals is a good idea.

 Of course, if you believe this or not depends on your
goals.  But if you read my stance on Thomas' paper in my other mail,
you will see why I think that we are totally in line with the original
Hurd goals.

You are, but not everyone else.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]