[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Translucent storage: design, pros, and cons
From: |
Jonathan S. Shapiro |
Subject: |
Re: Translucent storage: design, pros, and cons |
Date: |
Fri, 12 Jan 2007 16:27:40 -0500 |
On Fri, 2007-01-12 at 20:13 +0100, Tom Bachmann wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Jonathan S. Shapiro schrieb:
> > On Fri, 2007-01-12 at 19:58 +0100, Tom Bachmann wrote:
> >
> >> Well. I have the binary of a program (or, actually, it's source code,
> >> but there exists a compiled version, for convenience). I load it into
> >> memory and give it whatever capabilities I think are needed, enforcing
> >> whatever properties I want. What can the constructor do that I can't?
> >
> > Tom:
> >
> > 1) What about capabilities it holds that you do not?
>
> I create it. All capabilities that it has have been given to it by me.
> This is, as I understand it, a core property of the partial design
> Marcus described in part two of his notes.
Why do you assume that you create it? You may supply the storage for the
instance but not the constructor.
>
> > 2) There is still utility in doing this by means of a commonly used
> > routine.
>
> Yes, and as I have said before, I don't argue that it is to be removed
> per se (actually, not at all, for exactly the reason you state), but
> that it is not to be considered a "relevant" part of the design, if it's
> utility drops to only being commonly used for convenience (which is what
> it appears to me to be in the translucent storage / hierarchic trust
> relationships design).
> - --
> - -ness-
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFFp93nvD/ijq9JWhsRAof6AJoD62rlDqVLKWETwmVh1Jtzkgr9GgCfW8MU
> rbpH4tD0M/JnFPDf12mqpN8=
> =ZJrj
> -----END PGP SIGNATURE-----
>
>
> _______________________________________________
> L4-hurd mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/l4-hurd
--
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100
- Re: Translucent storage: design, pros, and cons, (continued)
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/11
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/12
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Re: Translucent storage: design, pros, and cons,
Jonathan S. Shapiro <=
- Re: Translucent storage: design, pros, and cons, Tom Bachmann, 2007/01/12
- Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/12
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/14
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- constructor daemon vs. constructor library, Neal H. Walfield, 2007/01/15
- Re: constructor daemon vs. constructor library, Jonathan S. Shapiro, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Marcus Brinkmann, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Jonathan S. Shapiro, 2007/01/15
- Re: Program instantiation (was: Re: Translucent storage: design, pros, and cons, Neal H. Walfield, 2007/01/15