Re: L4-HURD , POSIX, UNIX

[Jonathan S. Shapiro]

On Mon, 2005-10-31 at 16:50 +0100, ness wrote:
> Jonathan S. Shapiro wrote:
> > On Sun, 2005-10-30 at 23:10 -0600, William Grim wrote:
> > 
> >>So I guess the next question in our design should be: What should we
> >>make the new environment look like?  Is it possible to start with the
> >>POSIX design, find the flaws, and build a new design based on POSIX
> >>but with all the flaws removed, or do we need to design something
> >>completely new?  It doesn't matter to me which one we do; for me, a
> >>new design would be easier to follow.  However, those that know POSIX
> >>internals may have a different viewpoint, but I think a totally new
> >>design could also be easier to build correctly from the beginning.
> > 
> > 
> > This is a decision that the Hurd group must make for itself. I have two
> > thoughts that may or may not be helpful.
> > 
> > 1. In the history of computing, no sound design has ever emerged out of
> > an attempt to patch and recover an earlier design.
> > 
> > 2. Designing from scratch is both very easy and very hard. It is very
> > easy because you have the ability to state your design principles and
> > stick to them -- hopefully better than the previous OS designer did. It
> > is very hard because sticking to design principles involves a great deal
> > of discipline and pain. It is satisfying, but sometimes not very fun. It
> > does not interact well with a "let's just write some code" orientation.
> > If this path is taken, all of the key participants will need to buy in
> > to this idea of "principles drive the code", or it won't work socially.
> > 
> > 
> > shap
> > 
> So, decoding you comment, you would advise us to design the Hurdish API 
> from scratch. We should define principles and goals before and stick to 
> them. And we should learn from failures of other OS designers that 
> didn't do so (it'd be nice of you to give examples for this).
> This might be a good idea. And this would heavily influence the 
> implemetation (as this Hurdish API would be exported by the core servers).
> Maybye it's really time to seriously consider designing a Hurdish API.
> (of course this is a lot of work and would maybye delay the Hurd even 
> more, but I think it got more and more clear that it's necessary)

If you are asking "What would shap do if *he* were the architect?", then
yes, I would begin from scratch -- but I already have done this.

If you are asking "What does shap think the Hurd group should do?", then
I would say: figure out what your real objectives for the system are,
and from this decide what approach to system architecture is
appropriate. However: several of the truly innovative features that we
have been considering are the same ones that led me to start from
scratch.

And now we arrive back at something I tried to say way back at the
beginning of the month: my views about how to do system architecture are
fairly mature and fairly carefully reasoned. This makes them easier to
describe in a coherent way, but conversely it makes them much harder to
dislodge in the ears of the listener. There is a real risk in any
extended architecture discussion with me that the listener ends up drawn
to my view -- simply because it *is* carefully thought out and
reasonably cohesive. [I am certainly not alone in this property --
Jochen had it too, and others do as well.]

It does not follow that my intuitions and sensibilities are appropriate
for the Hurd. The Hurd group must decide for the Hurd.

shap