summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorThomas Schwinge <tschwinge@gnu.org>2008-11-05 09:30:58 +0100
committerThomas Schwinge <tschwinge@gnu.org>2008-11-05 09:30:58 +0100
commit40fdc9bd87b5a67caafcaaf366479b6ac0f0a9b2 (patch)
tree5d2df92cf4be8c52c3bd35bc8b2c865ba906934b
parent516e7d2203c2f9b2b45b64232705e12c6f6f31b9 (diff)
parentcc62748b7ef1f26c543ee3dea4af0a1fa43078ed (diff)
Merge branch 'master' of kepler:tmp/hurd-homepage_to_git/converted.2.r into homepage
-rw-r--r--acknowledgements.html110
-rw-r--r--auth.html248
-rw-r--r--byte-letter.txt25
-rw-r--r--changelogs.html194
-rw-r--r--devel.html159
-rw-r--r--docs.html302
-rw-r--r--download.html140
-rw-r--r--gnumach-download.html189
-rw-r--r--gnumach-install.html131
-rw-r--r--gnumach.html180
-rw-r--r--help.html167
-rw-r--r--history.html199
-rw-r--r--howto/subhurd.html89
-rw-r--r--hurd-and-linux.html104
-rw-r--r--hurd-announce47
-rw-r--r--hurd-announce2143
-rw-r--r--hurd-announcements.html114
-rw-r--r--hurd-flash22
-rw-r--r--hurd-flash1025
-rw-r--r--hurd-flash1125
-rw-r--r--hurd-flash1276
-rw-r--r--hurd-flash13120
-rw-r--r--hurd-flash1462
-rw-r--r--hurd-flash1560
-rw-r--r--hurd-flash2152
-rw-r--r--hurd-flash377
-rw-r--r--hurd-flash4101
-rw-r--r--hurd-flash523
-rw-r--r--hurd-flash646
-rw-r--r--hurd-flash717
-rw-r--r--hurd-flash873
-rw-r--r--hurd-flash939
-rw-r--r--hurd-folks.html78
-rw-r--r--hurd-fs-org219
-rw-r--r--hurd-l4.html174
-rw-r--r--hurd-migr141
-rw-r--r--hurd-name.html53
-rw-r--r--hurd-paper.html812
-rw-r--r--hurd-talk.html1151
-rw-r--r--hurd.html224
-rw-r--r--install.html126
-rw-r--r--mig-download.html167
-rw-r--r--mig.html125
-rw-r--r--old_hurd_faq.html318
-rw-r--r--related-projects.html131
-rw-r--r--whatis/translator.html290
-rw-r--r--whatsnew.html300
-rw-r--r--whatsold.html558
48 files changed, 8326 insertions, 0 deletions
diff --git a/acknowledgements.html b/acknowledgements.html
new file mode 100644
index 00000000..dec8c4b6
--- /dev/null
+++ b/acknowledgements.html
@@ -0,0 +1,110 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+
+<HTML>
+ <HEAD>
+ <TITLE>GNU&nbsp;Hurd: Acknowledgements</TITLE>
+ <LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+ </HEAD>
+
+<BODY BGCOLOR="#000000" LINK="#8888EE" VLINK="#9F00DD" ALINK="#000088">
+<IMAGE SRC="/graphics/hurd_sm_mf_invert.jpg">
+<TABLE width="100%" border="0" cellspacing="0" cellpadding="20">
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<A HREF="hurd.html#contents"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+<P>
+<!---A HREF="mirrors.html#contents">Mirrors</A><BR--->
+<A HREF="acknowledgements.html#contents">Acknowledgements</A><BR>
+<!---A HREF="copyright.html#contents">Copyright Notice</A--->
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP" TEXT="#000000" BGCOLOR="#FFFFFF">
+<A NAME="contents"><H1>Acknowledgements</H1></A>
+
+<P>We wish a warm ``Thank GNU'' to everybody who has helped in the
+development of the Hurd. Here is a categorized list of people who
+made significant contributions. If we have omitted anybody, we
+apologize... please let us know so that we can update this list!
+
+<DL>
+<DT>Hurd software</DT>
+<DD><DL>
+ <DT>Mark Kettenis</DT>
+ <DD>many GNU C library and Hurd bug fixes and updates</DD>
+ <DT>Miles Bader</DT>
+ <DD>paid by the FSF to help make the Hurd usable as a standalone system,
+ wrote several important translators</DD>
+ <DT>OKUJI Yoshinori</DT>
+ <DD>many gnumach bug fixes and updates</DD>
+ <DT>Roland McGrath</DT>
+ <DD>paid by the FSF to design and implement the GNU C library for the Hurd,
+ as well as many Hurd features, current Hurd C library maintainer</DD>
+ <DT>Thomas Bushnell, BSG (formerly Michael I. Bushnell)</DT>
+ <DD>paid by the FSF as primary architect of the Hurd, current Hurd maintainer</DD>
+ <DT>UCHIYAMA Yasushi</DT>
+ <DD>ported XFree86 to the Hurd</DD>
+ </DL></DD>
+
+<DT>Debian GNU/Hurd</DT>
+<DD><DL>
+ <DT>Gordon Matzigkeit</DT>
+ <DD>paid by the FSF as a liason from GNU to Debian</DD>
+ <DT>Marcus Brinkmann</DT>
+ <DD>bootstrapped the Debian GNU/Hurd base set and many packages, liason
+ from Debian to GNU</DD>
+ <DT>Santiago Vila</DT>
+ <DD>support for cross-compiling Debian packages</DD>
+ </DL></DD>
+
+<DT>Documentation</DT>
+<DD><DL>
+ <DT>Derek Upham</DT>
+ <DD>wrote the original GNU&nbsp;Hurd FAQ</DD>
+ <DT>Gordon Matzigkeit</DT>
+ <DD>reorganized and updated the GNU&nbsp;Hurd Reference Manual for release 0.3</D
+D>
+ <DT>Matthew C. Vernon</DT>
+ <DD>wrote the ``Idiot's Guide'' for getting started with the Hurd</DD>
+ <DT>Matthias Pfisterer</DT>
+ <DD>reorganized and updated the web site in early 1999</DD>
+ <DT>Stephen L. Favor</DT>
+ <DD>current FAQ maintainer</DD>
+ <DT>Trent Fisher</DT>
+ <DD>wrote the original version of the Hurd pages</DD>
+ </DL></DD>
+</DL>
+
+<HR>
+
+Return to <A HREF="/home.html" TARGET="_parent">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo" TARGET="_parent">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1999, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.<P>
+Updated:
+<!-- hhmts start -->
+30 Nov 1999 gord
+<!-- hhmts end -->
+<HR>
+</TD>
+</TR>
+</TABLE>
+
+</BODY>
+</HTML>
diff --git a/auth.html b/auth.html
new file mode 100644
index 00000000..676442ee
--- /dev/null
+++ b/auth.html
@@ -0,0 +1,248 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+ <A HREF="/software/hurd/auth.html">English</A>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#intro" NAME="TOCintro">Introduction</A>
+ <LI><A HREF="#ids" NAME="TOCids">How IDs are represented and used</A>
+ <LI><A HREF="#posix" NAME="TOCposix">POSIX and beyond</A>
+ <LI><A HREF="#servers" NAME="TOCservers">Related servers</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCintro" NAME="intro">Introduction</A></H3>
+<P>
+In this text, which mostly resembles the talk I gave at Libre Software
+Meeting 2002 in Bordeaux, I will describe what the auth server does,
+why it is so important and which cool things you can do with it, both
+on the programming and the user side. I will also describe related
+programs like the password and fakeauth servers. Note that this text
+is targeted at programmers who want to understand the auth mechanism
+in detail and are already familiar with concepts like Remote Procedure
+Calls (RPCs) as well as the way User- and Group-IDs are used in the
+POSIX world.
+
+<P>
+The auth server is a very small server, therefore it gives a useful
+example when you want to learn how a server typically looks like. One
+reason why it is so small is that the auth interface, which it
+implements, consists of only four RPCs. You can find the interface in
+hurd/hurd/auth.defs and the server itself in hurd/auth/.
+
+<H3><A HREF="#TOCids" NAME="ids">How IDs are represented and used</A></H3>
+<P>
+Each process holds (usually) one port to auth (an auth_t in C source,
+which actually is a mach_port_t, of course). The purpose of auth is
+to manage User-IDs and Group-IDs, which is the reason why users often
+will have no choice but to make use of the systems main auth server,
+which does not listen on /servers/auth; instead you inherit a port to
+auth from your parent process. Each such port is (internally in the
+auth server) associated with a set of effective User- and Group-IDs as
+well as a set of available User- and Group-IDs. So we have four sets
+of IDs in total. The available IDs can be turned into corresponding
+effective IDs at any time.
+
+<P>
+When you send an auth_getids RPC on the port you hold, you will get
+information about which IDs are associated with it, so you can figure
+out which permissions you have. But how will a server know that you
+have these permissions and therefore know which actions (e.g. writing
+into file "foo") it is supposed to do on your behalf and which not?
+The establishing of a trusted connection to a server works as follows:
+
+<P><OL>
+<LI>A user wants a server to know its IDs</LI>
+<LI>The user requests a reauthentication from the server</LI>
+<LI>In this request the user will include a port</LI>
+<LI>Both will hand this port to auth</LI>
+<LI>The user uses auth_user_authenticate</LI>
+<LI>The server uses auth_server_authenticate</LI>
+<LI>The server also passes a new port to auth</LI>
+<LI>auth matches these two requests</LI>
+<LI>The user gets the new port from auth</LI>
+<LI>The server learns about the IDs of the user</LI>
+<LI>The user uses the new port for further communication</LI>
+</OL>
+
+<P>
+We have different RPCs for users and servers because what we pass and
+what we get back differs for them: Users get a port, and servers get
+the sets of IDs, and have to specify the port which the user will get.
+
+<P>
+It is interesting to note that auth can match the requests by
+comparing two integers, because when you get the same port from two
+people, you will have the same mach_port_t (which is nothing but an
+integer).
+
+<P>
+All of this of course only works if they use the same auth server,
+which is why I said often you have no choice other than to use the
+one main auth server. But this is no serious restriction, as the auth server has
+almost no functionality one might want to replace. In fact, there is
+one replacement for the default auth implementation, but more on that
+later.
+
+<H3><A HREF="#TOCposix" NAME="posix">POSIX and beyond</A></H3>
+<P>
+Before we examine what is possible with this design, let us take a
+short look at how the POSIX semantics are implemented on top of this
+design. When a program that comes out of POSIX-land asks for its own
+effective User- or Group-ID, we will tell it about the first of the
+effective IDs. In the same sense, the POSIX real User- or Group-ID is
+the first available ID and the POSIX saved User- or Group-ID is the
+second available ID, which is why you have the same ID two times in
+the available IDs when you log into your GNU/Hurd machine (you can
+figure out which IDs you have with the program "ids", that basically
+just does an auth_getauth RPC). When you lack one of those IDs (for
+example when you have no effective Group-ID), a POSIX program asking
+for this particular information will get "-1" as the ID.
+
+<P>
+But as you can imagine, we can do more than what POSIX specifies. Fox
+example, we can modify our permissions. This is always done with the
+auth_makeauth RPC. In this RPC, you specify the IDs that should be
+associated with the new port. All of these IDs must be associated
+with either the port where the RPC is sent to or one of the additional
+ports you can specify; an exception is the superuser root, which is
+allowed to creat ports that are associated with arbitrary IDs.
+Hereby you can convert available into effective IDs.
+
+<P>
+This opens the door to a bunch of nice features. For example, we have
+the addauth program in the Hurd, which makes it possible to add an ID
+to either a single process or a group of processes if you hold the ID or know the
+appropriate password, and there is a corresponding rmauth program that
+removes an ID. So when you are working on your computer with GNU
+Emacs and want to edit a system configuration file, you switch to
+Emacs' shell-mode, do an "addauth root", enter the password, edit the
+file, and when you are done switch back to shell-mode and do "rmauth
+root". These programs have some interesting options, and there are
+various other programs, for setting the complete list of IDs (setauth)
+and so on.
+
+<H3><A HREF="#TOCservers" NAME="servers">Related servers</A></H3>
+<P>
+Finally, I want to explain two servers which are related to auth. The
+first is the password server, which listens on /servers/password. If
+you pass to it a User- or Group-ID and the correct password for it, it
+will return a port to auth to you which is associated with the ID you
+passed to it. It can create such a port because it is running as
+root. So let us assume you are an FTP server process. You will start
+as root, because you want to use port 21 (in this case, "port" does
+not refer to a mach_port_t, of course). But then, you can drop all
+your permissions so that you run without any ID. This makes it far
+less dangerous to communicate with yet unknown users over the
+network. But when someone now hands a username and password to you,
+you can ask the password server for a new auth port. The password
+server will check the data you pass to it, for example by looking into
+/etc/shadow, and if it is valid, it will ask the auth server for a new
+port. It receives this port from auth and then passes it on to you.
+So you have raised your permissions. (And for the very curious: Yes,
+we are well aware of the differences between this concept and
+capabilities; and we also do have some kinds of capabilities in
+various parts of the Hurd.)
+
+<P>
+My second example is the fakeauth server. It also implements the auth
+protocol. It is the part of the fakeroot implementation that gives a
+process the impression that it runs as root, even if it doesn't. So
+when the process asks fakeauth about its own IDs, fakeauth will tell
+the process that it runs as root. But when the process wants to make
+use of the authentication protocol described earlier in this text,
+fakeauth will forward the request to its own auth server, which will
+usually be the systems main auth server, which will then be able to
+match the auth_*_authenticate requests. So what fakeauth does is
+acting as a proxy auth server that gives someone the impression to run
+as root, while not modifying what that one is allowed to do.
+
+<P>
+At this point, I have said at least most of what can be said about the
+auth server and the protocol it implements, so I will finish by saying
+that it might be an interesting task (for you) to modify some existing
+software to take advantage of the features I described here.
+
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+ <A HREF="/software/hurd/auth.html">English</A>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2002 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/byte-letter.txt b/byte-letter.txt
new file mode 100644
index 00000000..20fa61a0
--- /dev/null
+++ b/byte-letter.txt
@@ -0,0 +1,25 @@
+Byte magazine published this in the `Letters' section
+of the March '96 issue:
+
+ Where's the GNU Hurd?
+
+ The November 1995 articles "NT Roars
+ on the 604" and "CPU scorecards" were
+ quite welcome. But the Special Report on
+ operating systems did not mention GNU
+ Hurd. This OS is based on the Mach mi-
+ crokernel, and thus it has been essentially
+ ported to a wide variety of hardware plat-
+ forms--nearly as many as NetBSD. To
+ learn more about the Hurd, and especially
+ about its binary portability, visit http://
+ www.cs.pdx.edu/~trent/gnu/hurd/. Con-
+ trary to what you say in the text box "Op-
+ erating-System Research: Dim or Bright
+ Future?" (page 116), microkernel tech-
+ nology has not been exploited to its max-
+ imum capability, as the Hurd philosophy
+ demonstrates.
+
+ Todd Hutchinson
+ jasper@terra.3rdplanet.com
diff --git a/changelogs.html b/changelogs.html
new file mode 100644
index 00000000..5eb70e22
--- /dev/null
+++ b/changelogs.html
@@ -0,0 +1,194 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/changelogs.html">English</A>
+| <A HREF="/software/hurd/changelogs.eo.html">Esperanto</A>
+| <a href="/software/hurd/changelogs.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3>ChangeLogs</H3>
+<P>
+As the Hurd sources are kept and maintained in a CVS repository that
+is accessible via the web, you can follow the progress of development
+closely. We maintain ChangeLogs, in which we record every change to
+the source code at the time it is committed. The links below lead you
+directly to the ChangeLog files in the Hurd and its associated packages.
+<P>
+If you want to follow the development of the Hurd closely, we suggest
+that you subscribe to the <A
+HREF="http://lists.gnu.org/mailman/listinfo/commit-hurd/">commit-hurd mailing
+list</A> to which notifications about changes to the Hurd source code
+are sent. The <A HREF="/software/hurd/download.html">complete source
+code</A> is also available, of course.
+</P>
+<H4>The Hurd</H4>
+<P>
+The Hurd source tree contains many independent parts, and therefore
+has one ChangeLog for each directory. There is one <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ChangeLog">ChangeLog
+in the main directory</A>, and one in each of the following
+subdirectories:
+</P>
+<UL>
+<LI>Translators and other servers:
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/auth/ChangeLog">auth</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/exec/ChangeLog">exec</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ext2fs/ChangeLog">ext2fs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ftpfs/ChangeLog">ftpfs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/hostmux/ChangeLog">hostmux</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/init/ChangeLog">init</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/isofs/ChangeLog">isofs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/mach-defpager/ChangeLog">mach-defpager</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/nfs/ChangeLog">nfs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/nfsd/ChangeLog">nfsd</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/pfinet/ChangeLog">pfinet</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/pflocal/ChangeLog">pflocal</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/proc/ChangeLog">proc</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/storeio/ChangeLog">storeio</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/term/ChangeLog">term</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/tmpfs/ChangeLog">tmpfs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/trans/ChangeLog">trans</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ufs/ChangeLog">ufs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/usermux/ChangeLog">usermux</A>
+<LI>Utilities:
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/benchmarks/ChangeLog">benchmarks</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/boot/ChangeLog">boot</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/bsdfsck/ChangeLog">bsdfsck</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/fstests/ChangeLog">fstests</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/sutils/ChangeLog">sutils</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ufs-fsck/ChangeLog">ufs-fsck</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ufs-utils/ChangeLog">ufs-utils</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/utils/ChangeLog">utils</A>
+<LI>Boot code and system programs:
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/login/ChangeLog">login</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/config/ChangeLog">config</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/daemons/ChangeLog">daemons</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/serverboot/ChangeLog">serverboot</A>
+<LI>Release scripts and packaging:
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/debian/ChangeLog">debian</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/release/ChangeLog">release</A>
+<LI>Documentation:
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/doc/ChangeLog">doc</A>
+<LI>Interface definitions:
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/hurd/ChangeLog">hurd</A>
+<LI>Support libraries:
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libdiskfs/ChangeLog">libdiskfs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libfshelp/ChangeLog">libfshelp</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libftpconn/ChangeLog">libftpconn</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libhurdbugaddr/ChangeLog">libhurdbugaddr</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libihash/ChangeLog">libihash</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libiohelp/ChangeLog">libiohelp</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libnetfs/ChangeLog">libnetfs</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libpager/ChangeLog">libpager</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libpipe/ChangeLog">libpipe</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libports/ChangeLog">libports</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libps/ChangeLog">libps</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libshouldbeinlibc/ChangeLog">libshouldbeinlibc</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libstore/ChangeLog">libstore</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libthreads/ChangeLog">libthreads</A>,
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libtrivfs/ChangeLog">libtrivfs</A>
+</UL>
+<H4>GNU&nbsp;Mach</H4>
+The <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog">GNU
+Mach ChangeLog</A> covers all changes to GNU&nbsp;Mach and <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog?rev=1.128.2">GNU
+Mach 1 branch ChangeLog</A> those on the <SAMP>gnumach-1-branch</SAMP>.
+Changes before March 1997 are listed in <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog.0">ChangeLog.0</A>
+and <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog.00">ChangeLog.00</A>.
+<H4>MIG</H4>
+The <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/mig/ChangeLog">MIG ChangeLog</A>
+covers all changes to MIG.
+
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/changelogs.html">English</A>
+| <A HREF="/software/hurd/changelogs.eo.html">Esperanto</A>
+| <a href="/software/hurd/changelogs.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2006 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/devel.html b/devel.html
new file mode 100644
index 00000000..2a31f959
--- /dev/null
+++ b/devel.html
@@ -0,0 +1,159 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/devel.html">en</A>
+| <A HREF="/software/hurd/devel.eo.html">eo</A>
+| <a href="/software/hurd/devel.es.html">es</a>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#contrib" NAME="TOCcontrib">Contributing</A>
+ <li><a href="#machinery" name="TOCmachinery">Machinery: getting access to a
+ system</a>
+ <LI><A HREF="#tasks" NAME="TOCtasks">Tasks</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCcontrib" NAME="contrib">Contributing</A></H3>
+<P>
+If you want to contribute to the Hurd, you should first install and
+use it for a while, to become familiar with its features and design.
+To join the development team, subscribe to the
+<a href="http://lists.gnu.org/mailman/listinfo/bug-hurd">Bug-Hurd</a>
+<a href="mailto:bug-hurd@gnu.org">&lt;bug-hurd@gnu.org&gt;</a>
+mailing list, which is also the place where you can announce your
+intentions, make your proposals and send in your patches.
+(You can also send mail there without being subscribed to the list.)
+<P>
+There is also the <a
+href="http://lists.gnu.org/mailman/listinfo/hurd-devel-readers">
+Hurd-devel-readers</a>
+mailing list. It is the read-only version of Hurd-devel, an internal
+low-volume list restricted to the core developers of the Hurd. If you
+want to follow up on the discussion of the Hurd experts, please reply
+to the Bug-hurd mailing list. You can also follow the Hurd-devel
+mailing list by browsing the <A
+HREF="http://lists.gnu.org/archive/html/hurd-devel/">web-based archive of
+Hurd-devel</A>.
+
+<h3><a href="#TOCmachinery" name="machinery">Machinery: getting access to a
+system</a></h3>
+<p>
+There are essentially two possibilities: either you install the GNU/Hurd on a
+system (see <a href="/software/hurd/install.html">here</a>) or if you don't
+have a system to install it on, you can be provided with a shell account. See
+<a href="http://www.bddebian.com/~wiki/public_hurd_boxen">this wiki page</a>
+for details.
+
+<H3><A HREF="#TOCtasks" NAME="tasks">Tasks</A></H3>
+<P>
+Developing an operating system is a huge job, with a lot of different
+things to do. To be able to keep track of issues, we use a
+<ul>
+ <li><a
+ href="http://savannah.gnu.org/bugs/?func=browse&set=open&group=hurd">bug
+ tracker</a> to register and comment on bugs, a
+ <li><a
+ href="http://savannah.gnu.org/task/?func=browse&set=open&group=hurd">task
+ tracker</a> for tasks people could work on and a
+ <li><a
+ href="http://savannah.gnu.org/patch/?func=browse&set=open&group=hurd">patch
+ tracker</a> where people can install their patches.
+</ul>
+There is also an older (but still valid) list of specific items in the
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/tasks?rev=HEAD&content-type=text/plain">task file</A>
+and in the
+<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/TODO?rev=HEAD&content-type=text/plain">TODO file</A>
+of the Hurd source repository.
+
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/devel.html">en</A>
+| <A HREF="/software/hurd/devel.eo.html">eo</A>
+| <a href="/software/hurd/devel.es.html">es</a>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2006, 2007
+Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/docs.html b/docs.html
new file mode 100644
index 00000000..9c3a43f1
--- /dev/null
+++ b/docs.html
@@ -0,0 +1,302 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<meta http-equiv="content-type" content="text/html; charset=utf-8">
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/docs.html">English</A>
+| <A HREF="/software/hurd/docs.eo.html">Esperanto</A>
+| <a href="/software/hurd/docs.es.html">Spanish</a>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <li><a href="#papers" name="TOCpapers">Introductory material, papers and
+ other informational documents</a>
+ <LI><A HREF="#faq" NAME="TOCfaq">Frequently asked questions</A>
+ <li><a href="#wiki" name="TOCwiki">Wiki</a>
+ <LI><A HREF="#manuals" NAME="TOCmanuals">Reference manuals</A>
+</UL>
+<HR>
+
+<h3><a href="#TOCpapers" name="papers">Introductory material, papers and other
+informational documents</a></h3>
+<P>
+<UL>
+
+<LI>
+<A HREF="hurd-paper.html">Towards a New Strategy of OS Design</A>, an
+architectural overview by Thomas Bushnell, BSG.
+
+<LI>
+<A HREF="hurd-talk.html">The Hurd</A>, a presentation by Marcus
+Brinkmann.
+
+<LI>
+<A HREF="/software/hurd/users-guide/using_gnuhurd.html" NAME="UsersGuide">
+GNU/Hurd User's Guide</A>, an introduction to the important
+concepts and software of the GNU system, written for new
+users, AKA "GNUbies."
+<P>
+Available Formats:
+<UL>
+<LI>
+<A HREF="/software/hurd/users-guide/using_gnuhurd.html">HTML version</A> for
+browsing online.
+<LI>
+<A HREF="/software/hurd/users-guide/using_gnuhurd.ps">PostScript version [477kB, 67 pages]</A>
+for download.
+<LI>
+<A HREF="/software/hurd/users-guide/using_gnuhurd.txt">ASCII text version [154kB]</A>.
+<LI>
+<A HREF="/software/hurd/users-guide/using_gnuhurd.texi">Texinfo source [155kB]</A>.
+</UL>
+
+<LI>
+<A HREF="/software/hurd/hacking-guide/hhg.html">The Hurd Hacking
+Guide</A>, an introduction to GNU&nbsp;Hurd and Mach programming by
+Wolfgang J&auml;hrling.
+<P>
+Available Formats:
+<UL>
+<LI>
+<A HREF="/software/hurd/hacking-guide/hhg.html">HTML version</A> for
+browsing online.
+<LI>
+<A HREF="/software/hurd/hacking-guide/hhg.ps">PostScript version [187kB, 37 pages]</A>
+for download.
+<LI>
+<A HREF="/software/hurd/hacking-guide/hhg.txt">ASCII text version [59kB]</A>.
+<LI>
+<A HREF="/software/hurd/hacking-guide/hhg.texi">Texinfo source [60kB]</A>.
+</UL>
+
+<li>
+<a href="http://hurdextras.nongnu.org/ipc_guide/">The <em>Unofficial GNU Mach
+IPC beginner's guide</em></a>, an easy introduction to Inter Process
+Comunication in the Mach microkernel by Manuel Pavón Valderrama.
+
+<li>
+<a
+href="http://walfield.org/pub/people/neal/papers/hurd-misc/mach-ipc-without-mig.txt"><em>Mach
+IPC without MIG</em></a>, an exercise by Neal H Walfield <q>to understand Mach
+IPC at one of its lowest application levels</q>.
+
+<ul>
+<li>
+<a
+href="http://walfield.org/pub/people/neal/papers/hurd-misc/ipc-hello.c"><em>ipc-hello.c</em></a>:
+<q>Hello world à la mach ipc</q>.
+
+</ul>
+
+<li>
+<a
+href=http://walfield.org/pub/people/neal/papers/hurd-misc/manual-bootstrap.txt><em>Manually
+Bootstrapping a Translator</em></a>, a text by Neal H. Walfield about how to
+<q>manually connect the translator to the filesystem</q>.
+
+<LI>
+<A HREF="auth.html">The Authentication Server</A>, the transcript of a talk about the details of
+the authentication mechanisms in the Hurd by Wolfgang J&auml;hrling.
+
+<li><a
+href="http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html"><em>The
+Mach Paging Interface as Used by the Hurd</em></a>, a text by Neal Walfield.
+
+<li><a
+href="http://lists.gnu.org/archive/html/bug-hurd/2007-01/msg00046.html"><em>A
+Critique of the GNU&nbsp;Hurd Multi-server Operating System</em></a>, an
+analysis of the GNU&nbsp;Hurd on GNU&nbsp;Mach system, written by Neal Walfield
+and Marcus Brinkmann.
+
+<li><a
+href="http://lists.gnu.org/archive/html/l4-hurd/2007-01/msg00007.html">Position
+paper <em>Improving Usability via Access Decomposition and Policy
+Refinement</em></a>: Neal Walfield and Marcus Brinkmann give an overview about
+how a future, subsequent system may be architected.
+
+</UL>
+
+<H3><A HREF="#TOCfaq" NAME="faq">Frequently asked questions</A></H3>
+<P>
+Please check out the
+<A HREF="faq.en.html">Frequently
+Asked Questions about the GNU&nbsp;Hurd (33k characters)</A> and their
+answers, which cover most issues a new user will be confronted with.
+<P>
+This document is available in several languages:
+<UL>
+<LI><A HREF="faq.en.html">English</A>
+<LI><A HREF="faq.fr.html">fran&ccedil;ais</A>
+<LI><A HREF="faq.de.html">deutsch</A>
+<LI><A HREF="faq.ja.html">Japanese</A>
+<LI><A HREF="faq.es.html">espa&ntilde;ol</A>
+<LI><A HREF="faq.it.html">italiano</A>
+
+</UL>
+
+<h3><a href="#TOCwiki" name="wiki">Wiki</a></h3>
+<p>A <a href="http://www.bddebian.com/~wiki/">wiki</a> is available for
+collecting ideas and reciepes. Fell free
+to <a href="http://www.bddebian.com/~wiki/HowToContributeToThisWiki">contribute</a>!
+
+<p>Some topics:
+
+<ul>
+
+<li><a href="http://www.bddebian.com/~wiki/hurd/ng">The future direction of
+the GNU Hurd</a>.
+
+</ul>
+
+
+<H3><A HREF="#TOCmanuals" NAME="manuals">Reference manuals</A></H3>
+
+<ul>
+
+<li>
+<p>
+The GNU&nbsp;Mach Reference Manual documents the architecture, the usage and
+the programming of the GNU&nbsp;Mach microkernel. At the moment, the manual
+documents the interface completely, but is not very useful as a tutorial or
+introduction into the Mach architecture.
+<p>
+Available Formats:
+<ul>
+<li><a href="/software/hurd/gnumach-doc/index.html">HTML version</a>
+for browsing online;</li>
+<li><a href="/software/hurd/gnumach-doc/mach.ps">PostScript version</a>
+[around 900KiB];</li>
+<li><a href="/software/hurd/gnumach-doc/mach.ps.gz">gzipped PostScript
+version</a> [around 300KiB];</li>
+<li><a href="/software/hurd/gnumach-doc/mach.pdf">PDF version</a>
+[around 700KiB].</li>
+</ul>
+<p>
+If you want to work on the manual, you're advised to make a checkout of the <a
+href="gnumach-download.html#cvs">source tree</a>. Be sure to get the
+<samp>GNU&nbsp;Mach 1 branch</samp> when you intend to work on the manual. You
+can then find the manual's sources in the <samp>doc/</samp> directory. Please
+submit any modifications to <a
+href="mailto:bug-hurd@gnu.org">&lt;bug-hurd@gnu.org&gt;</a> (if possible in
+unidiff format, as produced by <samp>diff -u</samp>).
+
+</li>
+
+<li>
+<P>
+The GNU&nbsp;Hurd Reference Manual documents the architecture, the usage
+and the programming of the GNU&nbsp;Hurd. At the moment, the manual is
+quite incomplete.
+<P>
+Available Formats:
+<UL>
+<LI>
+<A HREF="/software/hurd/doc/hurd_toc.html">HTML version</A> for browsing online.
+</LI>
+<LI>
+<A HREF="/software/hurd/doc/hurd.ps">PostScript version [1020kB, 91 pages]</A>
+for download.
+</LI>
+</UL>
+<P>
+If you want to work on the manual, you're advised to make a checkout of the <a
+href="download.html#cvs">source tree</a>. You can then find the manual's
+sources in the <samp>doc/</samp> directory. Please submit any modifications to
+<a href="mailto:bug-hurd@gnu.org">&lt;bug-hurd@gnu.org&gt;</a> (if possible in
+unidiff format, as produced by <samp>diff -u</samp>).
+
+</li>
+
+</ul>
+
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/docs.html">English</A>
+| <A HREF="/software/hurd/docs.eo.html">Esperanto</A>
+| <a href="/software/hurd/docs.es.html">Spanish</a>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007
+Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/download.html b/download.html
new file mode 100644
index 00000000..d2d718f5
--- /dev/null
+++ b/download.html
@@ -0,0 +1,140 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/download.html">English</A>
+| <A HREF="/software/hurd/download.eo.html">Esperanto</A>
+| <a href="/software/hurd/download.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#cvs" NAME="TOCcvs">CVS repository</A>
+ <LI><A HREF="#cvsweb" NAME="TOCcvsweb">Browsing the code</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCcvs" NAME="cvs">CVS repository</A></H3>
+<P>
+The Hurd source code is managed in the version control system <A
+HREF="/software/cvs/cvs.html">CVS</A>. You can check out the CVS
+repository through anonymous CVS over SSH with the following
+instruction set. When prompted for a password for <I>anoncvs</I>,
+simply press the Enter key.
+
+<P>
+Source tree:
+&nbsp;<BR>
+<SAMP>cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd</SAMP>
+
+<P>Updates from within the module's directory do not need the -d parameter.
+
+<P>For the full details, read the <A
+href="https://savannah.gnu.org/cvs/?group=hurd">savannah</A> page.
+
+<H3><A HREF="#TOCcvsweb" NAME="cvsweb">Browsing the code</A></H3>
+<P>
+You can also browse the <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/hurd/hurd/">CVS
+repository of the Hurd</A> with your web browser. The web pages are
+generated dynamically at the time you request them and are always up
+to date.
+<P>
+There is also a <A
+HREF="http://www.htu.tugraz.at/~past/hurd/global/">cross referenced
+database</A> of the Hurd, GNU&nbsp;Mach, MIG, and the GNU C library sources
+online for you to browse. It provides better searching and browsing
+facilities than the online CVS repository, but it is not always up to
+date and does not contain history information.
+
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web sites.</EM>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/download.html">English</A>
+| <A HREF="/software/hurd/download.eo.html">Esperanto</A>
+| <a href="/software/hurd/download.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/gnumach-download.html b/gnumach-download.html
new file mode 100644
index 00000000..fa1990d9
--- /dev/null
+++ b/gnumach-download.html
@@ -0,0 +1,189 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <a href="/software/hurd/gnumach-download.html">en</a>
+| <a href="/software/hurd/gnumach-download.es.html">es</a>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#release" NAME="TOCrelease">Latest Release</A>
+ <LI><A HREF="#cvs" NAME="TOCcvs">CVS repository</A>
+ <LI><A HREF="#cvsweb" NAME="TOCcvsweb">Browsing the code</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCrelease" NAME="release">Latest Release</A></H3>
+<P>
+The latest release of GNU&nbsp;Mach is version 1.3, 2002-05-28. However, it is
+recommended that you use the version in CVS instead, the
+<em>gnumach-1-branch</em> to be exact, as we are only a few steps before we'll
+do another release from that branch.
+
+<!--
+It features:
+<UL>
+<LI>Bug fixes.</LI>
+<LI>The kernel now directly supports "boot scripts" in the form of
+multiboot module names with the same syntax as the Hurd's
+<code>serverboot</code> program. That is, instead of telling GRUB
+<code>module /boot/serverboot</code>, you can give GRUB a series of
+commands like <code>module /hurd/ext2fs ${...}</code> where the syntax
+after <code>module</code> is the same as in boot scripts for Hurd's
+<code>serverboot</code>.</LI>
+<LI>The kernel message device <code>kmsg</code> is now enabled by
+default. <code>-ESCAPE_ME-disable-kmsg</code> turns it off.</LI>
+<LI>Large disks (>= 10GB) are now correctly supported, the new
+<code>get_status</code> call <code>DEV_GET_RECORDS</code> can return
+the number of records of a device.</LI>
+<LI>Lots of tweaks have been done to the virtual memory management to
+make it perform better on today's machines.</LI>
+<LI>The console supports ANSI escape sequences for colors and
+attributes.</LI>
+<LI>Support for the terminal speeds B57600 and B115200 has been
+added.</LI>
+</UL>
+<P>
+You can download the latest version of GNU&nbsp;Mach from the GNU ftp server:
+<UL>
+<LI><CODE><A
+HREF="http://ftp.gnu.org/gnu/gnumach/gnumach-1.3.tar.gz">gnumach-1.3.tar.gz</A></CODE>
+[3639K].</LI>
+<LI><CODE><A
+HREF="http://ftp.gnu.org/gnu/gnumach/gnumach-1.3.tar.gz.sig">gnumach-1.3.tar.gz.sig</A></CODE>
+[1K].</LI>
+<LI><CODE><A
+HREF="http://ftp.gnu.org/gnu/gnumach/gnumach-1.2-1.3.diff.gz">gnumach-1.2-1.3.diff.gz</A></CODE>
+[310K], containing the differences between GNU&nbsp;Mach 1.2 and GNU&nbsp;Mach 1.3.</LI>
+<LI><CODE><A
+HREF="http://ftp.gnu.org/gnu/gnumach/gnumach-1.2-1.3.diff.gz.sig">gnumach-1.2-1.3.diff.gz.sig</A></CODE>
+[1K].</LI>
+</UL>
+-->
+
+<H3><A HREF="#TOCcvs" NAME="cvs">CVS repository</A></H3>
+<P>
+The GNU&nbsp;Mach source code is managed in the version control system <a
+href="/software/cvs/cvs.html">CVS</A>. You can check out the CVS repository
+with the following instruction set.
+
+<P>
+Source tree:
+<BR>
+<SAMP>cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co gnumach</SAMP>
+<P>
+Use to following to get the <samp>GNU&nbsp;Mach 1 branch</samp>:
+<BR>
+<SAMP>cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach</SAMP>
+
+<P>Updates from within the module's directory do not need the -d parameter.
+
+<p>For the full details, read the <a
+href="https://savannah.gnu.org/cvs/?group=hurd">Savannah</a> page.
+
+<H3><A HREF="#TOCcvsweb" NAME="cvsweb">Browsing the code</A></H3>
+<P>
+You can also browse the <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/hurd/gnumach/">CVS
+repository of GNU&nbsp;Mach</A> with your web browser. The web pages are
+generated dynamically at the time you request them and are always up
+to date.
+<P>
+There is also a <A
+HREF="http://www.htu.tugraz.at/~past/hurd/global/">cross referenced
+database</A> of the Hurd, GNU&nbsp;Mach, MIG, and the GNU C library sources
+online for you to browse. It provides better searching and browsing
+facilities than the online CVS repository, but it is not always up to
+date and does not contain history information.
+
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web sites.</EM>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <a href="/software/hurd/gnumach-download.html">en</a>
+| <a href="/software/hurd/gnumach-download.es.html">es</a>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/gnumach-install.html b/gnumach-install.html
new file mode 100644
index 00000000..c42f2404
--- /dev/null
+++ b/gnumach-install.html
@@ -0,0 +1,131 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/gnumach-install.html">English</A>
+| <a href="/software/hurd/gnumach-install.es.html">Spanish</a>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#version" NAME="TOCversion">Latest version</A>
+ <LI><A HREF="#install" NAME="TOCinstall">Installation instructions</A>
+ <LI><A HREF="#boot" NAME="TOCboot">Booting GNU&nbsp;Mach</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCversion" NAME="version">Latest version</A></H3>
+<P>
+The last stable version of GNU&nbsp;Mach is 1.3, but it is recommended that
+you use the <a href="/software/hurd/gnumach-download.html#cvs">version in
+CVS</a> instead, the <em>gnumach-1-branch</em> to be exact, as we are only a
+few steps before we'll do another release from that branch.
+
+<H3><A HREF="#TOCinstall" NAME="install">Installation instructions</A></H3>
+<P>
+GNU&nbsp;Mach can be compiled or cross-compiled easily. The only package
+you are not likely to have installed already is MIG, the Mach
+interface generator. If you cross-compile gnumach, you need a
+cross-MIG for your architecture. You also need the static version of
+the C library for your host architecture, as some functions are taken
+directly from it. We recommend that you use the <A
+HREF="/software/libc/libc.html">GNU C library</A>, other C libraries
+have not been tested and might not work. After you have followed the
+installation instructions in the package and the reference manual, you
+should end up with a kernel binary where your boot loader can find it.
+
+<H3><A HREF="#TOCboot" NAME="boot">Booting GNU&nbsp;Mach</A></H3>
+<P>
+To actually use the kernel and boot the GNU operating system, you need
+a boot loader. Not all boot loaders are capable to boot the GNU
+system, you need one that supports the multiboot standard. The
+bootloader of the GNU system is <A HREF="/software/grub/grub.html">GNU
+GRUB</A>, which supports a broad range of operating systems including
+GNU/Hurd.
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/gnumach-install.html">English</A>
+| <a href="/software/hurd/gnumach-install.es.html">Spanish</a>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/gnumach.html b/gnumach.html
new file mode 100644
index 00000000..4ba0e9f7
--- /dev/null
+++ b/gnumach.html
@@ -0,0 +1,180 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/gnumach.html">English</A>
+| <A HREF="/software/hurd/gnumach.he.html">Hebrew</A>
+| <A HREF="/software/hurd/gnumach.pl.html">Polish</A>
+| <A HREF="/software/hurd/gnumach.es.html">Spanish</A>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<P>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#introduction" NAME="TOCintroduction">Introduction to Mach</A>
+ <LI><A HREF="#advantages" NAME="TOCadvantages">Advantages of GNU&nbsp;Mach</A>
+ <LI><A HREF="#status" NAME="TOCstatus">Status of the project</A>
+</UL>
+<P>
+<HR>
+
+<H3><A HREF="#TOCintroduction" NAME="introduction">Introduction to GNU&nbsp;Mach</A></H3>
+<P>
+GNU&nbsp;Mach is the microkernel of the GNU system. A microkernel provides
+only a limited functionality, just enough abstraction on top of the
+hardware to run the rest of the operating system in user space. The
+GNU&nbsp;Hurd servers and the GNU C library implement the POSIX compatible
+base of the GNU system on top of the microkernel architecture provided
+by Mach.
+<P>
+Currently, GNU&nbsp;Mach runs on IA32 machines. GNU&nbsp;Mach should, and
+probably will, be ported to other hardware architectures in the
+future. Mach was ported to many operating systems in the past.
+<P>
+GNU&nbsp;Mach is maintained by the Hurd developers for the GNU project. If
+you need help with GNU&nbsp;Mach or want to contribute to the development
+of the microkernel, you should <A
+HREF="/software/hurd/help.html">contact the Hurd people</A>.
+
+<H3><A HREF="#TOCadvantages" NAME="advantages">Advantages of GNU&nbsp;Mach</A></H3>
+GNU&nbsp;Mach is not the most advanced microkernel known to the planet, nor
+is it the fastest or smallest, but it has a rich set of interfaces and
+some features which make it useful as the base of the Hurd system.
+<DL>
+<DT><STRONG>it's free software</STRONG></DT>
+<DD>
+Anybody can use, modify, and redistribute it under the terms of the
+<A HREF="/copyleft/gpl.html">GNU General Public License (GPL)</A>.</DD>
+</DD>
+<DT><STRONG>it's built to survive</STRONG></DT>
+<DD>
+As a microkernel, GNU&nbsp;Mach doesn't implement a lot of the features
+commonly found in an operating system, but only the bare minimum that
+is required to implement a full operating system on top of it. This
+means that a lot of the operating system code is maintained outside of
+GNU&nbsp;Mach, and while this code may go through a complete redesign, the
+code of the microkernel can remain comparatively stable.
+</DD>
+<DT><STRONG>it's scalable</STRONG></DT>
+<DD>
+Mach is particularly well suited for SMP and network cluster
+techniques. Thread support is provided at the kernel level, and the
+kernel itself takes advantage of that. Network transparency at the
+IPC level makes resources of the system available across machine
+boundaries (with NORMA IPC, currently not available in GNU&nbsp;Mach).
+</DD>
+<DT><STRONG>it exists</STRONG></DT>
+<DD>
+The Mach microkernel is real software that works Right Now. It is not
+a research or a proposal. You don't have to wait at all before you
+can start using and developing it. Mach has been used in many
+operating systems in the past, usually as the base for a single UNIX
+server. In the GNU system, Mach is the base of a functional
+multi-server operating system, the Hurd.
+</DD>
+</DL>
+
+<H3><A HREF="#TOCstatus" NAME="status">Status of the project</A></H3>
+<P>
+GNU&nbsp;Mach 1.3 was released in May 2002, and features advanced boot
+script support, support for large disks (>= 10GB) and an improved
+console.
+<P>
+GNU&nbsp;Mach is used as the default microkernel in the GNU/Hurd system.
+It is compatible with other popular Mach distributions. The device
+drivers for block devices and network cards are taken from Linux 2.0.x
+kernel versions, and so a broad range of common hardware is supported.
+<P>
+However, the Linux device drivers have been improved greatly since the
+2.0.x version, and a new version of GNU&nbsp;Mach based on the OSKit
+library is being worked on, which uses newer drivers and in general
+has cleaner machine specific support code.
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/gnumach.html">English</A>
+| <A HREF="/software/hurd/gnumach.he.html">Hebrew</A>
+| <A HREF="/software/hurd/gnumach.pl.html">Polish</A>
+| <A HREF="/software/hurd/gnumach.es.html">Spanish</A>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/help.html b/help.html
new file mode 100644
index 00000000..dd4595c3
--- /dev/null
+++ b/help.html
@@ -0,0 +1,167 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/help.html">English</A>
+| <A HREF="/software/hurd/help.eo.html">Esperanto</A>
+| <a href="/software/hurd/help.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <li><a href="#mail" name="TOCmail">Public mailing lists</a>
+ <li><a href="#mailmaintainers" name="TOCmailmaintainers">Non-public mail
+ contact to the maintainers</a>
+ <LI><A HREF="#irc" NAME="TOCirc">Internet relay chat</A>
+</UL>
+<HR>
+
+<h3><a href="#TOCmail" name="mail">Public mailing lists</a></h3>
+<p>
+Note that you do <em>not</em> need to be subscribed to post to any of the
+following mailing lists: your message will be approved even if you're not a
+member of the mailing list and people are advised to keep you in the
+<samp>Cc</samp> list.
+<P>
+If you have questions about the installation, how the Hurd works and
+how it is used, or general questions concerning the Hurd, GNU&nbsp;Mach or
+the other packages maintained by the Hurd people, you can send an
+email to the <a
+HREF="http://mail.gnu.org/mailman/listinfo/help-hurd">Help-Hurd</A> <A
+HREF="mailto:help-hurd@gnu.org">&lt;help-hurd@gnu.org&gt;</A> mailing
+list.
+<P>
+Bug reports for the GNU&nbsp;Hurd, GNU&nbsp;Mach and the other packages
+maintained by the Hurd people, as well as development issues should be sent to
+the <a
+HREF="http://mail.gnu.org/mailman/listinfo/bug-hurd">Bug-Hurd</A> <A
+HREF="mailto:bug-hurd@gnu.org">&lt;bug-hurd@gnu.org&gt;</A> mailing
+list.
+<P>
+All emails concerning the Debian&nbsp;GNU/Hurd binary distribution should
+go to the
+<A HREF="http://lists.debian.org/debian-hurd/">Debian GNU/Hurd</A>
+<A HREF="mailto:debian-hurd@lists.debian.org">&lt;debian-hurd@lists.debian.org&gt;</A>
+mailing list.
+<P>
+If you want to contribute to the development of the Hurd, look at the
+<A HREF="/software/hurd/devel.html">Development page</A>.
+
+<p>Discussion about the future direction of the GNU&nbsp;Hurd takes place on
+the <a href="http://lists.gnu.org/mailman/listinfo/l4-hurd">L4-hurd</a> <a
+href="mailto:l4-hurd@gnu.org">&lt;l4-hurd@gnu.org&gt;</a> mailing list.
+
+<h3><a href="#TOCmailmaintainers" name="mailmaintainers">Non-public mail
+contact to the maintainers</a></h3>
+<p>
+If you have a concern you want to send to the Hurd maintainers without writing
+to a public mailing list, then please send email to <a
+href="mailto:hurd-maintainers@gnu.org">&lt;hurd-maintainers@gnu.org&gt;</a>,
+but please use the <a
+href="http://mail.gnu.org/mailman/listinfo/bug-hurd">Bug-Hurd</a> <a
+href="mailto:bug-hurd@gnu.org">&lt;bug-hurd@gnu.org&gt;</a> mailing list, if
+possible.
+
+<H3><A HREF="#TOCirc" NAME="irc">Internet relay chat</A></H3>
+<P>
+The GNU Project uses
+<A HREF="http://www.freenode.net/">Freenode</A> as it's official IRC
+network. The network of IRC servers can be accessed through
+<SAMP>irc.gnu.org</SAMP>. The channel <SAMP>#hurd</SAMP> is
+dedicated to the Hurd. You can find other users and developers
+interested in the Hurd there and chat with them in real time.
+Further information is available on <a
+href="http://www.bddebian.com/~wiki/irc">this wiki page</a>.
+
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web sites.</EM>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/help.html">English</A>
+| <A HREF="/software/hurd/help.eo.html">Esperanto</A>
+| <a href="/software/hurd/help.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007
+Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/history.html b/history.html
new file mode 100644
index 00000000..bde11d8e
--- /dev/null
+++ b/history.html
@@ -0,0 +1,199 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/history.html">English</A>
+| <A HREF="/software/hurd/history.eo.html">Esperanto</A>
+| <A HREF="/software/hurd/history.he.html">Hebrew</A>
+| <a href="/software/hurd/history.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#start" NAME="TOCstart">How it started</A>
+ <LI><A HREF="#announce" NAME="TOCannounce">Announcements</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCstart" NAME="start">How it started</A></H3>
+<P>
+Richard Stallman (RMS) started GNU in 1983, as a project to create a
+complete free operating system. In the text of the GNU Manifesto, he
+mentioned that there is a primitive kernel. In the first GNUsletter,
+Feb. 1986, he says that GNU's kernel is TRIX, which was developed at
+the Massachusetts Institute of Technology.
+
+<P>
+By December of 1986, the Free Software Foundation (FSF) had "started
+working on the changes needed to TRIX" [Gnusletter, Jan. 1987].
+Shortly thereafter, the FSF began "negotiating with Professor Rashid
+of Carnegie-Mellon University about working with them on the
+development of the Mach kernel" [Gnusletter, June, 1987]. The text
+implies that the FSF wanted to use someone else's work, rather than
+have to fix TRIX.
+
+<P>
+In [Gnusletter, Feb. 1988], RMS was talking about taking Mach and
+putting the Berkeley Sprite filesystem on top of it, "after the parts
+of Berkeley Unix... have been replaced."
+
+<P>
+Six months later, the FSF is saying that "if we can't get Mach, we'll
+use TRIX or Berkeley's Sprite." Here, they present Sprite as a
+full-kernel option, rather than just a filesystem.
+
+<P>
+In January, 1990, they say "we aren't doing any kernel work. It does
+not make sense for us to start a kernel project now, when we still
+hope to use Mach" [Gnusletter, Jan. 1990]. Nothing significant occurs
+until 1991, when a more detailed plan is announced:
+
+<BLOCKQUOTE>
+We are still interested in a multi-process kernel running on top of
+Mach. The CMU lawyers are currently deciding if they can release Mach
+with distribution conditions that will enable us to distribute it. If
+they decide to do so, then we will probably start work. CMU has
+available under the same terms as Mach a single-server partial Unix
+emulator named Poe; it is rather slow and provides minimal
+functionality. We would probably begin by extending Poe to provide
+full functionality. Later we hope to have a modular emulator divided
+into multiple processes. [Gnusletter, Jan. 1991].
+</BLOCKQUOTE>
+
+<P>
+RMS explains the relationship between the Hurd and Linux in <A
+HREF="hurd-and-linux.html">The Hurd and Linux</A>, where he mentions
+that the FSF started developing the Hurd in 1990. As of [Gnusletter,
+Nov. 1991], the Hurd (running on Mach) is GNU's official kernel.
+
+<H3><A HREF="#TOCannounce" NAME="announce">Announcements</A></H3>
+<DL>
+<DT>
+<A HREF="hurd-flash15">Release 0.2 announcement (complete GNU system)</A></DT>
+<DT>
+<A HREF="hurd-flash14">Release 0.2 announcement (Hurd)</A></DT>
+<DT>
+<A HREF="hurd-flash13">Test release announcement (Aug 96)</A></DT>
+<DT>
+<A HREF="hurd-flash12">Test release status (Jul 96)</A></DT>
+<DT>
+<A HREF="hurd-flash11">Binary image available, Apr 96</A></DT>
+<DD>
+This and <A HREF="http://www.netbsd.org/">NetBSD</A> boot flopies should
+be enough to get a working GNU/Hurd system!</DD>
+<DT>
+<A HREF="hurd-flash10">New Snapshot, Apr 96</A> -- NFS and lots else
+works!</DT>
+<DT>
+<A HREF="hurd-flash9">News Flash, Nov 95</A> -- ftp works!</DT>
+<DT>
+<A HREF="hurd-flash8">New Snapshot, Jul 95</A> -- ext2fs support</DT>
+<DT>
+<A HREF="hurd-flash7">New Snapshot, Apr 95</A></DT>
+<DT>
+<A HREF="hurd-flash6">News flash, Nov 94</A></DT>
+<DT>
+<A HREF="hurd-flash5">News flash, Sep 94</A> -- gcc runs!</DT>
+<DT>
+<A HREF="hurd-flash4">News flash, Aug 94</A></DT>
+<DT>
+<A HREF="hurd-flash3">News flash, Jul 94</A> -- emacs runs!</DT>
+<DT>
+<A HREF="hurd-flash2">News flash, May 94</A></DT>
+<DT>
+<A HREF="hurd-flash">News flash, Apr 94</A> -- it boots!</DT>
+<DT>
+<A HREF="hurd-announce2">GNU&nbsp;Hurd announcement, Nov 93</A></DT>
+<DT>
+<A HREF="hurd-announce">GNU&nbsp;Hurd announcement, May 91</A></DT>
+</DL>
+
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/history.html">English</A>
+| <A HREF="/software/hurd/history.eo.html">Esperanto</A>
+| <A HREF="/software/hurd/history.html">Hebrew</A>
+| <a href="/software/hurd/history.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/howto/subhurd.html b/howto/subhurd.html
new file mode 100644
index 00000000..54aa3b3c
--- /dev/null
+++ b/howto/subhurd.html
@@ -0,0 +1,89 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+
+<HTML>
+ <HEAD>
+ <TITLE>GNU Hurd - Free Software Foundation (FSF)</TITLE>
+ <LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+ </HEAD>
+
+<BODY BGCOLOR="#000000" LINK="#8888EE" VLINK="#9F00DD" ALINK="#000088">
+<IMAGE SRC="/graphics/hurd_sm_mf_invert.jpg">
+<TABLE width="100%" border="0" cellspacing="0" cellpadding="20">
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<A HREF="../hurd.html#contents"><STRONG>The GNU Hurd</STRONG></A><BR>
+<p>
+<a href="/software/hurd/whatis/">Whatis?</a><br>
+<a href="/software/hurd/howto/">Howto?</a><br>
+</p>
+
+<P>
+<!---A HREF="mirrors.html#contents">Mirrors</A><BR--->
+<A HREF="../acknowledgements.html#contents">Acknowledgements</A><BR>
+<!---A HREF="copyright.html#contents">Copyright Notice</A--->
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP" TEXT="#000000" BGCOLOR="#FFFFFF">
+<h1>Running a Subhurd</h1>
+<p class="author">By Roland McGrath</p>
+<p>The most useful thing you can do when trying to troubleshoot the boot
+sequence of the Hurd is try to run your the system in a
+sub-hurd, while watching it using ps and gdb from the working hurd. Since
+the sub-hurd is never going to make it all the way up, you don't even
+really need to make a separate filesystem for it; you can just boot the
+sub-hurd read-only on your main root filesystem if you like.</p>
+
+<p>The way to boot the sub-hurd is with `boot'. I would suggest something
+like this: boot -d -I -Tdevice /boot/servers.boot hd0s6</p>
+
+<p>The -d says to pause before the start-up of each server and wait for you to
+hit return, which gives you time to go attach gdb to the task before it
+starts running. The -I says to leave the terminal signals normal, so
+hitting C-z will suspend boot rather than sending a C-z to the virtual
+console device of the sub-hurd. (Note that suspending boot does not
+suspend the sub-hurd, just boot itself; boot acts as the server for device
+access from the sub-hurd, so the sub-hurd's attempts to write to its
+console or open devices block while boot is suspended.)</p>
+
+<p>When you do `ps -A' on the main hurd, the sub-hurd tasks will appear as
+unknown processes. You can figure out which is which just by looking at
+the order of unknown processes that appear with higher PIDs than the boot
+process. They appear in the order you see in the "bootstrap: ..."
+messages, i.e. the first unknown after boot will be ext2fs.static, the
+second exec, then init, then proc.</p>
+
+
+<HR>
+
+Return to <A HREF="/home.html" TARGET="_parent">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo" TARGET="_parent">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1998, 1999, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.<P>
+Updated:
+<!-- hhmts start -->
+$Date$ $Author$
+<!-- hhmts end -->
+<HR>
+</TD>
+</TR>
+</TABLE>
+
+</BODY>
+</HTML>
diff --git a/hurd-and-linux.html b/hurd-and-linux.html
new file mode 100644
index 00000000..d9181d88
--- /dev/null
+++ b/hurd-and-linux.html
@@ -0,0 +1,104 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The Hurd and Linux - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd, linux">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+
+<H1>The Hurd and Linux</H1>
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-and-linux.cn.html">Chinese(Simplified)</A>
+| <A HREF="/software/hurd/hurd-and-linux.zh.html">Chinese(Traditional)</A>
+| <A HREF="/software/hurd/hurd-and-linux.he.html">Hebrew</A>
+| <A HREF="/software/hurd/hurd-and-linux.html">English</A>
+| <a href="/software/hurd/hurd-and-linux.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<P>
+by <A HREF="http://www.stallman.org/">Richard Stallman</A>.
+
+<P>
+
+People sometimes ask, ``Why did the FSF develop a new free kernel
+instead of using Linux?'' It's a reasonable question. The answer,
+briefly, is that that is not the question we faced.
+
+<P>
+When we started developing the Hurd in 1990, the question facing us
+was, ``How can we get a free kernel for the GNU system?'' There was
+no free Unix-like kernel then, and we knew of no other plan to write
+one. The only way we could expect to have a free kernel was to write
+it ourselves. So we started.
+
+<P>
+We heard about Linux after its release. At that time, the question
+facing us was, ``Should we cancel the Hurd project and use Linux
+instead?''
+
+<P>
+We heard that Linux was not at all portable (this may not be true
+today, but that's what we heard then). And we heard that Linux was
+architecturally on a par with the Unix kernel; our work was leading to
+something much more powerful.
+
+<P>
+Given the years of work we had already put into the Hurd, we decided
+to finish it rather than throw them away.
+
+<P>
+If we did face the question that people ask---if Linux were already
+available, and we were considering whether to start writing another
+kernel---we would not do it. Instead we would choose another project,
+something to do a job that no existing free software can do.
+
+<P>
+But we did start the Hurd, back then, and now we have made it work.
+We hope its superior architecture will make free operating systems
+more powerful.
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-and-linux.cn.html">Chinese(Simplified)</A>
+| <A HREF="/software/hurd/hurd-and-linux.zh.html">Chinese(Traditional)</A>
+| <A HREF="/software/hurd/hurd-and-linux.he.html">Hebrew</A>
+| <A HREF="/software/hurd/hurd-and-linux.html">English</A>
+| <a href="/software/hurd/hurd-and-linux.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+FSF &amp; GNU inquiries &amp; questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF.
+<P>
+Comments on these web pages to
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+
+<p>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+</p>
+
+<HR>
+</BODY>
+</HTML>
diff --git a/hurd-announce b/hurd-announce
new file mode 100644
index 00000000..2f165ad8
--- /dev/null
+++ b/hurd-announce
@@ -0,0 +1,47 @@
+From mib@PREP.AI.MIT.EDU Tue May 7 12:07:53 1991
+From: mib@PREP.AI.MIT.EDU
+Newsgroups: gnu.announce
+Subject: FSF work on a GNU OS
+Date: 6 May 91 22:15:22 GMT
+Reply-To: mib@prep.ai.mit.edu
+Distribution: gnu
+Organization: GNUs Not Usenet
+
+The Free Software Foundation is beginning work on a GNU operating
+system built on top of the Mach 3.0 microkernel. There are three
+goals to this project worth noting:
+
+o Binary compatability with 4.4 BSD, and other U*x or U*xish systems
+ on other hardware where appropriate, convenient, and consistent with
+ the design;
+
+o Posix compliance (in combination with the GNU C Library and the GNU
+ C Compiler); and
+
+o Ease of use as well as several new features and functionality.
+
+
+I am interested in constructive criticism on the interfaces, design,
+and implementation from experts in the field of OS research and design
+consistent with the above goals. Advice from seasoned U*x hackers is
+especially welcome.
+
+We have a mailing list for discussion. Currently there is little
+discussion on the group; the major contributors to the ideas behind
+the design all live in the Boston area at this point, and work has
+been done via face-to-face communication. I would like to open the
+field of discussion to a broader base, both to get wider dissemination
+of the ideas behind the current design, as well as to get a greater
+breadth of criticism. Periodic postings are currently made to the
+mailing list containing a snapshot of the interfaces used by the
+various pieces of the system. I would like to see discussion as well;
+perhaps we need a critical mass to get this.
+
+Interested individuals should send me email. I don't regularly read
+the newsgroups to which this message is posted.
+
+
+[U*x is an abbreviation for a well-known trademark of AT&T. :-)]
+
+ -mib
+
diff --git a/hurd-announce2 b/hurd-announce2
new file mode 100644
index 00000000..dce41c43
--- /dev/null
+++ b/hurd-announce2
@@ -0,0 +1,143 @@
+From mib@gnu.ai.mit.edu Wed Nov 3 21:51:03 1993
+Path: usenet.ee.pdx.edu!cs.uoregon.edu!ogicse!emory!nigel.msen.com!sdd.hp.com!swrinde!cs.utexas.edu!uunet!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!prep.ai.mit.edu!gnulists
+From: mib@gnu.ai.mit.edu (Michael I Bushnell)
+Newsgroups: gnu.announce,gnu.misc.discuss
+Subject: Hurd status and call for volunteers
+Message-ID: <9311020719.AA02206@geech.gnu.ai.mit.edu>
+Date: 1 Nov 93 21:19:05 GMT
+Article-I.D.: geech.9311020719.AA02206
+Followup-To: gnu.misc.discuss
+Distribution: world
+Lines: 124
+Approved: info-gnu@prep.ai.mit.edu
+To: info-gnu@prep.ai.mit.edu
+X-Shopping-List:
+ (1) Chaotic casino griddles (2) Cervical congestion (3) Neoclassical
+ consoles
+Xref: usenet.ee.pdx.edu gnu.announce:160 gnu.misc.discuss:3985
+
+This message to help sate curiosity, as well as to ask for volunteers.
+Until we are ready for alpha test, this is the last such message that
+will be posted here. If you want to receive further such messages,
+send mail to hurd-ann-request@gnu.ai.mit.edu and ask to be put on that
+(moderated) announcements list.
+
+
+What is already done with the Hurd:
+
+The filesystem is complete; it runs (read-only), and most of its calls
+have been tested and work. The filesystem is able to download
+programs, by a kludge similar to the kludge used to enable the kernel
+to download the first task. In the actual bootstap sequence, it will
+download the execserver.
+
+The proc and auth servers are completed; the exec server is nearly
+complete (for a.out, not for bfd).
+
+C library support for Mach and Hurd rpc stubs, and some of the mach
+and hurd specific code, is done. Much untested and probably wrong
+code has been written to implement Unix "system calls". A large piece
+of this (the descriptor management code) is believed by Roland to have
+some architectural flaw, but he isn't sure.
+
+Some small filesystem servers (shadow directories, for example) have
+been written, but have not been compiled, let alone tested.
+
+
+There are currently three things happening wrt the Hurd:
+
+I am spending nearly all my time getting things to boot and run. My
+work is currently directed toward that goal; in the immediate present
+I am working with Roland on getting the library in its near-final
+state (which will last a long time) to make compiling easier. It is
+because this is nearly done that I can send this message.
+
+Roland is working on the library. Most of the remaining architectural
+work is done and being tested. Then Roland will work on integrating
+cthreads (which is mostly busywork), miscellaneous filesystem calls,
+and then file descriptors. After that comes signals.
+
+Jan Brittenson will be working on the network server library. This is
+a library that, when linked against a BSD protocol stack, will produce
+a Hurd network server. (Such a server implements the socket interface
+in socket.defs.)
+
+
+There are four general tasks that can be done by other people:
+
+1. Completing the existing work on the terminal driver. The existing
+work implements most of the logic you already associate with a Posixy
+terminal driver; it needs the port management and buffering logic
+added.
+
+2. Writing a readline terminal driver. We will want, as an
+alternative to the Posixy terminal driver, a readline type terminal
+driver.
+
+3. Writing miscellaneous shell utilities. Here we need shell
+utilities to create translators, etc. They should have a nice rich
+set of features to do all kinds of GNU things.
+
+4. Writing miscellaneous filesystem servers. Here we need a
+transparent tar server, a transparent FTP server, and the like.
+
+
+Future plans for work to be written by me (once the bootstrap works,
+and in addition to testing library code as Roland finishes it):
+
+o split the existing filesystem into three parts:
+ o a library for port management for complicated multi-threaded
+ servers;
+ o a library for "normal" disk-based filesystems;
+ o ufs specific code.
+
+o Write the PF_FILE socket server (what you know as PF_UNIX).
+
+o Finish the posixy terminal driver if nobody else has.
+
+o Write miscellaneous shell utilities that nobody else has.
+
+o Build a self-hosting system.
+
+
+What you need in order to be able to help now:
+
+o A 386 PC running Mach 3.0. If you have some other kind of hardware,
+ then you need to port the GNU C library support first. I'm not
+ entirely sure how much work that involves; you will need to contact
+ Roland. It might be too much trouble at this point to spend any
+ effort on it. It's best if it's a machine for which a free port of
+ Mach is available, though you could do useful work even if it's not.
+
+ If you are not currently running Mach 3.0 with somebody's
+ single-server, then it is very unlikely you could help, unless you
+ have a Unix source license. In that case, you could talk to CMU
+ (write mach@cs.cmu.edu) to find out how to get Mach 3.0 running on
+ your machine. It is not possible to do development without a Unix
+ emulator of some kind; just bare Mach 3.0 is not sufficient. I have
+ neither the time nor knowledge to help someone get a 3.0
+ single-server system running.
+
+o Clue. I don't have enough time to explain operating systems or Unix
+ to people. You need to have an iron-clad grasp of Unix semantics
+ (specificaly BSD); it's essential that things be exactly right from
+ that standpoint. It's not enough that you've programmed Unix
+ before; you need to understand all the nits. However, you may
+ disregard my previous comments about a "two question limit". You do
+ need the ability to intuit to some extent, however.
+
+o Time. It's not good for me to delegate a task and then have nothing
+ happen on it. If you have a full-time job where you can't justify
+ Hurd work as part of your job, you might find that you don't really
+ have as much time as you thought. Please make sure you really have
+ enough time before volunteering for a task.
+
+o Efficient net access. Without a real Internet connection (mail only
+ is not sufficient), it will be impossible for you to do development
+ right now.
+
+
+If you think you can help, send me email. If you don't think you can
+help right now, then don't give up: the list of conditions will change
+as the list of delegatable tasks changes.
+
diff --git a/hurd-announcements.html b/hurd-announcements.html
new file mode 100644
index 00000000..ab3fbad5
--- /dev/null
+++ b/hurd-announcements.html
@@ -0,0 +1,114 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+
+<HTML>
+ <HEAD>
+ <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
+ <TITLE>Hurd Announcements - Free Software Foundation (FSF)</TITLE>
+ <LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+ </HEAD>
+
+<BODY TEXT="#000000"
+ BGCOLOR="#FFFFFF"
+ LINK="#1F00FF"
+ VLINK="#9900DD"
+ ALINK="#FF0000">
+
+<H1>Current and Past Announcements</H1>
+
+These are all the announcements made over the years. Most of them were
+either sent to <A HREF="news:gnu.announce">gnu.announce</A> or Hurd interest
+mailing lists.
+
+<DL>
+
+<DT>
+<A HREF="hurd-flash15">Release 0.2 announcement (complete GNU system)</A></DT>
+
+<DT>
+<A HREF="hurd-flash14">Release 0.2 announcement (Hurd)</A></DT>
+
+<DT>
+<A HREF="hurd-flash13">Test release announcement (Aug 96)</A></DT>
+
+<DT>
+<A HREF="hurd-flash12">Test release status (Jul 96)</A></DT>
+
+<DT>
+<A HREF="hurd-flash11">Binary image available, Apr 96</A></DT>
+
+<DD>
+This and <A HREF="http://www.netbsd.org/">NetBSD</A> boot flopies should
+be enough to get a working Hurd system!</DD>
+
+<DT>
+<A HREF="hurd-flash10">New Snapshot, Apr 96</A> -- NFS and lots else
+works!</DT>
+
+<DT>
+<A HREF="hurd-flash9">News Flash, Nov 95</A> -- ftp works!</DT>
+
+<DT>
+<A HREF="hurd-flash8">New Snapshot, Jul 95</A> -- ext2fs support</DT>
+
+<DT>
+<A HREF="hurd-flash7">New Snapshot, Apr 95</A></DT>
+
+<DT>
+<A HREF="hurd-flash6">News flash, Nov 94</A></DT>
+
+<DT>
+<A HREF="hurd-flash5">News flash, Sep 94</A> -- gcc runs!</DT>
+
+<DT>
+<A HREF="hurd-flash4">News flash, Aug 94</A></DT>
+
+<DT>
+<A HREF="hurd-flash3">News flash, Jul 94</A> -- emacs runs!</DT>
+
+<DT>
+<A HREF="hurd-flash2">News flash, May 94</A></DT>
+
+<DT>
+<A HREF="hurd-flash">News flash, Apr 94</A> -- it boots!</DT>
+
+<DT>
+<A HREF="hurd-announce2">GNU&nbsp;Hurd announcement, Nov 93</A></DT>
+
+<DT>
+<A HREF="hurd-announce">GNU&nbsp;Hurd announcement, May 91</A></DT>
+
+<BR><A HREF="hurd-announce"></A>&nbsp;</DL>
+
+<HR>
+
+Return to <A HREF="/home.html" TARGET="_parent">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo" TARGET="_parent">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1998, 1999 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.<P>
+Updated:
+<!-- hhmts start -->
+23 Jan 1999 matthias
+<!-- hhmts end -->
+<HR>
+
+
+</BODY>
+</HTML>
diff --git a/hurd-flash b/hurd-flash
new file mode 100644
index 00000000..d1bacc79
--- /dev/null
+++ b/hurd-flash
@@ -0,0 +1,22 @@
+Path: gnurd!usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!gatech!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mib
+From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
+Newsgroups: gnu.misc.discuss,comp.os.mach
+Subject: Hurd now bootstraps
+Date: 05 Apr 1994 21:49:50 GMT
+Organization: Free Software Foundation, Cambridge, MA
+Lines: 11
+Message-ID: <MIB.94Apr5174952@churchy.gnu.ai.mit.edu>
+NNTP-Posting-Host: churchy.gnu.ai.mit.edu
+
+
+The GNU Hurd now bootstraps, successfully starting the core servers
+(the filesystem, exec server, process server, auth server, and init)
+and running the first program. A snapshot of the code that did this
+is on alpha.gnu.ai.mit.edu in the usual place, /gnu/hurd-snap.tar.gz.
+
+--
++1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David,
++1 617 253 8568 (W) -+- and Jonathan loved him as his own soul.
+1105 Broadway | Then Jonathan made a covenant with David
+Somerville, MA 02144 | because he loved him as his own soul.
+
diff --git a/hurd-flash10 b/hurd-flash10
new file mode 100644
index 00000000..d6d5685b
--- /dev/null
+++ b/hurd-flash10
@@ -0,0 +1,25 @@
+Date: Mon, 15 Apr 1996 15:28:29 -0400
+Message-Id: <199604151928.PAA00636@geech.gnu.ai.mit.edu>
+From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
+To: hurd-ann@gnu.ai.mit.edu
+Subject: New Hurd snapshot available
+X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+
++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv
++ b+++ !D B-- e+ u++(*) h* f? r n y++
+X-Tom-Swiftie: "Use the `&' operator to get the address," Tom pointed out.
+Sender: owner-abshurd@cs.pdx.edu
+Precedence: bulk
+
+
+I have just cut a new source snapshot. If things go nicely, a binary
+snapshot may appear soon as well. You can find this snapshot as
+
+ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap-960415.tar.gz
+
+Many many things work! Emacs built native and just *went*. The
+system now works standalone; you can use gdb (it's much nicer than
+other mach-ish gdb's, of course); the network is functional (complete
+with NFS), etc.
+
+Michael
+
diff --git a/hurd-flash11 b/hurd-flash11
new file mode 100644
index 00000000..57851b01
--- /dev/null
+++ b/hurd-flash11
@@ -0,0 +1,25 @@
+From: Miles Bader <miles@gnu.ai.mit.edu>
+To: hurd-ann@gnu.ai.mit.edu
+Date: Thu, 18 Apr 1996 19:08:07 -0400
+Subject: hurd binary image
+
+
+A filesystem image from a working hurd system, corresponding to the latest
+snapshot, is available as:
+
+ ftp://alpha.gnu.ai.mit.edu/gnu/hurd-image-960418.tar.gz
+
+The whole tree takes about 37meg (warning -- it unpacks into `.'). Follow
+the instructions in ./INSTALL-binary to make a working hurd system.
+
+Due to a timely trashing of the disk on our main hurd machine, it has been
+verified that it is possible to make a bootable hurd system from scratch
+using this image and a set of netbsd 1.1 boot floppies...
+
+The sources for the mach kernel included in the image are available in the
+same directory as mach4-UK22.tar.gz and mach4-i386-UK22.tar.gz.
+
+-Miles
+--
+Miles Bader / miles@gnu.ai.mit.edu / (617) 253-8568
+Amadera e ike!
diff --git a/hurd-flash12 b/hurd-flash12
new file mode 100644
index 00000000..5be9c94e
--- /dev/null
+++ b/hurd-flash12
@@ -0,0 +1,76 @@
+From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
+Newsgroups: gnu.misc.discuss
+Subject: Hurd 0.0 release status
+Followup-To: gnu.misc.discuss
+Date: 13 Jul 1996 23:53:41 GMT
+Organization: Touring Consulting Services
+Lines: 35
+Message-ID: <MIB.96Jul13195341@gnu.ai.mit.edu>
+NNTP-Posting-Host: churchy.gnu.ai.mit.edu
+
+
+People are eager to know how close we are to release, so here's an
+update:
+
+There is one rather annoying bug I'd like to find which is causing
+random crashes. I expect this will not be too hard to locate. There
+are some more trivial bugs, but the release will not be held up for
+them.
+
+Forty-three packages of GNU software have been built native.
+Remaining to be built are three packages for which new releases are
+expected soon.
+
+Also remaining to be built native are bash, gdb, mach, the Hurd
+itself, and the internet utilities and daemons. We intend to sync our
+separate copy of libc source with the libc maintainer, and then build
+it native too.
+
+Because of obnoxious export restrictions, we have still to make
+separate shared libraries for the crypt functions.
+
+Except for the actual final packaging, all the release engineering
+tasks to be done have been completed.
+
+
+To summarize, we still need to:
+
+o Fix one obnoxious bug
+o Compile three packages that are waiting for release;
+o Compile gdb, bash, mach, and hurd native
+o Sync libc source and compile native
+o Deal with crypt shared libraries
+o Final packaging
+
+Michael
+
+From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
+Newsgroups: gnu.misc.discuss
+Subject: Re: Hurd--ne plus ultra of vaporware?
+Date: 17 Jul 1996 03:02:14 GMT
+
+In article <4sg6tp$n4t@linux.cs.Helsinki.FI> torvalds@linux.cs.Helsinki.FI (Linus Torvalds) writes:
+
+ Hey! We could also ask some well-known rock-group for one of their
+ lyrics, and use that as the theme song for the Hurd release. And then
+ we could ask shops to stay open longer to sell the Hurd! Whaddaya think?
+ Don't say it has been delayed, just shout so loudly about all the new
+ features that nobody cares about the delay?
+
+Perhaps we could get Morrisey to sing the song. He's very good
+looking. Much better looking than that Mick Jagger fellow.
+
+Or something delicate, like Bach's French Suite in G. That would be
+fun.
+
+In any case, here's the state of the release:
+
+o Everything but nine packages has been compiled native.
+o The random crash bug I alluded to is fixed.
+o We have to build a floppy image for part of the installation instructions.
+
+That's it. I bet you nobody in Redmond has ever made a statement like
+that...
+
+Michael
+
diff --git a/hurd-flash13 b/hurd-flash13
new file mode 100644
index 00000000..a2de6bfd
--- /dev/null
+++ b/hurd-flash13
@@ -0,0 +1,120 @@
+Date: Mon, 5 Aug 1996 22:36:31 -0400
+From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG)
+To: info-gnu@prep.ai.mit.edu, hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu
+Subject: Hurd 0.0 and GNU 0.0 released
+X-Name-Change: My name used to be `Michael'; now it is `Thomas'.
+X-Tom-Swiftie: "I guess I shouldn't have broken the mirror," Tom reflected.
+
+
+
+
+I am pleased to announce version 0.0 of the GNU Hurd, available via
+anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file
+/pub/gnu/hurd-0.0.tar.gz (about 1.2 MB compressed).
+
+This file contains complete source code for the following:
+
+Hurd servers:
+
+ auth, crash, devio, devport, exec, ext2fs, fifo, fwd, ifsock, init,
+ magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term,
+ ufs.
+
+Hurd libraries:
+
+ diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps,
+ shouldbeinlibc, store, threads, trivfs.
+
+Hurd utilities and other programs:
+
+ boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts,
+ storeinfo, login, w, uptime, hurdids, loginpr, sush, vmstat,
+ portinfo, devprobe, reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs,
+ stati.ufs, getty, rc.
+
+
+------
+
+
+In addition, we have prepared a binary distribution of a complete
+version 0.0 GNU system corresponding to this Hurd release. This
+release runs only on PC-AT compatible systems with i[345]86
+processors.
+
+The GNU Hurd, plus Mach, is a kernel, not an operating system. The
+GNU operating system, like the Unix operating system, consists of many
+components, including kernel, libraries, compilers, assembler, shell,
+parser generators, utilities, window system, editors, text formatters,
+and so on. The GNU project set out a decade ago to develop this
+system, and we've been writing various components of it ever since.
+
+This release uses the `UK22' version of the Mach kernel, as
+distributed by the University of Utah. It is too difficult to prepare
+a detailed list of supported devices at this point. Common disk
+controllers and ethernet cards are generally supported.
+
+This release does not contain the X Window System.
+
+This release may be fetched by anonymous FTP from prep.ai.mit.edu
+[18.159.42] in the directory /pub/gnu/gnu-0.0/.
+
+In that directory, you should find the following files:
+
+ README
+ SOURCES
+ INSTALL-binary
+ grub-boot.image (about 1.4 MB, not compressed)
+ gnu-0.0.tar.gz (about 56.9 MB compressed)
+ gnu-0.0-stripped.tar.gz (about 26.2 MB compressed)
+
+SOURCES contains a complete list describing the sources for the
+binaries found in the image. INSTALL-binary contains complete
+installation instructions for this release.
+
+(The files README, SOURCES, and INSTALL-binary are also found in the
+root directory of the gnu-0.0 release.)
+
+gnu-0.0.tar.gz holds the image of the complete system. It unpacks
+into a directory that requires approximately 233 MB of disk space.
+
+gnu-0.0-stripped.tar.gz holds the same contents as gnu-0.0, except
+that executable programs have been stripped to save space, and the
+libraries have had debugging symbols stripped to save space and speed
+linking. It unpacks into a directory that requires about 85.5 MB of
+disk space.
+
+We recommend using the unstripped image, or you will be unable to
+debug anything. Surely there are bugs. So fetch the unstripped
+image, at least to have around.
+
+grub-boot.image is an image of a 3.5" floppy disk that you will need
+in order to complete part of the installation instructions.
+
+The following free software packages are found in this release:
+
+ autoconf, automake, bash, bc, binutils, bison, cpio, cvs, diffutils,
+ doschk, e2fsprogs, ed, emacs, fileutils, findutils, flex, from, gawk,
+ gcal, gcc, gdb, gdbm, gettext, glibc, gmp, gperf, grep, grub, gzip,
+ hello, hurd, indent, inetutils, less, mach, make, m4, miscfiles,
+ ncurses, nethack, nvi, patch, ptx, rcs, readline, recode, sed,
+ serverboot, sharutils, shellutils, tar, termcap, termutils, texinfo,
+ textutils, time, wdiff.
+
+
+------
+
+
+Here are md5sum checksums for the files mentioned in this message:
+
+b5f888bab3eb193fe97a00a141324c9d INSTALL-binary
+345dcd826747d7b11fc78f4db162d75b README
+1a5744bb4ed3448045fa6d24153d65fe SOURCES
+f7b1bc428bc4ee29977a5b28f5762092 gnu-0.0-stripped.tar.gz
+24554c58e5c89f295176e17d21dbae8e gnu-0.0.tar.gz
+8338c619d860b71bc4128c9c0fd39d63 grub-boot.image
+1fd18ccc4c81d051b83d28b13dc07ee2 hurd-0.0.tar.gz
+
+-----
+
+Br. Thomas Bushnell, n/BSG
+
diff --git a/hurd-flash14 b/hurd-flash14
new file mode 100644
index 00000000..2d67687a
--- /dev/null
+++ b/hurd-flash14
@@ -0,0 +1,62 @@
+I am pleased to announce version 0.2 of the GNU Hurd, available via
+anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file
+/pub/gnu/hurd-0.2.tar.gz (about 1.37 MB compressed).
+
+(The GNU Hurd, plus Mach, is a kernel, not an operating system. The
+GNU operating system, like the Unix operating system, consists of many
+components, including kernel, libraries, compilers, assembler, shell,
+parser generators, utilities, window system, editors, text formatters,
+and so on. The GNU project set out a decade ago to develop this
+system, and we've been writing various components of it ever since.)
+
+This release contains many bug fixes from version 0.1. Many thanks to
+all the people who are helping find bugs!
+
+The best way you can help find bugs is to try and compile and use on
+the Hurd as many programs as you can find and find out where bugs
+still exist. There are also unimplemented features, and your reports
+will help us to prioritize which things we work on.
+
+The system is vastly more reliable than it has been in the past.
+
+One important addition:
+
+ New programs addauth, rmauth, unsu, su, and setauth modify the uid
+ sets of running programs. Using addauth you can add root to your
+ emacs, write a file, and then use rmauth to take the uid back. (Of
+ course, passwords are required when necessary.) New program `ids'
+ will tell you what all the user ids are that a program has. Note
+ that in the Hurd a program can have several user ids all at once,
+ just like Unix supports having several group ids. Now that you can
+ dynamically change the ids of running programs, system
+ administration (among other things) becomes much easier.
+
+For more detailed news, see the NEWS file in the distribution.
+
+This release contains complete source code for the following:
+
+Hurd servers:
+
+ auth, crash, devport, exec, ext2fs, fifo, fwd, ifsock, init,
+ magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term,
+ ufs, storeio, firmlink.
+
+Hurd libraries:
+
+ diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps,
+ shouldbeinlibc, store, threads, trivfs, hurdbugaddr, ftpconn
+
+Hurd utilities and other programs:
+
+ boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts,
+ storeinfo, login, w, uptime, ids, sush, vmstat, portinfo, devprobe,
+ reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs, stati.ufs, getty,
+ rc, e2os, vminfo, nfsd, mail.local, serverboot, MAKEDEV, loginpr,
+ addauth, rmauth, unsu, setauth, ftpcp, ftpdir.
+
+We are also making a complete GNU 0.2 binary release, which will
+include Hurd 0.2, glibc 2.0.4, gnumach 1.1.2, and many other
+programs. This binary release is announced separately.
+
+
+Thomas Bushnell, n/BSG
diff --git a/hurd-flash15 b/hurd-flash15
new file mode 100644
index 00000000..0785ac59
--- /dev/null
+++ b/hurd-flash15
@@ -0,0 +1,60 @@
+
+I am pleased to announce version 0.2 of the complete Hurd based GNU
+system. This release runs only on PC-AT compatible systems with
+i[3456]86 processors.
+
+The GNU Hurd, plus Mach, is a kernel, not an operating system. The
+GNU operating system, like the Unix operating system, consists of many
+components, including kernel, libraries, compilers, assembler, shell,
+parser generators, utilities, window system, editors, text formatters,
+and so on. The GNU project set out a decade ago to develop this
+system, and we've been writing various components of it ever since.
+
+This release uses the GNUmach distribution of the Mach kernel, version
+1.1.3. Popular PC devices are generally supported.
+
+This release does not contain the X Window System.
+
+This release may be fetched from the directory
+ftp://prep.ai.mit.edu/pub/gnu/gnu-0.2. (prep.ai.mit.edu is 18.159.42,
+for the nameserver-impaired).
+
+In that directory, you should find the following files:
+
+README
+SOURCES
+INSTALL-binary
+grub-boot.image (about 1.5 MB, not compressed)
+gnu-0.2.tar.gz (about 73 MB compressed)
+
+SOURCES contains a complete list describing the sources for the
+binaries found in the image. INSTALL-binary contains complete
+installation instructions for this release.
+
+(The files README, SOURCES, and INSTALL-binary are also found in the
+root directory of the gnu-0.2 release.)
+
+gnu-0.2.tar.gz holds the image of the complete system. It unpacks
+into a directory that requires approximately 285 MB of disk space.
+
+grub-boot.image is an image of a 3.5" floppy disk that you will need
+in order to complete part of the installation instructions.
+
+The following free software packages are included in this release:
+
+autoconf automake bash bc binutils bison cpio cvs diffutils doschk
+e2fsprogs ed emacs emacs lisp manual fileutils findutils flex from g77
+gawk gcal gcc gdb gettext glibc gmp gnuchess gnumach gnugo grep grub
+gzip hello hurd indent inetutils less libg++ lynx m4 make miscfiles
+ncurses nethack nvi patch perl ptx readline rcs recode sed sendmail
+sh-utils sharutils tar termutils texinfo textutils time wdiff
+
+--
+
+Here are md5sum checksums for the files mentioned in this message:
+
+3749b016ab581e007b90d17b9092e134 INSTALL-binary
+1f800c326ba4c3a0b3f3a3463597317b README
+40d1e1a38dd86f28fe2718081ac865cb SOURCES
+f29c1a03c1667a8019b66f6effa89d39 gnu-0.2.tar.gz
+8ad3c7254802a16068a956e836266212 grub-boot.image
diff --git a/hurd-flash2 b/hurd-flash2
new file mode 100644
index 00000000..b1d4f66f
--- /dev/null
+++ b/hurd-flash2
@@ -0,0 +1,152 @@
+From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
+Newsgroups: gnu.misc.discuss,comp.os.mach,comp.os.linux.development,comp.os.linux.misc,comp.unix.pc-clone.32bit
+Subject: GNU Hurd Task List and Call for Volunteers
+Followup-To: gnu.misc.discuss
+Date: 18 May 1994 17:54:47 GMT
+Organization: FOO
+Lines: 140
+Message-ID: <MIB.94May18135447@churchy.gnu.ai.mit.edu>
+NNTP-Posting-Host: churchy.gnu.ai.mit.edu
+Xref: usenet.ee.pdx.edu gnu.misc.discuss:7630 comp.os.mach:1434 comp.os.linux.d
+evelopment:9867 comp.os.linux.misc:16767 comp.unix.pc-clone.32bit:5854
+
+
+Now that the Hurd can run (albeit haltingly) on its own, it is
+possible for people who do not have Mach 3.0 single-servers to
+contribute without much trouble. (However, if you don't have a
+single-server, you probably won't be able to use a debugger, but that
+doesn't mean you can't do debugging, right?)
+
+We at the FSF don't have any expertise in setting up Mach 3.0
+machines; the machines that we do development on belong to the Open
+Software Foundation and were set up by them. So one of the things on
+the task list is to organize things so that people (like us and most
+of you) who don't know how to do it can do it. It's not impossible to
+figure out, it's just a pain and a marvelous thing for a volunteer to
+do.
+
+You can get Mach 3.0 from CMU; you get the C library and the Hurd from
+us. You need the soon-to-be-released version 1.07.6 of the C library
+and the latest Hurd snapshot (as well as our special version of MiG)
+from alpha.gnu.ai.mit.edu.
+
+All our work is based upon i386. The Hurd (except for a few programs;
+see the Hurd README file) is machine independent. The C library
+should not be too much trouble to port. Ports and information about
+porting difficulty for either of these are greatly desired.
+
+The Hurd is not yet self-hosting. While you are welcome to fetch the
+code and put things together, it is not likely that you will have a
+useful system right now. But you might be able to do significant work
+(see the task list below). And, even if you can't do significant
+work, I'm interested in hearing about any places where you had
+particular difficulty.
+
+If you want to start on one of these tasks, please let me know so I
+can keep track of volunteers properly. This task list will be updated
+periodically; gnu@prep.ai.mit.edu always has the latest version.
+
+ -mib
+
+GNU Hurd Task List Version 1.0.
+
+If you would like to work on one of these, please contact mib@gnu.ai.mit.edu.
+
+
+Mach 3.0 Work
+
+ o Mach 3.0 comes with CMU makefiles that depend on a drecky environment.
+ It would be very helpful to have makefiles and installation stuff so
+ that it worked well for cross-compilation between systems and used
+ GNU tools.
+
+ o MiG needs to be made able to support cross-compilation.
+
+ o A replacement for MiG that understood C .h files.
+
+ o Bootstrap tools and documentation to help people set up Mach 3.0
+ machines if they already have Linux; if they already have Net BSD;
+ if they don't have anything.
+
+ o Mach 3.0 needs to provide support for task virtual timers similar
+ in functionality to the Unix ITIMER_PROF and ITIMER_VIRTUAL timers.
+
+ o Mach 3.0 needs to provide a way for users to do statistical PC
+ profiling similar to the Unix profil system call.
+
+ o Mach 3.0 needs a facility to automatically send task and thread
+ status on task/thread exit to a port that can only be changed by
+ a privileged user; this would be used to implement process
+ accounting.
+
+ o Mach 3.0 needs a facility to find out what task is the parent of
+ a given task.
+
+ o Mach 3.0 needs a facility to find out which pages of a task's
+ address space are in core to implement Unix's mincore call.
+
+ o Mach 3.0 needs a facility to do msync.
+
+ o Mach 3.0 needs a replacement for MEMORY_OBJECT_COPY_CALL that
+ works at least for the cases needed in ordinary files. (Write mib if
+ you want to know what the problem is and some ideas about how to
+ solve it.)
+
+ o Mach 3.0 needs proxy memory objects. (mib can tell you what these
+ are and why they are important.)
+
+ o Mach 3.0 needs a way to do per-task resource counters that are
+ accessible to servers called by the task.
+
+ o Mach 3.0 needs facilities to implement resource limits of various sorts.
+
+ o Mach 3.0 needs a way to have a thread's CPU time statistics
+ include time spent by servers on its behalf.
+
+ o Of course, free ports are always necessary to machines that don't
+ already have free ports.
+
+ o Much work can be done doing research in how to improve Mach VM
+ performance and timesharing scheduling policy.
+
+
+Hurd work (these are brief descriptions; mib can give more information):
+
+ o We need a translator for /dev.
+
+ o We need a replacement for utmp and wtmp that understands the
+ Hurd `login collection' concept. Programs like who and finger
+ then need to be changed to use this.
+
+ o We need some existing shell programs changed to do Hurd things:
+ like ls, su, fsck, tar, cpio, etc.
+
+ o Some new programs need to be written: login, getty, ps, tools
+ for new filesystem features.
+
+ o Shadow directory translators. (Roland has the beginnings of this.)
+
+ o A system for write, send, talkd and so forth to bleep users;
+ this should be integrated with the utmp replacement above.
+
+ o X.
+
+ o A filesystem for /tmp that uses virtual memory instead of disk.
+
+ o Filesystem implementations (using libdiskfs) for other popular
+ formats, especially the Linux formats as well as MSDOG.
+
+ o Transparent FTP translator.
+
+ o NFS client implementation. You should start with BSD's 4.4 code
+ and support the extensions they support; don't worry about Hurd
+ extensions right now. (The server we want to write ourselves
+ because it will probably involve changing the Hurd interfaces.)
+
+ o A fancy terminal driver that uses readline and supports detach/attach.
+
+--
++1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David,
++1 617 253 8568 (W) -+- and Jonathan loved him as his own soul.
+1105 Broadway | Then Jonathan made a covenant with David
+Somerville, MA 02144 | because he loved him as his own soul.
diff --git a/hurd-flash3 b/hurd-flash3
new file mode 100644
index 00000000..19a5f371
--- /dev/null
+++ b/hurd-flash3
@@ -0,0 +1,77 @@
+Date: Tue, 05 Jul 1994 20:15:09 -0400
+From: mib@gnu.ai.mit.edu (Michael I Bushnell)
+To: hurd-ann@gnu.ai.mit.edu
+Subject: New Hurd snapshot
+
+
+A new Hurd snapshot has been released. You can get it from
+alpha.gnu.ai.mit.edu in the file /gnu/hurd-snap.tar.gz. You will need
+the most recent version of the GNU C library; version 1.08.3 or later.
+(Version 1.08.3 is an alpha release; you can get it from
+alpha.gnu.ai.mit.edu in the same directory.)
+
+This snapshot of the Hurd has a limping terminal driver. It can run
+emacs, bash, a whole slew of utilities, and (most importantly) GNU
+Hello.
+
+ -mib
+
+
+Here is the new part of the NEWS file:
+
+The Hurd now runs all the programs in the GNU fileutils, textutils,
+and shellutils distributions, with the exception of who. Most
+importantly it runs GNU Hello. Also, emacs works (with the kludgy
+`boot' terminal driver) and bash works.
+
+The simple pipes server works; it will be replaced eventually by the
+pflocal server (which isn't done yet). The terminal driver is limping
+but working. It doesn't support terminal ioctls yet. A minor bug in
+auth has been fixed. boot interprets more Hurd protocols; this was
+done to get emacs functioning. Some more-or-less serious bugs in exec
+were fixed; they were found by running emacs (a quite large executable
+indeed). At bootstrap time, init starts pipes and term itself;
+eventually these will be passive translators, but we don't want to
+write the new disk format until we're self-hosting or fsck and UX will
+get confused. The file proc/primes.c has been documented; thanks go
+to Jim Blandy. Some bugs in proc dealing with pgrp and wait were
+fixed; a nasty hash table bug was also fixed. The simple shell can do
+pipes. Several serious bugs in ufs were fixed dealing with extension
+of large files and writes of data not aligned on block boundaries.
+The ufs pager was over-serialized; that's been fixed. Directory
+lookups and modifications now use mapped I/O directly; this is an
+important speed-up. The structure of the pager lockes has been
+changed significantly. UFS now supports Mach copying mode
+MEMORY_OBJECT_COPY_DELAY; this significantly improves process startup
+time.
+
+Some minor changes have been made to several interfaces. The
+interface for fs.defs:dir_readdir has been totally changed. There are
+some new fs.defs interfaces: file_check_access, file_notice_changes,
+dir_notice_changes. The fsys.defs:fsys_getroot interface was changed
+to work correctly. process.defs:proc_setprocargs is renamed, and a
+fetch function proc_get_arg_locations is added. The ifsock.defs
+interface was simplified.
+
+Several bugs were fixed in libdiskfs. The new dir_readdir interface
+requires new support from format-specific code. Some race conditions
+have been fixed. dir-pathtrans.c now deals correctly with multiple
+slashes in a row. A new concept called "light references" allows
+pagers to remain active without preventing truncate-on-nolinks from
+working right. New interfaces in fs.defs are implemented (except
+file_notice_changes). Active translator usage has been fixed to work
+correctly, but passive translators are still untested. libdiskfs now
+thinks it supports S_IFSOCK nodes, but that's untested (of course)
+because pflocal isn't done yet.
+
+The passive translator startup interface in libfshelp has been
+radically simplified. The pager library now lets other code set and
+changee the attributes on objects, synchronously if desired. An
+init/terminate race condition was fixed. The ports library now
+allows single-threaded users to work right (they didn't before). The
+trivfs library works; see the ifsock server for a simple example of
+its use. See term or pipes for more complex examples.
+
+There is a task list in the file `tasks'; let me know if you are
+interested in working on one of these.
+
diff --git a/hurd-flash4 b/hurd-flash4
new file mode 100644
index 00000000..89ae9848
--- /dev/null
+++ b/hurd-flash4
@@ -0,0 +1,101 @@
+From: mib@gnu.ai.mit.edu (Michael I Bushnell)
+To: hurd-ann@gnu.ai.mit.edu
+Date: Mon, 8 Aug 94 16:01:23 -0400
+Subject: New Hurd Snapshot
+X-Shopping-List:
+ (1) Starboard sauce (2) Cinematic lesions (3) Two-way alphabetic
+ accordions
+
+
+A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu in
+/pub/gnu/hurd-snap.tar.gz.
+
+It is expected that the next snapshot after this one will have signals
+basically working and thus be usable for a self-hosting system. In
+addition, the next snapshot will probably have the current state of
+our networking code (which has been proceeding, but has been absent
+from the snapshots).
+
+Here is the NEWS about this current snapshot, however. Because some
+big changes were made to the makefile and directory structure, things
+might have gotten inadvertently ommitted from the snapshot. If this
+happened, please let me know ASAP and I'll fix it and make a new
+snapshot.
+
+ -mib
+
+
+August 8, 1994:
+
+Structural changes:
+
+Makefiles have been vastly improved and are simpler. The programs
+`su', `ps', and `sh' have been moved from separate dirs into `utils';
+the programs `symlink' and `ifsock' have been moved into `trans'.
+
+Several changes were made to GCC use. You should definitely get GCC
+version 2.6.0 now. Version 2.6.1 will have distributed the proper
+`specs' file for the i386-gnu target, but it isn't quite ready yet, so
+you still have to copy hurd/gcc-specs into
+gcc-lib/i386-gnu/2.6.0/specs.
+
+
+Interface changes:
+
+The tioctl.defs suite is complete now.
+
+INTR RPC's have been changed; individual RPC's are no longer marked
+INTR. Rather, entire interfaces are marked `INTR_INTERFACE' if they
+conform to the library's signalling/interruption expectations.
+
+There is a new magical retry type (for dir_pathtrans and fsys_getroot)
+called `machtype' and a new one `/'; the former is for @sys tweaks and
+the latter cleans up the retry of root-based symlinks a bit.
+
+There is a new interface `login.defs'.
+
+The "dotdot node" is no longer passed at fsys_startup time; instead,
+it is passed by fsys_getroot.
+
+
+Library changes:
+
+The ports library now does death-timeouts for multi-threaded servers;
+it doesn't actually work right yet, however. Also the ports library
+has new features (soft vs. hard ports; no outstanding ports
+notifications) that enable server-death to be done cleanly. (I hope;
+libdiskfs and ufs haven't yet been changed to use it, so libports
+might not actually have the right facilities yet.)
+
+The translator startup routines in libfshelp have been vastly improved
+(so that they can actually be used).
+
+Numerous bugfixes in libdiskfs, particularly relating to translator
+usage. Use new magical retry type `/' when appropriate. Use new
+dotdot node protocol. O_FSYNC and O_NOATIME are now honored properly.
+Alternative methods of storing symlinks are now supported through new
+hooks.
+
+The new dotdot protocol is now used by libtrivfs. Also, users of the
+library are now able to set the atime and mtime when necessary.
+
+The special threads version of malloc has been placed back in
+libthreads now that the C library uses a Mach-safe version on its own.
+
+
+Program changes:
+
+The `boot' program no longer implements the tioctl interface now that
+the terminal driver works.
+
+A bug was fixed in the handling of pgrps in `proc'.
+
+Many bugfixes in term. The tioctl interface is now implemented. EOF
+processing is fixed; break characters now work right. Signals and
+interruption are now done correctly. VDISCARD works.
+
+Ufs has Some bigs fixed in dir.c. Filesystem upgraded to BSD 4.4.
+There are now some compatibility flags.
+
+New program dev.trim does a very minimal /dev (but doesn't work yet).
+New program dev is an initial (but poor) attempt at a real /dev.
diff --git a/hurd-flash5 b/hurd-flash5
new file mode 100644
index 00000000..041a0ef7
--- /dev/null
+++ b/hurd-flash5
@@ -0,0 +1,23 @@
+From: mib@gnu.ai.mit.edu (Michael I Bushnell)
+Message-Id: <9409210619.AA17570@churchy.gnu.ai.mit.edu>
+To: "Lots of potentially interested people and" <nobody@gnu.ai.mit.edu>
+Subject: New milestone acheived by the GNU Hurd
+X-Tom-Swiftie: "I can't get this fire started," Tom said woodenly.
+
+
+I have just successfully compiled and run a null C program on the
+Hurd. This is using GCC native as one would normally use GCC.
+
+Sadly, it took quite a while (too long, in fact) to read the large
+archives that make up the GNU C library, but I think I know where the
+substantial inefficiency is.
+
+Once that is done, I would be happy to label this a "self-hosting
+system". But not just yet.
+
+The last bug preventing this was an error in dealing with files over
+about 8 M; this came about because in order to link a program one
+needed the GNU C library, which is over 9M when symbols are included.
+
+ -mib
+
diff --git a/hurd-flash6 b/hurd-flash6
new file mode 100644
index 00000000..e774714e
--- /dev/null
+++ b/hurd-flash6
@@ -0,0 +1,46 @@
+Return-Path: <pdxgate.cs.pdx.edu!gnu.ai.mit.edu!mib>
+Received: from pdxgate.cs.pdx.edu by gnurd with uucp
+ (Linux Smail3.1.28.1 #14) id m0r66pm-00010fC; Fri, 11 Nov 94 17:00 PST
+Received: from cs.pdx.edu by pdxgate.cs.pdx.edu (4.1/CATastrophe-9/19/94-U)
+ id AA05257; Fri, 11 Nov 94 16:40:48 PST
+Received: from churchy.gnu.ai.mit.edu by cs.pdx.edu (4.1/CATastrophe-9/19/94-P)
+ id AA02600; Fri, 11 Nov 94 16:40:22 PST
+Received: by churchy.gnu.ai.mit.edu (5.65/4.0)
+ id <AA12621@churchy.gnu.ai.mit.edu>; Fri, 11 Nov 94 16:45:35 -0500
+Received: by churchy.gnu.ai.mit.edu (5.65/4.0)
+ id <AA12580@churchy.gnu.ai.mit.edu>; Fri, 11 Nov 94 16:38:44 -0500
+Date: Fri, 11 Nov 94 16:38:44 -0500
+From: mib@gnu.ai.mit.edu (Michael I Bushnell)
+Message-Id: <9411112138.AA12580@churchy.gnu.ai.mit.edu>
+To: hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu, info-gnu@prep.ai.mit.edu
+Subject: New Hurd Snapshot
+X-Shopping-List:
+ (1) Horrendous collision devotions (2) Wondrous consolation (3)
+ Conscious cooking auctions
+X-Filter: mailagent [version 3.0 PL19] for trent@gnurd.uu.pdx.edu
+
+
+A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu. There
+may be unforseen problems with this snapshot, so the old one has been
+left. You may fetch this snapshot via anonymous FTP in the file
+/gnu/hurd-snap.tar.gz.
+
+The Hurd requires a modified version of MiG; you can get it by
+anonymous ftp to kahlua.cs.utah.edu in /pub/mach/mach4-UK02p6.tar.gz.
+Note that we are not yet using Mach4 for the Hurd, but we plan to
+switch as soon as its feasible.
+
+Other necessary software to run this snapshot include the latest
+snapshot of binutils/ld/gas source from Cygnus and the latest GCC.
+(Problems have been reported with GCC 2.6.1; you might want to wait
+until 2.6.2 is released.) And, of course, you also need the latest
+test version of the GNU C Library, found on alpha.gnu.ai.mit.edu.
+
+This is not yet a real release; it is certainly not up to the quality
+of even a hesitant alpha release. But it may be useful for
+educational value or to help with the Hurd effort.
+
+I will be out of town for most of the rest of the year; I will be
+reading email but I may not be able to help with problems. Sorry...
+
+ -mib
diff --git a/hurd-flash7 b/hurd-flash7
new file mode 100644
index 00000000..ce6e08d2
--- /dev/null
+++ b/hurd-flash7
@@ -0,0 +1,17 @@
+Date: Wed, 12 Apr 1995 15:08:18 -0400
+From: Michael I Bushnell <mib@gnu.ai.mit.edu>
+To: hurd-ann@duality.gnu.ai.mit.edu
+Subject: New Hurd Snapshot available
+
+A new hurd snapshot is now available from
+ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap.tar.gz.
+
+This snapshot contains many improvements over the last one, and is
+also probably easier to compile.
+
+This snapshot must be used with the most recent libc snapshot,
+ftp://alpha.gnu.ai.mit.edu/gnu/libc-950411.tar.gz. Previous versions
+of the library will not work right.
+
+If any files are discovered to be missing, please let me know asap.
+
diff --git a/hurd-flash8 b/hurd-flash8
new file mode 100644
index 00000000..555186ec
--- /dev/null
+++ b/hurd-flash8
@@ -0,0 +1,73 @@
+Date: Sun, 23 Jul 1995 16:27:46 -0400
+Message-Id: <199507232027.QAA09306@geech.gnu.ai.mit.edu>
+From: Michael I Bushnell <mib@gnu.ai.mit.edu>
+To: hurd-ann@gnu.ai.mit.edu
+Subject: Hurd snapshot!
+X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+
++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv
++ b+++ !D B-- e+ u++(*) h* f? r n y++
+X-Zippy-Says: I just had a NOSE JOB!!
+Sender: owner-abshurd@cs.pdx.edu
+Precedence: bulk
+
+
+I have just put a new Hurd snapshot on alpha.gnu.ai.mit.edu in
+/gnu/hurd-snap-950723.tar.gz.
+
+You will also need the new libc snapshot, which should appear in the
+same place today. Older libc snapshots will not be happy.
+
+The binary images (hurd-floppy.fs.gz and hurd-image.tar.gz) have not
+been updated. It is difficult to use the Hurd standalon, because the
+Mach boot loaders can now no longer boot the Hurd. A new boot loader
+is nearly finished. Perhaps we can make new binary images then, or a
+volunteer might take over this useful work. (Hint, hint.)
+
+Michael
+
+
+
+Here is the NEWS:
+
+July 23, 1995
+
+Shared libraries now work; use -static to link programs and avoid the
+shared libraries. The Hurd programs are normally built static; this
+will probably change soon.
+
+The ext2fs server now works, as do the tools to manipulate ext2fs
+filesystems. A snapshot of the tools will be made soon under separate
+cover. Many thanks to Ted Ts'o for his valuable work on the tools.
+
+Readers of the Makefiles will notice that we now generate dependencies
+automatically.
+
+The old netserv library is gone.
+
+The `boot' hack has been modified slightly to avoid the normalq libc startup
+files, because they no longer work with UX.
+
+Some small bugs have been fixed in the devio server.
+
+The ports library has been totally rewritten; new features permit
+servers to have greater control over thread RPC's and port creation.
+
+The fshelp library now does most of the work for translator
+interaction; it's simpler now too. Filesystems have much less work to
+do; the relevant code in libdiskfs is now understanble instead of
+unparseable chaos.
+
+The ports library provides for timeouts; the diskfs library almost
+uses it, but because of a bug, it's disabled for now.
+
+Filesystems are now expected to sync themselves if necessary; the new
+fsys_set_options RPC provides for changeing (or cancelling) the sync
+intervale. The diskfs library does this for you. The update program
+is no longer necessary.
+
+A small bug in the proc server has been hacked around; the real fix
+will come later.
+
+Many important bugs in the C library have been fixed since the last
+snapshot; perhaps all of them. ;-)
+
diff --git a/hurd-flash9 b/hurd-flash9
new file mode 100644
index 00000000..1ff32ba9
--- /dev/null
+++ b/hurd-flash9
@@ -0,0 +1,39 @@
+Date: Wed, 29 Nov 1995 13:13:23 -0500
+Message-Id: <199511291813.NAA10983@duality.gnu.ai.mit.edu>
+From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
+To: hurd-ann@gnu.ai.mit.edu (and others)
+Subject: Announcement
+X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+
++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv
++ b+++ !D B-- e+ u++(*) h* f? r n y++
+X-Windows: The Cutting Edge of Obsolescence.
+Sender: owner-abshurd@cs.pdx.edu
+Precedence: bulk
+
+
+The Hurd has succesfully completed its first FTP:
+
+bash# ftp 128.52.46.31
+Connected to 128.52.46.31.
+220 albert.gnu.ai.mit.edu FTP server (Version 5.60) ready.
+Name (128.52.46.31:root):
+331 Password required for root.
+Password:230 User root logged in.
+ftp> cd ~mib
+250 CWD command successful.
+ftp> get ftptest
+200 PORT command successful.
+150 Opening ASCII mode data connection for ftptest (16 bytes).
+226 Transfer complete.
+17 bytes received in 0.07 secs (0.24 Kbytes/sec)
+ftp> quit
+221 Goodbye.
+bash# cat ftptest
+this is a test.
+bash#
+
+
+Tre cool.
+
+Michael
+
diff --git a/hurd-folks.html b/hurd-folks.html
new file mode 100644
index 00000000..14dcaf83
--- /dev/null
+++ b/hurd-folks.html
@@ -0,0 +1,78 @@
+<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML>
+<HEAD>
+<TITLE>GNU&nbsp;Hurd folks - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<H3>GNU&nbsp;Hurd folks</H3>
+<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg"
+ ALT=" [image of a Hurd Metafont Logo] "
+ WIDTH="333" HEIGHT="80">&#32;(jpeg 10k)</A>
+<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A>
+<A HREF="/philosophy/gif.html">no gifs due to patent problems</A>
+<P>
+
+A number of people maintain their own unofficial <A
+HREF="hurd.html">GNU&nbsp;Hurd</A> pages to describe their involvements.
+These are valuable sites because they help introduce more people to
+the Hurd, and to the <A HREF="/gnu/gnu-history.html">GNU project</A>.
+
+<P>
+
+Send mail to <A HREF="http://www.fig.org/~gord/">Gordon Matzigkeit</A> <A
+HREF="mailto:gord@gnu.org">&lt;gord@gnu.org&gt;</A> if you have a page
+you would like added to this list.
+
+<P>
+
+Thank GNU to everybody who has contributed to the Hurd's development!
+
+<EM>
+These links are at other web sites not maintained by the FSF.
+<BR>
+The FSF is not responsible for the content of these other web sites.
+</EM>
+<P>
+
+<UL>
+ <LI><A HREF="http://www.rr.iij4u.or.jp/~kkojima/">kaz Kojima</A>
+ ported the Hurd to the <A
+ HREF="http://www.rr.iij4u.or.jp/~kkojima/hurdmips.html">MIPS
+ R3000 and R4000</A> processors.
+
+ <LI><A HREF="http://www-mbi3.kuicr.kyoto-u.ac.jp/~okuji/">
+ OKUJI Yoshinori</A> maintains a set of <A
+ HREF="http://www-mbi3.kuicr.kyoto-u.ac.jp/~okuji/hurd.html">Japanese
+ Hurd pages</A>.
+
+ <LI><A HREF="http://f77.nop.or.jp/">UCHIYAMA Yasushi</A> has ported
+ XFree86 to the Hurd.
+
+</UL>
+
+<HR>
+
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+FSF &amp; GNU inquiries &amp; questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF.
+<P>
+Comments on these web pages to
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1998 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.<P>
+Updated:
+<!-- hhmts start -->
+Last modified: Tue Sep 11 08:01:49 CEST 2001
+<!-- hhmts end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/hurd-fs-org b/hurd-fs-org
new file mode 100644
index 00000000..ba515623
--- /dev/null
+++ b/hurd-fs-org
@@ -0,0 +1,219 @@
+From: mib@duality.gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
+Newsgroups: gnu.misc.discuss
+Subject: Re: GNU vs. Linux FSSTND conflict?
+Date: 13 Aug 1995 22:31:18 GMT
+Organization: Free Software Foundation, Cambridge, MA
+In-reply-to: Rick Niles's message of 13 Aug 1995 16:20:29 GMT
+
+In article <40l8od$ia9@news4.digex.net> Rick Niles <niles@axp745.gsfc.nasa.gov>
+ writes:
+
+ Is there a conflict between the GNU Filesystem Structure and
+ the Linux Filesystem Structure (FSSTND)?
+
+What you point out is the trivial difference; there are significant
+lossages in FSSTND, such as the absence of libexec...
+
+ I've heard on this newsgroup that the GNU std. is to elminate
+ the use of /usr. So:
+
+ I guess the first question is: Is this true?
+
+Yes.
+
+ If it is how do you answer those who say the root part. should
+ be small and only enough to boot the system? And
+ the rest of the system should be on a separate part. (/usr)
+
+In GNU the directory /bin will be an amalgam of several directories;
+this well be done by the use of a translator in the Hurd. (It will be
+similar to BSD shadow filesystems.)
+
+So we have no need to confuse users by putting binaries in two
+different places. We can put different binaries in different physical
+locations without either forcing them to appear in different places or
+creating a forest of symlinks.
+
+But the FSSTND's arguments are bogus even for Unixoid systems which do
+force differently located files to have different directory names:
+
+ o It is often mounted from very small media. For example, many Linux
+ users install and recover systems by mounting root off a RAM disk,
+ which is copied from a single 1.44M or 1.2M floppy disk.
+
+This is a non-issue. Obviously a floppy can only have a small number
+of files, but that's totally irrelevant in deciding what should be on
+root on a fully loaded system.
+
+ o The root filesystem has many system-specific configuration files in
+ it. Possible examples include a kernel that is specific to the
+ system, a different hostname, etc. This means that the root
+ filesystem isn't always shareable between networked systems.
+ Keeping it small on networked systems minimizes the amount of space
+ lost on servers to unshareable files. It also allows workstations
+ with smaller local hard drives.
+
+It should be possible to require only the etc directory to be
+per-system; there is no reason that bin and such should be non-shared
+at all.
+
+ o While you may have the root filesystem on a large partition, and
+ may be able to fill it to your heart's content, there will be
+ people with smaller partitions. If you have more files installed,
+ you may find incompatibilities with other systems using root
+ filesystems on smaller partitions. If you are a developer then you
+ may be turning your assumption into a problem for a large number of
+ users.
+
+This is totally incoherent, as far as I can tell. If someone can tell
+me what it means, then maybe I could help. What sort of
+incompatibilities are expected?
+
+Michael
+
+
+
+From: gord@enci.ucalgary.ca (Gord Matzigkeit)
+Newsgroups: gnu.misc.discuss
+Subject: Re: GNU vs. Linux FSSTND conflict?
+Date: 14 Aug 1995 18:55:20 -0600
+In-reply-to: mib@duality.gnu.ai.mit.edu's message of 13 Aug 1995 22:31:18 GMT
+
+-----BEGIN PGP SIGNED MESSAGE-----
+
+Hi!
+
+>>>>> "mib" == Michael I Bushnell, p/BSG <mib@duality.gnu.ai.mit.edu> writes:
+
+ mib> In article <40l8od$ia9@news4.digex.net> Rick Niles
+ mib> <niles@axp745.gsfc.nasa.gov> writes:
+[hack & slice]
+
+ >> If it is how do you answer those who say the root
+ >> part. should be small and only enough to boot the system? And
+ >> the rest of the system should be on a separate part. (/usr)
+
+ mib> In GNU the directory /bin will be an amalgam of several
+ mib> directories; this well be done by the use of a translator in the
+ mib> Hurd. (It will be similar to BSD shadow filesystems.)
+
+This is what I figured... my reply didn't get posted to USENET,
+though, because our NNTP server has been down for the last day or two.
+
+ mib> So we have no need to confuse users by putting binaries in two
+ mib> different places. We can put different binaries in different
+ mib> physical locations without either forcing them to appear in
+ mib> different places or creating a forest of symlinks.
+
+This is grand! One of my ideas that I mentioned to Rick was that I'm
+currently using depot, and I see that the GNU union/shadowfs could
+replace that.
+
+What depot does is manages symlinks for a "software environment" (a
+more restricted version of what you have described).
+
+The way I think I'll be setting up my Hurd machine is to have all the
+physical disks mounted under "/disk", each containing a fragment of
+the filesystem.
+
+Now, my only concerns are:
+
+1) control files, as far as determining precedence, and what can and
+cannot be shadowed (for collision resolution), and what is just
+auxilliary info (like CVS directories in the site package, which
+should not be mapped onto the software environment)
+
+2) packages. Is there some slick way to divide the filesystem into
+"package pieces", like depot does?
+
+One suggestion to get (2), is that I could create an intermediate
+directory, say "/package", that would be the union of various mounted
+physical disks (under /disk), and would contain things like:
+
+emacs-19.30/bin
+emacs-19.30/lib...
+gcc-2.7.3/bin...
+fileutils-5.8/man...
+site/sbin/useful_perl_script
+
+et al. Then I would unionfs all the directories in the /package dir
+onto the root filesystem.
+
+This would have most of the advantages I'm getting from depot, namely,
+the ability to specify different precedences on different machines,
+so that I can try out emacs-19.31 on one workstation without
+disrupting the others.
+
+Is there a better way to do this? I do like the idea of three
+different hierarchies for files (under /disk, where I can see what is
+on each server; under /package, where I can see what is in each
+package; the GNU standard dirs, where I actually use the files), but I
+am hoping that there is something more elegant. Hmm. Maybe not.
+
+ mib> It should be possible to require only the etc directory to be
+ mib> per-system; there is no reason that bin and such should be
+ mib> non-shared at all.
+
+This is one point (for security), that would mandate the use of config
+files, so that the unionfs doesn't map /etc/some_important_file from
+another server.
+
+This is yet another thing that I'm looking forward to. Thanks. ;)
+
+- --Gordon
+
+- --
+Gordon Matzigkeit | Heck, it was only a TOASTER... lighten up!
+gord@enci.ucalgary.ca | PGP mail preferred... finger me for my key.
+Keyprint: D5 66 08 E0 4D F4 D7 7B 8A C8 8A 9C 7F 39 25 A7 - ID 339ABEB9
+
+
+-----BEGIN PGP SIGNATURE-----
+Version: 2.6.2
+Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface
+
+iQCVAwUBMC/wcyFsfCEzmr65AQHubwP7BGVHqs9ACB8hFUqDdF2oWu/lLq1hW/Oa
+qra2ZfcKfIZq9hIM4tLRJ0qCaiOVm5MGLgH7Yax+ZyOPb4K0fCObzk1XY5b0enhV
+9SR70UZ7Qm7MXj+PFCp5lxvrNiaFXMbil0EN5FQEvH9kUp0ed1NWcaXGqTK6gezm
+YBUumt2Zadk=
+=6f2c
+-----END PGP SIGNATURE-----
+
+
+
+
+From: mib@duality.gnu.ai.mit.edu (Michael I. Bushnell, p/BSG)
+Newsgroups: gnu.misc.discuss
+Subject: Re: GNU vs. Linux FSSTND conflict?
+Date: 16 Aug 1995 14:43:47 GMT
+In-reply-to: gord@enci.ucalgary.ca's message of 14 Aug 1995 18:55:20 -0600
+
+In article <npka8gj893.fsf@enci.ucalgary.ca> gord@enci.ucalgary.ca (Gord Matzig
+keit) writes:
+
+ The way I think I'll be setting up my Hurd machine is to have all the
+ physical disks mounted under "/disk", each containing a fragment of
+ the filesystem.
+
+Our idea is to do something roughly like this.
+
+ 1) control files, as far as determining precedence, and what can and
+ cannot be shadowed (for collision resolution), and what is just
+ auxilliary info (like CVS directories in the site package, which
+ should not be mapped onto the software environment)
+
+Yes, the relevant translator will support a *rich* set of semantics
+for this kind of things specified by a control file.
+
+ 2) packages. Is there some slick way to divide the filesystem into
+ "package pieces", like depot does?
+
+We're going to do this; rms and I have worked out a usable scheme that
+meets all the necessary goals.
+
+The physical location of files has to be reflected by sharing rules
+(see the GNU makefile standards); users have to be able to see all the
+files relevant to a particular program easily; programs have to be
+easily de-installed. We have a scheme that meets these three.
+
+Michael
diff --git a/hurd-l4.html b/hurd-l4.html
new file mode 100644
index 00000000..f1200e15
--- /dev/null
+++ b/hurd-l4.html
@@ -0,0 +1,174 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-l4.html">English</A>
+| <A HREF="/software/hurd/hurd-l4.eo.html">Esperanto</A>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#what" NAME="TOCwhat">The GNU&nbsp;Hurd on top of the L4 microkernel</A>
+ <LI><A HREF="#docs" NAME="TOCdocs">Documentation</A>
+ <LI><A HREF="#cvs" NAME="TOCcvs">CVS repository</A>
+ <LI><A HREF="#cvsweb" NAME="TOCcvsweb">Browsing the code</A>
+ <LI><A HREF="#mail" NAME="TOCmail">Mailing lists</A>
+ <LI><A HREF="#irc" NAME="TOCirc">Internet relay chat</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCwhat" NAME="what">The GNU&nbsp;Hurd on top of the L4 microkernel</A></H3>
+<P>
+The GNU&nbsp;Hurd on top of the L4 microkernel is an on-going effort to
+port the Hurd system to the <A
+HREF="http://www.l4ka.org">L4Ka::Pistachio microkernel</A>.
+
+This project is not released yet. The only way to find out more about
+it is to browse the source code, read what little documentation there
+is, and talk to the participants.
+
+
+<H3><A HREF="#TOCdocs" NAME="docs">Documentation</A></H3>
+<P>
+In the CVS Repository is a tex document that describes some of our
+design ideas. This document is not always up to date, nor is it
+complete. But it describes a lot of the core ideas in some detail.
+
+
+<H3><A HREF="#TOCcvs" NAME="cvs">CVS repository</A></H3>
+<P>
+The Hurd-on-L4 source code is managed in the version control system <A
+HREF="/software/cvs/cvs.html">CVS</A>. You can check out the CVS
+repository through anonymous CVS over SSH with the following
+instruction set. When prompted for a password for <I>anoncvs</I>,
+simply press the Enter key.
+
+<P>
+Source tree:
+&nbsp;<BR>
+<SAMP>cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co hurd-l4</SAMP>
+
+<P>Updates from within the module's directory do not need the -d parameter.
+
+<P>For the full details, read the <A
+href="https://savannah.gnu.org/cvs/?group=hurd">savannah</A> page.
+
+
+<H3><A HREF="#TOCcvsweb" NAME="cvsweb">Browsing the code</A></H3>
+<P>
+You can also browse the <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/hurd/hurd-l4/">CVS
+repository of the Hurd-on-L4</A> with your web browser. The web pages are
+generated dynamically at the time you request them and are always up
+to date.
+
+
+<H3><A HREF="#TOCmail" NAME="mail">Mailing lists</A></H3>
+<P>
+If you have questions about the Hurd-on-L4 you can send an e-mail to
+the <A
+HREF="http://mail.gnu.org/mailman/listinfo/l4-hurd">L4-Hurd</A> <A
+HREF="mailto:l4-hurd@gnu.org">&lt;l4-hurd@gnu.org&gt;</A> mailing
+list.
+
+
+<H3><A HREF="#TOCirc" NAME="irc">Internet relay chat</A></H3>
+<P>
+The GNU Project uses
+<A HREF="http://www.freenode.net/">Freenode</A> as its official IRC
+network. The network of IRC servers can be accessed through
+<SAMP>irc.gnu.org</SAMP>. The channel <SAMP>#hurd-l4</SAMP> is
+dedicated to the Hurd-on-L4. You can find other users and developers
+interested in the Hurd on L4 there and chat with them in real time.
+
+
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web sites.</EM>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-l4.html">English</A>
+| <A HREF="/software/hurd/hurd-l4.eo.html">Esperanto</A>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/hurd-migr b/hurd-migr
new file mode 100644
index 00000000..ce36c86c
--- /dev/null
+++ b/hurd-migr
@@ -0,0 +1,141 @@
+Path: usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!howland.reston.ans.net!E
+U.net!Germany.EU.net!netmbx.de!sietec.de!news!jh
+From: jh@poseidon.sietec.de (Jochen Roger Hayek)
+Newsgroups: gnu.misc.discuss
+Subject: HURD & migration facilities
+Date: 24 Oct 1994 15:12:34 GMT
+Organization: Sietec Systemtechnik, Berlin
+Lines: 16
+Distribution: world
+Message-ID: <JH.94Oct24161234@poseidon.sietec.de>
+Reply-To: Jochen.Roger.Hayek@sietec.de
+NNTP-Posting-Host: sunmiet3.sietec.de
+
+I read an article from acm's sigops vol. 28, number 4 this weekend, having the
+title:
+
+ a brief survey of systems providing
+ process or object migration facilities
+ by Mark Nuttall
+
+I found it very instructive.
+
+I think process / object migration should be considered for HURD, too,
+and it's important to look at that before supporting / emulating
+UNIX's fork and inherited open file descriptors,
+because those features might get contradictory if not carefully designed.
+
+Regards esp. to the HURD folks
+
+JH
+
+Path: usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!spool.mu.edu!bloom-beacon.mit.ed
+u!ai-lab!life.ai.mit.edu!mib
+From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell)
+Newsgroups: gnu.misc.discuss
+Subject: Re: HURD & migration facilities
+Date: 24 Oct 1994 18:10:25 GMT
+Organization: Free Software Foundation, Cambridge, MA
+Lines: 27
+Distribution: world
+Message-ID: <MIB.94Oct24141025@churchy.gnu.ai.mit.edu>
+References: <JH.94Oct24161234@poseidon.sietec.de>
+NNTP-Posting-Host: churchy.gnu.ai.mit.edu
+In-reply-to: jh@poseidon.sietec.de's message of 24 Oct 1994 15:12:34
+ GMT
+
+In article <JH.94Oct24161234@poseidon.sietec.de> jh@poseidon.sietec.de (Jochen
+Roger Hayek) writes:
+
+ I think process / object migration should be considered for HURD, too,
+ and it's important to look at that before supporting / emulating
+ UNIX's fork and inherited open file descriptors,
+ because those features might get contradictory if not carefully designed.
+
+Process migration is not a problem for the Hurd--it's a problem for
+Mach. If a Mach task can be correctly migrated, then there is no
+problem.
+
+However, I want to do more than that with the Hurd; I want to have a
+collection of machines (I think I'll call it a ``Collective'') appear
+as a single machine. (Shades of amoeba here.)
+
+This is the first (and harder) task--making a single global space of
+pids, etc.
+
+The second (and easier) task is migration.
+
+ -mib
+--
++1 617 623 3248 (H) | En arche en ho logos,
++1 617 253 8568 (W) -+- kai ho logos en pros ton theon,
+1105 Broadway | kai theos en ho logos.
+Somerville, MA 02144 | Kai ho logos sarx egeneto,
+mib@gnu.ai.mit.edu | kai eskenosen en hemin.
+
+Newsgroups: gnu.misc.discuss
+Path: usenet.ee.pdx.edu!cs.uoregon.edu!reuter.cse.ogi.edu!psgrain!agora!hermes.
+rdrop.com!erich
+From: erich@uruk.org (Erich Boleyn)
+Subject: Re: HURD & migration facilities
+Sender: news@agora.rdrop.com (David Greenman)
+Nntp-Posting-Host: uruk.org
+Organization: RainDrop Laboratories
+Message-ID: <ERICH.94Oct29093537@uruk.org>
+References: <JH.94Oct24161234@poseidon.sietec.de>
+ <MIB.94Oct24141025@churchy.gnu.ai.mit.edu>
+In-Reply-To: mib@churchy.gnu.ai.mit.edu's message of 24 Oct 1994 18:10:25 GMT
+Date: Sat, 29 Oct 1994 16:35:37 GMT
+Lines: 50
+
+
+In article <MIB.94Oct24141025@churchy.gnu.ai.mit.edu> mib@churchy.gnu.ai.mit.ed
+u (Michael I Bushnell) writes:
+
+ Process migration is not a problem for the Hurd--it's a problem for
+ Mach. If a Mach task can be correctly migrated, then there is no
+ problem.
+
+ However, I want to do more than that with the Hurd; I want to have a
+ collection of machines (I think I'll call it a ``Collective'') appear
+ as a single machine. (Shades of amoeba here.)
+
+Great! (I think we talked about this before...)
+
+ This is the first (and harder) task--making a single global space of
+ pids, etc.
+
+This point seems somewhat questionable. Maybe we're thinking about
+the same idea in the long run, but I don't think that migrating
+data about the whole system around would be very useful...
+I mean, you still want a very large collective to work, though it
+could well get bogged down by the details of huge amounts of info.
+
+I think a more optimal (and more practical) approach would be to:
+
+Create a model of a "user context" that keeps track across multiple
+machines what resources and programs a user is working with.
+
+There would also be publically known "services" that would be advertised.
+Note that "advertising" is a specific activity that is usually not
+performed, unless one desires to do so.
+
+Anything else is really of little or no concern except to a local group of
+machines (for resource-balancing issues). So machines would automatically
+keep in touch with other nearby machines, but it would be modulated by
+distance.
+
+The big question is this (and for that matter, other models) is that
+of authentication in some kind of reasonably reliable manner.
+
+ The second (and easier) task is migration.
+
+Agreed.
+
+Erich
+
+--
+Erich Stefan Boleyn \ Mad Genius wanna-be, CyberMuffin
+Mathematician, Software Engineer \ slavering computer nerd
+Internet E-mail: <erich@uruk.org> \ "Forget Artificial Intelligence,
+Motto: "I'll live forever or die trying" \ I want the real thing!"
diff --git a/hurd-name.html b/hurd-name.html
new file mode 100644
index 00000000..946045d1
--- /dev/null
+++ b/hurd-name.html
@@ -0,0 +1,53 @@
+<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML>
+<HEAD>
+<TITLE>What the name Hurd means - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<H3>What the name ``Hurd'' means</H3>
+<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg"
+ ALT=" [image of a Hurd Metafont Logo] "
+ WIDTH="333" HEIGHT="80">&#32;(jpeg 10k)</A>
+<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A>
+<A HREF="/philosophy/gif.html">no gifs due to patent problems</A>
+
+<P>
+
+"Hurd" stands for "Hird of Unix-Replacing Daemons".
+And, then, "Hird" stands for "Hurd of Interfaces Representing Depth".
+
+<P>
+
+We have here, to my knowledge, the first software to be named by a
+pair of mutually recursive acronyms.
+
+<P>
+
+---Thomas (formerly Michael I.) Bushnell
+
+<HR>
+
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+FSF &amp; GNU inquiries &amp; questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF.
+<P>
+Comments on these web pages to
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.<P>
+Updated:
+<!-- hhmts start -->
+16 Feb 1998 tower
+<!-- hhmts end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/hurd-paper.html b/hurd-paper.html
new file mode 100644
index 00000000..bb49829c
--- /dev/null
+++ b/hurd-paper.html
@@ -0,0 +1,812 @@
+<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN">
+<HTML>
+<HEAD>
+<TITLE>Towards a New Strategy of OS Design</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<H1>Towards a New Strategy of OS Design</H1>
+<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg"
+ ALT=" [image of a Hurd Metafont Logo] "
+ WIDTH="333" HEIGHT="80">&#32;(jpeg 10k)</A>
+<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A>
+<A HREF="/philosophy/gif.html">no gifs due to patent problems</A>
+<BR>
+<BR>
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-paper.html">English</A>
+| <A HREF="/software/hurd/hurd-paper.he.html">Hebrew</A>
+| <A HREF="/software/hurd/hurd-paper.tr.html">Turkish</A>
+]
+
+<P>
+This article explains why FSF is developing a new operating system named the
+Hurd, which will be a foundation of the whole GNU system.
+The Hurd is built
+on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and
+message-passing facilities.
+The GNU C Library will provide the Unix system
+call interface, and will call the Hurd for needed services it can't provide
+itself.
+The design and implementation of the Hurd is being lead by Michael
+Bushnell, with assistance from Richard Stallman, Roland McGrath,
+Jan Brittenson, and others.
+
+<H2>Part 1: A More Usable Approach to OS Design</H2>
+<P>
+The fundamental purpose of an operating system (OS) is to enable a variety of
+programs to share a single computer efficiently and productively.
+This
+demands memory protection, preemptively scheduled timesharing, coordinated
+access to I/O peripherals, and other services.
+In addition, an OS can allow
+several users to share a computer.
+In this case, efficiency demands services
+that protect users from harming each other, enable them to share without
+prior arrangement, and mediate access to physical devices.
+<P>
+On today's computer systems, programmers usually implement these goals
+through a large program called the kernel.
+Since this program must be
+accessible to all user programs, it is the natural place to add functionality
+to the system.
+Since the only model for process interaction is that of
+specific, individual services provided by the kernel, no one creates other
+places to add functionality.
+As time goes by, more and more is added to the
+kernel.
+<P>
+A traditional system allows users to add components to a kernel only if they
+both understand most of it and have a privileged status within the system.
+Testing new components requires a much more painful edit-compile-debug cycle
+than testing other programs.
+It cannot be done while others are using the
+system.
+Bugs usually cause fatal system crashes, further disrupting others'
+use of the system.
+The entire kernel is usually non-pageable.
+(There are
+systems with pageable kernels, but deciding what can be paged is difficult
+and error prone.
+Usually the mechanisms are complex, making them difficult
+to use even when adding simple extensions.)
+<P>
+Because of these restrictions, functionality which properly belongs
+<STRONG>behind</STRONG>
+the wall of a traditional kernel is usually left out of systems unless it is
+absolutely mandatory.
+Many good ideas, best done with an open/read/write
+interface cannot be implemented because of the problems inherent in the
+monolithic nature of a traditional system.
+Further, even among those with
+the endurance to implement new ideas, only those who are privileged users of
+their computers can do so.
+The software copyright system darkens the mire by
+preventing unlicensed people from even reading the kernel source.
+<P>
+Some systems have tried to address these difficulties.
+Smalltalk-80 and
+the Lisp Machine both represented one method of getting around the problem.
+System code is not distinguished from user code; all of the system is
+accessible to the user and can be changed as need be.
+Both systems were
+built around languages that facilitated such easy replacement and extension,
+and were moderately successful.
+But they both were fairly poor at insulating
+users and programs from each other, failing one of the principal goals of OS
+design.
+<P>
+Most projects that use the Mach 3.0 kernel carry on the hard-to-change
+tradition of OS design.
+The internal structure is different, but the same
+heavy barrier between user and system remains.
+The single-servers, while
+fairly easy to construct, inherit all the deficiencies of the monolithic
+kernels.
+<P>
+A multi-server divides the kernel functionality up into logical blocks with
+well-defined interfaces.
+Properly done, it is easier to make changes and add
+functionality.
+So most multi-server projects do somewhat better.
+Much more
+of the system is pageable.
+You can debug the system more easily.
+You can
+test new system components without interfering with other users.
+But the
+wall between user and system remains; no user can cross it without special
+privilege.
+<P>
+The GNU&nbsp;Hurd, by contrast, is designed to make the area of
+<STRONG>system</STRONG>
+code as
+limited as possible.
+Programs are required to communicate only with a few
+essential parts of the kernel; the rest of the system is replaceable
+dynamically.
+Users can use whatever parts of the remainder of the system
+they want, and can easily add components themselves for other users to take
+advantage of.
+No mutual trust need exist in advance for users to use each
+other's services, nor does the system become vulnerable by trusting the
+services of arbitrary users.
+<P>
+This has been done by identifying those system components which users
+<STRONG>must</STRONG>
+use in order to communicate with each other.
+One of these is responsible for
+identifying users' identities and is called the
+<DFN>
+authentication server.
+</DFN>
+In
+order to establish each other's identities, programs must communicate, each
+with an authentication server they trust.
+Another component establishes
+control over system components by the superuser, provides global bookkeeping
+operations, and is called the
+<DFN>
+process server.
+</DFN>
+<P>
+Not all user programs need to communicate with the process server; it is only
+necessary for programs which require its services.
+Likewise, the
+authentication server is only necessary for programs that wish to communicate
+their identity to another.
+None of the remaining services carry any special
+status; not the network implementation, the filesystems, the program
+execution mechanism (including setuid), or any others.
+
+<H3>The Translator Mechanism</H3>
+<P>
+The Hurd uses Mach ports primarily as methods for communicating between users
+and servers.
+(A Mach port is a communication point on a Mach task where
+messages are sent and received.) Each port implements a particular set of
+protocols, representing operations that can be undertaken on the underlying
+object represented by the port.
+Some of the protocols specified by the Hurd
+are the I/O protocol, used for generic I/O operations; the file protocol,
+used for filesystem operations; the socket protocol, used for network
+operations; and the process protocol, used for manipulating processes et al.
+<P>
+Most servers are accessed by opening files.
+Normally, when you open a file,
+you create a port associated with that file that is owned by the server
+that owns the directory containing the file.
+For example, a disk-based
+filesystem will normally serve a large number of ports, each of which
+represents an open file or directory.
+When a file is opened, the server
+creates a new port, associates it with the file, and returns the port to the
+calling program.
+<P>
+However, a file can have a
+<DFN>translator</DFN>
+associated with it.
+In this case,
+rather than return its own port which refers to the contents of the file, the
+server executes a translator program associated with that file.
+This
+translator is given a port to the actual contents of the file, and is then
+asked to return a port to the original user to complete the open operation.
+<P>
+This mechanism is used for
+<CODE>mount</CODE>
+by having a translator associated with
+each mount point.
+When a program opens the mount point, the translator (in
+this case, a program which understands the disk format of the mounted
+filesystem) is executed and returns a port to the program.
+After the
+translator is started, it need not be run again unless it dies; the parent
+filesystem retains a port to the translator to use in further requests.
+<P>
+The owner of a file can associate a translator with it without special
+permission.
+This means that any program can be specified as a translator.
+Obviously the system will not work properly if the translator does not
+implement the file protocol correctly.
+However, the Hurd is constructed so
+that the worst possible consequence is an interruptible hang.
+<P>
+One way to use translators is to access hierarchically structured data using
+the file protocol.
+For example, all the complexity of the user interface to
+the
+<CODE>ftp</CODE>
+program is removed.
+Users need only know that a particular
+directory represents FTP and can use all the standard file manipulation
+commands (e.g
+<CODE>ls</CODE>
+or
+<CODE>cp</CODE>)
+to access the remote system, rather than learning
+a new set.
+Similarly, a simple translator could ease the complexity of
+<CODE>tar</CODE>
+or
+<CODE>gzip</CODE>.
+(Such transparent access would have some added cost, but it would
+be convenient.)
+
+<H3>Generic Services</H3>
+<P>
+With translators, the filesystem can act as a rendezvous for interfaces which
+are not similar to files.
+Consider a service which implements some version
+of the X protocol, using Mach messages as an underlying transport.
+For each
+X display, a file can be created with the appropriate program as its
+translator.
+X clients would open that file.
+At that point, few file
+operations would be useful (read and write, for example, would be useless),
+but new operations (
+<CODE>XCreateWindow</CODE>
+or
+<CODE>XDrawText</CODE>)
+might become meaningful.
+In this case, the filesystem protocol is used only to manipulate
+characteristics of the node used for the rendezvous.
+The node need not
+support I/O operations, though it should reply to any such messages with a
+<CODE>message_not_understood</CODE>
+return code.
+<P>
+This translator technique is used to contact most of the services in the Hurd
+that are not structured like hierarchical filesystems.
+For example, the
+password server, which hands out authorization tags in exchange for
+passwords, is contacted this way.
+Network protocol servers are also
+contacted in this fashion.
+Roland McGrath thought up this use of translators.
+
+<H3>Clever Filesystem Pictures</H3>
+<P>
+In the Hurd, translators can also be used to present a filesystem-like view
+of another part of the filesystem, with some semantics changed.
+For example,
+it would be nice to have a filesystem that cannot itself be changed, but
+nonetheless records changed versions of its files elsewhere.
+(This could be
+useful for source code management.)
+<P>
+The Hurd will have a translator which creates a directory which is a
+conceptual union of other directories, with collision resolution rules of
+various sorts.
+This can be used to present a single directory to users that
+contains all the programs they would want to execute.
+There are other useful
+variations on this theme.
+
+<H3>What The User Can Do</H3>
+<P>
+No translator gains extra privilege by virtue of being hooked into the
+filesystem.
+Translators run with the uid of the owner of the file being
+translated, and can only be set or changed by that owner.
+The I/O and
+filesystem protocols are carefully designed to allow their use by mutually
+untrusting clients and servers.
+Indeed, translators are just ordinary
+programs.
+The GNU C library has a variety of facilities to make common sorts
+of translators easier to write.
+<P>
+Some translators may need special privileges, such as the password server or
+translators which allow setuid execution.
+These translators could be run by
+anyone, but only if they are set on a root-owned node would they be able to
+provide all their services successfully.
+This is analogous to letting any
+user call the
+<CODE>reboot</CODE>
+system call, but only honoring it if that user is root.
+
+<H3>Why This Is So Different</H3>
+<P>
+What this design provides is completely novel to the Unix world.
+Until now,
+OSs have kept huge portions of their functionality in the realm of system
+code, thus preventing its modification and extension except in extreme need.
+Users cannot replace parts of the system in their programs no matter how much
+easier that would make their task, and system managers are loath to install
+random tweaks off the net into their kernels.
+<P>
+In the Hurd, users can change almost all of the things that are decided for
+them in advance by traditional systems.
+In combination with the tremendous
+control given by the Mach kernel over task address spaces and properties, the
+Hurd provides a system in which users will, for the first time, be able to
+replace parts of the system they dislike, without disrupting other users.
+<P>
+Most Mach-based OSs to date have mostly implemented a wider set of the
+<STRONG>
+same old
+</STRONG>
+Unix semantics in a new environment.
+In contrast, GNU is extending
+those semantics to allow users to improve, bypass, or replace them.
+
+
+<H2>Part 2: A Look at Some of the Hurd's Beasts</H2>
+<H3>The Authentication Server</H3>
+<P>
+One of the Hurd's more central servers is the authentication server.
+Each
+port to this server identifies a user and is associated by this server with
+an
+<DFN>id block</DFN>.
+Each id block contains sets of user and group ids.
+Either
+set may be empty.
+This server is not the same as the password server
+referred to above.
+<P>
+The authentication server exports three services.
+First, it provides simple
+boolean operations on authentication ports: given two authentication ports,
+this server will provide a third port representing the union of the two sets
+of uids and gids.
+Second, this server allows any user with a uid of zero to
+create an arbitrary authentication port.
+Finally, this server provides RPCs
+(Remote Procedure Calls between different programs and possibly different
+hosts) which allow mutually untrusting clients and servers to establish their
+identities and pass initial information on each other.
+This is crucial to
+the security of the filesystem and I/O protocols.
+<P>
+Any user could write a program which implements the authentication protocol;
+this does not violate the system's security.
+When a service needs to
+authenticate a user, it communicates with its trusted authentication server.
+If that user is using a different authentication server, the transaction will
+fail and the server can refuse to communicate further.
+Because, in effect,
+this forces all programs on the system to use the same authentication server,
+we have designed its interface to make any safe operation possible, and to
+include no extraneous operations.
+(This is why there is a separate password
+server.)
+<H3>The Process Server</H3>
+<P>
+The process server acts as an information categorization repository.
+There
+are four main services supported by this server.
+First, the process server
+keeps track of generic host-level information not handled by the Mach kernel.
+For example, the hostname, the hostid, and the system version are maintained
+by the process server.
+Second, this server maintains the Posix notions of
+sessions and process groups, to help out programs that wish to use Posix
+features.
+<P>
+Third, the process server maintains a one-to-one mapping between Mach tasks
+and Hurd processes.
+Every task is assigned a pid.
+Processes can register a
+message port with this server, which can then be given out to any program
+which requests it.
+This server makes no attempt to keep these message ports
+private, so user programs are expected to implement whatever security they
+need themselves.
+(The GNU C Library provides convenient functions for all
+this.) Processes can tell the process server their current `argv' and `envp'
+values; this server will then provide, on request, these vectors of arguments
+and environment.
+This is useful for writing
+<CODE>ps</CODE>-like
+programs and also
+makes it easier to hide or change this information.
+None of these features
+are mandatory.
+Programs are free to disregard all of this and never register
+themselves with the process server at all.
+They will, however, still have a
+pid assigned.
+<P>
+Finally, the process server implements
+<DFN>process collections</DFN>,
+which are used
+to collect a number of process message ports at the same time.
+Also,
+facilities are provided for converting between pids, process server ports,
+and Mach task ports, while ensuring the security of the ports managed.
+<P>
+It is important to stress that the process server is optional.
+Because of
+restrictions in Mach, programs must run as root in order to identify all the
+tasks in the system.
+But given that, multiple process servers could
+co-exist, each with their own clients, giving their own model of the
+universe.
+Those process server features which do not require root privileges
+to be implemented could be done as per-user servers.
+The user's hands are
+not tied.
+<H3>Transparent FTP</H3>
+<P>
+Transparent FTP is an intriguing idea whose time has come.
+The popular
+<CODE>ange-ftp</CODE>
+package available for GNU Emacs makes access to FTP files
+virtually transparent to all the Emacs file manipulation functions.
+Transparent FTP does the same thing, but in a system wide fashion.
+This
+server is not yet written; the details remain to be fleshed out, and will
+doubtless change with experience.
+<P>
+In a BSD kernel, a transparent FTP filesystem would be no harder to write
+than in the Hurd.
+But mention the idea to a BSD kernel hacker, and the
+response is that ``such a thing doesn't belong in the kernel''.
+In a sense,
+this is correct.
+It violates all the layering principles of such systems to
+place such things in the kernel.
+The unfortunate side effect, however, is
+that the design methodology (which is based on preventing users from changing
+things they don't like) is being used to prevent system designers from making
+things better.
+(Recent BSD kernels make it possible to write a user program
+that provides transparent FTP.
+An example is
+<CODE>alex</CODE>,
+but it needs to run
+with full root privileges.)
+<P>
+In the Hurd, there are no obstacles to doing transparent FTP.
+A translator
+will be provided for the node
+<CODE>/ftp</CODE>.
+The contents of
+<CODE>/ftp</CODE>
+will probably
+not be directly listable, though further subdirectories will be.
+There will
+be a variety of possible formats.
+For example, to access files on uunet, one
+could
+<CODE>
+cd /ftp/ftp.uu.net:anonymous:mib@gnu.
+</CODE>
+Or to access files on a remote
+account, one might
+<CODE>
+cd /ftp/gnu.org:mib:passwd.
+</CODE>
+Parts of this
+command could be left out and the transparent FTP program would read them
+from a user's
+<CODE>.netrc</CODE>
+file.
+In the last case, one might just
+<CODE>
+cd /ftp/gnu.org;
+</CODE>
+when the rest of the data is already in
+<CODE>.netrc</CODE>.
+<P>
+There is no need to do a
+<CODE>cd</CODE>
+first--use any file command.
+To find out about
+RFC 1097 (the Telnet Subliminal Message Option), just type
+<CODE>
+more /ftp/ftp.uu.net/inet/rfc/rfc1097.
+</CODE>
+A copy command to a local disk
+could be used if the RFC would be read frequently.
+<H3>Filesystems</H3>
+<P>
+Ordinary filesystems are also being implemented.
+The initial release of the
+Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File
+System.
+In addition to the ordinary semantics, it will provide means to
+record translators, offer thirty-two bit user ids and group ids, and supply a
+new id per file, called the
+<DFN>author</DFN>
+of the file, which can be set by the
+owner arbitrarily.
+In addition, because users in the Hurd can have multiple
+uids (or even none), there is an additional set of permission bits providing
+access control for
+<DFN>
+unknown user
+</DFN>
+(no uids) as distinct from
+<DFN>
+known but arbitrary user
+</DFN>
+(some uids: the existing
+<DFN>world</DFN>
+category of file
+permissions).
+<P>
+The Network File System protocol will be implemented using 4.4 BSD as a
+starting point.
+A log-structured filesystem will also be implemented using
+the same ideas as in Sprite, but probably not the same format.
+A GNU network
+file protocol may be designed in time, or NFS may be extended to remove its
+deficiencies.
+There will also be various ``little'' filesystems, such as the
+MS-DOS filesystem, to help people move files between GNU and other OSs.
+
+<H3>Terminals</H3>
+<P>
+An I/O server will provide the terminal semantics of Posix.
+The GNU C
+Library has features for keeping track of the controlling terminal and for
+arranging to have proper job control signals sent at the proper times, as
+well as features for obeying keyboard and hangup signals.
+<P>
+Programs will be able to insert a terminal driver into communications
+channels in a variety of ways.
+Servers like
+<CODE>rlogind</CODE>
+will be able to insert
+the terminal protocol onto their network communication port.
+Pseudo-terminals will not be necessary, though they will be provided for
+backward compatibility with older programs.
+No programs in GNU will depend
+on them.
+<P>
+Nothing about a terminal driver is forced upon users.
+A terminal driver
+allows a user to get at the underlying communications channel easily, to
+bypass itself on an as-needed basis or altogether, or to substitute a
+different terminal driver-like program.
+In the last case, provided the
+alternate program implements the necessary interfaces, it will be used by the
+C Library exactly as if it were the ordinary terminal driver.
+<P>
+Because of this flexibility, the original terminal driver will not provide
+complex line editing features, restricting itself to the behavior found in
+Posix and BSD.
+In time, there will be a
+<CODE>readline</CODE>-based
+terminal driver,
+which will provide complex line-editing features for those users who want
+them.
+<P>
+The terminal driver will probably not provide good support for the
+high-volume, rapid data transmission required by UUCP or SLIP.
+Those
+programs do not need any of its features.
+Instead they will be using the
+underlying Mach device ports for terminals, which support moving large
+amounts of data efficiently.
+
+<H3>Executing Programs</H3>
+<P>
+The implementation of the
+<CODE>execve</CODE>
+call is spread across three programs.
+The
+library marshals the argument and environment vectors.
+It then sends a
+message to the file server that holds the file to be executed.
+The file
+server checks execute permissions and makes whatever changes it desires in
+the exec call.
+For example, if the file is marked setuid and the fileserver
+has the ability, it will change the user identification of the new image.
+The file server also decides if programs which had access to the old task
+should continue to have access to the new task.
+If the file server is
+augmenting permissions, or executing an unreadable image, then the exec needs
+to take place in a new Mach task to maintain security.
+<P>
+After deciding the policy associated with the new image, the filesystem calls
+the exec server to load the task.
+This server, using the BFD (Binary File
+Descriptor) library, loads the image.
+BFD supports a large number of object
+file formats; almost any supported format will be executable.
+This server
+also handles scripts starting with
+<CODE>#!</CODE>,
+running them through the indicated
+program.
+<P>
+The standard exec server also looks at the environment of the new image; if
+it contains a variable
+<CODE>EXECSERVERS</CODE>
+then it uses the programs specified
+there as exec servers instead of the system default.
+(This is, of course,
+not done for execs that the file server has requested be kept secure.)
+<P>
+The new image starts running in the GNU C Library, which sends a message to
+the exec server to get the arguments, environment, umask, current directory,
+etc.
+None of this additional state is special to the file or exec servers;
+if programs wish, they can use it in a different manner than the Library.
+
+<H3>New Processes</H3>
+<P>
+The
+<CODE>fork</CODE>
+call is implemented almost entirely in the GNU C Library.
+The new
+task is created by Mach kernel calls.
+The C Library arranges to have its
+image inherited properly.
+The new task is registered with the process server
+(though this is not mandatory).
+The C Library provides vectors of functions
+to be called at fork time: one vector to be called before the fork, one after
+in the parent, and one after in the child.
+(These features should not be
+used to replace the normal fork-calling sequence; it is intended for
+libraries which need to close ports or clean up before a fork occurs.)
+The C
+library will implement both fork calls specified by the draft Posix.4a (the
+proposed standard dealing with the threads extension to the real-time
+extension).
+<P>
+Nothing forces the user to create new tasks this way.
+If a program wants to
+use almost the normal fork, but with some special characteristics, then it
+can do so.
+Hooks will be provided by the C Library, or the function can even
+be completely replaced.
+None of this is possible in a traditional Unix
+system.
+
+<H3>Asynchronous Messages</H3>
+<P>
+As mentioned above, the process server maintains a
+<DFN>
+message port
+</DFN>
+for each
+task registered with it.
+These ports are public, and are used to send
+asynchronous messages to the task.
+Signals, for example, are sent to the
+message port.
+The signal message also provides a port as an indication that
+the sender should be trusted to send the signal.
+The GNU C Library lists a
+variety of ports in a table, each of which identifies a set of signals that
+can be sent by anyone who possesses that port.
+For example, if the user
+possesses the task's kernel port, it is allowed to send any signal.
+If the
+user possesses a special
+<DFN>
+terminal id
+</DFN>
+port, it is allowed to send the
+keyboard and hangup signals.
+Users can add arbitrary new entries into the C
+library's signal permissions table.
+<P>
+When a process's process group changes, the process server will send it a
+message indicating the new process group.
+In this case, the process server
+proves its authority by providing the task's kernel port.
+<P>
+The C library also has messages to add and delete uids currently used by the
+process.
+If new uids are sent to the program, the library adds them to its
+current set, and then exchanges messages with all the I/O servers it knows
+about, proving to them its new authorization.
+Similarly, a message can
+delete uids.
+In the latter case, the caller must provide the process's task
+port.
+(You can't harm a process by giving it extra permission, but you can
+harm it by taking permission away.) The Hurd will provide user programs to
+send these messages to processes.
+For example, the
+<CODE>su</CODE>
+command will be able
+to cause all the programs in your current login session, to gain a new uid,
+rather than spawn a subshell.
+<P>
+The C library will allow programs to add asynchronous messages they wish to
+recognize, as well as prevent recognition of the standard set.
+<H3>Making It Look Like Unix</H3>
+<P>
+The C Library will implement all of the calls from BSD and Posix as well as
+some obvious extensions to them.
+This enables users to replace those calls
+they dislike or bypass them entirely, whereas in Unix the calls must be used
+``as they come'' with no alternatives possible.
+<P>
+In some environments binary compatibility will also be supported.
+This works
+by building a special version of the library which is then loaded somewhere
+in the address space of the process.
+(For example, on a VAX, it would be
+tucked in above the stack.) A feature of Mach, called system call
+redirection, is then used to trap Unix system calls and turn them into jumps
+into this special version of the library.
+(On almost all machines, the cost
+of such a redirection is very small; this is a highly optimized path in Mach.
+On a 386 it's about two dozen instructions.
+This is little worse than a
+simple procedure call.)
+<P>
+Many features of Unix, such as signal masks and vectors, are handled
+completely by the library.
+This makes such features significantly cheaper
+than in Unix.
+It is now reasonable to use
+<CODE>sigblock</CODE>
+extensively to protect
+critical sections, rather than seeking out some other, less expensive method.
+
+<H3>Network Protocols</H3>
+<P>
+The Hurd will have a library that will make it very easy to port 4.4 BSD
+protocol stacks into the Hurd.
+This will enable operation, virtually for
+free, of all the protocols supported by BSD.
+Currently, this includes the
+CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO
+protocols.
+<P>
+For optimal performance some work would be necessary to take advantage of
+Hurd features that provide for very high speed I/O.
+For most protocols this
+will require some thought, but not too much time.
+The Hurd will run the
+TCP/IP protocols as efficiently as possible.
+<P>
+As an interesting example of the flexibility of the Hurd design, consider the
+case of IP trailers, used extensively in BSD for performance.
+While the Hurd
+will be willing to send and receive trailers, it will gain fairly little
+advantage in doing so because there is no requirement that data be copied and
+avoiding copies for page-aligned data is irrelevant.
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-paper.html">English</A>
+| <A HREF="/software/hurd/hurd-paper.he.html">Hebrew</A>
+| <A HREF="/software/hurd/hurd-paper.tr.html">Turkish</A>
+]
+
+<HR>
+
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+FSF &amp; GNU inquiries &amp; questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF.
+<P>
+Comments on these web pages to
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1996 Trent Fisher
+<BR>
+Copyright (C) 1996, 1997, 1998, 2007 Free Software Foundation, Inc.,
+51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.<P>
+Updated:
+<!-- hhmts start -->
+19 Dec 1998 jonas
+<!-- hhmts end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/hurd-talk.html b/hurd-talk.html
new file mode 100644
index 00000000..630bbc7d
--- /dev/null
+++ b/hurd-talk.html
@@ -0,0 +1,1151 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-talk.html">English</A>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H4><A NAME="contents">Table of Contents</A></H4>
+<UL>
+ <LI><A HREF="#int" NAME="TOCint">Introduction</A>
+ <LI><A HREF="#ove" NAME="TOCove">Overview</A>
+ <LI><A HREF="#his" NAME="TOChis">Historicals</A>
+ <LI><A HREF="#ker" NAME="TOCker">Kernel Architectures</A>
+ <LI><A HREF="#mic" NAME="TOCmic">Micro vs Monolithic</A>
+ <LI><A HREF="#sin" NAME="TOCsin">Single Server vs Multi Server</A>
+ <LI><A HREF="#mul" NAME="TOCmul">Multi Server is superior, ...</A>
+ <LI><A HREF="#the" NAME="TOCthe">The Hurd even more so.</A>
+ <LI><A HREF="#mac" NAME="TOCmac">Mach Inter Process Communication</A>
+ <LI><A HREF="#how" NAME="TOChow">How to get a port?</A>
+ <LI><A HREF="#exa" NAME="TOCexa">Example of <SAMP>hurd_file_name_lookup</SAMP></A>
+ <LI><A HREF="#pat" NAME="TOCpat">Pathname resolution example</A>
+ <LI><A HREF="#map" NAME="TOCmap">Mapping the POSIX Interface</A>
+ <LI><A HREF="#filser" NAME="TOCfilser">File System Servers</A>
+ <LI><A HREF="#act" NAME="TOCact">Active vs Passive</A>
+ <LI><A HREF="#aut" NAME="TOCaut">Authentication</A>
+ <LI><A HREF="#ope" NAME="TOCope">Operations on authentication ports</A>
+ <LI><A HREF="#est" NAME="TOCest">Establishing trusted connections</A>
+ <LI><A HREF="#pas" NAME="TOCpas">Password Server</A>
+ <LI><A HREF="#pro" NAME="TOCpro">Process Server</A>
+ <LI><A HREF="#filsys" NAME="TOCfilsys">Filesystems</A>
+ <LI><A HREF="#dev" NAME="TOCdev">Developing the Hurd</A>
+ <LI><A HREF="#sto" NAME="TOCsto">Store Abstraction</A>
+ <LI><A HREF="#deb" NAME="TOCdeb">Debian GNU/Hurd</A>
+ <LI><A HREF="#stabin" NAME="TOCstabin">Status of the Debian GNU/Hurd binary archive</A>
+ <LI><A HREF="#stainf" NAME="TOCstainf">Status of the Debian infrastructure</A>
+ <LI><A HREF="#staarc" NAME="TOCstaarc">Status of the Debian Source archive</A>
+ <LI><A HREF="#debide" NAME="TOCdebide">Debian GNU/Hurd: Good idea, bad idea?</A>
+ <LI><A HREF="#end" NAME="TOCend">End</A>
+</UL>
+<HR>
+<H3>Talk about the Hurd</H3>
+<P>
+This talk about the Hurd was written by Marcus Brinkmann for
+<UL>
+<LI>OSDEM, Brussels, 4. Feb 2001,
+<LI>Frühjahrsfachgespräche, Cologne, 2. Mar 2001 and
+<LI>Libre Software Meeting, Bordeaux, 4. Jul 2001.
+</UL>
+
+<H4><A HREF="#TOCint" NAME="int">Introduction</A></H4>
+<P>
+When we talk about free software, we usually refer to the free
+software licenses. We also need relief from software patents, so our
+freedom is not restricted by them. But there is a third type of
+freedom we need, and that's user freedom.
+
+<P>
+Expert users don't take a system as it is. They like to change the
+configuration, and they want to run the software that works best for
+them. That includes window managers as well as your favourite text
+editor. But even on a GNU/Linux system consisting only of free
+software, you can not easily use the filesystem format, network
+protocol or binary format you want without special privileges. In
+traditional unix systems, user freedom is severly restricted by the
+system administrator.
+
+<P>
+The Hurd removes these restrictions from the user. It provides an
+user extensible system framework without giving up POSIX compatibility
+and the unix security model. Throughout this talk, we will see that
+this brings further advantages beside freedom.
+
+<H4><A HREF="#TOCove" NAME="ove">Overview</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+
+<P>
+The Hurd is a POSIX compatible multi-server
+system operating on top of the GNU&nbsp;Mach microkernel.
+
+<P>
+Topics:
+<UL>
+ <LI>GNU&nbsp;Mach</LI>
+ <LI>The Hurd</LI>
+ <LI>Development</LI>
+ <LI>Debian GNU/Hurd</LI>
+</UL>
+</TD></TR></TABLE>
+
+<P>
+The Hurd is a POSIX compatible multi-server system operating on top of
+the GNU&nbsp;Mach Microkernel.
+
+<P>
+I will have to explain what GNU&nbsp;Mach is, so we start with that. Then
+I will talk about the Hurd's architecture. After that, I will give a
+short overview on the Hurd libraries. Finally, I will tell you how
+the Debian project is related to the Hurd.
+
+<H4><A HREF="#TOChis" NAME="his">Historicals</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%">
+<TR><TD VALIGN="TOP" ALIGN="LEFT">
+<UL>
+ <LI>1983: Richard Stallman founds the GNU project.</LI>
+ <LI>1988: Decision is made to use Mach 3.0 as the kernel.</LI>
+ <LI>1991: Mach 3.0 is released under compatible license.</LI>
+ <LI>1991: Thomas Bushnell, BSG, founds the Hurd project.</LI>
+ <LI>1994: The Hurd boots the first time.</LI>
+ <LI>1997: Version 0.2 of the Hurd is released.<BR><BR></LI>
+ <LI>1998: Debian hurd-i386 archive is created.</LI>
+ <LI>2001: Debian GNU/Hurd snapshot fills three CD images.</LI>
+</UL>
+</TD></TR></TABLE>
+
+<P>
+When Richard Stallman founded the GNU project in 1983, he wanted to
+write an operating system consisting only of free software. Very
+soon, a lot of the essential tools were implemented, and released
+under the GPL. However, one critical piece was missing: The kernel.
+<P>
+After considering several alternatives, it was decided not to write a
+new kernel from scratch, but to start with the Mach microkernel. This
+was in 1988, and it was not before 1991 that Mach was released under a
+license allowing the GNU project to distribute it as a part of the
+system.
+<P>
+In 1998, I started the Debian GNU/Hurd project, and in 2001 the number
+of available GNU/Hurd packages fills three CD images.
+
+<H4><A HREF="#TOCker" NAME="ker">Kernel Architectures</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Microkernel:
+<UL>
+ <LI>Enforces resource management (paging, scheduling)</LI>
+ <LI>Manages tasks</LI>
+ <LI>Implements message passing for IPC</LI>
+ <LI>Provides basic hardware support</LI>
+</UL>
+<P>
+Monolithic kernel:
+<UL>
+ <LI>No message passing necessary</LI>
+ <LI>Rich set of features (filesystems, authentication, network
+ sockets, POSIX interface, ...)</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+Microkernels were very popular in the scientific world around that
+time. They don't implement a full operating system, but only the
+infrastructure needed to enable other tasks to implement most
+features. In contrast, monolithical kernels like Linux contain
+program code of device drivers, network protocols, process management,
+authentication, file systems, POSIX compatible interfaces and much
+more.
+<P>
+So what are the basic facilities a microkernel provides? In general,
+this is resource management and message passing. Resource management,
+because the kernel task needs to run in a special privileged mode of
+the processor, to be able to manipulate the memory management unit and
+perform context switches (also to manage interrupts). Message
+passing, because without a basic communication facility the other
+tasks could not interact to provide the system services. Some
+rudimentary hardware device support is often necessary to bootstrap
+the system. So the basic jobs of a microkernel are enforcing the
+paging policy (the actual paging can be done by an external pager
+task), scheduling, message passing and probably basic hardware device
+support.
+<P>
+Mach was the obvious choice back then, as it provides a rich set of
+interfaces to get the job done. Beside a rather brain-dead device
+interface, it provides tasks and threads, a messaging system allowing
+synchronous and asynchronous operation and a complex interface for
+external pagers. It's certainly not one of the sexiest microkernels
+that exist today, but more like a big old mama. The GNU project
+maintains its own version of Mach, called GNU&nbsp;Mach, which is based on
+Mach 4.0. In addition to the features contained in Mach 4.0, the GNU
+version contains many of the Linux 2.0 block device and network card
+drivers.
+<P>
+A complete treatment of the differences between a microkernel and
+monolithical kernel design can not be provided here. But a couple of
+advantages of a microkernel design are fairly obvious.
+
+<H4><A HREF="#TOCmic" NAME="mic">Micro vs Monolithic</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Microkernel
+<UL>
+ <LI>Clear cut responsibilities
+ <LI>Flexibility in operating system design, easier debugging</LI>
+ <LI>More stability (less code to break)</LI>
+ <LI>New features are not added to the kernel</LI>
+</UL>
+<P>
+Monolithic kernel
+<UL>
+ <LI>Intolerance or creeping featuritis</LI>
+ <LI>Danger of spaghetti code</LI>
+ <LI>Small changes can have far reaching side effects</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+Because the system is split up into several components, clean
+interfaces have to be developed, and the responsibilities of each part
+of the system must be clear.
+<P>
+Once a microkernel is written, it can be used as the base for several
+different operating systems. Those can even run in parallel which
+makes debugging easier. When porting, most of the hardware dependant
+code is in the kernel.
+<P>
+Much of the code that doesn't need to run in the special kernel mode
+of the processor is not part of the kernel, so stability increases
+because there is simply less code to break.
+<P>
+New features are not added to the kernel, so there is no need to hold
+the barrier high for new operating system features.
+<P>
+Compare this to a monolithical kernel, where you either suffer from
+creeping featuritis or you are intolerant of new features (we see both
+in the Linux kernel).
+<P>
+Because in a monolithical kernel, all parts of the kernel can access
+all data structures in other parts, it is more likely that short cuts
+are used to avoid the overhead of a clean interface. This leads to a
+simple speed up of the kernel, but also makes it less comprehensible
+and more error prone. A small change in one part of the kernel can
+break remote other parts.
+
+<H4><A HREF="#TOCsin" NAME="sin">Single Server vs Multi Server</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Single Server
+<UL>
+ <LI>A single task implements the functionality of the operating system.</LI>
+</UL>
+<P>
+Multi Server
+<UL>
+ <LI>Many tasks cooperate to provide the system's functionality.</LI>
+ <LI>One server provides only a small but well-defined part of the
+ whole system.</LI>
+ <LI>The responsibilities are distributed logically among the servers.</LI>
+</UL>
+<P>
+A single-server system is comparable to a monolithic kernel system. It
+has similar
+advantages and disadvantages.
+</TD></TR></TABLE>
+<P>
+There exist a couple of operating systems based on Mach, but they all
+have the same disadvantages as a monolithical kernel, because those
+operating systems are implemented in one single process running on top
+of the kernel. This process provides all the services a monolithical
+kernel would provide. This doesn't make a whole lot of sense (the
+only advantage is that you can probably run several of such isolated
+single servers on the same machine). Those systems are also called
+single-server systems. The Hurd is the only usable multi-server
+system on top of Mach. In the Hurd, there are many server programs,
+each one responsible for a unique service provided by the operating
+system. These servers run as Mach tasks, and communicate using the
+Mach message passing facilities. One of them does only provide a
+small part of the functionality of the system, but together they build
+up a complete and functional POSIX compatible operating system.
+
+<H4><A HREF="#TOCmul" NAME="mul">Multi Server is superior, ...</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Any multi-server has advantages over single-server:
+<UL>
+ <LI>Clear cut responsibilities</LI>
+ <LI>More stability: If one server dies, all others remain</LI>
+ <LI>Easier development cycle: Testing without reboot (or replacing
+ running servers), debugging with gdb</LI>
+ <LI>Easier to make changes and add new features
+</UL>
+</TD></TR></TABLE>
+<P>
+Using several servers has many advantages, if done right. If a file
+system server for a mounted partition crashes, it doesn't take down
+the whole system. Instead the partition is "unmounted", and
+you can try to start the server again, probably debugging it this time
+with gdb. The system is less prone to errors in individual
+components, and over-all stability increases. The functionality of
+the system can be extended by writing and starting new servers
+dynamically. (Developing these new servers is easier for the reasons
+just mentioned.)
+<P>
+But even in a multi-server system the barrier between the system and
+the users remains, and special privileges are needed to cross it. We
+have not achieved user freedom yet.
+
+<H4><A HREF="#TOCthe" NAME="the">The Hurd even more so.</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+The Hurd goes beyond all this, and allows users to write and run their
+servers, too!
+<UL>
+ <LI>Users can replace system servers dynamically with their own
+ implementations.</LI>
+ <LI>Users can decide what parts of the remainder of the system they
+ want to use.</LI>
+ <LI>Users can extend the functionality of the system.</LI>
+ <LI>No mutual trust necessary to make use of other users
+ services.</LI>
+ <LI>Security of the system is not harmed by trusting users
+ services.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+To quote Thomas Bushnell, BSG, from his paper
+<A HREF="/software/hurd/hurd-paper.html">``A new strategy towards OS
+design'' (1996)</A>:
+<BLOCKQUOTE>
+The GNU&nbsp;Hurd, by contrast, is designed to make the area of system code
+as limited as possible. Programs are required to communicate only
+with a few essential parts of the kernel; the rest of the system is
+replaceable dynamically. Users can use whatever parts of the
+remainder of the system they want, and can easily add components
+themselves for other users to take advantage of. No mutual trust need
+exist in advance for users to use each other's services, nor does the
+system become vulnerable by trusting the services of arbitrary users.
+</BLOCKQUOTE>
+
+<P>
+<EM>So the Hurd is a set of servers running on top of the Mach
+micro-kernel, providing a POSIX compatible and extensible operating
+system. What servers are there? What functionality do they provide,
+and how do they cooperate?</EM>
+
+<H4><A HREF="#TOCmac" NAME="mac">Mach Inter Process Communication</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Ports are message queues which can be used as one-way communication
+channels.
+<UL>
+ <LI>Port rights are receive, send or send-once</LI>
+ <LI>Exactly one receiver</LI>
+ <LI>Potentially many senders</LI>
+</UL>
+<P>
+MIG provides remote procedure calls on top of Mach IPC. RPCs look like
+function calls to the user.
+</TD></TR></TABLE>
+<P>
+Inter-process communication in Mach is based on the ports concept. A
+port is a message queue, used as a one-way communication channel. In
+addition to a port, you need a port right, which can be a send right,
+receive right, or send-once right. Depending on the port right, you
+are allowed to send messages to the server, receive messages from it,
+or send just one single message.
+<P>
+For every port, there exists exactly one task holding the receive
+right, but there can be no or many senders. The send-once right is
+useful for clients expecting a response message. They can give a
+send-once right to the reply port along with the message. The kernel
+guarantees that at some point, a message will be received on the reply
+port (this can be a notification that the server destroyed the
+send-once right).
+<P>
+You don't need to know much about the format a message takes to be
+able to use the Mach IPC. The Mach interface generator mig hides the
+details of composing and sending a message, as well as receiving the
+reply message. To the user, it just looks like a function call, but
+in truth the message could be sent over a network to a server running
+on a different computer. The set of remote procedure calls a server
+provides is the public interface of this server.
+
+
+<H4><A HREF="#TOChow" NAME="how">How to get a port?</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Traditional Mach:
+<UL>
+ <LI>Nameserver provides ports to all registered servers.</LI>
+ <LI>The nameserver port itself is provided by Mach.</LI>
+ <LI>Like a phone book: One list.</LI>
+</UL>
+<P>
+The Hurd:
+<UL>
+ <LI>The filesystem is used as the server namespace.</LI>
+ <LI>Root directory port is inserted into each task.</LI>
+ <LI>The C library finds other ports with hurd_file_name_lookup,
+ performing a pathname resolution.</LI>
+ <LI>Like a tree of phone books.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+So how does one get a port to a server? You need something like a
+phone book for server ports, or otherwise you can only talk to
+yourself. In the original Mach system, a special nameserver is
+dedicated to that job. A task could get a port to the nameserver from
+the Mach kernel and ask it for a port (with send right) to a server
+that registered itself with the nameserver at some earlier time.
+<P>
+In the Hurd, there is no nameserver. Instead, the filesystem is used
+as the server namespace. This works because there is always a root
+filesystem in the Hurd (remember that the Hurd is a POSIX compatible
+system); this is an assumption the people who developed Mach couldn't
+make, so they had to choose a different strategy. You can use the
+function hurd_file_name_lookup, which is part of the C library, to get
+a port to the server belonging to a filename. Then you can start to
+send messages to the server in the usual way.
+
+<H4><A HREF="#TOCexa" NAME="exa">Example of <SAMP>hurd_file_name_lookup</SAMP></A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT"><PRE>
+mach_port_t identity;
+mach_port_t pwserver;
+kern_return_t err;
+
+pwserver = hurd_file_name_lookup
+ ("/servers/password");
+
+err = password_check_user (pwserver,
+ 0 /* root */, "supass",
+ &identity);
+</PRE></TD></TR></TABLE>
+<P>
+As a concrete example, the special filename
+<SAMP>/servers/password</SAMP> can be used to request a port to the
+Hurd password server, which is responsible to check user provided
+passwords.
+<P>
+(explanation of the example)
+
+<H4><A HREF="#TOCpat" NAME="pat">Pathname resolution example</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem.
+<UL>
+ <LI>The C library asks the root filesystem server about
+ <SAMP>/mnt/readme.txt</SAMP>.</LI>
+ <LI>The root filesystem returns a port to the mnt filesystem server
+ (matching <SAMP>/mnt</SAMP>) and the retry name
+ <SAMP>/readme.txt</SAMP>.</LI>
+ <LI>The C library asks the mnt filesystem server about
+ <SAMP>/readme.txt</SAMP>.</LI>
+ <LI>The mnt filesystem server returns a port to itself and records
+ that this port refers to the regular file
+ <SAMP>/readme.txt</SAMP>.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+The C library itself does not have a full list of all available
+servers. Instead pathname resolution is used to traverse through a
+tree of servers. In fact, filesystems themselves are implemented by
+servers (let us ignore the chicken and egg problem here). So all the
+C library can do is to ask the root filesystem server about the
+filename provided by the user (assuming that the user wants to resolve
+an absolute path), using the <SAMP>dir_lookup</SAMP> RPC. If the
+filename refers to a regular file or directory on the filesystem, the
+root filesystem server just returns a port to itself and records that
+this port corresponds to the file or directory in question. But if a
+prefix of the full path matches the path of a server the root
+filesystem knows about, it returns to the C library a port to this
+server and the remaining part of the pathname that couldn't be
+resolved. The C library than has to retry and query the other server
+about the remaining path component. Eventually, the C library will
+either know that the remaining path can't be resolved by the last
+server in the list, or get a valid port to the server in question.
+
+<H4><A HREF="#TOCmap" NAME="map">Mapping the POSIX Interface</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<TABLE BORDER="0" CELLPADDING="10">
+<TR>
+<TH>Filedescriptor</TH>
+<TH>Port to server providing the file</TH>
+</TR><TR>
+<TD VALIGN="TOP" ALIGN="LEFT"><SAMP>fd = open(name,...)</SAMP></TD>
+<TD VALIGN="TOP"
+ALIGN="LEFT"><SAMP>dir_lookup(..,name,..,&amp;port)</SAMP><BR>
+[pathname resolution]</TD>
+</TR><TR>
+<TD VALIGN="TOP" ALIGN="LEFT"><SAMP>read(fd, ...)</SAMP></TD>
+<TD VALIGN="TOP" ALIGN="LEFT"><SAMP>io_read(port, ...)</SAMP></TD>
+</TR><TR>
+<TD VALIGN="TOP" ALIGN="LEFT"><SAMP>write(fd, ...)</SAMP></TD>
+<TD VALIGN="TOP" ALIGN="LEFT"><SAMP>io_write(port, ...)</SAMP></TD>
+</TR><TR>
+<TD VALIGN="TOP" ALIGN="LEFT"><SAMP>fstat(fd, ...)</SAMP></TD>
+<TD VALIGN="TOP" ALIGN="LEFT"><SAMP>io_stat(port, ...)</SAMP></TD>
+</TR><TR>
+<TD VALIGN="TOP" ALIGN="LEFT">...</TD><TD></TD>
+</TR>
+</TABLE>
+</TD></TR></TABLE>
+<P>
+It should by now be obvious that the port returned by the server can
+be used to query the files status, content and other information from
+the server, if good remote procedure calls to do that are defined and
+implemented by it. This is exactly what happens. Whenever a file is
+opened using the C libraries <SAMP>open()</SAMP> call, the C library
+uses the above pathname resolution to get a port to a server providing
+the file. Then it wraps a file descriptor around it. So in the Hurd,
+for every open file descriptor there is a port to a server providing
+this file. Many other C library calls like <SAMP>read()</SAMP> and
+<SAMP>write()</SAMP> just call a corresponding RPC using the port
+associated with the file descriptor.
+
+<H4><A HREF="#TOCfilser" NAME="filser">File System Servers</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<UL>
+ <LI>Provide file and directory services for ports (and more).</LI>
+ <LI>These ports are returned by a directory lookup.</LI>
+ <LI>Translate filesystem accesses through their root path (hence the
+ name translator).</LI>
+ <LI>The C library maps the POSIX file and directory interface (and
+ more) to RPCs to the filesystem servers ports, but also does work on
+ its own.</LI>
+ <LI>Any user can install file system servers on inodes they own.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+So we don't have a single phone book listing all servers, but rather a
+tree of servers keeping track of each other. That's really like
+calling your friend and asking for the phone number of the blond girl
+at the party yesterday. He might refer you to a friend who hopefully
+knows more about it. Then you have to retry.
+<P>
+This mechanism has huge advantages over a single nameserver. First,
+note that standard unix permissions on directories can be used to
+restrict access to a server (this requires that the filesystems
+providing those directories behave). You just have to set the
+permissions of a parent directory accordingly and provide no other way
+to get a server port.
+<P>
+But there are much deeper implications. Most of all, a pathname never
+directly refers to a file, it refers to a port of a server. That
+means that providing a regular file with static data is just one of
+the many options the server has to service requests on the file port.
+A server can also create the data dynamically. For example, a server
+associated with <SAMP>/dev/random</SAMP> can provide new random data
+on every <SAMP>io_read()</SAMP> on the port to it. A server
+associated with <SAMP>/dev/fortune</SAMP> can provide a new fortune
+cookie on every <SAMP>open()</SAMP>.
+<P>
+While a regular filesystem server will just serve the data as stored
+in a filesystem on disk, there are servers providing purely virtual
+information, or a mixture of both. It is up to the server to behave
+and provide consistent and useful data on each remote procedure call.
+If it does not, the results may not match the expectations of the user
+and confuse him.
+<P>
+A footnote from the Hurd info manual:
+<BLOCKQUOTE>
+(1) You are lost in a maze of twisty little filesystems, all
+alike....
+</BLOCKQUOTE>
+<P>
+Because a server installed in the filesystem namespace translates all
+filesystem operations that go through its root path, such a server is
+also called "active translator". You can install translators using
+the settrans command with the <SAMP>-a</SAMP> option.
+
+<H4><A HREF="#TOCact" NAME="act">Active vs Passive</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Active Translators:
+<UL>
+ <LI>"<SAMP>settrans -a /cdrom /hurd/isofs /dev/hd2</SAMP>"</LI>
+ <LI>Are running filesystem servers.</LI>
+ <LI>Are attached to the root node they translate.</LI>
+ <LI>Run as a normal process.</LI>
+ <LI>Go away with every reboot, or even time out.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+Many translator settings remain constant for a long time. It would be
+very lame to always repeat the same couple of dozens settrans calls
+manually or at boot time. So the Hurd provides a filesystem extension
+that allows to store translator settings inside the filesystem and let
+the filesystem servers do the work to start those servers on demand.
+Such translator settings are called "passive translators". A passive
+translator is really just a command line string stored in an inode of
+the filesystem. If during a pathname resolution a server encounters
+such a passive translator, and no active translator does exist already
+(for this node), it will use this string to start up a new translator
+for this inode, and then let the C library continue with the path
+resolution as described above. Passive translators are installed with
+settrans using the <SAMP>-p</SAMP> option (which is already the
+default).
+
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Passive Translators:
+<UL>
+ <LI>"<SAMP>settrans /mnt /hurd/ext2fs /dev/hd1s1</SAMP>"</LI>
+ <LI>Are stored as command strings into an inode.</LI>
+ <LI>Are used to start a new active translator if there isn't
+ one.</LI>
+ <LI>Startup is transparent to the user.</LI>
+ <LI>Startup happens the first time the server is needed.</LI>
+ <LI>Are permanent across reboots (like file data).</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+So passive translators also serve as a sort of automounting feature,
+because no manual interaction is required. The server start up is
+deferred until the service is need, and it is transparent to the user.
+<P>
+When starting up a passive translator, it will run as a normal process
+with the same user and group id as those of the underlying inode. Any
+user is allowed to install passive and active translators on inodes
+that he owns. This way the user can install new servers into the
+global namespace (for example, in his home or tmp directory) and thus
+extend the functionality of the system (recall that servers can
+implement other remote procedure calls beside those used for files and
+directories). A careful design of the trusted system servers makes
+sure that no permissions leak out.
+<P>
+In addition, users can provide their own implementations of some of
+the system servers instead the system default. For example, they can
+use their own exec server to start processes. The user specific exec
+server could for example start java programs transparently (without
+invoking the interpreter manually). This is done by setting the
+environment variable <SAMP>EXECSERVERS</SAMP>. The systems default
+exec server will evaluate this environment variable and forward the
+RPC to each of the servers listed in turn, until some server accepts
+it and takes over. The system default exec server will only do this
+if there are no security implications. (XXX There are other ways to
+start new programs than by using the system exec server. Those are
+still available.)
+<P>
+Let's take a closer look at some of the Hurd servers. It was already
+mentioned that only few system servers are mandatory for users. To
+establish your identity within the Hurd system, you have to
+communicate with the trusted systems authentication server
+<SAMP>auth</SAMP>. To put the system administrator into control over
+the system components, the process server does some global
+bookkeeping.
+<P>
+But even these servers can be ignored. However, registration with the
+authentication server is the only way to establish your identity
+towards other system servers. Likewise, only tasks registered as
+processes with the process server can make use of its services.
+
+<H4><A HREF="#TOCaut" NAME="aut">Authentication</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+A user identity is just a port to an authserver. The auth server
+stores four set of ids for it:
+<UL>
+ <LI>effective user ids</LI>
+ <LI>effective group ids</LI>
+ <LI>available user ids</LI>
+ <LI>available group ids</LI>
+</UL>
+<P>
+Basic properties:
+<UL>
+ <LI>Any of these can be empty.</LI>
+ <LI>A 0 among the user ids identifies the superuser.</LI>
+ <LI>Effective ids are used to check if the user has the
+ permission.</LI>
+ <LI>Available ids can be turned into effective ids on user
+ request.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+The Hurd auth server is used to establish the identity of a user for a
+server. Such an identity (which is just a port to the auth server)
+consists of a set of effective user ids, a set of effective group ids,
+a set of available user ids and a set of available group ids. Any of
+these sets can be empty.
+
+<H4><A HREF="#TOCope" NAME="ope">Operations on authentication ports</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+The auth server provides the following operations on ports:
+<UL>
+ <LI>Merge the ids of two ports into a new one.</LI>
+ <LI>Return a new port containing a subset of the ids in a port.</LI>
+ <LI>Create a new port with arbitrary ids (superuser only).</LI>
+ <LI>Establish a trusted connection between users and servers.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+If you have two identities, you can merge them and request an identity
+consisting of the unions of the sets from the auth server. You can
+also create a new identity consisting only of subsets of an identity
+you already have. What you can't do is extending your sets, unless
+you are the superuser which is denoted by having the user id 0.
+
+<H4><A HREF="#TOCest" NAME="est">Establishing trusted connections</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<UL>
+ <LI>User provides a rendezvous port to the server (with
+ <SAMP>io_reauthenticate</SAMP>).</LI>
+ <LI>User calls <SAMP>auth_user_authenticate</SAMP> on the
+ authentication port (his identity), passing the rendezvous port.</LI>
+ <LI>Server calls <SAMP>auth_server_authenticate</SAMP> on its
+ authentication port (to a trusted auth server), passing the
+ rendezvous port and the server port.</LI>
+ <LI>If both authentication servers are the same, it can match the
+ rendezvous ports and return the server port to the user and the user
+ ids to the server.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+Finally, the auth server can establish the identity of a user for a
+server. This is done by exchanging a server port and a user identity
+if both match the same rendezvous port. The server port will be
+returned to the user, while the server is informed about the id sets
+of the user. The server can then serve or reject subsequent RPCs by
+the user on the server port, based on the identity it received from
+the auth server.
+<P>
+Anyone can write a server conforming to the auth protocol, but of
+course all system servers use a trusted system auth server to
+establish the identity of a user. If the user is not using the system
+auth server, matching the rendezvous port will fail and no server port
+will be returned to the user. Because this practically requires all
+programs to use the same auth server, the system auth server is
+minimal in every respect, and additional functionality is moved
+elsewhere, so user freedom is not unnecessarily restricted.
+
+<H4><A HREF="#TOCpas" NAME="pas">Password Server</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+The password server <SAMP>/servers/password</SAMP> runs as root and
+returns a new authentication port in exchange for a unix password.
+<P>
+The ids corresponding to the authentication port match the unix user
+and group ids.
+<P>
+Support for shadow passwords is implemented here.
+</TD></TR></TABLE>
+<P>
+The password server sits at <SAMP>/servers/password</SAMP> and runs as
+root. It can hand out ports to the auth server in exchange for a unix
+password, matching it against the password or shadow file. Several
+utilities make use of this server, so they don't need to be setuid
+root.
+
+<H4><A HREF="#TOCpro" NAME="pro">Process Server</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+The superuser must remain control over user tasks, so:
+<UL>
+ <LI>All mach tasks are associated with a PID in the system default
+ proc server.</LI>
+</UL>
+<P>
+Optionally, user tasks can store:
+<UL>
+ <LI>Their environment variables.</LI>
+ <LI>Their argument vector.</LI>
+ <LI>A port, which others can request based on the PID (like a
+ nameserver).</LI>
+</UL>
+<P>
+Also implemented in the proc server:
+<UL>
+ <LI>Sessions and process groups.</LI>
+ <LI>Global configuration not in Mach, like hostname, hostid, system
+ version.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+The process server is responsible for some global bookkeeping. As
+such it has to be trusted and is not replaceable by the user.
+However, a user is not required to use any of its service. In that
+case the user will not be able to take advantage of the POSIXish
+appearance of the Hurd.
+<P>
+The Mach Tasks are not as heavy as POSIX processes. For example,
+there is no concept of process groups or sessions in Mach. The proc
+server fills in the gap. It provides a PID for all Mach tasks, and
+also stores the argument line, environment variables and other
+information about a process (if the mach tasks provide them, which is
+usually the case if you start a process with the default
+<SAMP>fork()</SAMP>/<SAMP>exec()</SAMP>). A process can also register
+a message port with the proc server, which can then be requested by
+anyone. So the proc server also functions as a nameserver using the
+process id as the name.
+<P>
+The proc server also stores some other miscellaneous information not
+provided by Mach, like the hostname, hostid and system version.
+Finally, it provides facilities to group processes and their ports
+together, as well as to convert between pids, process server ports and
+mach task ports.
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+User tasks not registering themselve with proc only have a PID assigned.
+<P>
+Users can run their own proc server in addition to the system default,
+at least for those parts of the interface that don't require superuser
+privileges.
+</TD></TR></TABLE>
+<P>
+Although the system default proc server can't be avoided (all Mach
+tasks spawned by users will get a pid assigned, so the system
+administrator can control them), users can run their own additional
+process servers if they want, implementing the features not requiring
+superuser privileges.
+
+<H4><A HREF="#TOCfilsys" NAME="filsys">Filesystems</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Store based filesystems
+<UL>
+ <LI><SAMP>ext2fs</SAMP></LI>
+ <LI><SAMP>ufs</SAMP></LI>
+ <LI><SAMP>isofs</SAMP> (iso9660, RockRidge, GNU extensions)</LI>
+ <LI><SAMP>fatfs</SAMP> (under development)</LI>
+</UL>
+<P>
+Network file systems
+<UL>
+ <LI><SAMP>nfs</SAMP></LI>
+ <LI><SAMP>ftpfs</SAMP></LI>
+</UL>
+<P>
+Miscellaneous
+<UL>
+ <LI><SAMP>hostmux</SAMP></LI>
+ <LI><SAMP>usermux</SAMP></LI>
+ <LI><SAMP>tmpfs</SAMP> (under development)</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+We already talked about translators and the file system service they
+provide. Currently, we have translators for the ext2, ufs and iso9660
+filesystems. We also have an nfs client and an ftp filesystem.
+Especially the latter is intriguing, as it provides transparent access
+to ftp servers in the filesystem. Programs can start to move away
+from implementing a plethora of network protocols, as the files are
+directly available in the filesystem through the standard POSIX file
+interface.
+
+
+<H4><A HREF="#TOCdev" NAME="dev">Developing the Hurd</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Over a dozen libraries support the development of new servers.
+<P>
+For special server types highly specialized
+libraries require only the implementation of a
+number of callback functions.
+<UL>
+ <LI>Use <SAMP>libdiskfs</SAMP> for store based filesystems.</LI>
+ <LI>Use <SAMP>libnetfs</SAMP> for network filesystems, also for
+ virtual filesystems.</LI>
+ <LI>Use <SAMP>libtrivfs</SAMP> for simple filesystems providing only
+ a single file or directory.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+The Hurd server protocols are complex enough to allow for the
+implementation of a POSIX compatible system with GNU extensions.
+However, a lot of code can be shared by all or at least similar
+servers. For example, all storage based filesystems need to be able to
+read and write to a store medium splitted in blocks. The Hurd comes
+with several libraries which make it easy to implement new servers.
+Also, there are already a lot of examples of different server types in
+the Hurd. This makes writing a new server easier.
+<P>
+<SAMP>libdiskfs</SAMP> is a library that supports writing store based
+filesystems like ext2fs or ufs. It is not very useful for filesystems
+which are purely virtual, like <SAMP>/proc</SAMP> or files in
+<SAMP>/dev</SAMP>.
+<P>
+<SAMP>libnetfs</SAMP> is intended for filesystems which provide a rich
+directory hierarchy, but don't use a backing store (for example ftpfs,
+nfs).
+<P>
+<SAMP>libtrivfs</SAMP> is intended for filesystems which just provide
+a single inode or directory. Most servers which are not intended to
+provide a filesystem but other services (like
+<SAMP>/servers/password</SAMP>) use it to provide a dummy file, so
+that file operations on the servers node will not return errors. But
+it can also be used to provide meaningful data in a single file, like
+a device store or a character device.
+
+<H4><A HREF="#TOCsto" NAME="sto">Store Abstraction</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Another very useful library is libstore, which is used by all store
+based filesystems. It provides a store media abstraction. A store
+consists of a store class and a name (which itself can sometimes
+contain stores).
+<P>
+Primitive store classes:
+<UL>
+ <LI>device store like device:hd2, device:hd0s1, device:fd0</LI>
+ <LI>file store like file:/tmp/disk_image</LI>
+ <LI>task store like task:PID</LI>
+ <LI>zero store like zero:4m (like /dev/zero, of size 4 MB)</LI>
+</UL>
+</TD></TR></TABLE>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Composed store classes:
+<UL>
+ <LI>copy store like copy:zero:4m</LI>
+ <LI>gunzip/bunzip2 store like gunzip:device:fd0</LI>
+ <LI>concat store like concat:device:hd0s2:device:hd1s5</LI>
+ <LI>ileave store (RAID-0(2))</LI>
+ <LI>remap store like remap:10+20,50+:file:/tmp/blocks</LI>
+ <LI>...</LI>
+</UL>
+<P>
+Wanted: A similar abstraction for streams (based on channels), which
+can be used by network and character device servers.
+</TD></TR></TABLE>
+<P>
+<SAMP>libstore</SAMP> provides a store abstraction, which is used by
+all store based filesystems. The store is determined by a type and a
+name, but some store types modify another store rather than providing
+a new store, and thus stores can be stacked. For example, the device
+store type expects a Mach device, but the remap store expects a list
+of blocks to pick from another store, like remap:1+:device:hd2, which
+would pick all blocks from hd2 but the first one, which skipped.
+Because this functionality is provided in a library, all libstore
+using filesystems support many different store kinds, and adding a new
+store type is enough to make all store based filesystems support it.
+
+<H4><A HREF="#TOCdeb" NAME="deb">Debian GNU/Hurd</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Goal:
+<UL>
+ <LI>Provide a binary distribution of the Hurd that is easy to
+ install.</LI>
+</UL>
+<P>
+Constraints:
+<UL>
+ <LI>Use the same source packages as Debian GNU/Linux.</LI>
+ <LI>Use the same infrastructure:
+ <UL>
+ <LI>Policy</LI>
+ <LI>Archive</LI>
+ <LI>Bug tracking system</LI>
+ <LI>Release process</LI>
+ </UL></LI>
+</UL>
+<P>
+Side Goal:
+<UL>
+ <LI>Prepare Debian for the future:
+ <UL>
+ <LI>More flexibility in the base system</LI>
+ <LI>Identify dependencies on the Linux kernel</LI>
+ </UL></LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+The Debian distribution of the GNU&nbsp;Hurd that I started in 1998 is
+supposed to become a complete binary distribution of the Hurd that is
+easy to install.
+
+<H4><A HREF="#TOCstabin" NAME="stabin">Status of the Debian GNU/Hurd binary archive</A></H4>
+<P>
+See
+<A HREF="http://buildd.debian.org/stats/graph.png">http://buildd.debian.org/stats/graph.png</A>
+for the most current version of the statistic.
+
+<H4><A HREF="#TOCstainf" NAME="stainf">Status of the Debian infrastructure</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Plus:
+<UL>
+ <LI>Source packages can identify build and host OS using
+ dpkg-architecture.</LI>
+</UL>
+<P>
+Minus:
+<UL>
+ <LI>The binary architecture field is insufficient.</LI>
+ <LI>The BTS has no architecture tag.</LI>
+ <LI>The policy/FHS need (small) Hurd specific extensions.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+While good compatibiity can be achieved at the source level,
+the binary packages can not always express their relationship
+to the available architectures sufficiently.
+<P>
+For example, the Linux version of makedev is binary-all, where
+a binary-all-linux relationship would be more appropriate.
+<P>
+More work has to be done here to fix the tools.
+
+<H4><A HREF="#TOCstaarc" NAME="staarc">Status of the Debian Source archive</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<UL>
+ <LI>Most packages just work.</LI>
+ <LI>Maintainers are usually responsive and cooperative.</LI>
+ <LI>Turtle, the autobuilder, crunches through the whole list right
+ now.</LI>
+</UL>
+<P>
+Common pitfalls are POSIX incompatibilities:
+<UL>
+ <LI>Upstream:
+ <UL>
+ <LI>Unconditional use of <SAMP>PATH_MAX</SAMP>
+ (<SAMP>MAXPATHLEN</SAMP>), <SAMP>MAXHOSTNAMELEN</SAMP>.</LI>
+ <LI>Unguarded use of Linux kernel features.</LI>
+ <LI>Use of legacy interfaces (<SAMP>sys_errlist</SAMP>,
+ <SAMP>termio</SAMP>).</LI>
+ </UL></LI>
+ <LI>Debian:
+ <UL>
+ <LI>Unguarded activation of extensions available with Linux.</LI>
+ <LI>Low quality patches.</LI>
+ <LI>Assuming GNU/Linux in package scripts.</LI>
+ </UL></LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+Most packages are POSIX compatible and can be compiled without
+changes on the Hurd. The maintainers of the Debian source packages
+are usually very kind, responsiver and helpful.
+<P>
+The Turtle autobuilder software (<A
+HREF="http://turtle.sourceforge.net" >http://turtle.sourceforge.net</A>)
+builds the Debian packages on the Hurd automatically.
+
+<H4><A HREF="#TOCdebide" NAME="debide">Debian GNU/Hurd: Good idea, bad idea?</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Upstream benefits:
+<UL>
+ <LI>Software packages become more portable.</LI>
+</UL>
+<P>
+Debian benefits:
+<UL>
+ <LI>Debian becomes more portable.</LI>
+ <LI>Maintainers learn about portability and other systems.</LI>
+ <LI>Debian gets a lot of public recognition.</LI>
+</UL>
+<P>
+GNU/Hurd benefits:
+<UL>
+ <LI>Large software base.</LI>
+ <LI>Great infrastructure.</LI>
+ <LI>Nice community to partner with.</LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+The sheet lists the advantages of all groups involved.
+
+<H4><A HREF="#TOCend" NAME="end">End</A></H4>
+<TABLE BORDER="1" CELLPADDING="5" WIDTH="100%"><TR><TD VALIGN="TOP" ALIGN="LEFT">
+<P>
+Join us at
+<UL>
+ <LI><A HREF="http://hurd.gnu.org/" >http://hurd.gnu.org/</A></LI>
+ <LI><A HREF="http://www.debian.org/ports/hurd"
+ >http://www.debian.org/ports/hurd</A></LI>
+ <LI><A HREF="http://www.hurdfr.org"
+ >http://www.hurdfr.org</A></LI>
+</UL>
+</TD></TR></TABLE>
+<P>
+List of contacts.
+
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web sites.</EM>
+
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd-talk.html">English</A>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001 Marcus Brinkmann <A HREF="mailto:marcus@gnu.org">&lt;marcus@gnu.org&gt;</A>
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/hurd.html b/hurd.html
new file mode 100644
index 00000000..b0eb9f80
--- /dev/null
+++ b/hurd.html
@@ -0,0 +1,224 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+<br>
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd.cn.html">Chinese(Simplified)</A>
+| <A HREF="/software/hurd/hurd.zh.html">Chinese(Traditional)</A>
+| <A HREF="/software/hurd/hurd.nl.html">Dutch</A>
+| <A HREF="/software/hurd/hurd.html">English</A>
+| <A HREF="/software/hurd/hurd.eo.html">Esperanto</A>
+| <A HREF="/software/hurd/hurd.el.html">Greek</A>
+| <A HREF="/software/hurd/hurd.he.html">Hebrew</A>
+| <A HREF="/software/hurd/hurd.it.html">Italian</A>
+| <A HREF="/software/hurd/hurd.pl.html">Polish</A>
+| <A HREF="/software/hurd/hurd.es.html">Spanish</A>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<P>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#introduction" NAME="TOCintroduction">Introduction to the Hurd</A>
+ <LI><A HREF="#advantages" NAME="TOCadvantages">Advantages of the Hurd</A>
+ <LI><A HREF="#name" NAME="TOCname">What the Hurd means</A>
+ <LI><A HREF="#status" NAME="TOCstatus">Status of the project</A>
+</UL>
+<P>
+<HR>
+
+<H3><A HREF="#TOCintroduction" NAME="introduction">Introduction to the Hurd</A></H3>
+<P>
+The GNU&nbsp;Hurd is the GNU project's replacement for the Unix kernel.
+The Hurd is a collection of servers that run on the Mach microkernel
+to implement file systems, network protocols, file access control, and
+other features that are implemented by the Unix kernel or similar
+kernels (such as Linux).
+<P>
+Currently, the Hurd runs on IA32 machines. The Hurd should, and
+probably will, be ported to other hardware architectures or other
+microkernels in the future.
+
+<H3><A HREF="#TOCadvantages" NAME="advantages">Advantages of the Hurd</A></H3>
+The Hurd is not the most advanced kernel known to the planet (yet),
+but it does have a number of enticing features:
+<DL>
+<DT><STRONG>it's free software</STRONG></DT>
+<DD>
+Anybody can use, modify, and redistribute it under the terms of the
+<A HREF="/copyleft/gpl.html">GNU General Public License (GPL)</A>.</DD>
+<DT><STRONG>it's compatible</STRONG></DT>
+<DD>
+The Hurd provides a familiar programming and user environment. For
+all intents and purposes, the Hurd is a modern Unix-like kernel. The
+Hurd uses the <A HREF="/software/libc/libc.html">GNU C Library</A>,
+whose development closely tracks standards such as ANSI/ISO, BSD,
+POSIX, Single Unix, SVID, and X/Open.
+</DD>
+<DT><STRONG>it's built to survive</STRONG></DT>
+<DD>
+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.
+</DD>
+<DT><STRONG>it's scalable</STRONG></DT>
+<DD>
+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
+(<I>collectives</I>), although this feature has not yet been
+implemented.
+</DD>
+<DT><STRONG>it's extensible</STRONG></DT>
+<DD>
+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 modified and extended.
+</DD>
+<DT><STRONG>it's stable</STRONG></DT>
+<DD>
+It is possible to develop and test new Hurd kernel components without
+rebooting the machine (not even accidentally). 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.
+</DD>
+<DT><STRONG>it exists</STRONG></DT>
+<DD>
+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 and developing it.
+</DD>
+</DL>
+
+<H3><A HREF="#TOCname" NAME="name">What the Hurd means</A></H3>
+According to Thomas Bushnell, BSG, the primary architect of the Hurd:
+<BLOCKQUOTE>
+`Hurd' stands for `Hird of Unix-Replacing Daemons'. And, then, `Hird'
+stands for `Hurd of Interfaces Representing Depth'. We have here, to
+my knowledge, the first software to be named by a pair of mutually
+recursive acronyms.
+</BLOCKQUOTE>
+
+<H3><A HREF="#TOCstatus" NAME="status">Status of the project</A></H3>
+<P>
+The Hurd, together with the GNU&nbsp;Mach microkernel, the GNU C Library
+and the other GNU and non-GNU programs in the GNU system, provide a
+rather complete and usable operating system today. It is not ready
+for production use, as there are still many bugs and missing features.
+However, it should be a good base for further development and
+non-critical application usage.
+<P>
+The GNU system (also called GNU/Hurd) is completely self-contained
+(you can compile all parts of it using GNU itself). You can run
+several instances of the Hurd in parallel, and debug even critical
+servers in one Hurd instance with gdb running on another Hurd
+instance. You can run the X window system, applications that use it,
+and advanced server applications like the Apache webserver.
+<P>
+On the negative side, the support for character devices (like sound
+cards) and other hardware is mostly missing. Although the POSIX
+interface is provided, some additional interfaces like POSIX shared
+memory or semaphores are still under development.
+<P>
+All this applies to the current development version, and not to the
+last release (0.2). We encourage everybody who is interested to try
+out the latest development version, and send feedback to the Hurd
+developers.
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/hurd.cn.html">Chinese(Simplified)</A>
+| <A HREF="/software/hurd/hurd.zh.html">Chinese(Traditional)</A>
+| <A HREF="/software/hurd/hurd.nl.html">Dutch</A>
+| <A HREF="/software/hurd/hurd.html">English</A>
+| <A HREF="/software/hurd/hurd.eo.html">Esperanto</A>
+| <A HREF="/software/hurd/hurd.el.html">Greek</A>
+| <A HREF="/software/hurd/hurd.he.html">Hebrew</A>
+| <A HREF="/software/hurd/hurd.it.html">Italian</A>
+| <A HREF="/software/hurd/hurd.pl.html">Polish</A>
+| <A HREF="/software/hurd/hurd.es.html">Spanish</A>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/install.html b/install.html
new file mode 100644
index 00000000..b1517dae
--- /dev/null
+++ b/install.html
@@ -0,0 +1,126 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/install.html">English</A>
+| <A HREF="/software/hurd/install.eo.html">Esperanto</A>
+| <a href="/software/hurd/install.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#version" NAME="TOCversion">Latest version</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCversion" NAME="version">Latest version</A></H3>
+<P>
+The GNU&nbsp;Hurd is under active development. Because of that, there is
+no `stable' version. We distribute the Hurd sources only through CVS
+at present.
+<P>
+Although it is possible to bootstrap the GNU/Hurd system from the sources
+by cross-compiling and installing the system software and the basic
+applications, this is a difficult process. It is not recommended that
+you do this. Instead, you should get a binary distribution of the
+GNU/Hurd, which comes with all the GNU software precompiled and an
+installation routine which is easy to use.
+<P>
+The Debian project has commited to provide such a binary distribution.
+<A HREF="http://www.debian.org/ports/hurd/">Debian GNU/Hurd</A> is
+currently under development and available in the sid/unstable branch
+of the Debian archive. Please see
+the <A HREF="http://www.debian.org/ports/hurd/">Debian GNU/Hurd</A>
+projects web page for installation instructions.
+
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web sites.</EM>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/install.html">English</A>
+| <A HREF="/software/hurd/install.eo.html">Esperanto</A>
+| <a href="/software/hurd/install.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/mig-download.html b/mig-download.html
new file mode 100644
index 00000000..efbf1359
--- /dev/null
+++ b/mig-download.html
@@ -0,0 +1,167 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/mig-download.html">English</A>
+| <a href="/software/hurd/mig-download.es.html">Spanish</a>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <LI><A HREF="#release" NAME="TOrelease">Latest Release</A>
+ <LI><A HREF="#cvs" NAME="TOCcvs">CVS repository</A>
+ <LI><A HREF="#cvsweb" NAME="TOCcvsweb">Browsing the code</A>
+</UL>
+<HR>
+
+<H3><A HREF="#TOCrelease" NAME="release">Latest Release</A></H3>
+<P>
+The latest release of MIG is version 1.3, 2002-03-08. However, it is
+recommended that you use the version in CVS instead, as we are only a few steps
+before we'll do another release from there.
+
+<!--
+It features:
+<UL>
+<LI>Minor bug fixes.</LI>
+<LI>The new keyword <CODE>retcode</CODE> is accepted as a parameter
+modifier. This does not do anything, but is accepted for
+compatibility with the MIG input syntax used with OSF Mach.</LI>
+<LI>The <CODE>debian/</CODE> subdirectory of packaging files is now
+included in the MIG source distribution.</LI>
+</UL>
+<P>
+You can download the latest version of MIG from the GNU ftp server:
+<UL>
+<LI><CODE><A
+HREF="http://ftp.gnu.org/gnu/mig/mig-1.3.tar.gz">mig-1.3.tar.gz</A></CODE>
+[145K].</LI>
+<LI><CODE><A
+HREF="http://ftp.gnu.org/gnu/mig/mig-1.3.tar.gz.sig">mig-1.3.tar.gz.sig</A></CODE>
+[1K].</LI>
+</UL>
+-->
+
+<H3><A HREF="#TOCcvs" NAME="cvs">CVS repository</A></H3>
+<P>
+The MIG source code is managed in the version control system <A
+HREF="/software/cvs/cvs.html">CVS</A>. You can check out the CVS
+repository through anonymous CVS over SSH with the following
+instruction set. When prompted for a password for <I>anoncvs</I>,
+simply press the Enter key.
+
+<P>
+Source tree:
+&nbsp;<BR>
+<SAMP>cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig</SAMP>
+
+<P>Updates from within the module's directory do not need the -d parameter.
+
+<P>For the full details, read the <A
+href="https://savannah.gnu.org/cvs/?group=hurd">savannah</A> page.
+
+<H3><A HREF="#TOCcvsweb" NAME="cvsweb">Browsing the code</A></H3>
+<P>
+You can also browse the <A
+HREF="http://cvs.savannah.gnu.org/viewcvs/hurd/mig/">CVS
+repository of MIG</A> with your web browser. The web pages are
+generated dynamically at the time you request them and are always up
+to date.
+<P>
+There is also a <A
+HREF="http://www.htu.tugraz.at/~past/hurd/global/">cross referenced
+database</A> of the Hurd, GNU&nbsp;Mach, MIG, and the GNU C library sources
+online for you to browse. It provides better searching and browsing
+facilities than the online CVS repository, but it is not always up to
+date and does not contain history information.
+
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web sites.</EM>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/mig-download.html">English</A>
+| <a href="/software/hurd/mig-download.es.html">Spanish</a>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/mig.html b/mig.html
new file mode 100644
index 00000000..49e19a37
--- /dev/null
+++ b/mig.html
@@ -0,0 +1,125 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <a href="/software/hurd/mig.html">en</a>
+| <a href="/software/hurd/mig.es.html">es</a>
+| <a href="/software/hurd/mig.he.html">he</a>
+| <a href="/software/hurd/mig.pl.html">pl</a>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<a href="/software/hurd/mig.html"><strong>GNU&nbsp;MIG</strong></a><br>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<P>
+<H3><A NAME="contents">Table of Contents</A></H3>
+<UL>
+ <li><a href="#introduction" name="TOCintroduction">Introduction to MIG</a>
+ <LI><A HREF="#status" NAME="TOCstatus">Status of the project</A>
+</UL>
+<P>
+<HR>
+
+<h3><a href="#TOCintroduction" name="introduction">Introduction to GNU&nbsp;MIG</a></h3>
+<p>
+GNU&nbsp;MIG is the GNU distribution of the Mach 3.0 interface generator `MIG', as
+maintained by the GNU&nbsp;Hurd developers for the GNU project.
+<p>
+The interface generator produces stub code from interface definition
+(<code>.defs</code>) files. The stub code makes it easy to implement
+and use Mach interfaces as remote procedure calls (RPC).
+<p>
+You need this tool to compile the GNU&nbsp;Mach and GNU&nbsp;Hurd distributions, and to
+compile the GNU C library for the Hurd. Also, you will need it for other
+software in the GNU system that uses Mach-based inter-process communication.
+
+<H3><A HREF="#TOCstatus" NAME="status">Status of the project</A></H3>
+<P>
+MIG 1.3 was released in March 2002, and features compatibility with
+OSF Mach.
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <a href="/software/hurd/mig.html">en</a>
+| <a href="/software/hurd/mig.es.html">es</a>
+| <a href="/software/hurd/mig.he.html">he</a>
+| <a href="/software/hurd/mig.pl.html">pl</a>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2006 Free Software Foundation, Inc.,
+51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/old_hurd_faq.html b/old_hurd_faq.html
new file mode 100644
index 00000000..b310824b
--- /dev/null
+++ b/old_hurd_faq.html
@@ -0,0 +1,318 @@
+<html>
+<head>
+<title>The Unofficial (and no longer maintained) GNU&nbsp;Hurd FAQ, Version 0.13 </title>
+</head>
+
+<body>
+<pre>The Unofficial (and no longer maintained) GNU&nbsp;Hurd FAQ, Version 0.13
+
+Contributions by:
+
+Michael I. Bushnell <mib@gnu.org>
+Len Tower <tower@gnu.org>
+Trent Fisher <trent@gnurd.uu.pdx.edu>
+jlr@usoft.spb.su
+Remy Card <Remy.Card@masi.ibp.fr>
+Louis-Dominique Dubeau <hallu@info.polymtl.ca>
+
+Original Document by: Derek Upham <upham@cs.ubc.ca>
+
+
+==============================
+
+Contents:
+
+Q0. Where can I get the Unofficial GNU&nbsp;Hurd FAQ?
+Q1. What is the Hurd?
+Q2. Where can I get a copy?
+Q3. Why bother writing a new OS when we have Linux and 386/BSD?
+Q4. What's all this about Mach 3.0 (and Mach 4.0)?
+Q5. Where can I find more information?
+Q6. What's a proper machine?
+Q7. What sort of machines will run Hurd in the future?
+Q8. What is the current development status?
+Q9. What sort of system would we have if the Hurd was bootable today?
+
+==============================
+
+Q0. Where can I get the Unofficial GNU&nbsp;Hurd FAQ?
+
+The Unofficial Hurd FAQ (what you are reading now) is occasionally
+posted to the USENET newsgroup, gnu.misc.discuss. It is also
+available from
+
+ http://www.enci.ucalgary.ca/~gord/hurd/hurd-faq.txt
+
+If you don't have WWW access, you may send mail to me, Gordon
+Matzigkeit <gord@enci.ucalgary.ca> with a subject line that reads:
+
+ Subject: send hurd-faq
+
+You should receive a PGP-signed copy of the current version of this
+document in a matter of minutes.
+
+
+Q1. What is the Hurd?
+
+The Hurd is the high-level operating system for GNU. It is currently
+under development. GNU was designed as a replacement for Unix, so the
+Hurd is multi-tasking and multi-user, POSIX-compliant, and will have
+networking and X-windows and all that good stuff.
+
+Hurd is an acronym for ``Hird of Unix-Replacing Daemons''. Hird, in
+turn, is an acronym for ``Hurd of Interfaces Representing Depth''.
+
+
+Q2. Where can I get a copy?
+
+To put it simply, you can't. It is still under development (by
+Michael Bushnell, Roland McGrath and Miles Bader). It is almost, but
+not quite, at the point where you can do real work on it. Keep your
+fingers crossed.
+
+Some people have actually bootstrapped it, but the work is not easy,
+and the current snapshot won't work until a new multiserver boot
+mechanism is made.
+
+If you *really* want to try it, beware that it is still pre-alpha
+code, and that it will likely crash on you. See Trent Fisher's Hurd
+pages (under question 5) for the latest information.
+
+
+Q3. Why bother writing a new OS when we have Linux and 386/BSD?
+
+For one thing, Linux and BSD don't scale well. Hardware designers are
+shifting more and more toward multiprocessor machines for performance,
+and standard Unix kernels do not provide much multiprocessor support.
+The Hurd, on the other hand, runs on top of the Mach 3.0 micro-kernel
+[[1]] from CMU. Mach was designed precisely for multiprocessing
+machines, so its portability should carry over nicely to the Hurd.
+
+In addition, the Hurd will be considerably more flexible and robust
+than generic Unix. Wherever possible, Unix kernel features have been
+moved into unprivileged space. Once there, anyone who desires can
+develop custom replacements for them. Users will be able to write and
+use their own file systems, their own `exec' servers, or their own
+network protocols if they like, all without disturbing other users.
+
+The Linux kernel has now been modified to allow user-level file
+systems, so there is proof that people will actually use features such
+as these. It will be much easier to do under the Hurd, however,
+because the Hurd is almost entirely run in user space and because the
+various servers are designed for this sort of modification.
+
+
+Q4. What's all this about Mach 3.0 (and Mach 4.0)?
+
+As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon
+University. A more descriptive term might be a greatest-common-factor
+kernel, since it provides facilities common to all ``real'' operating
+systems, such as memory management, interprocess communication,
+processes, and a bunch of other stuff. Unfortunately, the system
+calls used to access these facilities are only vaguely related to the
+familiar and cherished Unix system calls. There are no "fork",
+"wait", or "sleep" system-calls, no SIGHUPs, nothing like that. All
+this makes it rather difficult to, say, port GNU Emacs to a Mach box.
+
+The trick is, of course, to write an emulation library. Unix programs
+can then use (what they think are) POSIX system calls and facilities
+while they are really using Mach system calls and facilities.
+
+The simplest way of going about this is to take an ordinary Unix
+kernel, open it up, and rip out all the machine-specific guts; any
+time the Unix kernel talks to the machine, replace the code with calls
+to the Mach micro-kernel. Run this fake kernel on a Mach machine and
+you end up with something that looks and acts just like Unix (even to
+GNU Emacs). Note that the Unix kernel we have implemented is just one
+Really Big Mach program (called a single-server).
+
+The Hurd, on the other hand, breaks the giant Unix kernel down into
+various Mach programs running as daemons. Working in concert with
+facilities placed in the C library, these daemons provide all of the
+POSIX system-calls and features; from the outside they look just like
+a standard Unix kernel. This means that, for practical purposes,
+anything that you can port to Linux will also port to the Hurd.
+
+Of course, if a user wishes to run his own daemons, he can do that as
+well....
+
+Mach 4.0 is an enhanced version of Mach 3.0, put out by the people at
+the University of Utah. They are working on another free operating
+system, and part of it includes an enhanced, more flexible version of
+Mach. The Hurd has moved to Mach 4.0, which is good, because it is a
+lot easier to build than 3.0 was.
+
+You can find more information on Mach by browsing the Hurd pages given
+in the next answer, or by looking at the Project Mach and Flux
+homepages at:
+
+Carnegie Mellon University (for Mach versions before 4.0):
+
+ http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html
+
+the University of Utah (for Mach 4.0):
+
+ http://www.cs.utah.edu/projects/flux/mach4/html/
+
+
+Q5. Where can I find more information?
+
+The June 1995 GNU's Bulletin contains the following official
+information:
+
+ The GNU&nbsp;Hurd now runs programs native. We have implemented both
+ shared libraries using ELF, & the popular `ext2' file system used
+ by Linux. It can run GCC, `make', Emacs, & most other GNU
+ utilities. Progress is being made so rapidly that by the time you
+ read this it probably does much more. It is right on the verge of
+ being self-hosting (able to run on its own well enough to compile
+ its own source code, & be used for its own development). We have
+ much better device supportm [sic] & some new utilities, including a
+ fancy `ps' & `settrans'. For a complete system we still have much
+ more work to do, but we will make an alpha release as soon as the
+ network software is finished & shared libraries have been well
+ tested. We have a mailing list to announce progress; to be added
+ to it, ask `hurd-announce-request@gnu.org'.
+
+The Portland State University CS department (via Trent Fisher)
+maintains a WWW server with various Hurd documents, including Michael
+Bushnell's Hurd paper, all the collected GNU's Bulletins, and various
+announcements posted to "gnu.misc.discuss". The top-level GNU page is
+
+ http://www.cs.pdx.edu/~trent/gnu/gnu.html
+
+and the Hurd page is
+
+ http://www.cs.pdx.edu/~trent/gnu/hurd/hurd.html
+
+People in Europe might want to try the GNU WWW server for DESY
+Germany, first:
+
+ http://info.desy.de/gnu/www
+
+This site lacks culled, Hurd-specific information at the moment, but
+it does have the last two GNU's Bulletins plus lots of general
+information.
+
+There is a snapshot of the Hurd development tree on
+"alpha.gnu.ai.mit.edu" in the "/gnu" directory. It is updated as
+significant changes are made, and not guaranteed to run.
+
+You can subscribe to the Hurd announcement list by sending a request
+to "hurd-announce-request@gnu.org". This is a moderated list
+for distributing Hurd info to ``all and sundry'', and anyone can join.
+In addition, there is a private (invitation-only) list for developers
+to coordinate their efforts. It's not even worth thinking about
+unless you (a) have a lot of free time on your hands, (b) know Unix
+internals and Mach very well, and (c) have a proper machine.
+
+
+Q6. What's a proper machine?
+
+A ``proper machine'', at the moment, means an x86 box running Mach 3.0
+(or 4.0), with FreeBSD 2.x, NetBSD 1.x, or Linux.
+
+A single-server OS is no longer required for development because by
+the time the Hurd bootstrap mechanism is finished, the Hurd will
+probably be self-hosting.
+
+Linux, FreeBSD, or NetBSD will only be required to splat the Hurd
+binaries onto a partition of some sort, and to provide a way of
+transferring files to the Hurd until the networking code is ready.
+
+
+Q7. What sort of machines will run Hurd in the future?
+
+The first thing a prospective Hurd machine needs is a Mach 3.0 port.
+According to the most recent "comp.os.mach" FAQ (which hasn't been
+updated since February 1994), the following chips have redistributable
+Mach micro-kernels and device drivers:
+
+ Intel 80x86 (ISA and PS/2 buses)
+ Motorola 68000 (Sun 3)
+ Motorola 88000 (Omron Luna)
+ DEC Vax
+ DEC Pmax (DECstation 3100)
+ DEC Alpha
+ MIPS R4000 (DECstation 5000 et al.)
+ IBM RS/6000
+ Apple Macintosh
+
+IBM is planning to run WorkplaceOS (the OS/2 successor) over Mach 3.0
+on the PowerPC chip (closely related to the RS/6000), so the PowerPC
+will likely be added to this list soon. The University of Utah has
+ported Mach 4.0 to the HP700, but it is not yet stable.
+
+Sun Sparc machines have a redistributable Mach microkernel, but the
+device drivers require a SunOS 4.1.1 source license.
+
+In addition, any prospective Hurd machine needs a port of the GNU C
+library. Version 1.07.4 of the library can handle the following
+chips:
+
+ Intel 80x86 (BSD, Dynix, Hurd, SCO, SysV)
+ Motorola 68000 (HP BSD, NEWS, Sun 4)
+ MIPS R4000 (Ultrix)
+ Sun Sparc (Solaris 2, Sun 4)
+ DEC Alpha (OSF/1, mostly finished)
+
+So if the next Hurd snapshot is self-hosting, we will be able to run
+it (in theory) on Intel 80x86s, Motorola 68000s, MIPS R4000s and DEC
+Alphas.
+
+People who can port the Mach micro-kernel to new architectures are
+encouraged to do so. People who can port the GNU C library to new
+chips (a much larger group) are also encouraged to do so. You can
+help out here without knowing anything about Mach or having any
+special machine. Note that once the GNU C library exists for a new
+chip, for _any_ OS, making a Hurd port later is simple (and making
+ports to other chips becomes easier as well---the effects are
+cumulative).
+
+By current indications, the other hardware requirements (RAM, disk
+space, and the like) will be about the same as those of BSD 4.4.
+
+
+Q8. What is the current development status?
+
+Please see Trent Fisher's Hurd pages for details.
+
+
+Q9. What sort of a system would we have if the Hurd was bootable
+today?
+
+Quite likely, if you already use an end-user system like Linux,
+FreeBSD, or NetBSD, you'll be disappointed with the Hurd. It will
+take some time before the OS hackers really get to work on
+applications and major enhancements.
+
+But, rest assured, Hurd development should proceed very rapidly.
+
+Of course, if you think you can help, or you just enjoy neat stuff,
+then you'll probably like the Hurd. When you actually understand a
+fraction of what's going on behind the scenes, it's very impressive.
+
+All I'm saying is that I'm not expecting all the Windows '95 users in
+the world to switch to the Hurd right away. Wait a little while,
+maybe 5-6 years (ample time for GNUStep and Guile to be in use), and
+GNU users everywhere will be very happy that the FSF proceeded with
+the Hurd. :)
+
+
+==============================
+
+Footnotes:
+
+[[1]] Yes, I know that ``micro-kernel'' is about as apt a description
+as ``Reduced Instruction Set Chip'', but we're stuck with it.
+
+</pre>
+<P>
+Updated:
+<!-- hhmts start -->
+23 Feb 1998 grat-w
+<!-- hhmts end -->
+<HR>
+
+</body>
+</html>
diff --git a/related-projects.html b/related-projects.html
new file mode 100644
index 00000000..2556f5e2
--- /dev/null
+++ b/related-projects.html
@@ -0,0 +1,131 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/related-projects.html">English</A>
+| <A HREF="/software/hurd/related-projects.eo.html">Esperanto</A>
+| <a href="/software/hurd/related-projects.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<P>
+<H3>Related Projects</H3>
+<P>
+The Hurd is not alone, it is inspired by other projects, and other
+projects have been influenced or spawned by the Hurd.
+<P>
+Below you can find some of the projects which are closely related to
+the Hurd, be it because they develop software that might be part of
+the Hurd system some day, be it because they support or use the Hurd
+in their own development.
+<P>
+This list is nowhere near to be complete. We recommend to follow the
+mailing lists to be informed about recent developments.
+<P>
+<EM>Some of these links are at other web sites not maintained by the
+FSF. The FSF is not responsible for the content of these other web
+sites.</EM>
+
+<H4>Software</H4>
+
+<LI>GNU/Hurd on Alpha</LI>
+<P>
+The purpose of this project is to provide a working implementation of
+the GNU&nbsp;Hurd for the Alpha architecture.
+<BR>
+<CODE><A HREF="http://savannah.gnu.org/projects/hurd-alpha/">http://savannah.gnu.org/projects/hurd-alpha/</A></CODE>
+
+<LI>The GNU&nbsp;Hurd on top of the L4 microkernel</LI>
+<P>
+The purpose of this project is to port the Hurd system to the L4 microkernel.
+<BR>
+<CODE><A HREF="/software/hurd/hurd-l4.html">http://www.gnu.org/software/hurd/hurd-l4.html</A></CODE>
+
+
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/related-projects.html">English</A>
+| <A HREF="/software/hurd/related-projects.eo.html">Esperanto</A>
+| <a href="/software/hurd/related-projects.es.html">Spanish</a> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2002, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/whatis/translator.html b/whatis/translator.html
new file mode 100644
index 00000000..516d5049
--- /dev/null
+++ b/whatis/translator.html
@@ -0,0 +1,290 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+
+<HTML>
+ <HEAD>
+ <TITLE>GNU Hurd - Free Software Foundation (FSF)</TITLE>
+ <LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+ </HEAD>
+
+<BODY BGCOLOR="#000000" LINK="#8888EE" VLINK="#9F00DD" ALINK="#000088">
+<IMAGE SRC="/graphics/hurd_sm_mf_invert.jpg">
+<TABLE width="100%" border="0" cellspacing="0" cellpadding="20">
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<A HREF="../hurd.html#contents"><STRONG>The GNU Hurd</STRONG></A><BR>
+<p>
+<a href="/software/hurd/whatis/">Whatis?</a><br>
+<a href="/software/hurd/howto/">Howto?</a><br>
+</p>
+
+<P>
+<!---A HREF="mirrors.html#contents">Mirrors</A><BR--->
+<A HREF="../acknowledgements.html#contents">Acknowledgements</A><BR>
+<!---A HREF="copyright.html#contents">Copyright Notice</A--->
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP" TEXT="#000000" BGCOLOR="#FFFFFF">
+<A NAME="contents"><H1>GNU Hurd</H1></A>
+<h1>Translators</h1>
+<p class="author">By Marcus Brinkmann</p>
+<ul>
+<li><a href="#concept" name="TOC_concept">Concept</a></li>
+<li><a href="#examples" name="TOC_examples">Examples</a></li>
+<li><a href="#actpas" name="TOC_actpas">Passive Translators, Active Translators</a></li>
+<li><a href="#manage" name="TOC_manage">Managing Translators</a></li>
+</ul>
+<h3><a href="#TOC_concept" name="concept">Concept</a></h3>
+<p>
+Before we take a closer look at translators, let us consider regular
+filesystems. A filesystem is store for a hierarchical tree of directories
+and files. You access directories and files by a special character string,
+the path. Furthermore, there are symbolic links to refer to one file at
+several places in the tree, there are hard links to give one and the same
+file several names. There are also special device files for communication
+with the hardware device drivers of the kernel, and there are mount points
+to include other stores in the directory tree. Then there are obscure
+objects like fifos and hard links.</p>
+<p>
+Although these objects are very different, they share some common
+properties, for example, they have all an owner and a group associated with
+them as well as access rights (permissions). This information is written in
+inodes. This is a actually a further commonality: Every object has exactly
+one inode associated with it (hard links are somewhat special as they share
+one and the same inode). Sometimes, the inode has further information
+stored in it. For example, the inode can contain the target of a symbolic
+link.</p>
+<p>
+However, these commonalities are usually not exploited in the
+implementations, despite the common programming interface to them. All
+inodes can be accessed through the standard POSIX calls, for example
+<code>read()</code> and <code>write()</code>. For example, to add a new
+object type (for example a new link type) to a common monolithic unix
+kernel, you would need to modify the code for each filesystem
+seperately.</p>
+<p>
+In the Hurd, things work differently. Although in the Hurd a special
+filesystem server can exploit special properties of standard object types
+like links (in the ext2 filesystem with fast links, for example), it has a
+general interface to add such features without modifying existing code.</p>
+<p>
+The trick is to allow a program to be inserted between the actual content of
+a file and the user accessing this file. Such a program is called a
+translator, because it is able to process the incoming requests in many
+different ways. In other words, a translator is a Hurd server which provides
+the basic filesystem interface.</p>
+<p>
+Translators have very interesting properties. From the kernels point of
+view, they are just another user process. This means, translators can be run
+by any user. You don't need root priviligies to install or modify a
+translator, you only need the access rights for the underlying inode the
+translator is attached to. Many translators don't require an actual file to
+operate, they can provide information by their own means. This is why
+the information about translators is stored in the inode.</p>
+<p>
+Translators are responsible to serve all file system operations that involve
+the inode they are attached to. Because they are not restricted to the usual
+set of objects (device file, link etc), they are free to return anything
+that makes sense to the programmer. One could imagine a translator that
+behaves like a directory when accessed by <code>cd</code> or
+<code>ls</code> and at the same time behaves like a file when accessed by
+<code>cat</code>.</p>
+<h3><a href="#TOC_examples" name="examples">Examples</a></h3>
+<h4>Mount Points</h4>
+<p>
+A mount point can be seen as an inode that has a special translator attached
+to it. Its purpose would be to translate filesystem operations on the mount
+point in filesystem operations on another store, let's say, another
+partition.</p>
+<p>
+Indeed, this is how filesystems are implemented under the Hurd. A
+filesystem is a translator. This translator takes a store as its argument,
+and is able to serve all filesystem operations transparently.</p>
+<h4>Device Files</h4>
+<p>
+There are many different device files, and in systems with a monolithical
+kernel, they are all provided by the kernel itself. In the Hurd, all device
+files are provided by translators. One translator can provide support for
+many similar device files, for example all hard disk partitions. This way,
+the number of actual translators needed is quite small. However, note that
+for each device file accessed, a seperate translator task is started.
+Because the Hurd is heavily multi threaded, this is very cheap.</p>
+<p>
+When hardware is involved, a translator usually starts to communicate with
+the kernel to get the data from the hardware. However, if no hardware access
+is necessary, the kernel does not need to be involved. For example,
+<code>/dev/zero</code> does not require hardware access, and can therefore
+be implemented completely in user space.</p>
+<h4>Symbolic Links</h4>
+<p>
+A symbolic link can be seen as a translator. Accesing the symbolic link
+would start up the translator, which would forward the request to the
+filesystem that contains the file the link points to.</p>
+<p>
+However, for better performance, filesystems that have native support
+for symbolic links can take advantage of this feature and implement
+symbolic links differently. Internally, accessing a symbolic link would not
+start a new translator process. However, to the user, it would still look
+as if a passive translator is involved (see below for an explanation what a
+passsive translator is).</p>
+<p>
+Because the Hurd ships with a symlink translator, any filesystem server that
+provides support for translators automatically has support for symlinks (and
+firmlinks, and device files etc)! This means, you can get a working
+filesystem very fast, and add native support for symlinks and other features
+later.</p>
+<h3><a href="#TOC_actpas" name="actpas">Passive Translators, Active Translators</a></h3>
+<p>
+There are two types of translators, passive and active. They are really
+completely different things, so don't mix them up, but they have a close
+relation to each other.</p>
+<h4>Active Translators</h4>
+<p>
+An active translator is a running translator process, as introduced above.
+You can set and remove active translators using the
+<a href="reference-manual/hurd_7.html#SEC49"><code>settrans -a</code></a>
+command. The <code>-a</code> option is necessary to tell
+<code>settrans</code> that you want to modify the active translator.</p>
+<p>
+The <code>settrans</code> command takes three kind of arguments. First, you
+can set options for the <code>settrans</code> command itself, like
+<code>-a</code> to modify the active translator. Then you set the inode you
+want to modify. Remember that a translator is always associated with an
+inode in the directory hierarchy. You can only modify one inode at a time.
+If you do not specify any more arguments, <code>settrans</code> will try to
+remove an existing translator. How hard it tries depends on the force
+options you specify (if the translator is in use by any process, you will
+get "device or resource busy" error message unless you force it to go away).</p>
+<p>
+But if you specify further arguments, it will be interpreted as a command
+line to run the translator. This means, the next argument is the filename of
+the translator executable. Further arguments are options to the translator,
+and not to the <code>settrans</code> command.</p>
+<p>
+For example, to mount an ext2fs partition, you can run
+<code>settrans -a -c /mnt /hurd/ext2fs /dev/hd2s5</code>. The
+<code>-c</code> option will create the mount point for you if it doesn't
+exist already. This does not need to be a directory, by the way. To unmount,
+you would try <code>settrans -a /mnt</code>.</p>
+<h4>Passive Translators</h4>
+<p>
+A passive translator is set and modified with the same syntax as the active
+translator (just leave away the <code>-a</code>, so everything said above is
+true for passive translators, too. However, there is a difference: passive
+translators are not yet started.</p>
+<p>
+This makes sense, because this is what you usually want. You don't want the
+partition mounted unless you really access files on this partition. You
+don't want to bring up the network unless there is some traffic and so
+on.</p>
+<p>
+Instead, the first time the passive translator is accessed, it is
+automatically read out of the inode and an active translator is started on
+top of it using the command line that was stored in the inode. This is
+similar to the Linux automounter functionality. However, it does not come as
+an additional bonus that you have to set up manually, but an integral part of
+the system. So, setting passive translators defers starting the translator
+task until you really need it. By the way, if the active translator dies for
+some reason, the next time the inode is accessed the translator is
+restarted.</p>
+<p>
+There is a further difference: active translators can die or get lost. As
+soon as the active translator process is killed (for example, because you
+reboot the machine) it is lost forever. Passive translators are not transient
+and stay in the inode during reboots until you modify them with the
+<code>settrans</code> program or delete the inodes they are attached to.
+This means, you don't need to maintain a configuration file with your mount
+points.</p>
+<p>
+One last point: Even if you have set a passive translator, you can still
+set a different active translator. Only if the translator is automatically
+started because there was no active translator the time the inode was
+accessed the passive translator is considered.</p>
+<h3><a href="#TOC_manage" name="manage">Managing Translators</a></h3>
+<p>
+As mentioned above, you can use
+<a href="reference-manual/hurd_7.html#SEC49"><code>settrans</code></a>
+to set and alter passive and active translators. There are a lot of options
+to change the behaviour of <code>settrans</code> in case something goes
+wrong, and to conditionalize its action. Here are some common usages:</p>
+<ul><li><code>settrans -c /mnt /hurd/ext2fs /dev/hd2s5</code> mounts a
+partition, the translator will stay across reboots.</li>
+<li><code>settrans -a /mnt /hurd/ext2fs ~/dummy.fs</code> mounts a
+filesystem inside a data file, the translator will go away if it dies.</li>
+<li><code>settrans -fg /nfs-data</code> forces a translator to go away.</li>
+</ul>
+<p>
+You can use the <a href="hurd-doc-utils#showtrans"><code>showtrans</code></a>
+command to see if a translator is attached to an inode. This will only show
+you the passive translator though.</p>
+<p>
+You can change the options of an active (filesystem) translator with
+<code>fsysopts</code> without actually restarting it. This is very
+convenient. For example, you can do what is called "remounting a
+partition read-only" under Linux simply by running <code>fsysopts
+/mntpoint --readonly</code>. The running active translator
+will change its behaviour according to your request if possible.
+<code>fsysopts /mntpoint</code> without a parameter shows you the current
+settings.</p>
+<h4>Examples</h4>
+<p>
+I recommend that you start by reading the <code>/bin/mount</code> command,
+it is only a small script. Because setting filesystem translators is
+similar to mounting partitions, you can easily grasp the concept this way.
+Make a file system image with <code>dd if=/dev/zero of=dummy.fs bs=1024k
+count=8; mke2fs dummy.fs</code> and "mount" it with <code>settrans -c dummy
+/hurd/ext2fs `pwd`/dummy.fs</code>. Note that the translator is not started
+yet, no new <code>ext2fs</code> process is running (verify with <code>ps
+Aux</code>). Check that everything is correct using <code>showtrans</code></p>
+<p>
+Now type <code>ls dummy</code> and you will notice the short delay that
+occurs while the translator is started. After that, there will be no more
+delays accessing dummy. Under Linux, one would say that you automounted a
+loop file system. Check with <code>ps Aux</code> that there is an <code>ext2fs
+dummy</code> process up and running now. Now put some files into the new
+directory. Try to make the filesystem read-only with <code>fsysopts</code>.
+Note how further write attempts fail now. Try to kill the active translator
+with <code>settrans -g</code>.</p>
+<p>
+You should have some understanding of what is going on now. Now remember
+that this was only <em>one</em> special server, the Hurd ext2fs server.
+There are many more server in the <code>hurd</code> directory. Some of them
+are for filesystems. Some are needed for file system features like links.
+Some are needed for device files. Some are useful for networking. Imagine
+"mounting" an FTP Server with <code>settrans</code> and downloading files
+simply with the standard <code>cp</code> command. Or editing your web sites
+with <code>emacs /ftp/homepage.my.server.org/index.html</code>!</p>
+
+<HR>
+
+Return to <A HREF="/home.html" TARGET="_parent">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo" TARGET="_parent">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 1998, 1999, 2007 Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.<P>
+Updated:
+<!-- hhmts start -->
+$Date$ $Author$
+<!-- hhmts end -->
+<HR>
+</TD>
+</TR>
+</TABLE>
+
+</BODY>
+</HTML>
diff --git a/whatsnew.html b/whatsnew.html
new file mode 100644
index 00000000..7f2540ac
--- /dev/null
+++ b/whatsnew.html
@@ -0,0 +1,300 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/whatsnew.nl.html">Dutch</A>
+| <A HREF="/software/hurd/whatsnew.html">English</A>
+| <A HREF="/software/hurd/whatsnew.eo.html">Esperanto</A>
+| <A HREF="/software/hurd/whatsnew.de.html">German</A>
+| <A HREF="/software/hurd/whatsnew.he.html">Hebrew</A>
+| <A HREF="/software/hurd/whatsnew.pl.html">Polish</A>
+| <A HREF="/software/hurd/whatsnew.sk.html">Slovak</A>
+| <A HREF="/software/hurd/whatsnew.es.html">Spanish</A> <!-- Espa&ntilde;ol -->
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/related-projects.html"><STRONG>Related&nbsp;Projects</STRONG></A>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3>What is the GNU&nbsp;Hurd?</H3>
+<P>
+The GNU&nbsp;Hurd is the GNU project's replacement for the Unix kernel.
+The Hurd is a collection of servers that run on the Mach microkernel
+to implement file systems, network protocols, file access control, and
+other features that are implemented by the Unix kernel or similar
+kernels (such as Linux).
+<P>
+If you have any news related to the Hurd project, feel free to send a
+news entry to <A HREF="mailto:web-hurd@gnu.org">web-hurd@gnu.org</A>
+so that it can be added here.
+<HR>
+<H3>What's new?</H3>
+<P>
+<DL>
+<!-- News entries start here -->
+
+<dt>2008-09-11</dt>
+
+<dd>
+
+<p>Please see
+<a href="http://www.bddebian.com/~wiki/community/gsoc/">http://www.bddebian.com/~wiki/community/gsoc/</a>
+for information about how our <strong>Goggle Summer of Code 2008
+participation</strong> worked out. <strong>Congratulations to both students
+and mentors!</strong></p>
+
+</dd>
+
+
+<dt>2008-03-19</dt>
+
+<dd>
+
+<p>The GNU Hurd project has been accepted as a mentoring organisation for
+the <strong>Google Summer of Code 2008</strong></a>! If you are a student and
+looking for a job during the summer, take a look at
+our <a href="http://www.bddebian.com/~wiki/community/gsoc/">project ideas
+list</a> &mdash; here's your chance to help improving the GNU Hurd including
+mentoring from our side and being paid compensation from Google's!</p>
+
+<p>The application deadline has
+been <a href="http://groups.google.com/group/google-summer-of-code-announce/browse_thread/thread/9fa88f31aa401f70"><strong>extended</strong>
+to <strong>Monday, 2008-04-07</strong></a>, so there's more time for you
+students to hand in your Hurd applications.</p>
+
+</dd>
+
+
+<dt>2008-02-11</dt>
+
+<dd>
+
+<p>A number of GNU&nbsp;Hurd developers will again (as already in the previous
+years) meet at the time of the FOSDEM&nbsp;2008, which will take place from
+2008-02-23 to 24 in Brussels, Belgium.
+<a href="http://www.bddebian.com/~wiki/community/meetings/fosdem_2008/">This
+wiki page</a> has some details. <a href="/software/hurd/help.html">Contact
+us</a> if you are interested in meeting with us.</p>
+
+</dd>
+
+
+<dt>2007-10-12</dt>
+
+<dd>
+
+<p>Stefan Siegl
+added <a href="http://www.bddebian.com/~wiki/hurd/translator/pfinet/ipv6/">support
+for IPv6 networking</a> to the <em>pfinet</em> translator.
+
+</p>
+
+</dd>
+
+<dt>2007-10-01</dt>
+
+<dd>
+
+<p>This year the GNU Hurd had again been assigned one slot within
+the <strong>Google Summer of Code</strong> program, which was assigned
+to the task <strong>design and
+implement <a href="http://savannah.gnu.org/task/?1619"><em>libchannel</em></a>,
+a library for streams</strong>. Carl Fredrik Hammar has been working on this
+task and
+recently <a href="http://lists.gnu.org/archive/html/bug-hurd/2007-09/msg00009.html">posted
+a summary</a> about the successful work he had been doing, but also gave an
+outline about how he intends to continue improving and extending it.
+
+</p>
+
+</dd>
+
+<dt>2007-03-14</dt>
+
+<dd>
+
+<p>The GNU&nbsp;Hurd project will participate in this year's <strong>Google
+Summer of Code</strong>, under the aegis of the GNU project.</p>
+
+<p>The following is a list of items you might want to work on. If you want to
+modify these task proposals or have your own ideas on what to work, then please
+don't hesitate to contact us on the <a
+href="/software/hurd/help.html#mail">bug-hurd mailing list</a> or the <a
+href="/software/hurd/help.html#irc">#hurd IRC channel</a>.</p>
+
+<ul>
+
+<li>Design and implement <a
+href="http://savannah.gnu.org/task/?1619"><em>libchannel</em></a>, a library
+for streams.</li>
+
+<li>Rewrite <a href="http://savannah.gnu.org/task/?5469"><em>pfinet</em></a>,
+our interface to the IPv4 world; create a <a
+href="http://savannah.gnu.org/task/?5470"><em>pfinet6</em></a> to interface to
+the IPv6 world.</li>
+
+<li>Make GNU Mach use more <a href="http://savannah.gnu.org/task/?5488">up to
+date <em>device drivers</em></a>.</li>
+
+<li>Design and implement a <a
+href="http://savannah.gnu.org/task/?5485"><em>sound system</em></a>.</li>
+
+<li>Introduce the world of the <a
+href="http://savannah.gnu.org/task/?5486"><em>Andrew File System (AFS)</em></a>
+to the Hurd.</li>
+
+<li>Work on enhancing our <a href="http://savannah.gnu.org/task/?5497"><em>NFS
+client</em> and <em>NFSd</em></a>.</li>
+
+<li>Implement support for <a
+href="http://savannah.gnu.org/task/?5499"><em>Logical Volume Management
+(LVM)</em></a>.</li>
+
+</ul>
+
+<p>Please see the page <a href="/software/soc-projects/guidelines.html">GNU
+guidelines for Summer of Code projects</a> about how to make an application and
+<a href="/software/soc-projects/ideas.html">Summer of Code project ideas
+list</a> for a list of tasks for various GNU projects and information about
+about how to submit your own ideas for tasks.</p>
+
+</dd>
+
+
+<dt>2007-01-14</dt>
+
+<dd>
+
+<p>Neal Walfield and Marcus Brinkmann have written and submitted for
+publication <a
+href="http://lists.gnu.org/archive/html/bug-hurd/2007-01/msg00046.html"><em>A
+Critique of the GNU&nbsp;Hurd Multi-server Operating System</em></a> and a <a
+href="http://lists.gnu.org/archive/html/l4-hurd/2007-01/msg00007.html">position
+paper <em>Improving Usability via Access Decomposition and Policy
+Refinement</em></a>. Please follow the two preceding links to see the complete
+announcements. The authors welcome comments and discussion which may be
+directed to the <a href="mailto:bug-hurd@gnu.org">&lt;bug-hurd@gnu.org&gt;
+mailing list</a> for the Critique and to the <a
+href="mailto:l4-hurd@gnu.org">&lt;l4-hurd@gnu.org&gt; mailing list</a> for the
+position paper.
+
+<p>The abstract of the Critique: <blockquote><p>The GNU&nbsp;Hurd's design was
+motivated by a desire to rectify a number of observed shortcomings in Unix.
+Foremost among these is that many policies that limit users exist simply as
+remnants of the design of the system's mechanisms and their implementation. To
+increase extensibility and integration, the Hurd adopts an object-based
+architecture and defines interfaces, which, in particular those for the
+composition of and access to name spaces, are virtualizable.
+
+<p>This paper is first a presentation of the Hurd's design goals and a
+characterization of its architecture primarily as it represents a departure
+from Unix's. We then critique the architecture and assess it in terms of the
+user environment of today focusing on security. Then follows an evaluation of
+Mach, the microkernel on which the Hurd is built, emphasizing the design
+constraints which Mach imposes as well as a number of deficiencies its design
+presents for multi-server like systems. Finally, we reflect on the properties
+such a system appears to require.</blockquote>
+
+<p>The abstract of the position paper: <blockquote><p>Commodity operating
+systems fail to meet the security, resource management and integration
+expectations of users. We propose a unified solution based on a capability
+framework as it supports fine grained objects, straightforward access
+propagation and virtualizable interfaces and explore how to improve resource
+use via access decomposition and policy refinement with minimum interposition.
+We argue that only a small static number of scheduling policies are needed in
+practice and advocate hierarchical policy specification and central
+realization.</blockquote></dd>
+
+
+<P>
+<!-- News entries end here -->
+<DT><A HREF="/software/hurd/whatsold.html">Old news entries.</A></DT>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/whatsnew.nl.html">Dutch</A>
+| <A HREF="/software/hurd/whatsnew.html">English</A>
+| <A HREF="/software/hurd/whatsnew.eo.html">Esperanto</A>
+| <A HREF="/software/hurd/whatsnew.de.html">German</A>
+| <A HREF="/software/hurd/whatsnew.he.html">Hebrew</A>
+| <A HREF="/software/hurd/whatsnew.pl.html">Polish</A>
+| <A HREF="/software/hurd/whatsnew.es.html">Spanish</A> <!-- Espa&ntilde;ol -->
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
+Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>
diff --git a/whatsold.html b/whatsold.html
new file mode 100644
index 00000000..e2958d1c
--- /dev/null
+++ b/whatsold.html
@@ -0,0 +1,558 @@
+<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0//EN"
+ "http://www.w3.org/TR/REC-html40/strict.dtd">
+<HTML>
+<HEAD>
+<TITLE>The GNU&nbsp;Hurd - GNU Project - Free Software Foundation (FSF)</TITLE>
+<LINK REV="made" HREF="mailto:web-hurd@gnu.org">
+<META NAME="keywords" CONTENT="hurd">
+</HEAD>
+<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD">
+<TABLE width="100%" border="0" cellspacing="5" cellpadding="15">
+<TR>
+<TD COLSPAN="2">
+<IMG SRC="/graphics/hurd_sm_mf.jpg" ALT=" [image of the Hurd logo] ">
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/whatsold.html">English</A>
+]
+</TD>
+</TR>
+<TR>
+<TD ALIGN="LEFT" VALIGN="TOP" BGCOLOR="#eeeeee">
+<A HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/changelogs.html">ChangeLogs</A><BR>
+&nbsp;<br>
+<a href="/software/hurd/docs.html">Documentation</a><br>
+<P>
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/install.html">Installation</A><BR>
+<A HREF="/software/hurd/help.html">Getting&nbsp;Help</A><BR>
+<A HREF="/software/hurd/download.html">Source&nbsp;Code</A><BR>
+<A HREF="/software/hurd/devel.html">Development</A><BR>
+<A HREF="/software/hurd/history.html">History</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/gnumach-install.html">Installation</A><BR>
+<A HREF="/software/hurd/gnumach-download.html">Source&nbsp;Code</A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A><BR>
+&nbsp;<BR>
+<A HREF="/software/hurd/mig-download.html">Source&nbsp;Code</A><BR>
+</TD>
+<TD ALIGN="LEFT" VALIGN="TOP">
+<HR>
+<H3>What's old?</H3>
+<P>
+<DL>
+
+<dt>2007-01-07</dt>
+
+<dd>
+
+<p>A number of GNU&nbsp;Hurd developers will again (as already in the previous
+years) meet at the time of the FOSDEM&nbsp;2007, which will take place from
+2007-02-24 to 25 in Brussels, Belgium.
+<a href="http://www.bddebian.com/~wiki/community/meetings/fosdem_2007/">This
+wiki page</a> has some details. <a href="/software/hurd/help.html">Contact
+us</a> if you are interested in meeting with us.</p>
+
+</dd>
+
+
+<dt>27 April 2006</dt>
+<dd>
+<p>The GNU&nbsp;Hurd project will participate in this year's <strong>Google
+Summer of Code</strong>, under the aegis of the GNU project.</p>
+
+<p>The following is a list of items you might want to work on. If you want to
+modify or extend these tasks or have your own ideas what to work on, please
+feel invited to contact us on the <a
+href="/software/hurd/help.html#TOCmail">bug-hurd mailing list</a> or the <a
+href="/software/hurd/help.html#TOCirc">#hurd IRC channel</a>.</p>
+
+<ul>
+
+<li>Make GNU&nbsp;Mach use more <a href="http://savannah.gnu.org/task/?5488">up
+to date <em>device drivers</em></a>.</li>
+
+<li>Work on <a href="http://savannah.gnu.org/task/?5489">GNU&nbsp;Mach's
+<em>IPC / VM system</em></a>.</li>
+
+<li>Design and implement a <a
+href="http://savannah.gnu.org/task/?5485"><em>sound system</em></a>.</li>
+
+<li>Transition the Hurd libraries and servers <a
+href="http://savannah.gnu.org/task/?5487">from <em>cthreads</em> to
+<em>pthreads</em></a>.</li>
+
+<li>Find and implement a reasonable way to make the Hurd servers use <a
+href="http://savannah.gnu.org/task/?5490"><em>syslog</em></a>.</li>
+
+<li>Design and implement <a
+href="http://savannah.gnu.org/task/?1619"><em>libchannel</em></a>, a library
+for streams.</li>
+
+<li>Rewrite <a href="http://savannah.gnu.org/task/?5469"><em>pfinet</em></a>,
+our interface to the IPv4 world.</li>
+
+<li>Implement and make the Hurd properly use <a
+href="http://savannah.gnu.org/task/?5503"><em>extended
+attributes</em></a>.</li>
+
+<li>Design / implement / enhance support for the...
+
+ <ul>
+ <li><a href="http://savannah.gnu.org/task/?5486"><em>Andrew File System
+ (AFS)</em></a>;</li>
+
+ <li><a href="http://savannah.gnu.org/task/?5497"><em>NFS client</em> and
+ <em>NFSd</em></a>;</li>
+
+ <li><a href="http://savannah.gnu.org/task/?5498"><em>EXT3 file
+ system</em></a>;</li>
+
+ <li><a href="http://savannah.gnu.org/task/?5499"><em>Logical Volume Manager
+ (LVM)</em></a>.</li>
+
+ </ul>
+
+</ul>
+
+<p>Please see the page <a href="/software/soc-projects/guidelines.html">GNU
+guidelines for Summer of Code projects</a> about how to make an application and
+<a href="/software/soc-projects/ideas.html">Summer of Code project ideas
+list</a> for a list of tasks for various GNU projects and information about
+about how to submit your own ideas for tasks.</p>
+
+</dd>
+
+
+<DT>02 March 2006</DT> <DD> Added a Slovak translation of <A
+HREF="/software/hurd/whatsnew.html"><STRONG>What's New</STRONG></A> by Peter
+Kotrcka.
+<P>
+</DD>
+
+<DT>08 February 2006</DT>
+<DD>
+Added a Turkish translation
+of <A HREF="/software/hurd/hurd-paper.html"><STRONG>Towards a New Strategy of
+OS Design</STRONG></A> by Oktay Po&ccedil;an.
+<P>
+</DD>
+
+<DT>02 October 2005</DT>
+<DD>
+Added Polish translations
+of <A HREF="/software/hurd/whatsnew.html"><STRONG>What's
+New</STRONG></A>,
+<A HREF="/software/hurd/hurd.html"><STRONG>GNU&nbsp;Hurd</STRONG></A>,
+<A HREF="/software/hurd/gnumach.html"><STRONG>GNU&nbsp;Mach</STRONG></A>, and
+<A HREF="/software/hurd/mig.html"><STRONG>GNU&nbsp;MIG</STRONG></A> by Andrzej Zaborowski.
+<P>
+</DD>
+
+<DT>20 September 2005</DT>
+<DD>
+Material from the Operating System topic during
+the <A HREF="http://libresoftwaremeeting.org/">Libre Software
+Meeting</A> which took place this summer
+is <A
+HREF="http://medias.2005.libresoftwaremeeting.org/topics/os/">available
+online</A>. Included are slides and recordings of talks by Marcus
+Brinkmann and Neal Walfield about the Hurd/L4 port.
+<P>
+</DD>
+
+<DT>22 August 2005</DT>
+<DD>
+Added Esperanto translations of too many pages to list by Ludovic
+Court&egrave;s.
+<P>
+</DD>
+
+<DT>29 July 2005</DT>
+<DD>
+Added a Italian translation
+of <A HREF="/software/hurd/hurd.html"><STRONG>GNU
+Hurd</STRONG></A> by Carlo Palma.
+<P>
+</DD>
+
+<DT>26 July 2005</DT>
+<DD>
+Added Dutch translations
+of <A HREF="/software/hurd/whatsnew.html"><STRONG>What's
+New</STRONG></A> and <A HREF="/software/hurd/hurd.html"><STRONG>
+GNU&nbsp;Hurd</STRONG></A> by Roan Embrechts.
+<P>
+</DD>
+
+<DT>28 January 2005</DT>
+<DD>
+Marcus Brinkmann added
+<A HREF="/software/hurd/hurd-l4.html">a small web page</A> describing
+the ongoing developments on the Hurd-to-L4 port.
+<P>
+</DD>
+
+<DT>21 August 2003</Dt>
+<DD>
+Added a link to Patrick Strasser's <A
+HREF="http://www.htu.tugraz.at/~past/hurd/global/">the Hurd Source
+Code Cross Reference</A> in all the "Source code" sections.
+<P>
+</DD>
+
+<DT>16 July 2003</DT>
+<DD>
+GNU/LinuxTag 2003 is now over and since there was a talk given about
+the Hurd, a demo GNU/Hurd machine running and the sale of Hurd
+t-shirts, Wolfgang J&auml;hrling decided to write a <A
+HREF="http://mail.gnu.org/archive/html/help-hurd/2003-07/msg00029.html">short
+summary</A> of what happened there. Many thanks to Wolfgang
+J&auml;hrling, Volker Dormeyer and Michael Banck!
+<P>
+</DD>
+
+<DT>2 July 2003</DT>
+<DD>
+The tarball for Debian GNU/Hurd that Marcus Brinkmann made over the
+years has been discontinued in favour of Jeff Bailey's
+<A HREF="http://packages.debian.org/crosshurd">crosshurd</A> package.
+To install Debian GNU/Hurd from now on, this package should be used.
+Another Debian system is required to be installed on the same machine.
+The GNU/Hurd installation guide has not been updated yet.
+<P>
+</DD>
+
+<DT>14 February 2003</DT>
+<DD>
+The <A HREF="/software/hurd/docs.html#UsersGuide">GNU/Hurd User's Guide</A>
+is now accessible through the <A HREF="/software/hurd/docs.html">Documentation
+</A> section of the Hurd web pages.
+<P>
+</DD>
+
+<DT>18 January 2003</DT>
+<DD>
+Ga&euml;l Le Mignot, president of HurdFr,
+<A HREF="http://news.hurdfr.org/gen.php3/2002/11/05/44,0,1,0,0.html">
+presented the GNU&nbsp;Hurd on 22 November</A>
+2002 at EpX in Paris.
+<A HREF="http://kilobug.free.fr/hurd/pres-en/">English slides</A> and
+<A HREF="http://kilobug.free.fr/hurd/pres-fr/">French slides</A> of the
+talk are also available.
+<P>
+</DD>
+
+<DT>18 November 2002</DT>
+<DD>
+For one month now, the pthread implementation by Neal Walfield is part
+of the Hurd CVS source tree, and has been used to compile more
+software for the Debian GNU/Hurd archive. The lack of a POSIX
+compatible thread library (the Hurd was based on the cthread
+implementation that originally accompanied Mach) was a show stopper,
+and we are happy about the possibility to not only compile more
+applications, but also to start the work on migrating the Hurd source
+code to pthreads.
+<P>
+</DD>
+
+<DT>19 October 2002</DT>
+<DD>
+The Toronto Hurd Users Group meets again: The <A
+HREF="http://www.uwaterloo.ca/"> University of Waterloo</A> <A
+HREF="http://www.csclub.uwaterloo.ca/">Computer Science Club</A> will
+be hosting talks on the GNU&nbsp;Hurd on October 26 by Marcus Brinkmann and
+Neal Walfield. There will also be a <A
+HREF="http://www.gnupg.org/">GnuPG</A> keysigning before Marcus's
+talk. Please email <A HREF="mailto:rmgolbeck@uwaterloo.ca">Ryan
+Golbeck</A> your <A HREF="http://www.gnupg.org/">GnuPG</A> key so he
+can get everyone setup.</P>
+
+<P>Marcus will talk about <A
+HREF="http://www.csclub.uwaterloo.ca/events/MC2066-2002-10-26-3%3A00PM.html">the
+Hurd interfaces</A>. Neal will talk about about
+<A HREF="http://www.csclub.uwaterloo.ca/events/MC2066-2002-10-26-4%3A30PM.html">
+A GNU Approach to Virtual Memory Management in a Multiserver Operating
+System
+</A></P>
+
+<P>Date: 26 Oct 2002</P>
+<P>Time: 1330 (1:30pm EST) and 1500 (3:00pm EST)</P>
+<P>Place: University of Waterloo, Math and Computers building, room MC
+2066</P>
+
+<P>More information can be found at <A
+HREF="http://www.csclub.uwaterloo.ca/"> UW CS Club website</A> and
+at <A HREF="mailto:thug@gnu.org">thug@gnu.org</A>
+<P>
+</DD>
+
+<DT>03 October 2002</DT>
+<DD>Marcus Brinkmann speaks about the GNU&nbsp;Hurd at "Reflections |
+Projections 2002", the <A
+HREF="http://www.acm.uiuc.edu/conference/">National Student ACM
+Conference</A> at the University of Urbana-Champaign, Illinois. The
+conference is held on October 18-20.
+<P>
+</DD>
+
+<DT>03 October 2002</DT>
+<DD>A new article about <A HREF="/software/hurd/auth.html">the authentication
+server</A> has been added to the web pages. It resembles the talk
+about the same topic which was given at the Libre Software Meeting,
+therefore the target audience is mostly programmers which want to learn
+about the details of authentication in the Hurd.
+<P>
+</DD>
+
+<DT>16 August 2002</DT>
+<DD>The Hurd sources have stabilized again after a short period in
+which some of the interfaces were changed to prepare support of long
+files. All relevant filesystem and I/O interfaces have been modified
+to use 64 bit even on 32 bit systems.
+
+In light of the small and patient user base, we decided to drop
+backwards compatibility and replace the interfaces instead extending
+them. This means that the binaries of the Hurd, the C library, and
+some other programs need to be replaced manually, all at the same
+time, followed by a reboot.
+
+A <A
+HREF="http://www.debian.org/ports/hurd/extra-files/hurd-upgrade.txt">detailed
+step-by-step procedure how to upgrade</A> Debian GNU/Hurd is available
+on the Debian web site.
+
+People not using a binary distribution need to do a full manual
+bootstrap. It is recommended to treat this as a cross-compilation
+case.
+<P>
+</DD>
+
+<DT>31 July 2002</DT>
+<DD>A new page has been added to the site, listing <A
+HREF="related-projects.html">related projects</A>. You can find it at
+the bottom of the menu.
+<P>
+</DD>
+
+<DT>22 June 2002</DT>
+<DD>Various developers of the Hurd and people interested in it will meet
+at the <A HREF="http://lsm.abul.org/">Libre Software Meeting</A> in
+Bordeaux on July 9-13. Neal Walfield, who is working on porting the
+Hurd to the <A HREF="http://www.l4ka.org/">L4</A> microkernel, will give
+a presentation about L4, the people from
+<A HREF=" http://www.hurdfr.org/">HurdFr</A> will give an
+introduction to the Hurd, and another presentation about the Hurd will
+be given by Marcus Brinkmann. There might be additional talks about
+the Hurd and related topics.
+</P>
+</DD>
+
+<DT>28 May 2002</DT>
+<DD>We are pleased to announce version 1.3 of the GNU distribution of
+the Mach kernel, featuring advanced boot script support, support for
+large disks (>= 10GB) and an improved console.
+<P>
+This distribution is only for x86 PC machines.
+Volunteers interested in ports to other architectures are eagerly sought.
+<P>
+More <A HREF="gnumach-download.html#release">information about GNU
+Mach 1.3</A> is available on the GNU&nbsp;Mach web page.
+</P>
+</DD>
+
+<DT>24 May 2002</DT>
+<DD>Finally, the transition from the stdio-based GLibC Application
+Binary Interface (ABI) to the libio-based GLibC ABI has been
+completed. The Debian GNU/Hurd binary distribution has resumed
+building packages again, and everything should be back to normal.
+Note that we have also switched to <A
+HREF="http://gcc.gnu.org/gcc-3.1/">GCC 3.1</A> as our default
+compiler. Thanks to everyone who helped in making all this possible,
+and our apologize for any inconvenience we have caused you.
+<P>
+</DD>
+
+<DT>18 May 2002</DT>
+<DD>The "Linux and Unix User Group Heilbronn" (in Germany) is organizing
+a Debian GNU/Hurd <A
+HREF="http://www.luug-hn.org/vortraege.html">installation party</A> at
+25 May 2002. In addition to that, Wolfgang J&auml;hrling will give a talk
+about usage of GNU/Hurd, common problems found in porting programs to
+GNU/Hurd and programming of extensions for the Hurd. It is a public
+event, so everyone is free to show up and participate.
+<P>
+</DD>
+
+<DT>05 May 2002</DT>
+<DD>We are currently finishing the transition from a stdio-based GNU C
+Library (glibc) to a libio-based one. This is the result of about
+five months of work we put into getting the system ready and, of
+course, the work that the glibc developers did to make glibc what it
+is.
+<P>
+This change will have various advantages, for example libio has been
+tested more extensively, as it is also used by most GNU/Linux systems
+for some time now. However, it also means a change in the Application
+Binary Interface (ABI) of glibc, thus you will need to reinstall an
+existing Debian GNU/Hurd system. Upgrading has not been tested at
+all, so better do not expect it to work. Also note that you will need
+to get some of the Debian packages from <A
+HREF="ftp://alpha.gnu.org/gnu/hurd/debian-libio/">alpha.gnu.org</A>.
+Please read the recent mailing list archives for details.
+<P>
+<B>Important Note:</B> As another temporary complication, the current
+installation tarball is available at <A
+HREF="ftp://alpha.gnu.org/gnu/hurd/debian-staging/">a different place</A>
+than usual.
+<P>
+</DD>
+
+<DT>23 March 2002</DT>
+<DD>Added <A HREF="/software/hurd/hacking-guide/hhg.html">The Hurd
+Hacking Guide</A> to the documentation section. Thanks to Wolfgang
+J&auml;hrling for providing this introduction into GNU/Hurd and Mach
+programming!
+<P>
+</DD>
+
+<DT>08 March 2002</DT>
+<DD>We are pleased to announce version 1.3 of the GNU distribution of the
+Mach 3.0 interface generator `MIG'. It may be found in the file
+<SAMP><A HREF="http://ftp.gnu.org/gnu/mig/mig-1.3.tar.gz">http://ftp.gnu.org/gnu/mig/mig-1.3.tar.gz</A></SAMP> (about 145 KB compressed).
+<P>
+Diffs from version 1.2 are in <SAMP><A HREF="http://ftp.gnu.org/gnu/mig/mig-1.2-1.3.diff.gz">http://ftp.gnu.org/gnu/mig/mig-1.2-1.3.diff.gz</A></SAMP>
+(about 6 KB compressed, 15 KB uncompressed). Relative to version 1.2,
+version 1.3 contains only some minor fixes.
+<P>
+You need this tool to compile the GNU&nbsp;Mach and Hurd distributions, and
+to compile GNU libc for the Hurd.
+<P>
+Bug reports relating to this distribution should be sent to
+<A HREF="mailto:bug-hurd@gnu.org">bug-hurd@gnu.org</A>. Requests for assistance should be made on
+<A HREF="mailto:help-hurd@gnu.org">help-hurd@gnu.org</A>.
+<P>
+The md5sum checksum for this distibution is:
+<P>
+45c2b7456727d81dbd75f7152f8136fd mig-1.3.tar.gz
+<P>
+</DD>
+
+<DT>03 March 2002</DT>
+<DD>There is a new mailing list called <A
+HREF="http://mail.gnu.org/mailman/listinfo/hurd-devel-readers">
+Hurd-devel-readers</A>. It is the read-only version of Hurd-devel.
+<P>
+Hurd-devel is a mailing list for detailed discussions
+of design and implementation issues in the GNU&nbsp;Hurd; it is an internal
+low-volume list restricted to the core developers of the Hurd. While
+the <A HREF="http://lists.gnu.org/archive/html/hurd-devel/">web-based
+archive of Hurd-devel</A> has always been public, the new mailing list
+Hurd-devel-readers provides a convenient way to follow
+the discussion of the Hurd experts.
+<P>
+If you are a recipient of Hurd-devel-readers and want
+to follow up on the discussion, please reply to the
+Bug-hurd mailing list.
+<P>
+</DD>
+
+<DT>18 February 2002</DT>
+<DD>Pro-Linux has published a <A
+HREF="http://www.pl-berichte.de/berichte/hurd/hurd-status/">GNU/Hurd
+status report</A> (in German). They will infrequently publish updates
+in the future.
+<P>
+</DD>
+
+<DT>19 January 2002</DT>
+<DD>The Toronto Hurd User Group meets: The University of Waterloo
+Computer Science Club will be hosting a talk on the Hurd and the
+Debian GNU/Hurd operating system. There will also be a gpg keysigning
+and installfest for GNU/Hurd following the talk. All are welcome, and
+gpg keys are not required.
+<P>
+Date: 26 Jan 2002
+<P>
+Time: 1400 (2pm EST)
+<P>
+Place: University of Waterloo, Math and Computers building, room 3001
+(comfy lounge).
+<P>
+More information about this event at
+<A HREF="mailto:thug@gnu.org"><EM>thug@gnu.org</EM></A>
+<P>
+</DD>
+
+<DT>19 January 2002</DT>
+<DD>Added a <A HREF="/software/hurd/changelogs.html">subsection about
+the ChangeLogs</A>.
+<P>
+</DD>
+
+<DT>13 January 2002</DT>
+<DD>An
+<A HREF="http://www.pl-berichte.de/berichte/brinkmann.html">interview
+with Marcus Brinkmann</A> was published by <A
+HREF="http://pro-linux.de/">Pro-Linux</A> (the interview is in
+German).
+<P>
+</DD>
+
+<DT>11 January 2002</DT>
+<DD>Added a section called `What's new'.
+<P>
+</DD>
+</DL>
+</TD>
+</TR>
+</TABLE>
+
+<HR>
+
+[
+<!-- Please keep this list alphabetical -->
+<!-- PLEASE UPDATE THE LIST AT THE BOTTOM (OR TOP) OF THE PAGE TOO! -->
+ <A HREF="/software/hurd/whatsold.html">English</A>
+]
+
+<HR>
+
+<P>
+Return to <A HREF="/home.html">GNU's home page</A>.
+<P>
+
+Please send FSF &amp; GNU inquiries &amp; questions to
+
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+There are also <A HREF="/home.html#ContactInfo">other ways to
+contact</A> the FSF.
+<P>
+
+Please send comments on these web pages to
+
+<A HREF="mailto:web-hurd@gnu.org"><EM>web-hurd@gnu.org</EM></A>,
+send other questions to
+<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>.
+<P>
+Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
+Free Software Foundation, Inc.,
+59 Temple Place - Suite 330, Boston, MA 02111, USA
+<P>
+Verbatim copying and distribution of this entire article is
+permitted in any medium, provided this notice is preserved.
+<P>
+Updated:
+<!-- timestamp start -->
+$Date$ $Author$
+<!-- timestamp end -->
+<HR>
+</BODY>
+</HTML>