Merge commit 'bdb5476b45b43e1753514fe28d1be9436dd572bd'

3 files changed, 159 insertions, 1 deletions

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)