UNIX.

3 files changed, 19 insertions, 4 deletions

diff --git a/hurd/ng/part2systemstructure.mdwn b/hurd/ng/part2systemstructure.mdwn
index 4ce8026f..0f94ff2a 100644
--- a/hurd/ng/part2systemstructure.mdwn
+++ b/hurd/ng/part2systemstructure.mdwn
@@ -38,7 +38,12 @@ It is clear from this description that the child's existance is completely deter
 
 ## <a name="Canonical_Process_Destruction"> Canonical Process Destruction </a>
 
-Process destruction can be done either cooperatively, or forcibly. The difference corresponds approximately to the difference between SIGTERM and SIGKILL in Unix. To destroy a process cooperatively, a request message is sent to a special capability implemented by the child process. The child can then begin to tear down the program, and at some time send a request back to the parent process to ask for forced process destruction.
+Process destruction can be done either cooperatively, or forcibly.  The
+difference corresponds approximately to the difference between SIGTERM and
+SIGKILL in [[Unix]].  To destroy a process cooperatively, a request message is
+sent to a special capability implemented by the child process.  The child can
+then begin to tear down the program, and at some time send a request back to
+the parent process to ask for forced process destruction.
 
 Forced process destruction can be done by the parent process without any cooperation by the child process. The parent process simply destroys the primary container of the child (this means that the parent process should retain the primary container capability).
 
@@ -84,7 +89,13 @@ I will now describe some common applications that need to be supported, and how
 
 ## <a name="System_Services"> System Services </a>
 
-Unix-style suid applications have been proposed as one application for alternative process construction mechanisms. However, suid applications in Unix are, from the perspective of the parent, not confined, only isolated. Thus, they are readily replaced by a system service that is created by the system software, and that runs as a sibling to any user process. Only the ability to invoke the system service needs to be given to the user, not the ability to instantiate it.
+[[Unix]]-style suid applications have been proposed as one application for
+alternative process construction mechanisms.  However, suid applications in
+Unix are, from the perspective of the parent, not confined, only isolated.
+Thus, they are readily replaced by a system service that is created by the
+system software, and that runs as a sibling to any user process.  Only the
+ability to invoke the system service needs to be given to the user, not the
+ability to instantiate it.
 
 In fact, no gain can derived from letting the user instantiate system services. In Unix, system services run on durable resources, which the user can not revoke. Thus, the system service needs to acquire its resources from a container that is not derived from the user's primary container.
 
diff --git a/hurd/ng/usecaseprivatekeys.mdwn b/hurd/ng/usecaseprivatekeys.mdwn
index 612a8f25..3cb65af2 100644
--- a/hurd/ng/usecaseprivatekeys.mdwn
+++ b/hurd/ng/usecaseprivatekeys.mdwn
@@ -1,6 +1,10 @@
 _Private Keys_ as used by SSH servers, clients and generally by any cryptographic software need to be stored and manipulated securely. These may get replaced with smartcards soon, but in the mean time it appears to be an interesting use case.
 
-All Unix systems that I am aware of do not allow secrets to be protected in a manner that I would feel is appropiate. A users compromised web browser could either read your private key file or talk to the very popular ssh-agent program and get your secrets out (not sure how popular distributions are configured, but it can be done).
+All [[Unix]] systems that I am aware of do not allow secrets to be protected in
+a manner that I would feel is appropiate.  A users compromised web browser
+could either read your private key file or talk to the very popular ssh-agent
+program and get your secrets out (not sure how popular distributions are
+configured, but it can be done).
 
 The requirements so far are:
 
diff --git a/hurd/ng/usecaseuserfilesystem.mdwn b/hurd/ng/usecaseuserfilesystem.mdwn
index 6dce5670..4e4fdf35 100644
--- a/hurd/ng/usecaseuserfilesystem.mdwn
+++ b/hurd/ng/usecaseuserfilesystem.mdwn
@@ -3,7 +3,7 @@
 These appear as _translators_ in the current Hurd and something similar needs to appear in the next hurd.
 
 * The user should be able to dynamically add and remove translators
-* For some reason it seems appropiate to have seperate namespaces (VFS's) for each user (this is quite a departure from Unix. [[SamMason]])
+* For some reason it seems appropiate to have seperate namespaces (VFS's) for each user (this is quite a departure from [[Unix]]. [[SamMason]])
 * translators can be used to expose the structure of an archive file
 * translators can be provide access to remote file systems