summaryrefslogtreecommitdiff
path: root/contributing/web_pages/news/2011-q2-ps.mdwn
blob: a6af80fb6950907f1aa9d2414bc679df9232b558 (plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]

[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

<!--
[[!meta date="2011-07-19 23:42 UTC"]]
-->

A quarter of the Hurd, Q2 of 2011, PS: *GNU Hurd Truths and Rumors*.
[[!if test="included()" then="""[[!toggle id=full_news
text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]"""
else="
[[!paste id=full_news]]"]]

[[!cut id="full_news" text="""

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
    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!

  * **Java support for GNU/Hurd is nearby**: Jérémie Koenig is working
    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

"""]]

<!--

slashdot

and phoronix did some [performance tests of the Hurd][phorperf], 
[phorperf]: http://www.phoronix.com/scan.php?page=article&item=debian_gnu_hurd&num=1

---

IRC, freenode, #hurd, 2011-08-24:

    < ArneBab> hurd related: I now think you were right, antrik: the hurd
      rumors don't belong into the news (tschwinge)
    < antrik> ArneBab: you mean the postscriptum as a whole, or just the wild
      rumours part?...
    < ArneBab> the whole PS
    < ArneBab> it should rather go into a blog post
    < ArneBab> (in the wiki)
    < antrik> hm... I don't think I agree
    < ArneBab> why?
    < antrik> apparently there is a number of people following the news now,
      and apparently many of them misread some statements... it makes sense to
      use the same channel for clarifying them I'd say
    < ArneBab> hm, ok
    < ArneBab> how would you select the part to include?
    < antrik> roughly speaking, I'd include everything that actually relates to
      the previous news that were misunderstood
    < antrik> and drop all unrelated speculations that popped up
    < antrik> BTW, it *might* be useful perhaps to actually update the original
      news posting with the clarifications?...
    < ArneBab> we can't do that without breaking some peoples RSS feeds
    < antrik> note that there is another aspect to consider: the fact that
      several news sites picked it up is indeed genuine news by itself...
    < ArneBab> that's right, yes
    < antrik> will it really break anything? from what I heard so far it just
      means they will see the posting as new again, which would actually make
      sense in this case...
    < antrik> but I don't insist if you think it's too risky :-)
    < antrik> just an idea

-->