2011-q2-ps: Mass rewording

Reworked all of the text -- sometimes just rewording the sentences to
improve clarity, and (hopefully) make them sound more English; sometimes
slightly tweaking the statements; but also replacing some sections
entirely.

Fixed syntax of some links along the way.

1 files changed, 102 insertions, 71 deletions

diff --git a/contributing/web_pages/news/2011-q2-ps.mdwn b/contributing/web_pages/news/2011-q2-ps.mdwn
index a6af80fb..eb8c2c6e 100644
--- a/contributing/web_pages/news/2011-q2-ps.mdwn
+++ b/contributing/web_pages/news/2011-q2-ps.mdwn
@@ -12,7 +12,7 @@ License|/fdl]]."]]"""]]
 [[!meta date="2011-07-19 23:42 UTC"]]
 -->
 
-A quarter of the Hurd, Q2 of 2011, PS: *GNU Hurd Truths and Rumors*.
+A quarter of the Hurd, Q2 of 2011, PS: *GNU Hurd Truths and Myths*.
 [[!if test="included()" then="""[[!toggle id=full_news
 text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]"""
 else="
@@ -22,14 +22,18 @@ else="
 
 After our last *[[Quarter of the Hurd|news/2011-q2]]* has been picked up by a bunch
 of news sites, blogs, and so on, discussions have been running all over the
-net.  While we are happy to see that there obviously is quite some interest in
-the GNU Hurd, we also saw some rumors and outdated information flowing around.
-In the following, we try to clear the situation up a bit.
-
-  * **Debian GNU Hurd works to become a port in Debian**: We plan to
-    get into Wheezy as an additional port besides GNU/Linux and
-    GNU/kFreeBSD -- but we don't know whether we will make it.  It
-    mostly depends on a lot of work which is still to be done.  If you
+net.  <!-- probably good to link the actual articles? After this PS, we probably won't link them in the next regular news... -->
+We are happy to see that there is considerable interest in the Hurd;
+but we also saw some misunderstandings, false rumors, and outdated information floating around.
+Thus we will try to clarify the situation
+regarding some of the more common misunderstandings.
+
+  * **Debian GNU Hurd works to become a port in Debian**:
+    We plan to get into the next Debian release (Wheezy)
+    as an additional port alongside GNU/Linux and GNU/kFreeBSD --
+    but we don't know yet whether we will make it.
+    There is still substantial work necessary to indeed become a release candidate.
+    If you
     want to help, please see our [[contributing]] page and the *to do*
     list maintained on <http://wiki.debian.org/Debian_GNU/Hurd>.  We'd
     be happy to have you on board!
@@ -38,68 +42,95 @@ In the following, we try to clear the situation up a bit.
     on making a versatile Java programming environment available on
     the GNU/Hurd as part of his
     [[Google Summer of Code project|user/jkoenig/java]], focussing on
-    OpenJDK 7.  Also, we already do have support by the GCJ/ECJ
-    platform, but this is not fully functional, and Jérémie is
-    improving that, too.
-
-  * **GNU/Hurd supports X.org, though a bit unstable**: X.Org *does*
-    work, and has worked for a long time.  (Anyone remember
-    [1998's XFree86](http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/hurd/hurd_video.c?rev=1.1&content-type=text/vnd.viewcvs-markup),
-    by chance?)  It is correct however that not a lot of advanced
-    drivers work, due to missing DRM (Direct Rendering Manager)
-    support and that it is [[somewhat_unstable|hurd/status]].
-
-  * **The Hurd has weaker device support than Linux**: Currently most
-    drivers are from Linux 2.0. For network cards, Linux 2.6+ drivers
-    are available through DDE, though (needs manual setup for
-    now). With a good amount of work, DDE also allows porting other
-    classes of drivers to allow using the drivers from recent Linux
-    releases -- and push them into userspace.
-
-  * **The Hurd has SMP, but Mach needs drivers for new chipsets**: The
-    **Hurd servers support SMP** and **GNU Mach has SMP support**. But
-    the latter
-    [[does_not_yet_have_drivers_for_nowadays_chipsets|faq/smp]], so
-    the Hurd currently can't take advantage of multiple cores.
-
-  * **The good design of the Hurd allowed a tiny group of enthusiasts
-    to make it work**: For the last decade, the Hurd had on average 5
-    hobby developers. That these developers managed to get the Hurd
-    into a state where it actually gets not too far from the Linux
-    kernel in performance -- which has about 1000 developers, many of
-    them full time -- shows the efficiency of the Hurd's design.
-
-  * **Manual Installation is still challenging**: Please read the
-    [[README|http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/YES_REALLY_README.txt]]
-    ([[file|http://xkcd.com/293/]])? Just like any beta piece of
-    software, there are known pitfalls to avoid (or better, help to
-    fix). You can also simply use the the
-    [[preinstalled image|http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz]].
-
-  * **The system is called GNU**: The GNU userland (glibc, coreutils,
-    ...) and the GNU Hurd together form the GNU system. To avoid being
-    mistaken for GNU/Linux, we normally use the name GNU/Hurd or GNU
-    Hurd. The *correct* name is simply GNU.
-
-**Test results**
-
-The results of the test from Phoronix were quite good. We expected
-that the microkernel design of the Hurd would have a far more severe
-performance hit. 
-
-Some possible explanations include: 
-
-* The tests were mostly CPU bound, so the kernel was not that
-  relevant.
-* IPCs [are no more such a problem on recent hardware][ipc].
-
-Note: The emulation layer should rather make the context switches
-  worse, so it's likely not a reason for the unexpectedly good
-  performance.
-
-We hope to see more tests like that in the future!
-
-[ipc]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.16
+    OpenJDK 7 --
+    [partially working packages](http://jk.fr.eu.org/debian/experimental/)
+    are already available.
+    He also implemented GCJ/ECJ support,
+    though this is not yet fully functional either.
+    <!-- Is this correct? What is the actual status? -->
+
+  * **GNU/Hurd supports X.Org, though a bit unstable**:
+    X support has been present for ages
+    (anyone remember
+    [1998's XFree86](http://cvsweb.xfree86.org/cvsweb/xc/programs/Xserver/hw/xfree86/os-support/hurd/hurd_video.c?rev=1.1&content-type=text/vnd.viewcvs-markup)?);
+    and X.Org also has been supported for a long time.
+    (It's even mentioned in the
+    [X.Org 7.2 release announcement](http://www.x.org/wiki/Other/Press/X11R72Released?action=show&redirect=PressReleases%2FX11R72Released).)
+    It is true though that many modern drivers do not work anymore,
+    as they require DRM (Direct Rendering Manager) support now;
+    so often only VESA is available.
+    Also, X on the Hurd is [[somewhat_unstable|hurd/status]].
+
+  * **The Hurd has weaker device support than Linux**:
+    Most of the drivers we use today were imported from Linux 2.0.x.
+    For network cards,
+    Linux 2.6.29 drivers are available through [[DDE|hurd/dde]] --
+    however, this is not fully integrated yet,
+    so using these drivers needs manual setup for now.
+    Support for other driver types is also possible with DDE,
+    but it requires some not-trivial work for each additional class of drivers --
+    so this can take some time to become available.
+    (An additional provided by DDE is that the device drivers run in userspace --
+    unlike the old drivers we were using so far,
+    which are part of the underlying Mach microkernel.)
+
+  * **The Hurd has SMP, but needs support for new chipsets**:
+    Both Mach (the microkernel used by the Hurd),
+    and the Hurd servers themselves come with SMP support.
+    However, Mach [[misses drivers for modern SMP chipsets|faq/smp]];
+    and there are also some SMP-related bugs in the implementation --
+    so further work is needed
+    for the Hurd to take advantage of modern multicore processors.
+
+  * **Given the available manpower, the progress is very good**:
+    Over the past decade,
+    there were seldom more than half a dozen developers at any given time
+    hacking on the Hurd, in their spare time --
+    not hundreds of paid developers like Linux has.
+    Considering this, the progress made is quite encouraging;
+    with the system being [[pretty usable|hurd/status]] for many day-to-day tasks now.
+    It is generally understood that the ambitious architecture of the Hurd
+    required a lot of effort to get it working at all --
+    but the recent progress shows that once the foundations are in place,
+    the Hurd design indeed allows the developers to be very productive.
+
+  * **Installation can still be challenging**:
+    Please [[take notice|http://xkcd.com/293/]] of the
+    [README file](http://people.debian.org/~sthibault/hurd-i386/installer/cdimage/YES_REALLY_README.txt) --
+    just like with any software in development,
+    there are some known pitfalls to avoid.
+    (Or better yet, help to fix :-) )
+    Alternatively, you can simply use the the
+    [preinstalled image](http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img.tar.gz).
+
+  * **GNU Hurd is not the same as GNU/Hurd**:
+    The GNU project set out in 1983 to create a complete free operating system.
+    When a distribution such as Debian combines their GNU-based userland
+    with the GNU kernel (named `GNU Hurd`),
+    the result is more or less a full GNU system.
+    However, such third-party distributions are distinct
+    from what an afficial complete GNU system release would be;
+    and thus we often call them `GNU/Hurd`
+    (in contrast to `GNU/Linux` or `GNU/kFreeBSD`) for clarity.
+
+  * **Performance**:
+    The [benchmarks conducted by Phoronix](http://www.phoronix.com/scan.php?page=article&item=debian_gnu_hurd&num=1)
+    attested very good performance to the Hurd.
+    Keep in mind though that these benchmarks were almost completely CPU-bound;
+    so they essentially just confirm that we don't do anything stupid
+    regarding CPU intialisation. (Cache setup etc.)
+    The results would be different for benchmarks
+    that actually exercise the operating system functionality more.
+    The fact that the tests were performed in a virtualised environment,
+    might also have helped the results,
+    for example by mitigating the effects of our unoptimized I/O paths --
+    which are currently the major bottleneck in most situations.
+    Nevertheless, these results are a hint
+    that the extra IPC required in microkernel systems
+    [doesn't necessarily hamper performace](http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.16)
+    quite as much as often believed.
+    We are glad to see such solid benchmarks
+    help dispell some of the myths around the Hurd :-)
 
 """]]