Re: Translucent storage: design, pros, and cons

[Jonathan S. Shapiro]

Marcus:

I respect that you are under time pressure, but I am very concerned
about the last part of this message.

It is not clear to me whether you are saying "there are other
requirements to come and we will deal with them as they are refined" or
you are instead saying "I have decided that Coyotos won't do what we
need". If the latter, please let me know, because contributing to HURD
involves a significant commitment of time.

I do wish that you would stop moving the target. You raise an objection.
I respond. You raise a new, underspecified objection. I spend a large
effort getting it clarified. Because of the time this requires from me,
this pattern has become fairly unreasonable. We have reached the point
where you should be able to say "yes, Coyotos can plausibly serve as a
starting point if it is available to us in time", or "no, it cannot".

If the answer is "no", that is fine, but please respect the amount of
time I am committing by telling me so directly. As the saying goes: it
is time to shit or get off the pot. :-)

  [A friendly suggestion: don't get off the pot unless you realistically
   have an alternative pot around. "We'll build our own kernel" hasn't
   worked for HURD in the past.]

Concerning object virtualization, I feel confident saying that no OS has
*ever* done a better job at this than the KeyKOS/EROS/Coyotos chain of
systems. We may not do everything you want at this time, but you will
not find a closer starting point anywhere else.


Jonathan

On Wed, 2007-01-10 at 14:28 +0100, Marcus Brinkmann wrote:
> Hi,
> 
> Jonathan, first let me thank you for taking the care and time to think
> about this in terms of terminology and concepts you are familiar with,
> and making sense for you out of my vague descriptions.  It should be
> of great help in the discussion.
> 
> I have to be very brief, because I am currently in a very tight spot
> due to unrelated issues, but I want to give you at least a quick
> response on how close you hit the black spot.
> 
> In terms of abstract functionality related to ability of inspection, I
> think your proposal meets my "old" requirements fully, excluding just
> the "defensive network stack design" issue, where your proposal to
> have translucent read-only storage does not meet my original
> requirements strictly.  It's worth thinking about how strongly the
> differences matter, it could be that in actual practice it is
> neglible, but that is not entirely clear to me.
> 
> My main concern is tangential.  Making DRM hard is really just a
> side-effect of realizing other goals that require strong translucency
> and virtualization features.  Nothing too specific at this point, in
> particular with regards to memory storage, but our philosophical
> differences in that respect can maybe be illustrated by how we value
> shared libraries.  Way down the road, I am interested in a system
> where these features (and I really have to fill in what they are at a
> later time) are realized practically, and not just theoretically.  In
> other words, just as in any other system one has the desire to align
> the design towards a common underlying principle or idea, and that may
> suggest different mechanisms to achieve approximately the same thing.
> This has both opportunities and perils, but my main point is that my
> interests and positions can not be understood from an objection to DRM
> alone, that would give a distorted picture.
> 
> Thanks,
> Marcus
> 
> 
> 
> 
> _______________________________________________
> 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