summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/documentation.mdwn10
-rw-r--r--hurd/documentation/hurd-and-linux.html47
-rw-r--r--hurd/documentation/hurd-and-linux.mdwn11
-rw-r--r--hurd/documentation/hurd-paper.html760
-rw-r--r--hurd/documentation/hurd-paper.mdwn11
-rw-r--r--hurd/documentation/hurd-talk.html1061
-rw-r--r--hurd/documentation/hurd-talk.mdwn11
-rw-r--r--hurd/running/gnu/universal_package_manager.mdwn5
8 files changed, 41 insertions, 1875 deletions
diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn
index 0d311758..589246bd 100644
--- a/hurd/documentation.mdwn
+++ b/hurd/documentation.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008
-Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
+2009 Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -17,12 +17,12 @@ is included in the section entitled
* [[FAQ]]
- * [[*The_Hurd_and_Linux*|hurd-and-linux]], a comment by Richard Stallman.
+ * [[*The_Hurd_and_Linux*|/hurd-and-linux]], a comment by Richard Stallman.
- * [[*Towards_a_New_Strategy_of_OS_Design*|hurd-paper]], an architectural
+ * [[*Towards_a_New_Strategy_of_OS_Design*|/hurd-paper]], an architectural
overview by Thomas Bushnell, BSG.
- * [[*The_Hurd*|hurd-talk]], a presentation by Marcus Brinkmann.
+ * [[*The_Hurd*|/hurd-talk]], a presentation by Marcus Brinkmann.
* A document about *[[translators]]* by Marcus Brinkmann.
diff --git a/hurd/documentation/hurd-and-linux.html b/hurd/documentation/hurd-and-linux.html
deleted file mode 100644
index 1fc75f75..00000000
--- a/hurd/documentation/hurd-and-linux.html
+++ /dev/null
@@ -1,47 +0,0 @@
-[[!meta copyright="Copyright © 1996, 1997, 1998, 2008 Free Software Foundation,
-Inc."]]
-
-[[!meta license="Verbatim copying and distribution of this entire article is
-permitted in any medium, provided this notice is preserved."]]
-
-[[!meta title="The Hurd and Linux"]]
-
-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.
diff --git a/hurd/documentation/hurd-and-linux.mdwn b/hurd/documentation/hurd-and-linux.mdwn
new file mode 100644
index 00000000..678ea8da
--- /dev/null
+++ b/hurd/documentation/hurd-and-linux.mdwn
@@ -0,0 +1,11 @@
+[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta redir=/hurd-and-linux]]
diff --git a/hurd/documentation/hurd-paper.html b/hurd/documentation/hurd-paper.html
deleted file mode 100644
index 86375d46..00000000
--- a/hurd/documentation/hurd-paper.html
+++ /dev/null
@@ -1,760 +0,0 @@
-[[!meta copyright="Copyright © 1996, 1997, 1998, 2007, 2008 Free Software
-Foundation, Inc."]]
-
-[[!meta license="Verbatim copying and distribution of this entire article is
-permitted in any medium, provided this notice is preserved."]]
-
-[[!meta title="Towards a New Strategy of OS Design, an architectural overview
-by Thomas Bushnell, BSG."]]
-
-
-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.
diff --git a/hurd/documentation/hurd-paper.mdwn b/hurd/documentation/hurd-paper.mdwn
new file mode 100644
index 00000000..06c23662
--- /dev/null
+++ b/hurd/documentation/hurd-paper.mdwn
@@ -0,0 +1,11 @@
+[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta redir=/hurd-paper]]
diff --git a/hurd/documentation/hurd-talk.html b/hurd/documentation/hurd-talk.html
deleted file mode 100644
index 29518dd6..00000000
--- a/hurd/documentation/hurd-talk.html
+++ /dev/null
@@ -1,1061 +0,0 @@
-[[!meta copyright="Copyright © 2001 Marcus Brinkmann"]]
-
-[[!meta license="Verbatim copying and distribution of this entire article is
-permitted in any medium, provided this notice is preserved."]]
-
-[[!meta title="The Hurd, a presentation by Marcus Brinkmann"]]
-
-
-<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
-[[``Towards_a_New_Strategy_of_OS_design''_(1996)|hurd-paper]]:
-<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.
diff --git a/hurd/documentation/hurd-talk.mdwn b/hurd/documentation/hurd-talk.mdwn
new file mode 100644
index 00000000..83dcaf74
--- /dev/null
+++ b/hurd/documentation/hurd-talk.mdwn
@@ -0,0 +1,11 @@
+[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta redir=/hurd-talk]]
diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn
index bb8ff693..ecac8e21 100644
--- a/hurd/running/gnu/universal_package_manager.mdwn
+++ b/hurd/running/gnu/universal_package_manager.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -127,7 +128,7 @@ OK. I will give you steps.
i. Install a GNU System by folowing [[these_instructions|setup]]
-ii. Read about GNU Design: [[Towards_a_New_Strategy_of_OS_Design|documentation/hurd-paper]]
+ii. Read about GNU Design: [[Towards_a_New_Strategy_of_OS_Design|hurd-paper]]
iii. Read about translators <http://www.debian.org/ports/hurd/hurd-doc-translator>