A design guideline

[Jonathan S. Shapiro]

We have all been through the opaque storage discussion before. Marcus is
pursuing an interesting direction with his proposal for a purely
hierarchical and transparent arrangement. I think he will run into
difficulties, but this is a *hunch*, not a fact.

But the recent discussion suggests two major principles that the Hurd-NG
group needs to adopt:

  1. We should not embed a technical restriction that is ineffective.

     Example: somebody recently suggested that transparent memory
     has no effect on DRM or hidden code, and sketched how to build
     an application using hidden code with transparent memory.

     It is not clear to me if their example is correct, but I think
     that this is a very important example to understand. If the
     argument *does* turn out to be correct, then the memory
     transparency restriction is ineffective and should not be
     admitted into the design.

     This rule should apply no matter how strongly any of us may
     feel that the intended real-world objective is important.

  2. No subsystem design should be accepted merely in the basis
     that it (technically) works as expected. In order to admit
     a design, we must consider how to *defeat* the intended
     purpose of the design and subvert it for unintended purposes.
     Only when a design has been evaluated from this standpoint
     and survived should it be considered as a serious candidate
     for incorporation into a system.

I see too much discussion here where designs are not being examined from
a hostile point of view. If this is permitted, Hurd-NG will be just as
vulnerable as Windows.

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