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
|
[[!meta copyright="Copyright © 2001, 2002, 2008, 2010 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]]."]]"""]]
The GNU Hurd has a number of enticing features:
It's free software, so anybody can use, modify, and redistribute it under the
terms of the [[GNU General Public License (GPL)|GPL]].
It's compatible as it provides a familiar programming and user environment.
For all intents and purposes, the Hurd provides the same facilities as a modern
[[Unix]]-like kernel. The Hurd uses the [[GNU C Library|glibc]], whose
development closely tracks [[standards such as ANSI/ISO, BSD, POSIX, Single
Unix, SVID, and X/Open|faq/posix_compatibility]].
Unlike other popular kernel software, the Hurd has an object-oriented structure
that allows it to evolve without compromising its design. This structure will
help the Hurd undergo major redesign and modifications without having to be
entirely rewritten.
The Hurd is built in a very modular fashion. Other Unix-like kernels (Linux,
for example) are also modular in that they allow loading (and unloading) some
components as kernel modules, but the Hurd goes one step further in that most
of the components that constitute the whole kernel are running as separate
user-space processes and are thus using different address spaces that are
isolated from each other. This is a multi-server design based on a
[[microkernel]]. It is not possible that a faulty memory dereference inside
the [[TCP/IP stack|hurd/translator/pfinet]] can bring down the whole kernel,
and thus the whole system, which is a real problem in a monolothic Unix kernel
architecture.
One advantage of the Hurd's separation of kernel-like functionality into
separate components ([[servers|hurd/translator]]) is that these can be
constructed using different programming languages -- a feature that is not
easily possible in a monolithic kernel. Essentially, only an interface from
the programming environment to the [[RPC]] mechanism is required. (We have a
[[project proposal|community/gsoc/project_ideas/language_bindings]] for this,
if you're interested.)
<!-- This is a bit questionable...
It's scalable. The Hurd implementation is aggressively multithreaded so that
it runs efficiently on both single processors and symmetric multiprocessors.
The Hurd interfaces are designed to allow transparent network clusters
(*collectives*), although this feature has not yet been implemented.
See also [[unsorted/hurd-migr]] ([[!taglink open_issue_documentation]]).
-->
The Hurd is an attractive platform for learning how to become a kernel hacker
or for implementing new ideas in kernel technology. Every part of the system
is designed to be easily modified and extended.
It is possible to develop and test new Hurd kernel components without rebooting
the machine. Running your own kernel components doesn't interfere with other
users, and so no special system privileges are required. The mechanism for
kernel extensions is secure by design: it is impossible to impose your changes
upon other users unless they authorize them or you are the system
administrator.
The Hurd is real software that works right now. It is not a research project
or a proposal. You don't have to wait at all before you can [[start
using|hurd/running]] and [[developing|contributing]] it.
<!-- add stuff from hurd-talk.html -->
|
