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