summaryrefslogtreecommitdiff
path: root/contributing/web_pages/news
diff options
context:
space:
mode:
Diffstat (limited to 'contributing/web_pages/news')
-rw-r--r--contributing/web_pages/news/2011-q2-ps.mdwn79
1 files changed, 49 insertions, 30 deletions
diff --git a/contributing/web_pages/news/2011-q2-ps.mdwn b/contributing/web_pages/news/2011-q2-ps.mdwn
index 8931cbb8..778caf2d 100644
--- a/contributing/web_pages/news/2011-q2-ps.mdwn
+++ b/contributing/web_pages/news/2011-q2-ps.mdwn
@@ -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 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/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