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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
