Merge branch 'master' of flubber:~hurd-web/hurd-web

4 files changed, 64 insertions, 63 deletions

diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn
index 2719d2ab..ce3b26fb 100644
--- a/community/gsoc.mdwn
+++ b/community/gsoc.mdwn
@@ -23,8 +23,13 @@ always open to introducing newcomers to the world of the GNU Hurd outside of
 any Google Summer of whatever project.  Just pick a task from the list pointed
 to below on this page and get in touch with us!
 
-The GSoC 2009 student application time has come to an end -- we are now
-evaluating your applications.
+<!-- The GSoC 2009 student application time has come to an end -- we
+are now evaluating your applications. -->
+
+The applications have been evaluated and the following student has
+been accepted:
+
+  * [[Sergiu Ivanov|scolobb]]
 
 
 # History
diff --git a/community/gsoc/project_ideas/unionmount.mdwn b/community/gsoc/project_ideas/unionmount.mdwn
index 47a3d85d..86ef96c7 100644
--- a/community/gsoc/project_ideas/unionmount.mdwn
+++ b/community/gsoc/project_ideas/unionmount.mdwn
@@ -5,56 +5,7 @@ id="license" text="Permission is granted to copy, distribute and/or modify this
 document under the terms of the GNU Free Documentation License, Version 1.2 or
 any later version published by the Free Software Foundation; with no Invariant
 Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
-[[!meta title="Union Mounts"]]
-
-When setting a translator on Hurd -- similar to mounting a file system on UNIX
--- the new node(s) exported by the translator are obscuring the original node
-where the translator is set, and any nodes below it in the directory tree. The
-translator itself can access the underlying node (which is a very nice feature,
-as it allows translators presenting the contents of the node in a different
-format); but it's no longer accessible from the "outside".
-
-Plan9 has a feature where a file system can be mounted in union mode: the new
-file system doesn't obscure the mount point in this case, but instead the
-contents are combined. (This feature has also been under discussion in Linux
-for a couple of years now, under the label "VFS-based union mounts".)
-
-This kind of union mounts is generally useful, as it's sometimes more
-convenient than unioning existing filesystem locations with unionfs -- it's not
-necessary to mount a file system that is to be unioned at some external
-location first: just union-mount it directly at the target location.
-
-But union mounts also allow creating passive translator hierarchies: If there
-is a passive translator on a parent node, and further passive translators on
-child nodes, the union mount allows the child nodes with the further translator
-settings still to be visible after the parent translator has started.
-
-This could be useful for device nodes for example: let's say we have an
-ethernet multiplexer at /dev/veth. Now the virtual subnodes could all be
-directly under /dev, i.e. /dev/veth0, /dev/veth1 etc., and explicitely refer to
-the main /dev/veth node in the translator command line. It would be more
-elegant however to store the virtual nodes direcly below the main multiplexer
-node -- /dev/veth/0, /dev/veth/1 etc.
-
-There are two possible approaches how union mounts could be implemented in the
-Hurd. The first one is to let the various translators handle union mounts
-internally, i.e. let them present the underlying nodes to the clients in
-addition to the actual nodes they export themselfs. This probably can be
-implemented as some kind of extension to the existing netfs and diskfs
-libraries.
-
-The other possible apporach is less efficient and probably more tricky, but
-probably also more generic: create a special unionmount translator, which
-serves as a kind of proxy: setting the union-mounted translator on some
-internal node; and at the actual mount location, presenting a union of the
-nodes exported by this translator, and the nodes from the underlying file
-system.
-
-The goal of this project is implementing union mounts using either of the
-approaches described above. (Though it might be useful initially to prototype
-both for comparision.) The ethernet multiplexer shall serve as an example use
-case -- any changes necessary to allow using it with the union mount
-functionality are also to be considered part of the task.
+[[!meta redir=hurd/translator/unionmount]]
diff --git a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
index 8b6c4226..ff169b0a 100644
--- a/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
+++ b/community/weblogs/ArneBab/niches_for_the_hurd.mdwn
@@ -112,7 +112,13 @@ monologue at the end... I really should put these ideas into my blog.)"*
 
 Another example of features which would be easily possible with the Hurd: 
 
-* media-player translator: 
+* transparent ftp (already possible!):
+	- settrans -c ftp: /hurd/hostmux /hurd/ftpfs /
+	- ls ftp://ftp.gnu.org/
+	- # -> list the files on the FTP server.  
+
+
+* media-player translator:
  	- settrans play /hurd/mediaplayer_play
 	- cp song1.ogg song2.ogg play
 	- # -> files get buffered and played.
@@ -246,8 +252,8 @@ Applications
 A minor phase, which will surely be interleaved with the others: Making the ideas 
 tangible to turn them into ways how people can use the Hurd. 
 
-"Hey, look, this is the Hurd. You can use it like this to do that which you can't do 
-as well/easily/elegantly in any other way."
+*"Hey, look, this is the Hurd. You can use it like this to do that which you can't do 
+as well/easily/elegantly in any other way."*
 
 
 ### Applications for private use
@@ -264,18 +270,18 @@ it's too hard.
 
 From what I see, each direct cool application must be about as simple as 
 
-$ qemu hurd-is-cool.img
-$ login root
-$ settrans cool /hurd/cool
+$ qemu hurd-is-cool.img  
+$ login root  
+$ settrans cool /hurd/cool  
 $ ls cool
 
 One main focus in this example is: No command line parameters but the ones we 
 really need. No "-a", if the example is also cool without it. 
 No "--console" if it works otherwise. 
 
-Especially no "qemu --cd livecd --hda hurd.img ..." - that one is great for 
-specialists, but the goal here isn't to teach people better usage of qemu, 
-but to show them that the Hurd is cool, and only that. 
+Especially no *"qemu --cd livecd --hda hurd.img ..."* - that one is great for 
+people who already know qemu or want to learn it, but the goal here isn't to teach people 
+better usage of qemu, but to show them that the Hurd is cool, and only that. 
 
 All that interesting advanced stuff just gets newcomers confused. 
 
diff --git a/community/weblogs/antrik/hurd-mission-statement.mdwn b/community/weblogs/antrik/hurd-mission-statement.mdwn
new file mode 100644
index 00000000..592e176a
--- /dev/null
+++ b/community/weblogs/antrik/hurd-mission-statement.mdwn
@@ -0,0 +1,39 @@
+For a while I have been thinking about the lack of a roadmap for the
+Hurd; but now I realized that we lack something even more fundamental: a
+simple mission statement -- i.e. saying where we want to go, rather
+than how we want to get there. I think many of the problems we have are
+directly or indirectly related to that.
+
+As we didn't have such a mission statement so far, the people currently
+involved have vastly different ideas about the mission, which of course
+makes it a bit hard to come up with a suitable one now. However, I
+managed to come up with something that I believe is generic enough so
+all contributors can subscribe to it:
+
+>   *The mission of the Hurd project is: to create a general-purpose
+>   kernel suitable for the GNU operating system, which is viable for
+>   everyday use, and gives users and programs as much control over their
+>   computing environment as possible.*
+
+*"Suitable for GNU"* in the first part implies a number of things. I
+explicitely mentioned *"general-purpose"*, because this an important
+feature that sets the Hurd apart from many other microkernel projects,
+but isn't immediately obvious.
+
+I didn't mention that it must be entirely free software, as this should
+be obvious to anyone familiar with GNU.
+
+Another thing I did not mention, because it's too controversial: how
+much UNIX do we need? I think that being suitable for GNU requires a
+pretty high degree of UNIX compatibility, and also that the default
+environment looks to the user more or less like UNIX. However, some
+people claimed in the past that GNU could do without UNIX -- the wording
+used here doesn't totally preclude such views.
+
+The second part also leaves a lot of slack: I for my part still believe
+that a Mach-based Hurd can be viable for everyday use; but those who
+think that a microkernel change is required, should be happy with this
+wording as well.
+
+The third part tries to express the major idea behind the Hurd design in
+the most compact and generic way possible.