summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorantrik <antrik@users.sf.net>2011-10-05 10:49:14 +0200
committerantrik <antrik@users.sf.net>2011-10-05 10:49:14 +0200
commit472760ace3750cd013a1e5d6af42290600ee0a29 (patch)
tree366b262f81f69185c83e99d3653c3aabcaf3c623
parent39fc110979d8d2a0002fadb89eb6b7a77e7f4586 (diff)
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.
-rw-r--r--contributing/web_pages/news/2011-q2-ps.mdwn173
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 :-)
"""]]