Re: design goals vs mechanisms

[Marcus Brinkmann]

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

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

Thanks,
Marcus