diff options
Diffstat (limited to 'community')
| -rw-r--r-- | community/gsoc.mdwn | 9 | ||||
| -rw-r--r-- | community/gsoc/project_ideas/unionmount.mdwn | 55 | ||||
| -rw-r--r-- | community/weblogs/ArneBab/niches_for_the_hurd.mdwn | 24 | ||||
| -rw-r--r-- | community/weblogs/antrik/hurd-mission-statement.mdwn | 39 |
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. |