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

3 files changed, 75 insertions, 73 deletions

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