l4-hurd
[Top][All Lists]
Advanced

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

Re: How to add constructor to the Hurd?


From: Marcus Brinkmann
Subject: Re: How to add constructor to the Hurd?
Date: Wed, 03 May 2006 12:16:28 +0200
User-agent: Wanderlust/2.14.0 (Africa) SEMI/1.14.6 (Maruoka) FLIM/1.14.7 (Sanjō) APEL/10.6 Emacs/21.4 (i486-pc-linux-gnu) MULE/5.0 (SAKAKI)

At Wed, 3 May 2006 11:49:06 +0200,
Pierre THIERRY <address@hidden> wrote:
> 
> [1  <multipart/signed (7bit)>]
> [1.1  <text/plain; us-ascii (quoted-printable)>]
> Scribit address@hidden dies 02/05/2006 hora 23:47:
> > The answer should be pretty obvious: For the reasons stated before, we
> > will most likely never include the constructor mechanism in the
> > official ngHurd version distributed by the GNU project.
> 
> So your're so against non-free software that you want people not to be
> able to hide their code when they *need* to? That really seems a bit
> fanatic to me. And that's frightening, because among many of my friends,
> I'm a bit too fanatic about free software and the ethical issues about
> non-free software.
> 
> In fact, for obvious reasons I asked to Marcus. But who will have the
> power to decide eventually? In KDE, "those who write the code make the
> design decisions". It will obviously not be the case here (for good
> /and/ bad reasons, IMHO)

These are valid questions, and they need to be considered with extreme
caution.  You give the impression that it is my model in wich we make
a decision for somebody else, while the trusted computing model gives
you more possibilities.  I believe that this is a fundamental error in
analysis.

I just wrote a very long mail, with the subject "Part 1: Ownership and
Contracts".  In that mail, I give an analysis how contracts (for
example, like hiding your code while still allowing others to use it)
come to be.  It is my believe that this analysis shows clearly that
both systems allow to implement the same contracts.  What
differentiates them is that in my model, there is _no_ contract that
is "the default", while in EROS/Coyotos, there is a default contract.
Also, in my model, by default, no operation creates a contract, while
in EROS/Coyotos, every process instantiation, by default, creates a
contract.

The difference is not in what is theoretically possible, but in what
the default behaviour is.  You can read in that mail some of the
reasons why I believe that the behaviour I suggest is safer.  You do
not need to agree with these reasons, but I think it is very wrong to
suggest that my design imposes a fundamental limitation to the
creation of legitimate contracts.  It does, intentionally, impose a
barrier on the creation of contracts involuntarily.

These differences do have practical consequences.  While in the
EROS/Coyotos model, it is very straightforward to implement DRM-like
control, in my model it is substantially harder, maybe to the extent
of making it impossible.  However, this is because DRM-like control
contracts are extremely invasive, and because DRM-like control
contracts are fanatic about controlling your resources.  It is not
because we are fanatic about not letting you use them.

If after reading that mail you still have your concern, I would invite
you to respond to that mail and raise it in the context of my
analysis.

Thanks,
Marcus





reply via email to

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