summaryrefslogtreecommitdiff
path: root/hurd
diff options
context:
space:
mode:
Diffstat (limited to 'hurd')
-rw-r--r--hurd/faq/old_hurd_faq.txt289
1 files changed, 289 insertions, 0 deletions
diff --git a/hurd/faq/old_hurd_faq.txt b/hurd/faq/old_hurd_faq.txt
new file mode 100644
index 00000000..a94a28f4
--- /dev/null
+++ b/hurd/faq/old_hurd_faq.txt
@@ -0,0 +1,289 @@
+The Unofficial (and no longer maintained) GNU 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?
+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.
+
+
+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.