Re: Part 2: System Structure

[Jonathan S. Shapiro]

[If you are not interested in my comments about policy goals -- which in
this note are not confrontational -- skip down to the part starting with
"purely technical matters"]

On Tue, 2006-05-23 at 00:29 +0200, Bas Wijnen wrote:
> We should not give people the choice to be oppressed, because it is not the
> people who choose this, but the oppressors (in this case by not providing any
> non-DRM content).  If DRM is not possible on any system (if we would implement
> it, it would be the only system where it's possible), they will provide the
> content through other means.

This is not factually true. The user *can* choose not to accept DRM
content today, and a content provider could elect not to use it. The
suggestion that the decision is entirely one-sided is complete nonsense.
The problem is not lack of choice. The problem is imbalance of power.
And this imbalance is not universal (see aside, but this is probably not
central to the discussion).

  Aside: in the US, the porn industry (which accounts for the
  overwhelming majority of DVDs produced and sold) generally does
  *not* use content encryption, and I am not aware of any legal
  case against copying that has been brought by the business
  alliances in that industry. They rely instead on (a) a continuing
  supply of new, um, faces, and (b) very low production costs.


The argument that you are actually making is much more subtle (and, I
think, more powerful):

If we can build a sufficiently large *collective* block of users who
refuse DRM -- big enough that these users represent a noticeable
proportion of market share or a publicly visible group whose visibility
imposes noticeable embarrassment or noticeable marketing and PR costs to
the content providers, we *may* be able to restore more balance of power
to the viewers (either through the market or through legislation), and
by doing this we may be able to force DRM use to a more acceptable
middle position or even eliminate it entirely.

If this is the argument, then I think that it is a good argument, and
that it is even worth a try. Speaking personally, it's not a cause that
I wish to adopt -- I am doing too much elsewhere already -- but it is a
perfectly good cause.


So now let me return to purely technical matters:

First, two statements:

1. RMS is mistaken about a detail: the source of DRM compatibility in
   Coyotos is *not* the constructor per se. It is the combination of the
   constructor logic and the requirement of opaque storage. Viewed
   from a purely technical perspective, Marcus's proposed technical fix
   is quite brilliant (which is part of why I have struggled with it
   so hard -- it is very elegant, and for Coyotos-OS objectives,
   extremely damaging).

2. None of the translucency policies that have been discussed are
   enforced by the Coyotos kernel. If you are prepared to modify the
   existing space bank very slightly (so that it does not enforce
   opacity) and trivially adapting the existing core utilities, the
   policy that you describe can easily be implemented.

So: eliminating DRM does not require eliminating constructors. A
translucent space bank design is entirely sufficient. All of the rest of
the properties that you are worried to avoid are a consequence of
opacity. [It is possible that I have failed to consider something, but I
am fairly confident about this statement technically.]

I can even see approximately how the forensic support needed to make
*use* of a translucent space bank could be implemented. It will be much
easier to do this in Coyotos than in EROS, because processes are a
separate object type. I would be willing to assist in the necessary
space bank design changes, because I think that the debugging ability
would be useful for Coyotos-OS independent of Hurd-OS. For Coyotos-OS, I
will need to retain the mechanism supporting space bank opacity. For
Hurd this can be compiled out or simply disabled on the prime bank by
setting the "do not permit opaque child banks" restriction on the prime
bank capability.

This offers a design option: keep the basic foundational utilities (with
the addition of space bank translucency) as they are, and then build the
rest of the system on top of this -- possibly following the hierarchy
style that Marcus has proposed, or possibly modifying it in whatever way
seems appropriate to you.

The advantage to this is that it will allow you to re-use the driver
infrastructure and persistence infrastructure of Coyotos, which will
save all of us a lot of work.

I never expected that Hurd-OS would be Coyotos-OS. It is right and
proper that they should diverge. What I am trying to say here is that it
still seems possible for them to share substantial amounts of "core"
code, even though the two systems will make use of the objects in very
different ways.


The *only* concern that I have with this is a concern about
"positioning". It needs to be very clear that Hurd-OS is not Coyotos-OS,
because I have customers who are relying on these features in Coyotos-OS
and I do not want them to become confused.

On the other hand, it seems to me that the reverse is also true. Since
part of the purpose of the Hurd design is to establish a visible
position on the DRM issue, it is important for Hurd to distinguish
itself visibly from other operating systems (including Coyotos, but also
Linux and others).

So I do not see any great problem here.

Marcus: what are your reactions on this technical option, and also on
the need to be clear that the systems are different?



shap