community/gsoc/project_ideas (virtualization using Hurd mechanisms): Add some links.

1 files changed, 7 insertions, 6 deletions

diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 3d81a83e..ec4b6631 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -61,7 +61,7 @@ perhaps can be re-used.
 
 The main idea behind the Hurd design is to allow users to replace almost any
 system functionality. Any user can easily create a subenvironment using some
-custom servers instead of the default system servers. This can be seen as an
+custom [[servers|hurd/translator]] instead of the default system servers. This can be seen as an
 [advanced lightweight
 virtualization](http://tri-ceps.blogspot.com/2007/10/advanced-lightweight-virtualization.html)
 mechanism, which allows implementing all kinds of standard and nonstandard
@@ -73,7 +73,7 @@ desired constellations.
 
 The goal is to create a set of powerful tools for managing at least one
 desirable virtualization scenario. One possible starting point could be the
-subhurd/neighbour Hurd mechanism, which allows a second almost totally
+[[hurd/subhurd]]/[[hurd/neighbourhurd]] mechanism, which allows a second almost totally
 independant instance of the Hurd in parallel to the main one. The current
 implementation has serious limitations though. A subhurd can only be started by
 root. There are no communication channels between the subhurd and the main one.
@@ -89,7 +89,7 @@ using most of its facilities -- similar to a chroot environment. A simple way
 to create such a subenvironment with a single command would be very helpful.
 
 It might be possible to implement (perhaps as a prototype) a wrapper using
-existing tools (chroot and unionfs); or it might require more specific tools,
+existing tools (chroot and [[hurd/translator/unionfs]]); or it might require more specific tools,
 like some kind of unionfs-like filesytem proxy that mirrors other parts of the
 filesystem, but allows overriding individual locations, in conjuction with
 either chroot or some similar mechanism to create a subenvironment with a
@@ -105,15 +105,15 @@ of special filesystem proxy again -- in which the user serves as root, being
 able to create local sub-users and/or sub-groups.
 
 This would allow the user to run "dangerous" applications (webbrowser, chat
-client etc.) in a confined fashin, allowing it access to only a subset of the
+client etc.) in a confined fashion, allowing it access to only a subset of the
 user's files and other resources. (This could be done either using a lot of
 groups for individual resources, and lots of users for individual applications;
 adding a user to a group would give the corresponding application access to the
-corresponding resource -- an advanced ACL mechanism. Or leave out the groups,
+corresponding resource -- an advanced [[ACL]] mechanism. Or leave out the groups,
 assigning the resources to users instead, and use the Hurd's ability for a
 process to have multiple user ID's, to equip individual applications with set's
 of user ID's giving them access to the necessary resources -- basically a
-capability mechanism.)
+[[capability]] mechanism.)
 
 The student will have to pick (at least) one of the described scenarios -- or
 come up with some other one in a similar spirit -- and implement all the tools
@@ -128,6 +128,7 @@ Completing this project will require gaining a very good understanding of the
 Hurd architecture and spirit. Previous experience with other virtualization
 solutions would be very helpful.
 
+
 ## namspace based translator selection
 
 The main idea behind the Hurd is to make (almost) all system functionality