[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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
