5 files changed, 111 insertions, 20 deletions
diff --git a/faq/how_many_developers.mdwn b/faq/how_many_developers.mdwn
index a553df21..3c430ca4 100644
--- a/faq/how_many_developers.mdwn
+++ b/faq/how_many_developers.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 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
@@ -13,7 +13,7 @@ License|/fdl]]."]]"""]]
 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,
+former developers are still available 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
diff --git a/faq/posix_compatibility.mdwn b/faq/posix_compatibility.mdwn
index a54822c5..4490b7cb 100644
--- a/faq/posix_compatibility.mdwn
+++ b/faq/posix_compatibility.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 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
@@ -30,20 +30,3 @@ striving for total POSIX compliance -- and the high-level programs (that is,
 their users) may not even notice this, but we would avoid a lot of overhead
 that comes with wrapping the [[Hurd interfaces|hurd/interface]] to be POSIX
 compliant.
-
-
-\#hurd IRC channel on Freenode, 2010-12-21:
-
-    <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility
-      is not only for applications, but also for users familiar with the UNIX
-      environment
-    <antrik> also, I still don't buy the fact that most software is not written
-      for POSIX. even if assuming that GNOME programs don't use POSIX (which is
-      only half true), there is a lot of other software in a system that is
-      just as important, though less visible
-    <antrik> (server software, startup system, device management, automation,
-      ...)
-    <antrik> tschwinge: BTW, I meant to (and partially did) write a blog
-      article on this topic -- but I didn't get around to finish it...
-
-[[!tag open_issue_documentation]]
diff --git a/faq/posix_compatibility/discussion.mdwn b/faq/posix_compatibility/discussion.mdwn
new file mode 100644
index 00000000..0d722c9e
--- /dev/null
+++ b/faq/posix_compatibility/discussion.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2010, 2011 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_documentation]]
+
+\#hurd IRC channel on Freenode, 2010-12-21:
+
+    <antrik> tschwinge: the writeup ignores the fact that POSIX compatibility
+      is not only for applications, but also for users familiar with the UNIX
+      environment
+    <antrik> also, I still don't buy the fact that most software is not written
+      for POSIX. even if assuming that GNOME programs don't use POSIX (which is
+      only half true), there is a lot of other software in a system that is
+      just as important, though less visible
+    <antrik> (server software, startup system, device management, automation,
+      ...)
+    <antrik> tschwinge: BTW, I meant to (and partially did) write a blog
+      article on this topic -- but I didn't get around to finish it...
diff --git a/faq/smp.mdwn b/faq/smp.mdwn
new file mode 100644
index 00000000..e95edcd2
--- /dev/null
+++ b/faq/smp.mdwn
@@ -0,0 +1,28 @@
+[[!meta copyright="Copyright © 2009, 2011 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="Does GNU/Hurd support SMP/Multicore?"]]
+
+The Hurd servers themselves are multithreaded, so they should be able to take benefit of the parallelism brought by SMP/Multicore boxes. This has however never been tested yet because of the following.
+
+[[microkernel/Mach]] used to be running on SMP boxes like the [[!wikipedia
+Intel_iPSC/860]], so principally has the required infrastructure.  It has
+however not yet been enhanced to support nowadays' SMP standards like ACPI,
+etc.  Also, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue
+code likely isn't SMP-safe.  As this glue code layer is not used in the
+[[microkernel/mach/gnumach/ports/Xen]] port of GNU Mach, the plan is to try it
+in this enviroment first.
+
+[[!tag open_issue_gnumach open_issue_xen]]
+
+That is why for now GNU/Hurd will only use one logical processor (i.e. one core or one thread, depending on the socket type).
+
+Once this issue is solved, there are follow-up issues about
+[[open_issues/multiprocessing]] and [[open_issues/multithreading]].
diff --git a/faq/which_microkernel.mdwn b/faq/which_microkernel.mdwn
new file mode 100644
index 00000000..0852cf09
--- /dev/null
+++ b/faq/which_microkernel.mdwn
@@ -0,0 +1,55 @@
+[[!meta copyright="Copyright © 2009, 2011 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="What happened with the Hurd ports to the L4 / Coyotos / Viengoos
+microkernels?"]]
+
+<!-- This page shares some text with history/port_to_another_microkernel.  -->
+
+It is a frequently asked question, which microkernel the Hurd should be based
+upon assuming that [[microkernel/Mach]] is no longer considered state of the
+art, and it is well known that there has been a lot of discussion about this
+topic, and also some code produced, but then, years later, the Hurd is still
+based on [[GNU Mach|microkernel/mach/gnumach]].
+
+Around the turn of the millenium, some of the Hurd developers began
+experimenting with using other [[microkernel]]s for the Hurd, as they have been
+encountering a number of fundamental design issues with the [[Mach
+microkernel|microkernel/mach]], mostly with respect to
+[[open_issues/resource_management_problems]].
+
+At that time, L4 (Pistachio) was the prime candidate.  A reimplementation of
+the Hurd on this microkernel looked promising, and got pretty far (running some
+simple POSIX programs, such as `banner`).  However, over time some lingering
+design issues turned out to be fundamental problems: the original L4 is not
+suitable for building object-capability systems like the Hurd.  Thus
+development was aborted in 2005.
+
+During that process, Neal Walfield and Marcus Brinkmann started on a period of
+research on other microkernels, getting in deeper contact with other
+researchers.  There was a lot of discussion, and a lot of good ideas produced,
+but a straight-forward port of the Hurd to such a modern microkernel (Coyotos,
+or the new L4 variants, for example) didn't seem feasible to them anymore: they
+found microkernel design and system design to be interconnected in very
+intricate ways, and this demanded design changes in the Hurd's core itself.
+
+Based on this experience, the next step was to write an own microkernel
+instead, which Neal Walfield began doing with his experimental
+[[microkernel/Viengoos]] project, for his research on resource management.
+Currently he works in another research area though, and thus Viengoos is on
+hold.
+
+Note that while none of the microkernel research work is active now, the
+previous experiments already yielded a lot of experience, which will be very
+useful in the further development / improvement of the mainline (Mach-based)
+Hurd implementation.
+
+For more detauls about this topic, please see our history page about the
+[[history/port_to_another_microkernel]].