Merge branch 'master' of 192.168.10.50:hurd-web

3 files changed, 47 insertions, 5 deletions

diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn
index 65ea4f0f..ad8ea2f8 100644
--- a/community/gsoc/project_ideas/driver_glue_code.mdwn
+++ b/community/gsoc/project_ideas/driver_glue_code.mdwn
@@ -64,7 +64,7 @@ To be able to work on the framework,
 the student will also have to get a good understanding of certain aspects of Hurd,
 such as memory management for example.
 
-Possible mentors: Samuel Thibault (youpi)
+Possible mentors: Zheng Da, Samuel Thibault (youpi)
 
 Exercise: Get one of the not yet integrated Linux network card drivers to work.
 (Note: This should be straightforward,
diff --git a/faq/which_microkernel/discussion.mdwn b/faq/which_microkernel/discussion.mdwn
new file mode 100644
index 00000000..9ef3b915
--- /dev/null
+++ b/faq/which_microkernel/discussion.mdwn
@@ -0,0 +1,33 @@
+This version mixes up three distinct phases: rewrite from scratch; redesign;
+own microkernel.
+
+While Okuji initially might have intended a direct port of the existing Hurd
+code, by the time I started following Hurd development (2004 IIRC), it has been
+long clear that Hurd/L4 is a rewrite from scratch.
+
+The next phase was the desire of Neal and especially Macrus to completely
+reinvent the design of the Hurd. This was mostly fueled by Shapiro's influence,
+resulting in a security-above-everything rage. It was in this phase that not
+only the original L4 has been abandonend, but also all thoughts about using
+newer L4 variants (which might have been suitable) were forsaken in favor of
+Shapiro's Coyotos.
+
+The whole idea of redesigning the Hurd -- especially for security concerns --
+is highly controversial: I always strongly objected to it; and Marcus later
+admitted himself that he got carried away and lost sight of what really matters
+for the Hurd. (But only after realising that Shapiro's notion of high security
+is fundamentally incompatible with the GNU philosophy.) I opted for not
+explicitely mentioning this aspect in the FAQ at all, as it's impossible to
+explain properly in a compact form, and probably impossible at all to do it in
+an objective fashion.
+
+The final phase -- following the realisation of incompatibility with
+Shapiro/Coyotos -- was the attempt to create new microkernels specifically for
+Hurd's needs. Marcus abandonned his pretty soon, and never made it public, so I
+didn't mention it at all; but Viengoos is still relevant in certain ways.
+
+BTW, my original text also more explicitely answers the question what happened
+to the Coyotos port -- which after all is what the title promises...
+
+All in all, I still think my text was better. If you have any conerns with it,
+please discuss them...
diff --git a/open_issues/pfinet.mdwn b/open_issues/pfinet.mdwn
index 8782fe08..7aadd736 100644
--- a/open_issues/pfinet.mdwn
+++ b/open_issues/pfinet.mdwn
@@ -10,9 +10,18 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_hurd]]
 
-IRC, #hurd
+In certain situations, pfinet spawns more and more threads,
+apparently without any bounds.
 
-pfinet explosion
+The thread creation happens in bursts rather than continuously.
+According to a backtrace in GDB,
+all the threads are functional and waiting for client requests.
+(The bursts are getting smaller as the number of threads rises,
+but probably only because the enormous number of existing threads
+slows down processing in general.)
 
-    <antrik> I reproduce it with freeciv client connected to a remote X server
-    <antrik> it suffices to run freeciv-gtk2, and clicking "new game"
+This can be triggered quite reliably by X clients running on the Hurd system,
+connected to an X server on another machine over TCP,
+and transferring fairly large amounts of data.
+The easiest way to reproduce it I found is launching freeciv-gtk2,
+pressing the "new game" button, and then simply waiting for a while.