l4-hurd
[Top][All Lists]
Advanced

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

Re: L4-HURD , POSIX, UNIX


From: ness
Subject: Re: L4-HURD , POSIX, UNIX
Date: Mon, 31 Oct 2005 16:50:52 +0100
User-agent: Mozilla Thunderbird 1.0.7 (X11/20051031)

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)
--
-ness-




reply via email to

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