Merge commit 'bdb5476b45b43e1753514fe28d1be9436dd572bd'

5 files changed, 221 insertions, 6 deletions

diff --git a/community/gsoc.mdwn b/community/gsoc.mdwn
index 6eece956..efd29841 100644
--- a/community/gsoc.mdwn
+++ b/community/gsoc.mdwn
@@ -57,13 +57,27 @@ subprojects.
 -->
 
 
-# Applying for a Task
+Applications for 2012 are closed.
 
-<!--
+# Accepted projects
 
-Applications for 2011 are closed.
+## Disk I/O Performance Tuning
 
--->
+by Maksym Planeta
+
+See the project's
+[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/mcsim/46002).
+
+## Virtualization Using Hurd Mechanisms
+
+by Pierre Thierry
+
+See the project's
+[public page](http://www.google-melange.com/gsoc/project/google/gsoc2012/nowhereman/36001)
+and [[complete proposal|gsoc/2012/virt/proposal]].
+
+
+# Possible projects
 
 We have a list of [[project_ideas]], and students are likewise encouraged to
 submit their own project proposals.  Please follow our
@@ -86,7 +100,6 @@ with Hurd development, even outside of the GSoC context.  Please don't hesitate
 to contact us regarding mentoring even if it's not GSoC time at the moment, or
 if you aren't a student anyway.
 
-
 # History
 
 In 2006 and [[2007]], we participated in GSoC under the umbrella of the GNU
diff --git a/community/gsoc/2012/virt/proposal.mdwn b/community/gsoc/2012/virt/proposal.mdwn
new file mode 100644
index 00000000..d89f45d5
--- /dev/null
+++ b/community/gsoc/2012/virt/proposal.mdwn
@@ -0,0 +1,95 @@
+[[!meta title="Original proposal"]]
+
+*This is the proposal as it has been submitted to Google Summer of
+Code.*
+
+# The name of the project
+
+Virtualization Using Hurd Mechanisms
+
+# Summary
+
+The goal is to create tools that let a user create a set of servers
+that implement a Hurd environment and the necessary resources, with
+the possibility of relying on existing servers in the parent Hurd for
+some of them, instead of creating them.
+
+# Benefits
+
+This project will permit to create isolated systems but with far more
+flexibility than traditional virtualization tools, because the degree
+of isolation can be changed and possibly not only at creation time,
+and communication and sharing of subsystems can be arranged between
+isolated systems.
+
+# Deliverables
+
+D1 — User stories for the toolset, that will later serve as examples
+for the documentation
+
+D2 — Exhaustive but concise documentation of the set of needed servers
+making a working Hurd system (as much for me as for future users of
+the tool, building and linking to existing Hurd documentation)
+
+D3 — Low-level tool to create a working Hurd environment (possibly
+with strong limitations on the shape of the resources used by the
+environment, most probably on the underlying filesystem)
+
+D4 — Fake or noop servers for the documented set of needed servers, to
+be provided instead of working ones, where a feature is to be denied
+to a Hurd environnement
+
+D5 — Proxy servers, where desirable, to provide access to servers
+outside the environment (in ocaps terminology, caretakers)
+
+D6 — Extension of the low-level tool from D3 to remove its
+unreasonable limitations
+
+D7 — High-level tools to easily create environments and run programs
+in them (akin respectively to debootstrap and schroot)
+
+D8 — If possible, extensions to the D5 and D7 tools to enable dynamic
+modifications of the features and authority granted to environments
+and creation of multiple interconnected environments
+
+# Plan
+
+I intend to develop using the Scrum method, with sprints of two weeks,
+which mean that each two weeks, I will present at least one new
+working feature, working incrementally towards the full deliverable. I
+will also push my code at least once a day to a public Git hosting,
+including topic branches, so my progress can be followed easily.
+
+I intend to start from crosshurd and see how I can hook in its process
+of creation to allow being provided alternatives. Depending on how
+crosshurd is malleable to those changes, a modified crosshurd will
+either be a learning-stage prototype or the base of the
+implementation.
+
+To reuse Git terminology, once plumbing tools (i.e. tools that take
+detailed invocation information for each server) are working fine,
+I'll move on to porcelain tools, the final UI (i.e. tools that provide
+sensible default options, aliases mechanisms, etc.).
+
+# Communication
+
+I'm usually easy to reach through both email and jabber, so those and
+IRC will be my main way to inform my mentor and ask questions. I'll
+setup an ikiwiki to have a summary of the exchanges and the temporary
+documentation of the project (i.e. documentation that doesn't fit with
+the code yet).
+
+# Qualification
+
+Thansk to or because of my participation to the Hurd mailing lists,
+I've been utterly contaminated by the concept of POLA a few years
+ago. Since then, I've been longing, almost in a painful way, for a
+object-capability flavour of Debian. Having to deal in my previous day
+jobs with virtualization tools like Xen and VMWare when I knew there
+would be no need for paravirtualization or emulation to isolate
+systems in an object-capability OS only made it worst.
+
+Now most of the code I produce naturally becomes capability oriented,
+even if my underlying platform, programming language or OS, doesn't
+provide true capabilities. And creating true POLA systems and making
+it possible for others to benefit from POLA is now one of my dreams.
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 5d42b5c6..8ce10ffa 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -98,7 +98,6 @@ other: language_bindings, gnat, gccgo, perl_python.  -->
 [[!inline pages="community/gsoc/project_ideas/secure_chroot" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/package_manager" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/download_backends" show=0 feeds=no actions=yes]]
-[[!inline pages="community/gsoc/project_ideas/libgtop" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/maxpath" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/gnat" show=0 feeds=no actions=yes]]
 [[!inline pages="community/gsoc/project_ideas/gccgo" show=0 feeds=no actions=yes]]
diff --git a/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn
new file mode 100644
index 00000000..befd680a
--- /dev/null
+++ b/community/gsoc/project_ideas/namespace-based_translator_selection/discussion.mdwn
@@ -0,0 +1,64 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+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]]."]]"""]]
+
+[[!tag open_issue_hurd]]
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+    <youpi> btw, I was wondering, when working on namespace mangling, did they
+      think about automatitioning ?
+    <youpi> autopartitioning, I meant
+    <youpi> i.e. with a foo.img file, open foo.img,,part1
+    <braunr> what are you referring to with namespace mangling
+    <youpi> and voila
+    <youpi> I don't remember the exact term they used
+    <braunr> you mean there is a hurd library that parses names and can direct
+      to different services depending on part of the name ?
+    <youpi> namespace-based_translator_selection
+    <youpi> yes
+    <braunr> i thought it only handled directories
+    <braunr> well, the classical path representation
+    * civodul finds it ugly
+    <youpi> civodul: because of potential conflict, and the not-too-nice ",,"
+      part?
+    <youpi> actually I wonder whether using directory access would be nicer
+    <youpi> i.e. you have a foo.gz, just open foo.gz/gunzip to get the unzipped
+      content
+    <youpi> and for foo.img.gz, open foo.img.gz/gunzip/part/1
+    <civodul> youpi: because of the interpretation of special chars in file
+      names
+    <civodul> users should be free to use any character they like in file names
+    <civodul> foo.gz/gunzip looks nicer to me
+    <youpi> ok, so we agree
+    <youpi> that said, the user could choose the separator
+    <youpi> the namespace can be not run by root for everybody, but just for
+      your shell, run by yourself
+    <antrik> civodul: the user can't use any character anyways... '/' and '\0'
+      are reserved :-P
+    <civodul> antrik: '/' isn't quite reserved on the Hurd :-)
+    <civodul> you could implement dir_lookup such that it does something
+      special about it
+    <civodul> (server-side)
+    <antrik> civodul: as for overloading '/', although I haven't thought it
+      through entirely, I guess that would work for nodes that present as files
+      normally. however, it would *not* work for directory nodes
+    <antrik> which would be quite a serious limitation IMHO
+    <antrik> I can think of various kinds of useful directory translators
+    <antrik> what's more, one of the main use cases I originally had in mind is
+      a policy filter
+    <antrik> you could pass a directory name with a appropriate filter applied
+      to tar for example, so it wouldn't try to follow any translators
+    <antrik> I don't see why taking an obscure prefix like ,, would be much of
+      a problem in practice anyways
+    <antrik> (also, it doesn't strictly prevent the user from having such file
+      names... you just need to escape it if accessing such files through the
+      namespace multiplexer. though admittedly that would need some special
+      handling in *some* programs to work properly)
diff --git a/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn b/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn
new file mode 100644
index 00000000..87b1f07d
--- /dev/null
+++ b/community/weblogs/ArneBab/how-i-write-a-qoth.mdwn
@@ -0,0 +1,44 @@
+I just read on the hurd IRC channel (chat: #hurd at irc.freenode.net), that people consider my work valuable (I knew that, and I think that myself, but it is still nice to hear), so I want to dispell any possible myth about it :)
+
+What I do is not hard - at least not anymore, since I created a simple structure for it (But it still takes time).
+
+First I open up the relevant mailing lists for the quarter. I get them from [[contributing/web_pages/news/writing_the_qoth]]. Normally I just use the following:
+
+* <http://lists.gnu.org/archive/html/bug-hurd/YYYY-MM/threads.html>
+* <http://lists.debian.org/debian-hurd/YYYY/MM/>
+
+Then I copy them 3 times and use M-x replace-string (in emacs) to adjust them to the correct months.
+
+Additionally I open the Arch Hurd news:
+
+* <http://www.archhurd.org/news.php>
+* <http://planet.archhurd.org/>
+
+Having all those news at hand, I read every thread-starter and every news-item. For each of them I first check if I understand them (no use trying to explain something I don’t get myself) and if they provide a way for people to test what they improved (however complex that might be), then I 
+
+* note the name of the main contributor(-s), 
+* write a line of text what it does (often partly copied from the news-item),
+* add a link to the news-item, a code-repo or a patch and
+* a note how that new development helps achieve the goals_of_the_Hurd (see [[contributing/web_pages/news/writing_the_qoth]] for details).
+
+With that list of short news I go into [[contributing/web_pages/news/qoth_next]]. 
+
+Now I identify 2 to 4 main news items by some kind of “helps the Hurd most when more people know it”, “biggest change” and similar fudgery :)
+
+Finally I sort all the news items by intuition, crude logic I develop on-the-fly writing and the goal of making the qoth read somewhat like nice prose. 
+
+On the way to that I commit every little to medium step. I never know when I have to abort due to an interruption (I’m sure tschwinge loves my super-non-atomic horrible-to-review commits :-) - but better that than losing work == time, and I try to prefix the commit-messages with “news:” so he knows that it’s useless to review them as in-flight-patches…).
+
+Having finished the text (usually after 3 to 6 hours of overall work), I send it by mail to bug-hurd: <http://lists.gnu.org/archive/html/bug-hurd/>
+
+After about a week I incorporate the comments from there and publish the qoth as described in [[contributing/web_pages/news/writing_the_qoth]].
+
+Then tschwinge reviews it, does some last-minute changes and pushes it from the staging wiki to the website.
+
+And that’s it.
+
+I hope this small insight was interesting to you. Happy hacking and have fun with the Hurd!
+
+-- Arne Babenhauserheide
+
+PS: Writing this blog entry took about 20 minutes. The raw text is longer than a qoth, but it is much faster to write, because it avoids the main time-eater: Gathering the info with the necessary references to make sure that people can test what’s in here.