diff options
Diffstat (limited to 'community/gsoc/project_ideas.mdwn')
| -rw-r--r-- | community/gsoc/project_ideas.mdwn | 13 |
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 |