From 472760ace3750cd013a1e5d6af42290600ee0a29 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 5 Oct 2011 10:49:14 +0200 Subject: 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. --- contributing/web_pages/news/2011-q2-ps.mdwn | 173 ++++++++++++++++------------ 1 file changed, 102 insertions(+), 71 deletions(-) (limited to 'contributing/web_pages') 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. +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 . 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. + + + * **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 :-) """]] -- cgit v1.2.3