Re: Design goals

[Jonathan S. Shapiro]

Okay, here is a controversial one to consider:

  The native Hurd OS should be a principle-based design

That is, the Hurd design should be constrained by a set of clearly
articulated design principles, and should reject, omit, or modify
features that do not satisfy these principles.

What is a design principle?

A design principle is a test that lets you *reject* things. Hopefully,
when combined with other design principles, it forms a basis for making
coherent and consistent decisions about design goals and system
features.

Examples:

  "Hurd should be extensible" is not a principle. It is a design
  goal. It is not a principle because it is not useful in rejecting
  or filtering proposals.

  "Hurd's extensibility should not increase the system's vulnerability"
  is something very close to a principle. I do not consider it a good
  one because:

    a) it is expressed in terms of a feature, and

    b) it feels to me, subjectively, like there must be some more
       general principle that could be extracted from this one,
       after which this would become a design constraint by consequence.

    c) it is not quite capturing the right thing, because there are
       certainly places in the system where extensibility might be
       permitted in ways that would increase the vulnerability
       of the system if done badly -- for example, we might want to
       add a new network protocol.

  "The system's software design should preclude an administrator being
  able to examine a user's state without the user's consent" is a design
  principle governing the role and powers of the system administrator.
  I'm not sure that Hurd wants to adopt this principle; I am merely
  saying that in my opinion it is an example of a design principle.

  "The system should provide a uniform naming and protection mechanism
  allowing new object types to be introduced by application-level code"
  is a design principle governing the design of the naming and
  protection mechanism. [It is imperfectly achievable, since we do not
  currently know how to successfully extend the "read-only" property
  to such objects in general, so user-implemented objects are not
  really co-equal with kernel-implemented objects.]

  "The set of things that must be implicitly trusted by an application
  should be kept to a minimal and coherent set" is a design principle.
  This would allow introducing new servers, but it means that a client
  should not be deprived of the opportunity to reject those severs.
  Under this principle, we would not extend the confinement contract to
  consider a read-only file descriptor confined unless the client
  application has agreed that the file server is trusted in the eyes of
  the client application.


Enough examples. My proposal is that the Hurd native OS should be a
principle-based design. I am *intentionally* excluding hosted
personalities from this rule, because we want to include POSIX, and
POSIX will violate some of the principles that I think we will want in
the native OS.

Reactions?

shap