Talk about advantages, challenges, how many developers, why so few developers.

10 files changed, 165 insertions, 91 deletions

diff --git a/hurd/advantages.mdwn b/advantages.mdwn
index 254e33f6..18e6506b 100644
--- a/hurd/advantages.mdwn
+++ b/advantages.mdwn
@@ -6,8 +6,8 @@ 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]]."]]"""]]
 
 The GNU Hurd has a number of enticing features:
 
@@ -16,9 +16,9 @@ terms of the [[GNU General Public License (GPL)|GPL]].
 
 It's compatible as it provides a familiar programming and user environment.
 For all intents and purposes, the Hurd provides the same facilities as a modern
-Unix-like kernel.  The Hurd uses the [[GNU C Library|glibc]], whose development
-closely tracks standards such as ANSI/ISO, BSD, POSIX, Single Unix, SVID, and
-X/Open.
+[[Unix]]-like kernel.  The Hurd uses the [[GNU C Library|glibc]], whose
+development closely tracks standards such as ANSI/ISO, BSD, POSIX, Single Unix,
+SVID, and X/Open.
 
 Unlike other popular kernel software, the Hurd has an object-oriented structure
 that allows it to evolve without compromising its design.  This structure will
@@ -32,15 +32,17 @@ of the components that constitute the whole kernel are running as separate
 user-space processes and are thus using different address spaces that are
 isolated from each other.  This is a multi-server design based on a
 [[microkernel]].  It is not possible that a faulty memory dereference inside
-the [[TCP/IP stack|translator/pfinet]] can bring down the whole kernel, and
-thus the whole system, which is a real problem in a monolothic Unix kernel
+the [[TCP/IP stack|hurd/translator/pfinet]] can bring down the whole kernel,
+and thus the whole system, which is a real problem in a monolothic Unix kernel
 architecture.
 
 One advantage of the Hurd's separation of kernel-like functionality into
-separate components ([[servers|translator]]) is that these can be constructed
-using different programming lanugages -- a feature that is not easily possible
-in a monolithic kernel.  Essentially, only an interface from the programming
-environment to the [[RPC]] mechanism is required.
+separate components ([[servers|hurd/translator]]) is that these can be
+constructed using different programming lanugages -- a feature that is not
+easily possible in a monolithic kernel.  Essentially, only an interface from
+the programming environment to the [[RPC]] mechanism is required.  (We have a
+[[project proposal|community/gsoc/project_ideas/language_bindings]] for this,
+if you're interested.)
 
 <!-- This is a bit questionable...
 
@@ -64,4 +66,6 @@ administrator.
 
 The Hurd is real software that works right now.  It is not a research project
 or a proposal.  You don't have to wait at all before you can [[start
-using|running]] and [[developing|contributing]] it.
+using|hurd/running]] and [[developing|contributing]] it.
+
+<!-- add stuff from hurd-talk.html -->
diff --git a/hurd/challenges.mdwn b/challenges.mdwn
index 640b95c9..5368ae4e 100644
--- a/hurd/challenges.mdwn
+++ b/challenges.mdwn
@@ -8,9 +8,14 @@ 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]]."]]"""]]
 
-<!-- Should this page, and [[advantages]] be in the top-level directory?  -->
-
 The GNU Hurd has a lot of [[advantages]], but there are challenges, too.
 
-There is no successful true multi-server [[microkernel]] system for desktop use
-yet.  Though, they are quite popular in the simpler embedded space.
+Even though they're quite popular in the simpler embedded space, there is no
+successful true multi-server [[microkernel]] system for general-purpose desktop
+use yet.  This is still an ongoing research effort.  (TODO: add references.)
+
+Likewise, resource scheduling in distributed operating system kernels is a
+research topic.  For example, read more about it on the relevant [[Open Issues
+page|open_issues/multiprocessing]].
+
+TODO: more to come.  [[!tag open_issue_documentation]]
diff --git a/community/gsoc/project_ideas/language_bindings.mdwn b/community/gsoc/project_ideas/language_bindings.mdwn
index 460b380b..c8a02390 100644
--- a/community/gsoc/project_ideas/language_bindings.mdwn
+++ b/community/gsoc/project_ideas/language_bindings.mdwn
@@ -20,7 +20,7 @@ However, in practice this is not as easy as it should, because creating
 translators and other servers is quite involved -- the interfaces for doing
 that are not exactly simple, and available only for C programs. Being able to
 easily create simple translators in RAD languages is highly desirable, to
-really be able to reap the advantages of the Hurd architecture.
+really be able to reap the [[advantages]] of the Hurd architecture.
 
 Originally Lisp was meant to be the second system language besides C in the GNU
 system; but that doesn't mean we are bound to Lisp. Bindings for any popular
diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn
new file mode 100644
index 00000000..a553df21
--- /dev/null
+++ b/faq/how_many_developers.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!meta title="How many developers are working on the GNU Hurd?"]]
+
+Not many.  One handful work on it in their free time, and another two
+handful do help with [[Debian GNU/Hurd|hurd/running/debian]] and
+[[hurd/running/Arch_Hurd]] packaging.  Also, an additional handful of
+former developers are still availble for answering technical questions,
+but are not really participating in the current development anymore.
+
+For reaching out to new developers, we're participating in [[Google's
+Summer of Code program|community/gsoc]].  Likewise, any interested party
+(*you*!) are very welcome to start [[contributing]].  Mentoring is
+possible, too, to help you get started.
+
+Continue reading some speculation about [[why so few developers]] are working
+on the GNU Hurd.
diff --git a/faq/why_so_few_developers.mdwn b/faq/why_so_few_developers.mdwn
new file mode 100644
index 00000000..a2740abc
--- /dev/null
+++ b/faq/why_so_few_developers.mdwn
@@ -0,0 +1,27 @@
+[[!meta copyright="Copyright © 2010 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]]."]]"""]]
+
+[[!meta title="Why are there so few developers working on the GNU
+Hurd?"]]
+
+[[There aren't working a lot of people on the GNU
+Hurd|how_many_developers]].  Why is this?
+
+We can only speculate.  One major problem might be that the
+[[architectural benefits|advantages]] are generally perceived as very
+abstract, with little practical benefits.  We don't have many tools to
+present actually making use of the possibilities.
+
+Another reason is that it's been taking too long.  Most people don't
+believe it will ever be ready for production use, and thus would consider
+involvement a waste of time.  This latter point is invalid, of course, as
+learning can never be a waste of time.  The same holds for the
+[[challenges]] raised by the GNU Hurd -- we can only learn and improve
+upon working on them.
diff --git a/index.mdwn b/index.mdwn
index 249b2091..9520a438 100644
--- a/index.mdwn
+++ b/index.mdwn
@@ -31,7 +31,7 @@ computing environment as possible.
 
 ---
 
-[[!toc]]
+[[!toc levels=2]]
 
 
 ## News
@@ -122,6 +122,12 @@ For more details, please read our writeup on the
 [[current_state_of_the_GNU_Hurd|hurd/status]]. 
 
 
+### Advantages and Challenges
+
+The GNU Hurd operating system design provides [[advantages]], but uncovers new
+[[challenges]], too.
+
+
 ## How is this site arranged?
 
 The menu on the upper right corner provides a rough structuring about the
diff --git a/open_issues/benefits.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
index da1248c8..34e49e86 100644
--- a/open_issues/benefits.mdwn
+++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
@@ -11,60 +11,61 @@ License|/fdl]]."]]"""]]
 [[!tag open_issue_documentation]]
 
 What are the benefits of a native GNU/Hurd system, now that Linux et al. can do
-so much (think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux,
-etc.).
+so much? Think [[hurd/translator]]s: FUSE, [[hurd/subhurd]]s: User-Mode-Linux
+and other virtualization techiques, and so on.
 
 It is possible to begin [[implementing_Hurd_on_top_of_another_system]], but...
 
 IRC, #hurd, August / September 2010
 
     <marcusb> ArneBab: but Neal and I were not happy with that alone.  We were
-      looking for deeper improvements to the system, for, I think, sound reasons.
-      That is what brought us to the L4/Coyotos technologies
-    <marcusb> ArneBab: as you are writing a kernel in user space, you can still do
-      kernel improvements there
-    <marcusb> ArneBab: if you take it very far, you end up with a kernel that runs
-      Linux in user space (just flip the two) for the drivers
+      looking for deeper improvements to the system, for, I think, sound
+      reasons.  That is what brought us to the L4/Coyotos technologies
+    <marcusb> ArneBab: as you are writing a kernel in user space, you can still
+      do kernel improvements there
+    <marcusb> ArneBab: if you take it very far, you end up with a kernel that
+      runs Linux in user space (just flip the two) for the drivers
     <marcusb> ArneBab: that is what the L4 people did with the DDE
 
 ([[DDE]])
 
     <marcusb> ArneBab: so, with these different cuts, there are different
-      opportunities.  on the one end, you can run Linux as normal and get some of
-      the Hurd features such as translators in some programs.  At the other end,
-      you can do whatever you want and run some linux code for the drivers or none
-      at all.
-    <marcusb> ArneBab: one of the big questions then becomes: at which point can
-      the advantages offered by the Hurd be realized?
+      opportunities. on the one end, you can run Linux as normal and get some
+      of the Hurd features such as translators in some programs.  At the other
+      end, you can do whatever you want and run some linux code for the drivers
+      or none at all.
+    <marcusb> ArneBab: one of the big questions then becomes: at which point
+      can the advantages offered by the Hurd be realized?
     <marcusb> ArneBab: and that's not entirely clear to me
-    <marcusb> when I worked on this with Neal, we pushed further and further into
-      need-to-change-everything land
-    <marcusb> while the current efforts on the Hurd seem to be more equivalent to
-      the could-run-it-in-userspace-on-top-of-Linux camp
-    <ArneBab> marcusb: for that I think we need a way to move towards them step by
-      step. Would it be possible to get the advantages of better resource
+    <marcusb> when I worked on this with Neal, we pushed further and further
+      into need-to-change-everything land
+    <marcusb> while the current efforts on the Hurd seem to be more equivalent
+      to the could-run-it-in-userspace-on-top-of-Linux camp
+    <ArneBab> marcusb: for that I think we need a way to move towards them step
+      by step. Would it be possible to get the advantages of better resource
       allocation with a Viengoos in userspace, too?
     <ArneBab> and when that is stable, just switch over?
-    <marcusb> ArneBab: I don't know.  I suspect these people will know before us:
-      http://lxc.sourceforge.net/
-    <ArneBab> something like implementing flip points: flip Linux with Hurd to Hund
-      with Linux. Flip Mach with L4 to L4 with Mach.
+    <marcusb> ArneBab: I don't know.  I suspect these people will know before
+      us: http://lxc.sourceforge.net/
+    <ArneBab> something like implementing flip points: flip Linux with Hurd to
+      Hund with Linux. Flip Mach with L4 to L4 with Mach.
     <ArneBab> lxc sounds interesting.
     <marcusb> note that these efforts address security concerns more than other
       concerns
     <marcusb> so they will get isolation long before sharing is even considered
     <marcusb> but some of the issues are the same
-    <marcusb> once you allow malware to do what it wants, it's a small step to also
-      allow the user to what he wants :)
+    <marcusb> once you allow malware to do what it wants, it's a small step to
+      also allow the user to what he wants :)
     <ArneBab> it kinda looks like hacking it where it doesn’t really fit again…
-    <ArneBab> there I ask myself when the point comes that doing a cleaner design
-      offsets the popularity
+    <ArneBab> there I ask myself when the point comes that doing a cleaner
+      design offsets the popularity
     <ArneBab> they are pushing more and more stuff into userspace
     <ArneBab> which is a good thing (to me)
-    <ArneBab> it’s hard to clearly describe how, but even though I like having more
-      stuff in userspace, the way it is bolted onto Linux doesn’t feel good for me.
-    <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to a
-      non-fuse user
+    <ArneBab> it’s hard to clearly describe how, but even though I like having
+      more stuff in userspace, the way it is bolted onto Linux doesn’t feel
+      good for me.
+    <ArneBab> FUSE is cool, but if I use it, I am at a disadvantage compared to
+      a non-fuse user
     <ArneBab> while in the Hurd, these additional options are on eqal footing.
     <marcusb> ArneBab: are they pushing more and more into user space?  I don't
       think so.  I see more of the reverse, actually
@@ -74,13 +75,13 @@ IRC, #hurd, August / September 2010
     <ArneBab> to avoid flickering when switching between X and the console?
     <ArneBab> marcusb: Do you experience FUSE lxc and such being secondclass in
       Linux, too, or is that just a strange feeling of me?
-    <ArneBab> marcusb: and that splits the users into those who can get stuff into
-      the kernel and those who can only work in userspace – which I don’t really
-      like.
-    <ArneBab> That’s one more advantage of the Hurd: eqal footing for all (except
-      the Mach hackers, but they have a very limited terrain)
-    <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have a
-      principled objection to it (but just wanted a more general solution)
-    <marcusb> ArneBab: as a side note, although people keep complaining, the linux
-      kernel seems to be growing steadily, so getting stuff into the kernel doesn't
-      seem too hard.  8-O
+    <ArneBab> marcusb: and that splits the users into those who can get stuff
+      into the kernel and those who can only work in userspace – which I don’t
+      really like.
+    <ArneBab> That’s one more advantage of the Hurd: eqal footing for all
+      (except the Mach hackers, but they have a very limited terrain)
+    <marcusb> ArneBab: but UML kernel module is minimal, and Linus didn't have
+      a principled objection to it (but just wanted a more general solution)
+    <marcusb> ArneBab: as a side note, although people keep complaining, the
+      linux kernel seems to be growing steadily, so getting stuff into the
+      kernel doesn't seem too hard.  8-O
diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
index 1d7a1e50..7e88e322 100644
--- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn
+++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
@@ -21,8 +21,8 @@ IRC, #hurd, August / September 2010
 
     <marcusb> silver_hook: the Hurd can also refer to the interfaces of the
       filesystems etc, and a lot of that is really just server/client APIs that
-      could be implemented on any system that has transferable rights to message
-      capabilities.
+      could be implemented on any system that has transferable rights to
+      message capabilities.
     <marcusb> silver_hook: it's surprising how few systems *have* transferable
       rights, though!
     <marcusb> silver_hook: usually it is added as an afterthought
@@ -33,23 +33,24 @@ IRC, #hurd, August / September 2010
     <marcusb> youpi: it's described in the Stevens series even
     [...]
     <marcusb> ArneBab: well, let me put it this way.  the Linux kernel has no
-      interface to manipulate another tasks's virtual address space, ie you can't
-      map/unmap stuff in another process
-    <marcusb> ArneBab: you would have to use ptrace and load some stub code in that
-      process to make that happen.
-    <marcusb> ArneBab: so for complete transparent manipulation, you need a kernel
-      module
+      interface to manipulate another tasks's virtual address space, ie you
+      can't map/unmap stuff in another process
+    <marcusb> ArneBab: you would have to use ptrace and load some stub code in
+      that process to make that happen.
+    <marcusb> ArneBab: so for complete transparent manipulation, you need a
+      kernel module
     <marcusb> that is what the User Mode Linux kernel module does
-    <marcusb> ArneBab: so say you use the User Mode Linux kernel module for that
-      one feature.  Then you can do everything that User Mode Linux can do, which,
-      I assure you, includes running subhurds :)
+    <marcusb> ArneBab: so say you use the User Mode Linux kernel module for
+      that one feature.  Then you can do everything that User Mode Linux can
+      do, which, I assure you, includes running subhurds :)
     <marcusb> it can be a bit tricky to implement those features, but it is not
       harder than writing a kernel in the first place
-    <ArneBab> So, if I got an admin to install User Mode Linux and Mach emulation,
-      I’d get the flexibility (and independence from admin decisions) I have in the
-      Hurd?
-    <marcusb> ArneBab: one problem is that you still use Linux.  For those who want
-      to get rid of Linux for political reasons, that would mean complete failure
+    <ArneBab> So, if I got an admin to install User Mode Linux and Mach
+      emulation, I’d get the flexibility (and independence from admin
+      decisions) I have in the Hurd?
+    <marcusb> ArneBab: one problem is that you still use Linux.  For those who
+      want to get rid of Linux for political reasons, that would mean complete
+      failure
     <marcusb> ArneBab: if you have UML kernel module, you can implement Mach in
       user space
     <marcusb> ArneBab: in fact, John Tobey did this a couple of years ago, or
@@ -57,10 +58,10 @@ IRC, #hurd, August / September 2010
 
 ([[tschwinge]] has tarballs of John's work.)
 
-    <marcusb> ArneBab: or you can just implement parts of it and relay to Linux for
-      the rest
-    <marcusb> the point is, that if you don't care for kernel improvements, and are
-      sufficiently happy with the translator stuff, it's not hard to bring the Hurd
-      to Linux or BSD
+    <marcusb> ArneBab: or you can just implement parts of it and relay to Linux
+      for the rest
+    <marcusb> the point is, that if you don't care for kernel improvements, and
+      are sufficiently happy with the translator stuff, it's not hard to bring
+      the Hurd to Linux or BSD
 
-(Continue: [[benefits]].)
+Continue reading about the [[benefits of a native Hurd implementation]].
diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn
index 7b4f2611..224c0826 100644
--- a/open_issues/multiprocessing.mdwn
+++ b/open_issues/multiprocessing.mdwn
@@ -11,7 +11,7 @@ License|/fdl]]."]]"""]]
 [[!tag open_issue_hurd]]
 
 We would expect that fine-grained, compartmentalized systems, that is,
-microkernel-based multi-server systems in particular, would be ideal condidates
+microkernel-based multi-server systems in particular, would be ideal candidates
 for applying multiprocessing.  That is, however, only true from a first and
 inexperienced point of view: there are many difficulties.
 
@@ -19,14 +19,14 @@ inexperienced point of view: there are many difficulties.
 IRC, #hurd, August / September 2010
 
     <marcusb> silver_hook: because multi-server systems depend on inter-process
-      communication, and inter-process communication is many times more expensive
-      across cpus
-    <marcusb> silver_hook: so you either force interrelated work on the same cpu,
-      or suffer heavy penalties.  and in a typical fine-grained object system, all
-      objects are interconnected!
-    <marcusb> silver_hook: resources in today's systems, even in a single node with
-      one cpu, but more so in a network, are very non-uniform.  scheduling these
-      resources efficiently is a huge problem.  restricting the resource
+      communication, and inter-process communication is many times more
+      expensive across cpus
+    <marcusb> silver_hook: so you either force interrelated work on the same
+      cpu, or suffer heavy penalties.  and in a typical fine-grained object
+      system, all objects are interconnected!
+    <marcusb> silver_hook: resources in today's systems, even in a single node
+      with one cpu, but more so in a network, are very non-uniform.  scheduling
+      these resources efficiently is a huge problem.  restricting the resource
       distribution policies in the way microkernel systems tend to do is posing
       serious research challenges
 
diff --git a/tag.mdwn b/tag.mdwn
index e96e88d5..6051de3b 100644
--- a/tag.mdwn
+++ b/tag.mdwn
@@ -23,6 +23,11 @@ Most of them should be self-explanatory.
     GNU/Hurd|hurd/running/debian]] distribution, but not yet in the upstream
     sources.
 
+  * *open_issue_documentation*
+
+    Use for tagging pages / items that need to be handled / improved for
+    documentation purposes.
+
   * *open_issue_porting*
 
     A list of open issues in porting software to run on GNU/Hurd systems.  This