[Top][All Lists]

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

What is *difficult* with Coyotos

From: Jonathan S. Shapiro
Subject: What is *difficult* with Coyotos
Date: Thu, 27 Oct 2005 22:39:26 -0400

There is a set of issues that are not problems with Coyotos per se, but
are generically challenging design issues. Coyotos has been
intentionally designed to let application developers address some of
these issues, but as a consequence the issues become hard to ignore.
Depending on your point of view, this is either a feature or a cost.

1. Storage Accountability

Coyotos just won't let you lie to yourself about who is paying for what.
It is consciously and deliberately designed to make this type of sloppy
design difficult.

This is sometimes painful, because it requires looking at certain design
patterns much more skeptically. On the other hand, Coyotos (and EROS)
provide the necessary mechanisms to solve those problems in every case
we have encountered.

This issue will intrude on the implementation of the POSIX environment
servers, but it will not intrude on POSIX applications that run in that

2. Least Privilege

Least privilege is not a "wish list" thing in Coyotos. It is the thing
that the entire structure of the system is designed to achieve and
support. This has implications for the structure of applications.
Learning to develop in this framework takes some re-thinking and

People who are experienced kernel and system hackers are going to have
it the hardest. They have many assumptions that they have stopped
questioning. A depressing number of these assumptions fail when the
system design requires the developer to think in terms of accountability
for resource.

POSIX makes very few demands about this, and POSIX is the architecture
that most of you know. Setting aside the question of whether POSIX is
good or bad, it is probably clear from the discussion this month that
the EROS/Coyotos approach is very alien to the architectural assumptions

3. Persistence

People are going to scratch their heads about persistence for a long
time, and they are going to expect it to have major impact on how things
get built. Mostly you can just ignore it.

4. Design Emphasis

I am not convinced that this should be the design goal of Hurd, but in
the EROS/Coyotos group we have an expression that we use: "it is good
enough to commit when it is good enough that you would run the code on
your (personal) pacemaker".

[I have subsequently learned that this is a terrible goal, because the
testing and design standards of pacemaker manufacturers are depressingly

Obviously there is stuff under development that doesn't satisfy this
test. It is really a philosophy about design. Alfred is right: we *are*
paranoid in our design. We are very very good at it. We probably have
more experience at paranoid design than any other kernel group in the
world today, and it is the reason that my students are getting hired by
the most critical kernel groups all over the world.

But it isn't the usual FLOSS approach and orientation. Partly, this is
because most FLOSS developers are young and the approach requires
intensive experience and mentoring. Partly, we are just interested in
different problem domains. This is not a criticism. It is just a
description of a difference.

I don't know if this is a "problem" or not, but it is definitely going
to be a source of culture shock. I do not suggest that Hurd should be
built this way (you may wish to consider it), but the difference in
emphasis between the groups will take some getting used to.

One comment on all of the above. Marcus has listed scalability,
stability, and survivability (robustness and recoverability) as Hurd
goals. Discussion this month may have added some security goals.

These are the hardest problems anywhere in computing, and the solutions
simply cannot be found in textbooks. They don't come from hacking code.
They emerge as a consequence of disciplined design.

Because this stuff isn't in books anywhere, there are ONLY two ways to
achieve this type of discipline:

  1. Spend 30 years of your career re-discovering a fraction of it
  2. Spend some time working to learn it from a mentor (or more than
     one) and then figure out how to adapt what you have learned.

If these goals are serious, and not just PR, then this group needs an
experience mentor. I am probably not a good one, because my personality
will get in the way. I have very little tolerance for short cuts in
architecture when better ways are known. However, I am willing to make
what I know available to this community as best I can, and I have
already invited Marcus and Neal to come to Baltimore for an extended
visit to help them evaluate Coyotos.


reply via email to

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