Re: L4-HURD , POSIX, UNIX

[Bas Wijnen]

On Mon, Oct 31, 2005 at 08:02:29PM -0600, William Grim wrote:
> > 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.

Starting from scratch would mean to create a custom micro-kernel for the
project as well.  I think this approach would guarantee that the project never
gets finished.  We should prioritize our goals, draw a line at "everything
above here is essential", and one at "everything below here is optional".
Maybe this is just one line, but I think there can be some things in between.

For this reason, I sent a list of possible goals to the list some time ago.
I'll repost it in my preferential order, with those lines in it.  Obviously,
you are all encouraged to send your own views.

> Well, from my viewpoint, I rather like the idea of a persistent system. I
> spoke to someone briefly on the matter, telling him that I didn't yet have
> all the details, and even though I didn't have all the details yet, he
> seemed to think the idea of a persistent design was pretty innovative. He
> and I both agree that a system that can recover itself to within a few
> minutes is potentially a very good way to keep people more productive when
> bad things happen to the system. I will wait until we start to get more into
> the next phase of design discussion before I talk about the "but what if"
> aspect of this viewpoint.

I like persistence as well, mostly because I feel it results in a more robust
system.  However, if people already see concrete problems with it, I'd like to
hear them now, not after we decided that we want persistence.

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

This makes sense.  However, there is another point: Not only have you thought
out your views, you also have not thought out the other views as much.  We
haven't thought out any of them.  I understood that you offered yourself as
our mentor (correct me if I misunderstood), in which case this can be a reason
to go for your view.  Not because it is objectively "better", but because we
have at least one person with us who knows all about it.

> What I would like to keep in mind as we progress is that we need to show
> real progress. Perhaps a staged delivery lifecycle could help here?
> Delivering little pieces of the OS at regular intervals could help keep the
> program on track and show end users that we really are getting work
> accomplished.

And more importantly IMO, to show the developers that we're getting there, so
they stay motivated.

Thanks,
Bas

-- 
I encourage people to send encrypted e-mail (see http://www.gnupg.org).
If you have problems reading my e-mail, use a better reader.
Please send the central message of e-mails as plain text
   in the message body, not as HTML and definitely not as MS Word.
Please do not use the MS Word format for attachments either.
For more information, see http://129.125.47.90/e-mail.html

signature.asc
Description: Digital signature