summaryrefslogtreecommitdiff
path: root/Hurd/DesignPrinciples.mdwn
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2007-08-12 22:14:29 +0200
committerThomas Schwinge <tschwinge@gnu.org>2007-08-12 22:14:29 +0200
commit80af51ad8c2b60abd1295f7209c2a8099211c899 (patch)
tree7f27aa87cc29f330d01927e62d401db42ef231bd /Hurd/DesignPrinciples.mdwn
parentae128d097693da524c4a35d42fdc39b8d8b557dd (diff)
Move the NextHurd files to where they belong.
Diffstat (limited to 'Hurd/DesignPrinciples.mdwn')
-rw-r--r--Hurd/DesignPrinciples.mdwn39
1 files changed, 0 insertions, 39 deletions
diff --git a/Hurd/DesignPrinciples.mdwn b/Hurd/DesignPrinciples.mdwn
deleted file mode 100644
index 42faa52f..00000000
--- a/Hurd/DesignPrinciples.mdwn
+++ /dev/null
@@ -1,39 +0,0 @@
-# <a name="Design_Principles"> Design Principles </a>
-
-A design principle is a test that lets us **reject** things. Hopefully, when combined with other design principles, it forms a basis for making coherent and consistent decisions about design goals and system features. [1]
-
-## <a name="Stated_design_principles"> Stated design principles </a>
-
-None defined yet, but there seems to be consensus that ngHurd should be a principle-driven design.
-
-## <a name="Potential_design_principles"> Potential design principles </a>
-
-Here is an incomplete list of potential design principles for the ngHurd. It is taken from [2]. I left out some principles I think do not apply or are not in question. Feel free to add more.
-
-### <a name="Principles_from_the_Multics_Proj"> Principles from the Multics Project </a>
-
-* _Economy of mechanism_: Keep the design as simple as possible.
-* _Fail-safe defaults_: Base access decisions on permission rather than exclusion.
-* _Least priviledge_: Components should have no more authority than they require.
-* _Least common mechanism_: Minimize the amount of shared instances in the system.
-
-### <a name="Commonly_accepted_principles"> Commonly accepted principles </a>
-
-* _Separation of policy and mechanism_
-* _Least astonishment (also known as principle of least surprise):_ The system�s behavior should match what is naively expected.
-* _Complete accountability_: All real resources held by an application must come from some accounted pool.
-* _Safe restart_: On restart, the system must either already have, or be able to rapidly establish, a consistent and secure execution state.
-* _Reproducibility_: Correct operations should produce identical results regardless of workload.
-
-### <a name="Principles_specific_to_EROS"> </a> Principles specific to EROS
-
-* _Credible policy_: If a security policy cannot be implemented by correct application of the system�s protection mechanisms, do not claim to enforce it.
-* _Explicit authority designation_: Every operation that uses authority should explicitely designate the source of the authority it is using.
-* _Relinquishable authority_: If an application holds some authority, it should be able to voluntarily reduce this authority.
-
-----
-
-See also:
-
-* [1] <http://lists.gnu.org/archive/html/l4-hurd/2005-11/msg00120.html>
-* [2] EROS: A Principle-Driven Operating System from the Ground Up