summaryrefslogtreecommitdiff
path: root/community/gsoc/project_ideas.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'community/gsoc/project_ideas.mdwn')
-rw-r--r--community/gsoc/project_ideas.mdwn13
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