summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorArne Babenhauserheide <arne_bab@web.de>2011-09-01 23:35:43 +0200
committerArne Babenhauserheide <arne_bab@web.de>2011-09-01 23:35:43 +0200
commit195186ea111b1ceb54b2d4f095c5d0bb343a0022 (patch)
tree86bffd7cb1eb1a8dc1875b90af9d550e0fd6a662
parentd8bddde8e807591f2b45d5d084a50bffa6a7daad (diff)
news: worked on q2 ps a bit
-rw-r--r--news/2011-q2-ps.mdwn81
1 files changed, 50 insertions, 31 deletions
diff --git a/news/2011-q2-ps.mdwn b/news/2011-q2-ps.mdwn
index cbf039b0..752b7cd2 100644
--- a/news/2011-q2-ps.mdwn
+++ b/news/2011-q2-ps.mdwn
@@ -21,7 +21,7 @@ else="
[[!cut id="full_news" text="""
After our last *[[Quarter of the Hurd|2011-q2]]* has been picked up by a bunch
-of news sites, blogs, and so on, discussions have been running all over the
+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.
@@ -29,17 +29,10 @@ In the following, we try to clear the situation up a bit.
* *Debian wants to replace the Linux kernel with the GNU Hurd*. {X}
**Wrong**. 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 depends on a lot of factors, a lot of work is still to be done. If you
+ It mostly depends on a lot of work which is still to be done. If you
want to help, please see our [[contributing]] page and the *to do* list
- maintained on <http://wiki.debian.org/Debian_GNU/Hurd>.
-
- * *GNU Hurd developers want the Linux kernel to die*. {X}
- **Wrong**. All of us are happy users of the Linux kernel, every
- day, and GNU/Linux is the free operating system of choice, which
- we're using ourselves (unless sitting in front of a GNU/Hurd
- system). We work on the Hurd instead of Linux because of the
- [[additional capabilities and clean design|advantages]] it
- provides.
+ maintained on <http://wiki.debian.org/Debian_GNU/Hurd>.
+ We’d be happy to have you on board!
* *Java support for GNU/Hurd is in the works*. (./) **True**. Jérémie
Koenig is working on making a versatile Java programming environment
@@ -48,11 +41,12 @@ In the following, we try to clear the situation up a bit.
have support by the GCJ/ECJ platform, but this is not fully functional, and
Jérémie is improving that, too.
- * *GNU/Hurd has no support for X.org*. {X} **Wrong**. X.Org *does* work,
- and has 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.
+ * *GNU/Hurd has no support for X.org*. {X} **Wrong**. X.Org *does*
+ work, and has 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]].
[[tschwinge]] thinks that the following one is a bit questionable...
@@ -61,28 +55,53 @@ In the following, we try to clear the situation up a bit.
If you want to see if it works for you, just test a
[[hurd/running/Live_CD]].
-* *Hurd only supports legacy devices:* ½ Partly True: 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 no SMP:* <u>✔ **True**</u>: Even though 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.
-
-* *Developing a microkernel must be harder than developing a monolithic kernel, because the Hurd took so long:* ✘ **Wrong**: 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.
-
-* *Installation does not work:* ½ Partly True: Did you 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 which you could easily 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/GNU Hurd:* ✘ **Wrong**: 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.
+ * *Hurd only supports legacy devices:* ½ Partly True: 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 no SMP:* <u>✔ **True**</u>: 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.
+
+ * *Developing a microkernel must be harder than developing a
+ monolithic kernel, because the Hurd took so long:* ✘ **Wrong**:
+ 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.
+
+ * *Installation does not work:* ½ Partly True: Did you 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 which you could easily 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/GNU Hurd:* ✘ **Wrong**: 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.
+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:
+Some possible explanations include:
-* The tests were mostly CPU bound.
+* The tests were mostly CPU bound, so the kernel was not that
+ relevant.
* IPCs [are no more such a problem on recent hardware][ipc].
-And a non-explanation:
-
-* The emulation layer should rather make the context switches worse, so it’s likely not at play.
+Note: The emulation layer should rather make the context switches
+ worse, so it’s likely not a reason for the unexpectedly good
+ performance.
[ipc]: http://citeseer.ist.psu.edu/viewdoc/summary?doi=10.1.1.51.16