Re: Translucent storage: design, pros, and cons

[Jonathan S. Shapiro]

On Wed, 2007-01-10 at 23:14 +0100, Neal H. Walfield wrote: 
> At Wed, 10 Jan 2007 16:09:27 -0500,
> Jonathan S. Shapiro wrote:
> > 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".
> 
> I think this is unfair.  Marcus has been relatively consistent in his
> objection.  It is true that, as you have together examined the problem
> space, wrong paths have been taken and incorrect conclusions drawn.
> There have even been a few misunderstandings.  I think some of these
> could appear as if Marcus was changing his objective.  However, I
> think that this is just expected development in such a discussion.

I have no problem with the original objection concerning translucency,
or the discussion that followed. It has taken a long time, but it was a
complex issue and I feel that the time was not badly spent.

And yes, misunderstandings have occurred and will occur. This is not the
issue that concerns me.

> You are right that this discussion has been a long one.  I think the
> difficulty is that the issue it is not technical but rather
> socio-political and as such, it cannot be solved by technical means:
> technical means can only be evaluated according to their consistency
> with the proposed values.
> 
> It appears to me, and I think this is Marcus's objection, that you are
> asking if your technical proposal solves Marcus's problem.
> Unfortunately, for the above reason, it can't; it can be evaluated as
> whether it is consistent with the values.
> 
> I don't know if this helps.

You have put your finger on the problem neatly, but you have not
addressed my concern (and perhaps did not intend to).

It is impossible to select or design a kernel based on social
objectives. The social objectives must first be translated into
technical objectives and constraints. These must then be evaluated
against the existing and possible technical solutions. At the end of the
day, one of two things must happen:

  1. A kernel must be selected (or built) based on the evolved technical
     criteria, or

  2. The project must be abandoned as technically infeasible.

This assumes that the moving target moves at a manageable speed. If it
doesn't, the technical requirements never converge. This is what appears
to be happening with the HURD.

The part of Marcus's note that angers me is this part:

> 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.

I understood that DRM was not a primary focus. I was very explicit in my
note that I was using DrmPlayer as an example, not as an objective. I do
think that it is a good "torture test" for disclosure and openness, but
it is certainly not the only test we need to consider. The problem is
that at this time no other tests have been stated.

I have no idea what the reference to shared libraries is about. I do not
see why our philosophical differences are relevant to the *technical*
decision that needs to be made. Either the system is suitable or it can
be modified or it is unsuitable. If it is not suitable, then either it
is possible to state why fairly soon or HURD-NG is merely a fantasy.

I know that Marcus is not hiding anything on purpose, but it makes me
ABSOLUTELY NUTS is that after more than a year of discussions there are
still "features" that are hidden. I have *repeatedly* asked that the
design objectives of the HURD be captured concretely so that they can be
examined. Little progress has been made. I have spent much of the past
year trying to ensure that a concrete system design would be able to
support the HURD, and I now learn that this effort may have been largely
misdirected. Or perhaps not, but it is impossible to know. I feel like I
am trying to satisfy a target that sits in the dark refusing to disclose
itself and changes shape whenever it seems that I am finally coming to
understand it.

This is all costing me a great deal of energy, time, and money.

Marcus has not offered a single objective that Coyotos fails to meet.
Neither have you, and neither has anyone else. If a concrete problem is
identified, we will address it. I have made this *repeatedly* clear, but
still there is indecision.

How long am I expected to support this activity with money and time and
energy without any expectation that portions of Coyotos will be used --
even if only in modified form?

How do you suggest that I should feel about this?


shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100