[Top][All Lists]

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

Synopsis of confinement discussion

From: Jonathan S. Shapiro
Subject: Synopsis of confinement discussion
Date: Mon, 01 May 2006 01:50:02 -0400


I would like to summarize the discussion as I see it so far. This is my
view. Marcus will certainly disagree.

Marcus has made the decision to reject confinement. I believe that he is
making a profound mistake, but the Hurd is his system (and yours). It is
your decision to make. 

Marcus states repeatedly that "there are no use cases for the
constructor that are of interest to the Hurd". This is obviously false.
Several of you have offered example use cases. What *may* be true is
that there are no use cases that are of interest to Marcus. This is
*also* his decision (and yours) to make.

I too have decisions that I must make. As all of you know, the Hurd
project is a secondary goal for me. I would like you to succeed, and I
would like to support your success, but it is increasingly clear that
Marcus and I are focused on incompatible problems. Marcus wishes to
prevent what he sees as the "ownership" of "digital information". I
simply do not believe that his proposal will achieve this, and I am
reluctant to compromise a working architecture for no gain. I disagree
very fundamentally with his view about the ethics of digital information
ownership. As I said earlier, I am an advocate of "open source", but I
do not subscribe to the ideology of "free software" (and *definitely*
not to its generalization: free digital information). I believe that
software should be free because this is more effective, not because it
is a moral right.

For my part, I wish to create a computing environment in which mutually
suspicious parties can collaborate in spite of their suspicions. In
order to support mutually suspicious collaboration, it is necessary to
be able to set certain types of controls and boundaries on the use of
information. I do *not* mean DRM, but I definitely *do* need to be able
to establish situations in which the right to execute a program does not
imply the right to examine it's state -- this is the "encapsulation"
property, and it is exactly the property that Marcus desires to remove.

Because of the importance of encapsulation for the problems that I am
trying to solve, the constructor is extremely fundamental to the Coyotos
design, and it is at the center of the Coyotos system security
architecture. I simply do not have time to actively pursue two radically
different systems. I have classes to teach, students to advise, and a
business to run. If the Hurd chooses to abandon constructors, that is
okay, but it moves the Hurd design outside of anything that can
potentially support "suspicious collaboration." In my opinion, it also
moves the Hurd outside the space of potentially useful system designs in
the eyes of the real world, but that is very much a matter of opinion.

Later this week, when I am not working on three other things at the same
time (which has been a large part of the problem today), I will try to
set out in writing some of the things that Coyotos is trying to achieve,
and why confinement is essential to achieve them. Many of these are not
Hurd objectives, and I do not assert that they should be. Perhaps they
will provoke thought, and that is useful. Perhaps they will prompt
Marcus to re-examine, and perhaps not.

If the Hurd group decides that encapsulation is wrong for the Hurd, you
are certainly welcome to use the Coyotos kernel, and I will be happy to
explain how it works and make necessary repairs. However, I do not
believe that the resulting system will be relevant in the real world.

And just to be clear: if it goes that way, and if I discover in five
years that I was wrong, I will be very happy for Marcus and for all of

We have not yet reached this point, but we all need to be aware that it
is approaching rapidly.


reply via email to

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