diff options
| -rw-r--r-- | byte-letter.txt | 25 | ||||
| -rw-r--r-- | hurd-and-linux.html | 79 | ||||
| -rw-r--r-- | hurd-announce | 47 | ||||
| -rw-r--r-- | hurd-announce2 | 143 | ||||
| -rw-r--r-- | hurd-flash | 22 | ||||
| -rw-r--r-- | hurd-flash10 | 25 | ||||
| -rw-r--r-- | hurd-flash11 | 25 | ||||
| -rw-r--r-- | hurd-flash12 | 76 | ||||
| -rw-r--r-- | hurd-flash13 | 120 | ||||
| -rw-r--r-- | hurd-flash14 | 62 | ||||
| -rw-r--r-- | hurd-flash15 | 60 | ||||
| -rw-r--r-- | hurd-flash2 | 152 | ||||
| -rw-r--r-- | hurd-flash3 | 77 | ||||
| -rw-r--r-- | hurd-flash4 | 101 | ||||
| -rw-r--r-- | hurd-flash5 | 23 | ||||
| -rw-r--r-- | hurd-flash6 | 46 | ||||
| -rw-r--r-- | hurd-flash7 | 17 | ||||
| -rw-r--r-- | hurd-flash8 | 73 | ||||
| -rw-r--r-- | hurd-flash9 | 39 | ||||
| -rw-r--r-- | hurd-folks.html | 78 | ||||
| -rw-r--r-- | hurd-fs-org | 219 | ||||
| -rw-r--r-- | hurd-migr | 141 | ||||
| -rw-r--r-- | hurd-name.html | 53 | ||||
| -rw-r--r-- | hurd-paper.html | 792 | ||||
| -rw-r--r-- | hurd.html | 233 | ||||
| -rw-r--r-- | old_hurd_faq.html | 318 |
26 files changed, 3046 insertions, 0 deletions
diff --git a/byte-letter.txt b/byte-letter.txt new file mode 100644 index 00000000..20fa61a0 --- /dev/null +++ b/byte-letter.txt @@ -0,0 +1,25 @@ +Byte magazine published this in the `Letters' section +of the March '96 issue: + + Where's the GNU Hurd? + + The November 1995 articles "NT Roars + on the 604" and "CPU scorecards" were + quite welcome. But the Special Report on + operating systems did not mention GNU + Hurd. This OS is based on the Mach mi- + crokernel, and thus it has been essentially + ported to a wide variety of hardware plat- + forms--nearly as many as NetBSD. To + learn more about the Hurd, and especially + about its binary portability, visit http:// + www.cs.pdx.edu/~trent/gnu/hurd/. Con- + trary to what you say in the text box "Op- + erating-System Research: Dim or Bright + Future?" (page 116), microkernel tech- + nology has not been exploited to its max- + imum capability, as the Hurd philosophy + demonstrates. + + Todd Hutchinson + jasper@terra.3rdplanet.com diff --git a/hurd-and-linux.html b/hurd-and-linux.html new file mode 100644 index 00000000..9c463116 --- /dev/null +++ b/hurd-and-linux.html @@ -0,0 +1,79 @@ +<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> +<HTML> +<HEAD> +<TITLE>The Hurd and Linux - GNU Project - Free Software Foundation (FSF)</TITLE> +<LINK REV="made" HREF="mailto:webmasters@www.gnu.org"> +</HEAD> +<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD"> +<H3>The Hurd and Linux</H3> +<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg" + ALT=" [image of a Hurd Metafont Logo] " + WIDTH="333" HEIGHT="80"> (jpeg 10k)</A> +<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A> +<A HREF="/philosophy/gif.html">no gifs due to patent problems</A> +<P> +by <A HREF="/people/rms.html">Richard Stallman</A>. +<P> + +People sometimes ask, ``Why did the FSF develop a new free kernel +instead of using Linux?'' It's a reasonable question. The answer, +briefly, is that that is not the question we faced. + +<P> +When we started developing the Hurd in 1990, the question facing us +was, ``How can we get a free kernel for the GNU system?'' There was +no free Unix-like kernel then, and we knew of no other plan to write +one. The only way we could expect to have a free kernel was to write +it ourselves. So we started. + +<P> +We heard about Linux after its release. At that time, the question +facing us was, ``Should we cancel the Hurd project and use Linux +instead?'' + +<P> +We heard that Linux was not at all portable (this may not be true +today, but that's what we heard then). And we heard that Linux was +architecturally on a par with the Unix kernel; our work was leading to +something much more powerful. + +<P> +Given the years of work we had already put into the Hurd, we decided +to finish it rather than throw them away. + +<P> +If we did face the question that people ask---if Linux were already +available, and we were considering whether to start writing another +kernel---we would not do it. Instead we would choose another project, +something to do a job that no existing free software can do. + +<P> +But we did start the Hurd, back then, and now we have made it work. +We hope its superior architecture will make free operating systems +more powerful. + +<HR> + +Return to <A HREF="/home.html">GNU's home page</A>. +<P> +FSF & GNU inquiries & questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF. +<P> +Comments on these web pages to +<A HREF="mailto:webmasters@www.gnu.org"><EM>webmasters@www.gnu.org</EM></A>, +send other questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +<P> +Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc., +59 Temple Place - Suite 330, Boston, MA 02111, USA +<P> +Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved.<P> +Updated: +<!-- hhmts start --> +16 Feb 1998 tower +<!-- hhmts end --> +<HR> +</BODY> +</HTML> diff --git a/hurd-announce b/hurd-announce new file mode 100644 index 00000000..2f165ad8 --- /dev/null +++ b/hurd-announce @@ -0,0 +1,47 @@ +From mib@PREP.AI.MIT.EDU Tue May 7 12:07:53 1991 +From: mib@PREP.AI.MIT.EDU +Newsgroups: gnu.announce +Subject: FSF work on a GNU OS +Date: 6 May 91 22:15:22 GMT +Reply-To: mib@prep.ai.mit.edu +Distribution: gnu +Organization: GNUs Not Usenet + +The Free Software Foundation is beginning work on a GNU operating +system built on top of the Mach 3.0 microkernel. There are three +goals to this project worth noting: + +o Binary compatability with 4.4 BSD, and other U*x or U*xish systems + on other hardware where appropriate, convenient, and consistent with + the design; + +o Posix compliance (in combination with the GNU C Library and the GNU + C Compiler); and + +o Ease of use as well as several new features and functionality. + + +I am interested in constructive criticism on the interfaces, design, +and implementation from experts in the field of OS research and design +consistent with the above goals. Advice from seasoned U*x hackers is +especially welcome. + +We have a mailing list for discussion. Currently there is little +discussion on the group; the major contributors to the ideas behind +the design all live in the Boston area at this point, and work has +been done via face-to-face communication. I would like to open the +field of discussion to a broader base, both to get wider dissemination +of the ideas behind the current design, as well as to get a greater +breadth of criticism. Periodic postings are currently made to the +mailing list containing a snapshot of the interfaces used by the +various pieces of the system. I would like to see discussion as well; +perhaps we need a critical mass to get this. + +Interested individuals should send me email. I don't regularly read +the newsgroups to which this message is posted. + + +[U*x is an abbreviation for a well-known trademark of AT&T. :-)] + + -mib + diff --git a/hurd-announce2 b/hurd-announce2 new file mode 100644 index 00000000..dce41c43 --- /dev/null +++ b/hurd-announce2 @@ -0,0 +1,143 @@ +From mib@gnu.ai.mit.edu Wed Nov 3 21:51:03 1993 +Path: usenet.ee.pdx.edu!cs.uoregon.edu!ogicse!emory!nigel.msen.com!sdd.hp.com!swrinde!cs.utexas.edu!uunet!spool.mu.edu!bloom-beacon.mit.edu!ai-lab!prep.ai.mit.edu!gnulists +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +Newsgroups: gnu.announce,gnu.misc.discuss +Subject: Hurd status and call for volunteers +Message-ID: <9311020719.AA02206@geech.gnu.ai.mit.edu> +Date: 1 Nov 93 21:19:05 GMT +Article-I.D.: geech.9311020719.AA02206 +Followup-To: gnu.misc.discuss +Distribution: world +Lines: 124 +Approved: info-gnu@prep.ai.mit.edu +To: info-gnu@prep.ai.mit.edu +X-Shopping-List: + (1) Chaotic casino griddles (2) Cervical congestion (3) Neoclassical + consoles +Xref: usenet.ee.pdx.edu gnu.announce:160 gnu.misc.discuss:3985 + +This message to help sate curiosity, as well as to ask for volunteers. +Until we are ready for alpha test, this is the last such message that +will be posted here. If you want to receive further such messages, +send mail to hurd-ann-request@gnu.ai.mit.edu and ask to be put on that +(moderated) announcements list. + + +What is already done with the Hurd: + +The filesystem is complete; it runs (read-only), and most of its calls +have been tested and work. The filesystem is able to download +programs, by a kludge similar to the kludge used to enable the kernel +to download the first task. In the actual bootstap sequence, it will +download the execserver. + +The proc and auth servers are completed; the exec server is nearly +complete (for a.out, not for bfd). + +C library support for Mach and Hurd rpc stubs, and some of the mach +and hurd specific code, is done. Much untested and probably wrong +code has been written to implement Unix "system calls". A large piece +of this (the descriptor management code) is believed by Roland to have +some architectural flaw, but he isn't sure. + +Some small filesystem servers (shadow directories, for example) have +been written, but have not been compiled, let alone tested. + + +There are currently three things happening wrt the Hurd: + +I am spending nearly all my time getting things to boot and run. My +work is currently directed toward that goal; in the immediate present +I am working with Roland on getting the library in its near-final +state (which will last a long time) to make compiling easier. It is +because this is nearly done that I can send this message. + +Roland is working on the library. Most of the remaining architectural +work is done and being tested. Then Roland will work on integrating +cthreads (which is mostly busywork), miscellaneous filesystem calls, +and then file descriptors. After that comes signals. + +Jan Brittenson will be working on the network server library. This is +a library that, when linked against a BSD protocol stack, will produce +a Hurd network server. (Such a server implements the socket interface +in socket.defs.) + + +There are four general tasks that can be done by other people: + +1. Completing the existing work on the terminal driver. The existing +work implements most of the logic you already associate with a Posixy +terminal driver; it needs the port management and buffering logic +added. + +2. Writing a readline terminal driver. We will want, as an +alternative to the Posixy terminal driver, a readline type terminal +driver. + +3. Writing miscellaneous shell utilities. Here we need shell +utilities to create translators, etc. They should have a nice rich +set of features to do all kinds of GNU things. + +4. Writing miscellaneous filesystem servers. Here we need a +transparent tar server, a transparent FTP server, and the like. + + +Future plans for work to be written by me (once the bootstrap works, +and in addition to testing library code as Roland finishes it): + +o split the existing filesystem into three parts: + o a library for port management for complicated multi-threaded + servers; + o a library for "normal" disk-based filesystems; + o ufs specific code. + +o Write the PF_FILE socket server (what you know as PF_UNIX). + +o Finish the posixy terminal driver if nobody else has. + +o Write miscellaneous shell utilities that nobody else has. + +o Build a self-hosting system. + + +What you need in order to be able to help now: + +o A 386 PC running Mach 3.0. If you have some other kind of hardware, + then you need to port the GNU C library support first. I'm not + entirely sure how much work that involves; you will need to contact + Roland. It might be too much trouble at this point to spend any + effort on it. It's best if it's a machine for which a free port of + Mach is available, though you could do useful work even if it's not. + + If you are not currently running Mach 3.0 with somebody's + single-server, then it is very unlikely you could help, unless you + have a Unix source license. In that case, you could talk to CMU + (write mach@cs.cmu.edu) to find out how to get Mach 3.0 running on + your machine. It is not possible to do development without a Unix + emulator of some kind; just bare Mach 3.0 is not sufficient. I have + neither the time nor knowledge to help someone get a 3.0 + single-server system running. + +o Clue. I don't have enough time to explain operating systems or Unix + to people. You need to have an iron-clad grasp of Unix semantics + (specificaly BSD); it's essential that things be exactly right from + that standpoint. It's not enough that you've programmed Unix + before; you need to understand all the nits. However, you may + disregard my previous comments about a "two question limit". You do + need the ability to intuit to some extent, however. + +o Time. It's not good for me to delegate a task and then have nothing + happen on it. If you have a full-time job where you can't justify + Hurd work as part of your job, you might find that you don't really + have as much time as you thought. Please make sure you really have + enough time before volunteering for a task. + +o Efficient net access. Without a real Internet connection (mail only + is not sufficient), it will be impossible for you to do development + right now. + + +If you think you can help, send me email. If you don't think you can +help right now, then don't give up: the list of conditions will change +as the list of delegatable tasks changes. + diff --git a/hurd-flash b/hurd-flash new file mode 100644 index 00000000..d1bacc79 --- /dev/null +++ b/hurd-flash @@ -0,0 +1,22 @@ +Path: gnurd!usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!gatech!europa.eng.gtefsd.com!MathWorks.Com!news.kei.com!bloom-beacon.mit.edu!ai-lab!life.ai.mit.edu!mib +From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell) +Newsgroups: gnu.misc.discuss,comp.os.mach +Subject: Hurd now bootstraps +Date: 05 Apr 1994 21:49:50 GMT +Organization: Free Software Foundation, Cambridge, MA +Lines: 11 +Message-ID: <MIB.94Apr5174952@churchy.gnu.ai.mit.edu> +NNTP-Posting-Host: churchy.gnu.ai.mit.edu + + +The GNU Hurd now bootstraps, successfully starting the core servers +(the filesystem, exec server, process server, auth server, and init) +and running the first program. A snapshot of the code that did this +is on alpha.gnu.ai.mit.edu in the usual place, /gnu/hurd-snap.tar.gz. + +-- ++1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, ++1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. +1105 Broadway | Then Jonathan made a covenant with David +Somerville, MA 02144 | because he loved him as his own soul. + diff --git a/hurd-flash10 b/hurd-flash10 new file mode 100644 index 00000000..d6d5685b --- /dev/null +++ b/hurd-flash10 @@ -0,0 +1,25 @@ +Date: Mon, 15 Apr 1996 15:28:29 -0400 +Message-Id: <199604151928.PAA00636@geech.gnu.ai.mit.edu> +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +To: hurd-ann@gnu.ai.mit.edu +Subject: New Hurd snapshot available +X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ ++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv ++ b+++ !D B-- e+ u++(*) h* f? r n y++ +X-Tom-Swiftie: "Use the `&' operator to get the address," Tom pointed out. +Sender: owner-abshurd@cs.pdx.edu +Precedence: bulk + + +I have just cut a new source snapshot. If things go nicely, a binary +snapshot may appear soon as well. You can find this snapshot as + +ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap-960415.tar.gz + +Many many things work! Emacs built native and just *went*. The +system now works standalone; you can use gdb (it's much nicer than +other mach-ish gdb's, of course); the network is functional (complete +with NFS), etc. + +Michael + diff --git a/hurd-flash11 b/hurd-flash11 new file mode 100644 index 00000000..57851b01 --- /dev/null +++ b/hurd-flash11 @@ -0,0 +1,25 @@ +From: Miles Bader <miles@gnu.ai.mit.edu> +To: hurd-ann@gnu.ai.mit.edu +Date: Thu, 18 Apr 1996 19:08:07 -0400 +Subject: hurd binary image + + +A filesystem image from a working hurd system, corresponding to the latest +snapshot, is available as: + + ftp://alpha.gnu.ai.mit.edu/gnu/hurd-image-960418.tar.gz + +The whole tree takes about 37meg (warning -- it unpacks into `.'). Follow +the instructions in ./INSTALL-binary to make a working hurd system. + +Due to a timely trashing of the disk on our main hurd machine, it has been +verified that it is possible to make a bootable hurd system from scratch +using this image and a set of netbsd 1.1 boot floppies... + +The sources for the mach kernel included in the image are available in the +same directory as mach4-UK22.tar.gz and mach4-i386-UK22.tar.gz. + +-Miles +-- +Miles Bader / miles@gnu.ai.mit.edu / (617) 253-8568 +Amadera e ike! diff --git a/hurd-flash12 b/hurd-flash12 new file mode 100644 index 00000000..5be9c94e --- /dev/null +++ b/hurd-flash12 @@ -0,0 +1,76 @@ +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +Newsgroups: gnu.misc.discuss +Subject: Hurd 0.0 release status +Followup-To: gnu.misc.discuss +Date: 13 Jul 1996 23:53:41 GMT +Organization: Touring Consulting Services +Lines: 35 +Message-ID: <MIB.96Jul13195341@gnu.ai.mit.edu> +NNTP-Posting-Host: churchy.gnu.ai.mit.edu + + +People are eager to know how close we are to release, so here's an +update: + +There is one rather annoying bug I'd like to find which is causing +random crashes. I expect this will not be too hard to locate. There +are some more trivial bugs, but the release will not be held up for +them. + +Forty-three packages of GNU software have been built native. +Remaining to be built are three packages for which new releases are +expected soon. + +Also remaining to be built native are bash, gdb, mach, the Hurd +itself, and the internet utilities and daemons. We intend to sync our +separate copy of libc source with the libc maintainer, and then build +it native too. + +Because of obnoxious export restrictions, we have still to make +separate shared libraries for the crypt functions. + +Except for the actual final packaging, all the release engineering +tasks to be done have been completed. + + +To summarize, we still need to: + +o Fix one obnoxious bug +o Compile three packages that are waiting for release; +o Compile gdb, bash, mach, and hurd native +o Sync libc source and compile native +o Deal with crypt shared libraries +o Final packaging + +Michael + +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +Newsgroups: gnu.misc.discuss +Subject: Re: Hurd--ne plus ultra of vaporware? +Date: 17 Jul 1996 03:02:14 GMT + +In article <4sg6tp$n4t@linux.cs.Helsinki.FI> torvalds@linux.cs.Helsinki.FI (Linus Torvalds) writes: + + Hey! We could also ask some well-known rock-group for one of their + lyrics, and use that as the theme song for the Hurd release. And then + we could ask shops to stay open longer to sell the Hurd! Whaddaya think? + Don't say it has been delayed, just shout so loudly about all the new + features that nobody cares about the delay? + +Perhaps we could get Morrisey to sing the song. He's very good +looking. Much better looking than that Mick Jagger fellow. + +Or something delicate, like Bach's French Suite in G. That would be +fun. + +In any case, here's the state of the release: + +o Everything but nine packages has been compiled native. +o The random crash bug I alluded to is fixed. +o We have to build a floppy image for part of the installation instructions. + +That's it. I bet you nobody in Redmond has ever made a statement like +that... + +Michael + diff --git a/hurd-flash13 b/hurd-flash13 new file mode 100644 index 00000000..a2de6bfd --- /dev/null +++ b/hurd-flash13 @@ -0,0 +1,120 @@ +Date: Mon, 5 Aug 1996 22:36:31 -0400 +From: thomas@gnu.ai.mit.edu (Thomas Bushnell, n/BSG) +To: info-gnu@prep.ai.mit.edu, hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu +Subject: Hurd 0.0 and GNU 0.0 released +X-Name-Change: My name used to be `Michael'; now it is `Thomas'. +X-Tom-Swiftie: "I guess I shouldn't have broken the mirror," Tom reflected. + + + + +I am pleased to announce version 0.0 of the GNU Hurd, available via +anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file +/pub/gnu/hurd-0.0.tar.gz (about 1.2 MB compressed). + +This file contains complete source code for the following: + +Hurd servers: + + auth, crash, devio, devport, exec, ext2fs, fifo, fwd, ifsock, init, + magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term, + ufs. + +Hurd libraries: + + diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps, + shouldbeinlibc, store, threads, trivfs. + +Hurd utilities and other programs: + + boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts, + storeinfo, login, w, uptime, hurdids, loginpr, sush, vmstat, + portinfo, devprobe, reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs, + stati.ufs, getty, rc. + + +------ + + +In addition, we have prepared a binary distribution of a complete +version 0.0 GNU system corresponding to this Hurd release. This +release runs only on PC-AT compatible systems with i[345]86 +processors. + +The GNU Hurd, plus Mach, is a kernel, not an operating system. The +GNU operating system, like the Unix operating system, consists of many +components, including kernel, libraries, compilers, assembler, shell, +parser generators, utilities, window system, editors, text formatters, +and so on. The GNU project set out a decade ago to develop this +system, and we've been writing various components of it ever since. + +This release uses the `UK22' version of the Mach kernel, as +distributed by the University of Utah. It is too difficult to prepare +a detailed list of supported devices at this point. Common disk +controllers and ethernet cards are generally supported. + +This release does not contain the X Window System. + +This release may be fetched by anonymous FTP from prep.ai.mit.edu +[18.159.42] in the directory /pub/gnu/gnu-0.0/. + +In that directory, you should find the following files: + + README + SOURCES + INSTALL-binary + grub-boot.image (about 1.4 MB, not compressed) + gnu-0.0.tar.gz (about 56.9 MB compressed) + gnu-0.0-stripped.tar.gz (about 26.2 MB compressed) + +SOURCES contains a complete list describing the sources for the +binaries found in the image. INSTALL-binary contains complete +installation instructions for this release. + +(The files README, SOURCES, and INSTALL-binary are also found in the +root directory of the gnu-0.0 release.) + +gnu-0.0.tar.gz holds the image of the complete system. It unpacks +into a directory that requires approximately 233 MB of disk space. + +gnu-0.0-stripped.tar.gz holds the same contents as gnu-0.0, except +that executable programs have been stripped to save space, and the +libraries have had debugging symbols stripped to save space and speed +linking. It unpacks into a directory that requires about 85.5 MB of +disk space. + +We recommend using the unstripped image, or you will be unable to +debug anything. Surely there are bugs. So fetch the unstripped +image, at least to have around. + +grub-boot.image is an image of a 3.5" floppy disk that you will need +in order to complete part of the installation instructions. + +The following free software packages are found in this release: + + autoconf, automake, bash, bc, binutils, bison, cpio, cvs, diffutils, + doschk, e2fsprogs, ed, emacs, fileutils, findutils, flex, from, gawk, + gcal, gcc, gdb, gdbm, gettext, glibc, gmp, gperf, grep, grub, gzip, + hello, hurd, indent, inetutils, less, mach, make, m4, miscfiles, + ncurses, nethack, nvi, patch, ptx, rcs, readline, recode, sed, + serverboot, sharutils, shellutils, tar, termcap, termutils, texinfo, + textutils, time, wdiff. + + +------ + + +Here are md5sum checksums for the files mentioned in this message: + +b5f888bab3eb193fe97a00a141324c9d INSTALL-binary +345dcd826747d7b11fc78f4db162d75b README +1a5744bb4ed3448045fa6d24153d65fe SOURCES +f7b1bc428bc4ee29977a5b28f5762092 gnu-0.0-stripped.tar.gz +24554c58e5c89f295176e17d21dbae8e gnu-0.0.tar.gz +8338c619d860b71bc4128c9c0fd39d63 grub-boot.image +1fd18ccc4c81d051b83d28b13dc07ee2 hurd-0.0.tar.gz + +----- + +Br. Thomas Bushnell, n/BSG + diff --git a/hurd-flash14 b/hurd-flash14 new file mode 100644 index 00000000..2d67687a --- /dev/null +++ b/hurd-flash14 @@ -0,0 +1,62 @@ +I am pleased to announce version 0.2 of the GNU Hurd, available via +anonymous FTP from prep.ai.mit.edu [18.159.0.42] in the file +/pub/gnu/hurd-0.2.tar.gz (about 1.37 MB compressed). + +(The GNU Hurd, plus Mach, is a kernel, not an operating system. The +GNU operating system, like the Unix operating system, consists of many +components, including kernel, libraries, compilers, assembler, shell, +parser generators, utilities, window system, editors, text formatters, +and so on. The GNU project set out a decade ago to develop this +system, and we've been writing various components of it ever since.) + +This release contains many bug fixes from version 0.1. Many thanks to +all the people who are helping find bugs! + +The best way you can help find bugs is to try and compile and use on +the Hurd as many programs as you can find and find out where bugs +still exist. There are also unimplemented features, and your reports +will help us to prioritize which things we work on. + +The system is vastly more reliable than it has been in the past. + +One important addition: + + New programs addauth, rmauth, unsu, su, and setauth modify the uid + sets of running programs. Using addauth you can add root to your + emacs, write a file, and then use rmauth to take the uid back. (Of + course, passwords are required when necessary.) New program `ids' + will tell you what all the user ids are that a program has. Note + that in the Hurd a program can have several user ids all at once, + just like Unix supports having several group ids. Now that you can + dynamically change the ids of running programs, system + administration (among other things) becomes much easier. + +For more detailed news, see the NEWS file in the distribution. + +This release contains complete source code for the following: + +Hurd servers: + + auth, crash, devport, exec, ext2fs, fifo, fwd, ifsock, init, + magic, new-fifo, nfs, null, pfinet, pflocal, proc, symlink, term, + ufs, storeio, firmlink. + +Hurd libraries: + + diskfs, fshelp, ihash, iohelp, netfs, pager, pipe, ports, ps, + shouldbeinlibc, store, threads, trivfs, hurdbugaddr, ftpconn + +Hurd utilities and other programs: + + boot, shd, ps, settrans, showtrans, sync, su, mount, fsysopts, + storeinfo, login, w, uptime, ids, sush, vmstat, portinfo, devprobe, + reboot, halt, fsck, fsck.ufs, mkfs.ufs, clri.ufs, stati.ufs, getty, + rc, e2os, vminfo, nfsd, mail.local, serverboot, MAKEDEV, loginpr, + addauth, rmauth, unsu, setauth, ftpcp, ftpdir. + +We are also making a complete GNU 0.2 binary release, which will +include Hurd 0.2, glibc 2.0.4, gnumach 1.1.2, and many other +programs. This binary release is announced separately. + + +Thomas Bushnell, n/BSG diff --git a/hurd-flash15 b/hurd-flash15 new file mode 100644 index 00000000..0785ac59 --- /dev/null +++ b/hurd-flash15 @@ -0,0 +1,60 @@ + +I am pleased to announce version 0.2 of the complete Hurd based GNU +system. This release runs only on PC-AT compatible systems with +i[3456]86 processors. + +The GNU Hurd, plus Mach, is a kernel, not an operating system. The +GNU operating system, like the Unix operating system, consists of many +components, including kernel, libraries, compilers, assembler, shell, +parser generators, utilities, window system, editors, text formatters, +and so on. The GNU project set out a decade ago to develop this +system, and we've been writing various components of it ever since. + +This release uses the GNUmach distribution of the Mach kernel, version +1.1.3. Popular PC devices are generally supported. + +This release does not contain the X Window System. + +This release may be fetched from the directory +ftp://prep.ai.mit.edu/pub/gnu/gnu-0.2. (prep.ai.mit.edu is 18.159.42, +for the nameserver-impaired). + +In that directory, you should find the following files: + +README +SOURCES +INSTALL-binary +grub-boot.image (about 1.5 MB, not compressed) +gnu-0.2.tar.gz (about 73 MB compressed) + +SOURCES contains a complete list describing the sources for the +binaries found in the image. INSTALL-binary contains complete +installation instructions for this release. + +(The files README, SOURCES, and INSTALL-binary are also found in the +root directory of the gnu-0.2 release.) + +gnu-0.2.tar.gz holds the image of the complete system. It unpacks +into a directory that requires approximately 285 MB of disk space. + +grub-boot.image is an image of a 3.5" floppy disk that you will need +in order to complete part of the installation instructions. + +The following free software packages are included in this release: + +autoconf automake bash bc binutils bison cpio cvs diffutils doschk +e2fsprogs ed emacs emacs lisp manual fileutils findutils flex from g77 +gawk gcal gcc gdb gettext glibc gmp gnuchess gnumach gnugo grep grub +gzip hello hurd indent inetutils less libg++ lynx m4 make miscfiles +ncurses nethack nvi patch perl ptx readline rcs recode sed sendmail +sh-utils sharutils tar termutils texinfo textutils time wdiff + +-- + +Here are md5sum checksums for the files mentioned in this message: + +3749b016ab581e007b90d17b9092e134 INSTALL-binary +1f800c326ba4c3a0b3f3a3463597317b README +40d1e1a38dd86f28fe2718081ac865cb SOURCES +f29c1a03c1667a8019b66f6effa89d39 gnu-0.2.tar.gz +8ad3c7254802a16068a956e836266212 grub-boot.image diff --git a/hurd-flash2 b/hurd-flash2 new file mode 100644 index 00000000..b1d4f66f --- /dev/null +++ b/hurd-flash2 @@ -0,0 +1,152 @@ +From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell) +Newsgroups: gnu.misc.discuss,comp.os.mach,comp.os.linux.development,comp.os.linux.misc,comp.unix.pc-clone.32bit +Subject: GNU Hurd Task List and Call for Volunteers +Followup-To: gnu.misc.discuss +Date: 18 May 1994 17:54:47 GMT +Organization: FOO +Lines: 140 +Message-ID: <MIB.94May18135447@churchy.gnu.ai.mit.edu> +NNTP-Posting-Host: churchy.gnu.ai.mit.edu +Xref: usenet.ee.pdx.edu gnu.misc.discuss:7630 comp.os.mach:1434 comp.os.linux.d +evelopment:9867 comp.os.linux.misc:16767 comp.unix.pc-clone.32bit:5854 + + +Now that the Hurd can run (albeit haltingly) on its own, it is +possible for people who do not have Mach 3.0 single-servers to +contribute without much trouble. (However, if you don't have a +single-server, you probably won't be able to use a debugger, but that +doesn't mean you can't do debugging, right?) + +We at the FSF don't have any expertise in setting up Mach 3.0 +machines; the machines that we do development on belong to the Open +Software Foundation and were set up by them. So one of the things on +the task list is to organize things so that people (like us and most +of you) who don't know how to do it can do it. It's not impossible to +figure out, it's just a pain and a marvelous thing for a volunteer to +do. + +You can get Mach 3.0 from CMU; you get the C library and the Hurd from +us. You need the soon-to-be-released version 1.07.6 of the C library +and the latest Hurd snapshot (as well as our special version of MiG) +from alpha.gnu.ai.mit.edu. + +All our work is based upon i386. The Hurd (except for a few programs; +see the Hurd README file) is machine independent. The C library +should not be too much trouble to port. Ports and information about +porting difficulty for either of these are greatly desired. + +The Hurd is not yet self-hosting. While you are welcome to fetch the +code and put things together, it is not likely that you will have a +useful system right now. But you might be able to do significant work +(see the task list below). And, even if you can't do significant +work, I'm interested in hearing about any places where you had +particular difficulty. + +If you want to start on one of these tasks, please let me know so I +can keep track of volunteers properly. This task list will be updated +periodically; gnu@prep.ai.mit.edu always has the latest version. + + -mib + +GNU Hurd Task List Version 1.0. + +If you would like to work on one of these, please contact mib@gnu.ai.mit.edu. + + +Mach 3.0 Work + + o Mach 3.0 comes with CMU makefiles that depend on a drecky environment. + It would be very helpful to have makefiles and installation stuff so + that it worked well for cross-compilation between systems and used + GNU tools. + + o MiG needs to be made able to support cross-compilation. + + o A replacement for MiG that understood C .h files. + + o Bootstrap tools and documentation to help people set up Mach 3.0 + machines if they already have Linux; if they already have Net BSD; + if they don't have anything. + + o Mach 3.0 needs to provide support for task virtual timers similar + in functionality to the Unix ITIMER_PROF and ITIMER_VIRTUAL timers. + + o Mach 3.0 needs to provide a way for users to do statistical PC + profiling similar to the Unix profil system call. + + o Mach 3.0 needs a facility to automatically send task and thread + status on task/thread exit to a port that can only be changed by + a privileged user; this would be used to implement process + accounting. + + o Mach 3.0 needs a facility to find out what task is the parent of + a given task. + + o Mach 3.0 needs a facility to find out which pages of a task's + address space are in core to implement Unix's mincore call. + + o Mach 3.0 needs a facility to do msync. + + o Mach 3.0 needs a replacement for MEMORY_OBJECT_COPY_CALL that + works at least for the cases needed in ordinary files. (Write mib if + you want to know what the problem is and some ideas about how to + solve it.) + + o Mach 3.0 needs proxy memory objects. (mib can tell you what these + are and why they are important.) + + o Mach 3.0 needs a way to do per-task resource counters that are + accessible to servers called by the task. + + o Mach 3.0 needs facilities to implement resource limits of various sorts. + + o Mach 3.0 needs a way to have a thread's CPU time statistics + include time spent by servers on its behalf. + + o Of course, free ports are always necessary to machines that don't + already have free ports. + + o Much work can be done doing research in how to improve Mach VM + performance and timesharing scheduling policy. + + +Hurd work (these are brief descriptions; mib can give more information): + + o We need a translator for /dev. + + o We need a replacement for utmp and wtmp that understands the + Hurd `login collection' concept. Programs like who and finger + then need to be changed to use this. + + o We need some existing shell programs changed to do Hurd things: + like ls, su, fsck, tar, cpio, etc. + + o Some new programs need to be written: login, getty, ps, tools + for new filesystem features. + + o Shadow directory translators. (Roland has the beginnings of this.) + + o A system for write, send, talkd and so forth to bleep users; + this should be integrated with the utmp replacement above. + + o X. + + o A filesystem for /tmp that uses virtual memory instead of disk. + + o Filesystem implementations (using libdiskfs) for other popular + formats, especially the Linux formats as well as MSDOG. + + o Transparent FTP translator. + + o NFS client implementation. You should start with BSD's 4.4 code + and support the extensions they support; don't worry about Hurd + extensions right now. (The server we want to write ourselves + because it will probably involve changing the Hurd interfaces.) + + o A fancy terminal driver that uses readline and supports detach/attach. + +-- ++1 617 623 3248 (H) | The soul of Jonathan was bound to the soul of David, ++1 617 253 8568 (W) -+- and Jonathan loved him as his own soul. +1105 Broadway | Then Jonathan made a covenant with David +Somerville, MA 02144 | because he loved him as his own soul. diff --git a/hurd-flash3 b/hurd-flash3 new file mode 100644 index 00000000..19a5f371 --- /dev/null +++ b/hurd-flash3 @@ -0,0 +1,77 @@ +Date: Tue, 05 Jul 1994 20:15:09 -0400 +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +To: hurd-ann@gnu.ai.mit.edu +Subject: New Hurd snapshot + + +A new Hurd snapshot has been released. You can get it from +alpha.gnu.ai.mit.edu in the file /gnu/hurd-snap.tar.gz. You will need +the most recent version of the GNU C library; version 1.08.3 or later. +(Version 1.08.3 is an alpha release; you can get it from +alpha.gnu.ai.mit.edu in the same directory.) + +This snapshot of the Hurd has a limping terminal driver. It can run +emacs, bash, a whole slew of utilities, and (most importantly) GNU +Hello. + + -mib + + +Here is the new part of the NEWS file: + +The Hurd now runs all the programs in the GNU fileutils, textutils, +and shellutils distributions, with the exception of who. Most +importantly it runs GNU Hello. Also, emacs works (with the kludgy +`boot' terminal driver) and bash works. + +The simple pipes server works; it will be replaced eventually by the +pflocal server (which isn't done yet). The terminal driver is limping +but working. It doesn't support terminal ioctls yet. A minor bug in +auth has been fixed. boot interprets more Hurd protocols; this was +done to get emacs functioning. Some more-or-less serious bugs in exec +were fixed; they were found by running emacs (a quite large executable +indeed). At bootstrap time, init starts pipes and term itself; +eventually these will be passive translators, but we don't want to +write the new disk format until we're self-hosting or fsck and UX will +get confused. The file proc/primes.c has been documented; thanks go +to Jim Blandy. Some bugs in proc dealing with pgrp and wait were +fixed; a nasty hash table bug was also fixed. The simple shell can do +pipes. Several serious bugs in ufs were fixed dealing with extension +of large files and writes of data not aligned on block boundaries. +The ufs pager was over-serialized; that's been fixed. Directory +lookups and modifications now use mapped I/O directly; this is an +important speed-up. The structure of the pager lockes has been +changed significantly. UFS now supports Mach copying mode +MEMORY_OBJECT_COPY_DELAY; this significantly improves process startup +time. + +Some minor changes have been made to several interfaces. The +interface for fs.defs:dir_readdir has been totally changed. There are +some new fs.defs interfaces: file_check_access, file_notice_changes, +dir_notice_changes. The fsys.defs:fsys_getroot interface was changed +to work correctly. process.defs:proc_setprocargs is renamed, and a +fetch function proc_get_arg_locations is added. The ifsock.defs +interface was simplified. + +Several bugs were fixed in libdiskfs. The new dir_readdir interface +requires new support from format-specific code. Some race conditions +have been fixed. dir-pathtrans.c now deals correctly with multiple +slashes in a row. A new concept called "light references" allows +pagers to remain active without preventing truncate-on-nolinks from +working right. New interfaces in fs.defs are implemented (except +file_notice_changes). Active translator usage has been fixed to work +correctly, but passive translators are still untested. libdiskfs now +thinks it supports S_IFSOCK nodes, but that's untested (of course) +because pflocal isn't done yet. + +The passive translator startup interface in libfshelp has been +radically simplified. The pager library now lets other code set and +changee the attributes on objects, synchronously if desired. An +init/terminate race condition was fixed. The ports library now +allows single-threaded users to work right (they didn't before). The +trivfs library works; see the ifsock server for a simple example of +its use. See term or pipes for more complex examples. + +There is a task list in the file `tasks'; let me know if you are +interested in working on one of these. + diff --git a/hurd-flash4 b/hurd-flash4 new file mode 100644 index 00000000..89ae9848 --- /dev/null +++ b/hurd-flash4 @@ -0,0 +1,101 @@ +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +To: hurd-ann@gnu.ai.mit.edu +Date: Mon, 8 Aug 94 16:01:23 -0400 +Subject: New Hurd Snapshot +X-Shopping-List: + (1) Starboard sauce (2) Cinematic lesions (3) Two-way alphabetic + accordions + + +A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu in +/pub/gnu/hurd-snap.tar.gz. + +It is expected that the next snapshot after this one will have signals +basically working and thus be usable for a self-hosting system. In +addition, the next snapshot will probably have the current state of +our networking code (which has been proceeding, but has been absent +from the snapshots). + +Here is the NEWS about this current snapshot, however. Because some +big changes were made to the makefile and directory structure, things +might have gotten inadvertently ommitted from the snapshot. If this +happened, please let me know ASAP and I'll fix it and make a new +snapshot. + + -mib + + +August 8, 1994: + +Structural changes: + +Makefiles have been vastly improved and are simpler. The programs +`su', `ps', and `sh' have been moved from separate dirs into `utils'; +the programs `symlink' and `ifsock' have been moved into `trans'. + +Several changes were made to GCC use. You should definitely get GCC +version 2.6.0 now. Version 2.6.1 will have distributed the proper +`specs' file for the i386-gnu target, but it isn't quite ready yet, so +you still have to copy hurd/gcc-specs into +gcc-lib/i386-gnu/2.6.0/specs. + + +Interface changes: + +The tioctl.defs suite is complete now. + +INTR RPC's have been changed; individual RPC's are no longer marked +INTR. Rather, entire interfaces are marked `INTR_INTERFACE' if they +conform to the library's signalling/interruption expectations. + +There is a new magical retry type (for dir_pathtrans and fsys_getroot) +called `machtype' and a new one `/'; the former is for @sys tweaks and +the latter cleans up the retry of root-based symlinks a bit. + +There is a new interface `login.defs'. + +The "dotdot node" is no longer passed at fsys_startup time; instead, +it is passed by fsys_getroot. + + +Library changes: + +The ports library now does death-timeouts for multi-threaded servers; +it doesn't actually work right yet, however. Also the ports library +has new features (soft vs. hard ports; no outstanding ports +notifications) that enable server-death to be done cleanly. (I hope; +libdiskfs and ufs haven't yet been changed to use it, so libports +might not actually have the right facilities yet.) + +The translator startup routines in libfshelp have been vastly improved +(so that they can actually be used). + +Numerous bugfixes in libdiskfs, particularly relating to translator +usage. Use new magical retry type `/' when appropriate. Use new +dotdot node protocol. O_FSYNC and O_NOATIME are now honored properly. +Alternative methods of storing symlinks are now supported through new +hooks. + +The new dotdot protocol is now used by libtrivfs. Also, users of the +library are now able to set the atime and mtime when necessary. + +The special threads version of malloc has been placed back in +libthreads now that the C library uses a Mach-safe version on its own. + + +Program changes: + +The `boot' program no longer implements the tioctl interface now that +the terminal driver works. + +A bug was fixed in the handling of pgrps in `proc'. + +Many bugfixes in term. The tioctl interface is now implemented. EOF +processing is fixed; break characters now work right. Signals and +interruption are now done correctly. VDISCARD works. + +Ufs has Some bigs fixed in dir.c. Filesystem upgraded to BSD 4.4. +There are now some compatibility flags. + +New program dev.trim does a very minimal /dev (but doesn't work yet). +New program dev is an initial (but poor) attempt at a real /dev. diff --git a/hurd-flash5 b/hurd-flash5 new file mode 100644 index 00000000..041a0ef7 --- /dev/null +++ b/hurd-flash5 @@ -0,0 +1,23 @@ +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +Message-Id: <9409210619.AA17570@churchy.gnu.ai.mit.edu> +To: "Lots of potentially interested people and" <nobody@gnu.ai.mit.edu> +Subject: New milestone acheived by the GNU Hurd +X-Tom-Swiftie: "I can't get this fire started," Tom said woodenly. + + +I have just successfully compiled and run a null C program on the +Hurd. This is using GCC native as one would normally use GCC. + +Sadly, it took quite a while (too long, in fact) to read the large +archives that make up the GNU C library, but I think I know where the +substantial inefficiency is. + +Once that is done, I would be happy to label this a "self-hosting +system". But not just yet. + +The last bug preventing this was an error in dealing with files over +about 8 M; this came about because in order to link a program one +needed the GNU C library, which is over 9M when symbols are included. + + -mib + diff --git a/hurd-flash6 b/hurd-flash6 new file mode 100644 index 00000000..e774714e --- /dev/null +++ b/hurd-flash6 @@ -0,0 +1,46 @@ +Return-Path: <pdxgate.cs.pdx.edu!gnu.ai.mit.edu!mib> +Received: from pdxgate.cs.pdx.edu by gnurd with uucp + (Linux Smail3.1.28.1 #14) id m0r66pm-00010fC; Fri, 11 Nov 94 17:00 PST +Received: from cs.pdx.edu by pdxgate.cs.pdx.edu (4.1/CATastrophe-9/19/94-U) + id AA05257; Fri, 11 Nov 94 16:40:48 PST +Received: from churchy.gnu.ai.mit.edu by cs.pdx.edu (4.1/CATastrophe-9/19/94-P) + id AA02600; Fri, 11 Nov 94 16:40:22 PST +Received: by churchy.gnu.ai.mit.edu (5.65/4.0) + id <AA12621@churchy.gnu.ai.mit.edu>; Fri, 11 Nov 94 16:45:35 -0500 +Received: by churchy.gnu.ai.mit.edu (5.65/4.0) + id <AA12580@churchy.gnu.ai.mit.edu>; Fri, 11 Nov 94 16:38:44 -0500 +Date: Fri, 11 Nov 94 16:38:44 -0500 +From: mib@gnu.ai.mit.edu (Michael I Bushnell) +Message-Id: <9411112138.AA12580@churchy.gnu.ai.mit.edu> +To: hurd-ann@gnu.ai.mit.edu, hurd-dev@gnu.ai.mit.edu, info-gnu@prep.ai.mit.edu +Subject: New Hurd Snapshot +X-Shopping-List: + (1) Horrendous collision devotions (2) Wondrous consolation (3) + Conscious cooking auctions +X-Filter: mailagent [version 3.0 PL19] for trent@gnurd.uu.pdx.edu + + +A new Hurd snapshot has been placed on alpha.gnu.ai.mit.edu. There +may be unforseen problems with this snapshot, so the old one has been +left. You may fetch this snapshot via anonymous FTP in the file +/gnu/hurd-snap.tar.gz. + +The Hurd requires a modified version of MiG; you can get it by +anonymous ftp to kahlua.cs.utah.edu in /pub/mach/mach4-UK02p6.tar.gz. +Note that we are not yet using Mach4 for the Hurd, but we plan to +switch as soon as its feasible. + +Other necessary software to run this snapshot include the latest +snapshot of binutils/ld/gas source from Cygnus and the latest GCC. +(Problems have been reported with GCC 2.6.1; you might want to wait +until 2.6.2 is released.) And, of course, you also need the latest +test version of the GNU C Library, found on alpha.gnu.ai.mit.edu. + +This is not yet a real release; it is certainly not up to the quality +of even a hesitant alpha release. But it may be useful for +educational value or to help with the Hurd effort. + +I will be out of town for most of the rest of the year; I will be +reading email but I may not be able to help with problems. Sorry... + + -mib diff --git a/hurd-flash7 b/hurd-flash7 new file mode 100644 index 00000000..ce6e08d2 --- /dev/null +++ b/hurd-flash7 @@ -0,0 +1,17 @@ +Date: Wed, 12 Apr 1995 15:08:18 -0400 +From: Michael I Bushnell <mib@gnu.ai.mit.edu> +To: hurd-ann@duality.gnu.ai.mit.edu +Subject: New Hurd Snapshot available + +A new hurd snapshot is now available from +ftp://alpha.gnu.ai.mit.edu/gnu/hurd-snap.tar.gz. + +This snapshot contains many improvements over the last one, and is +also probably easier to compile. + +This snapshot must be used with the most recent libc snapshot, +ftp://alpha.gnu.ai.mit.edu/gnu/libc-950411.tar.gz. Previous versions +of the library will not work right. + +If any files are discovered to be missing, please let me know asap. + diff --git a/hurd-flash8 b/hurd-flash8 new file mode 100644 index 00000000..555186ec --- /dev/null +++ b/hurd-flash8 @@ -0,0 +1,73 @@ +Date: Sun, 23 Jul 1995 16:27:46 -0400 +Message-Id: <199507232027.QAA09306@geech.gnu.ai.mit.edu> +From: Michael I Bushnell <mib@gnu.ai.mit.edu> +To: hurd-ann@gnu.ai.mit.edu +Subject: Hurd snapshot! +X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ ++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv ++ b+++ !D B-- e+ u++(*) h* f? r n y++ +X-Zippy-Says: I just had a NOSE JOB!! +Sender: owner-abshurd@cs.pdx.edu +Precedence: bulk + + +I have just put a new Hurd snapshot on alpha.gnu.ai.mit.edu in +/gnu/hurd-snap-950723.tar.gz. + +You will also need the new libc snapshot, which should appear in the +same place today. Older libc snapshots will not be happy. + +The binary images (hurd-floppy.fs.gz and hurd-image.tar.gz) have not +been updated. It is difficult to use the Hurd standalon, because the +Mach boot loaders can now no longer boot the Hurd. A new boot loader +is nearly finished. Perhaps we can make new binary images then, or a +volunteer might take over this useful work. (Hint, hint.) + +Michael + + + +Here is the NEWS: + +July 23, 1995 + +Shared libraries now work; use -static to link programs and avoid the +shared libraries. The Hurd programs are normally built static; this +will probably change soon. + +The ext2fs server now works, as do the tools to manipulate ext2fs +filesystems. A snapshot of the tools will be made soon under separate +cover. Many thanks to Ted Ts'o for his valuable work on the tools. + +Readers of the Makefiles will notice that we now generate dependencies +automatically. + +The old netserv library is gone. + +The `boot' hack has been modified slightly to avoid the normalq libc startup +files, because they no longer work with UX. + +Some small bugs have been fixed in the devio server. + +The ports library has been totally rewritten; new features permit +servers to have greater control over thread RPC's and port creation. + +The fshelp library now does most of the work for translator +interaction; it's simpler now too. Filesystems have much less work to +do; the relevant code in libdiskfs is now understanble instead of +unparseable chaos. + +The ports library provides for timeouts; the diskfs library almost +uses it, but because of a bug, it's disabled for now. + +Filesystems are now expected to sync themselves if necessary; the new +fsys_set_options RPC provides for changeing (or cancelling) the sync +intervale. The diskfs library does this for you. The update program +is no longer necessary. + +A small bug in the proc server has been hacked around; the real fix +will come later. + +Many important bugs in the C library have been fixed since the last +snapshot; perhaps all of them. ;-) + diff --git a/hurd-flash9 b/hurd-flash9 new file mode 100644 index 00000000..1ff32ba9 --- /dev/null +++ b/hurd-flash9 @@ -0,0 +1,39 @@ +Date: Wed, 29 Nov 1995 13:13:23 -0500 +Message-Id: <199511291813.NAA10983@duality.gnu.ai.mit.edu> +From: mib@gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +To: hurd-ann@gnu.ai.mit.edu (and others) +Subject: Announcement +X-Geek-Code: (V2.1) GCS/J/M/MU/P/S/O>AT d- H-- s-: g+++ p0 !au a- w++ v+++(*) C+ ++$ UB++++$ P--- L 3- E++ N++ K++++ W-- M- V-- po-- Y+(--) t++ 5+ j++ R- G'''' tv ++ b+++ !D B-- e+ u++(*) h* f? r n y++ +X-Windows: The Cutting Edge of Obsolescence. +Sender: owner-abshurd@cs.pdx.edu +Precedence: bulk + + +The Hurd has succesfully completed its first FTP: + +bash# ftp 128.52.46.31 +Connected to 128.52.46.31. +220 albert.gnu.ai.mit.edu FTP server (Version 5.60) ready. +Name (128.52.46.31:root): +331 Password required for root. +Password:230 User root logged in. +ftp> cd ~mib +250 CWD command successful. +ftp> get ftptest +200 PORT command successful. +150 Opening ASCII mode data connection for ftptest (16 bytes). +226 Transfer complete. +17 bytes received in 0.07 secs (0.24 Kbytes/sec) +ftp> quit +221 Goodbye. +bash# cat ftptest +this is a test. +bash# + + +Tre cool. + +Michael + diff --git a/hurd-folks.html b/hurd-folks.html new file mode 100644 index 00000000..ccefd81c --- /dev/null +++ b/hurd-folks.html @@ -0,0 +1,78 @@ +<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> +<HTML> +<HEAD> +<TITLE>GNU Hurd folks - GNU Project - Free Software Foundation (FSF)</TITLE> +<LINK REV="made" HREF="mailto:webmasters@www.gnu.org"> +</HEAD> +<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD"> +<H3>GNU Hurd folks</H3> +<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg" + ALT=" [image of a Hurd Metafont Logo] " + WIDTH="333" HEIGHT="80"> (jpeg 10k)</A> +<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A> +<A HREF="/philosophy/gif.html">no gifs due to patent problems</A> +<P> + +A number of people maintain their own unofficial <A +HREF="hurd.html">GNU Hurd</A> pages to describe their involvements. +These are valuable sites because they help introduce more people to +the Hurd, and to the <A HREF="/gnu/gnu-history.html">GNU project</A>. + +<P> + +Send mail to <A HREF="http://www.fig.org/~gord/">Gordon Matzigkeit</A> <A +HREF="mailto:gord@gnu.org"><gord@gnu.org></A> if you have a page +you would like added to this list. + +<P> + +Thank GNU to everybody who has contributed to the Hurd's development! + +<EM> +These links are at other web sites not maintained by the FSF. +<BR> +The FSF is not responsible for the content of these other web sites. +</EM> +<P> + +<UL> + <LI><A HREF="http://www.rr.iij4u.or.jp/~kkojima/">kaz Kojima</A> + ported the Hurd to the <A + HREF="http://www.rr.iij4u.or.jp/~kkojima/hurdmips.html">MIPS + R3000 and R4000</A> processors. + + <LI><A HREF="http://www-mbi3.kuicr.kyoto-u.ac.jp/~okuji/"> + OKUJI Yoshinori</A> maintains a set of <A + HREF="http://www-mbi3.kuicr.kyoto-u.ac.jp/~okuji/hurd.html">Japanese + Hurd pages</A>. + + <LI><A HREF="http://f77.nop.or.jp/">UCHIYAMA Yasushi</A> has ported + <A HREF="Xfree86.html">XFree86</A> to the Hurd. + +</UL> + +<HR> + +Return to <A HREF="/home.html">GNU's home page</A>. +<P> +FSF & GNU inquiries & questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF. +<P> +Comments on these web pages to +<A HREF="mailto:webmasters@www.gnu.org"><EM>webmasters@www.gnu.org</EM></A>, +send other questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +<P> +Copyright (C) 1998 Free Software Foundation, Inc., +59 Temple Place - Suite 330, Boston, MA 02111, USA +<P> +Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved.<P> +Updated: +<!-- hhmts start --> + 5 Sep 1998 gord +<!-- hhmts end --> +<HR> +</BODY> +</HTML> diff --git a/hurd-fs-org b/hurd-fs-org new file mode 100644 index 00000000..ba515623 --- /dev/null +++ b/hurd-fs-org @@ -0,0 +1,219 @@ +From: mib@duality.gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +Newsgroups: gnu.misc.discuss +Subject: Re: GNU vs. Linux FSSTND conflict? +Date: 13 Aug 1995 22:31:18 GMT +Organization: Free Software Foundation, Cambridge, MA +In-reply-to: Rick Niles's message of 13 Aug 1995 16:20:29 GMT + +In article <40l8od$ia9@news4.digex.net> Rick Niles <niles@axp745.gsfc.nasa.gov> + writes: + + Is there a conflict between the GNU Filesystem Structure and + the Linux Filesystem Structure (FSSTND)? + +What you point out is the trivial difference; there are significant +lossages in FSSTND, such as the absence of libexec... + + I've heard on this newsgroup that the GNU std. is to elminate + the use of /usr. So: + + I guess the first question is: Is this true? + +Yes. + + If it is how do you answer those who say the root part. should + be small and only enough to boot the system? And + the rest of the system should be on a separate part. (/usr) + +In GNU the directory /bin will be an amalgam of several directories; +this well be done by the use of a translator in the Hurd. (It will be +similar to BSD shadow filesystems.) + +So we have no need to confuse users by putting binaries in two +different places. We can put different binaries in different physical +locations without either forcing them to appear in different places or +creating a forest of symlinks. + +But the FSSTND's arguments are bogus even for Unixoid systems which do +force differently located files to have different directory names: + + o It is often mounted from very small media. For example, many Linux + users install and recover systems by mounting root off a RAM disk, + which is copied from a single 1.44M or 1.2M floppy disk. + +This is a non-issue. Obviously a floppy can only have a small number +of files, but that's totally irrelevant in deciding what should be on +root on a fully loaded system. + + o The root filesystem has many system-specific configuration files in + it. Possible examples include a kernel that is specific to the + system, a different hostname, etc. This means that the root + filesystem isn't always shareable between networked systems. + Keeping it small on networked systems minimizes the amount of space + lost on servers to unshareable files. It also allows workstations + with smaller local hard drives. + +It should be possible to require only the etc directory to be +per-system; there is no reason that bin and such should be non-shared +at all. + + o While you may have the root filesystem on a large partition, and + may be able to fill it to your heart's content, there will be + people with smaller partitions. If you have more files installed, + you may find incompatibilities with other systems using root + filesystems on smaller partitions. If you are a developer then you + may be turning your assumption into a problem for a large number of + users. + +This is totally incoherent, as far as I can tell. If someone can tell +me what it means, then maybe I could help. What sort of +incompatibilities are expected? + +Michael + + + +From: gord@enci.ucalgary.ca (Gord Matzigkeit) +Newsgroups: gnu.misc.discuss +Subject: Re: GNU vs. Linux FSSTND conflict? +Date: 14 Aug 1995 18:55:20 -0600 +In-reply-to: mib@duality.gnu.ai.mit.edu's message of 13 Aug 1995 22:31:18 GMT + +-----BEGIN PGP SIGNED MESSAGE----- + +Hi! + +>>>>> "mib" == Michael I Bushnell, p/BSG <mib@duality.gnu.ai.mit.edu> writes: + + mib> In article <40l8od$ia9@news4.digex.net> Rick Niles + mib> <niles@axp745.gsfc.nasa.gov> writes: +[hack & slice] + + >> If it is how do you answer those who say the root + >> part. should be small and only enough to boot the system? And + >> the rest of the system should be on a separate part. (/usr) + + mib> In GNU the directory /bin will be an amalgam of several + mib> directories; this well be done by the use of a translator in the + mib> Hurd. (It will be similar to BSD shadow filesystems.) + +This is what I figured... my reply didn't get posted to USENET, +though, because our NNTP server has been down for the last day or two. + + mib> So we have no need to confuse users by putting binaries in two + mib> different places. We can put different binaries in different + mib> physical locations without either forcing them to appear in + mib> different places or creating a forest of symlinks. + +This is grand! One of my ideas that I mentioned to Rick was that I'm +currently using depot, and I see that the GNU union/shadowfs could +replace that. + +What depot does is manages symlinks for a "software environment" (a +more restricted version of what you have described). + +The way I think I'll be setting up my Hurd machine is to have all the +physical disks mounted under "/disk", each containing a fragment of +the filesystem. + +Now, my only concerns are: + +1) control files, as far as determining precedence, and what can and +cannot be shadowed (for collision resolution), and what is just +auxilliary info (like CVS directories in the site package, which +should not be mapped onto the software environment) + +2) packages. Is there some slick way to divide the filesystem into +"package pieces", like depot does? + +One suggestion to get (2), is that I could create an intermediate +directory, say "/package", that would be the union of various mounted +physical disks (under /disk), and would contain things like: + +emacs-19.30/bin +emacs-19.30/lib... +gcc-2.7.3/bin... +fileutils-5.8/man... +site/sbin/useful_perl_script + +et al. Then I would unionfs all the directories in the /package dir +onto the root filesystem. + +This would have most of the advantages I'm getting from depot, namely, +the ability to specify different precedences on different machines, +so that I can try out emacs-19.31 on one workstation without +disrupting the others. + +Is there a better way to do this? I do like the idea of three +different hierarchies for files (under /disk, where I can see what is +on each server; under /package, where I can see what is in each +package; the GNU standard dirs, where I actually use the files), but I +am hoping that there is something more elegant. Hmm. Maybe not. + + mib> It should be possible to require only the etc directory to be + mib> per-system; there is no reason that bin and such should be + mib> non-shared at all. + +This is one point (for security), that would mandate the use of config +files, so that the unionfs doesn't map /etc/some_important_file from +another server. + +This is yet another thing that I'm looking forward to. Thanks. ;) + +- --Gordon + +- -- +Gordon Matzigkeit | Heck, it was only a TOASTER... lighten up! +gord@enci.ucalgary.ca | PGP mail preferred... finger me for my key. +Keyprint: D5 66 08 E0 4D F4 D7 7B 8A C8 8A 9C 7F 39 25 A7 - ID 339ABEB9 + + +-----BEGIN PGP SIGNATURE----- +Version: 2.6.2 +Comment: Processed by Mailcrypt 3.3, an Emacs/PGP interface + +iQCVAwUBMC/wcyFsfCEzmr65AQHubwP7BGVHqs9ACB8hFUqDdF2oWu/lLq1hW/Oa +qra2ZfcKfIZq9hIM4tLRJ0qCaiOVm5MGLgH7Yax+ZyOPb4K0fCObzk1XY5b0enhV +9SR70UZ7Qm7MXj+PFCp5lxvrNiaFXMbil0EN5FQEvH9kUp0ed1NWcaXGqTK6gezm +YBUumt2Zadk= +=6f2c +-----END PGP SIGNATURE----- + + + + +From: mib@duality.gnu.ai.mit.edu (Michael I. Bushnell, p/BSG) +Newsgroups: gnu.misc.discuss +Subject: Re: GNU vs. Linux FSSTND conflict? +Date: 16 Aug 1995 14:43:47 GMT +In-reply-to: gord@enci.ucalgary.ca's message of 14 Aug 1995 18:55:20 -0600 + +In article <npka8gj893.fsf@enci.ucalgary.ca> gord@enci.ucalgary.ca (Gord Matzig +keit) writes: + + The way I think I'll be setting up my Hurd machine is to have all the + physical disks mounted under "/disk", each containing a fragment of + the filesystem. + +Our idea is to do something roughly like this. + + 1) control files, as far as determining precedence, and what can and + cannot be shadowed (for collision resolution), and what is just + auxilliary info (like CVS directories in the site package, which + should not be mapped onto the software environment) + +Yes, the relevant translator will support a *rich* set of semantics +for this kind of things specified by a control file. + + 2) packages. Is there some slick way to divide the filesystem into + "package pieces", like depot does? + +We're going to do this; rms and I have worked out a usable scheme that +meets all the necessary goals. + +The physical location of files has to be reflected by sharing rules +(see the GNU makefile standards); users have to be able to see all the +files relevant to a particular program easily; programs have to be +easily de-installed. We have a scheme that meets these three. + +Michael diff --git a/hurd-migr b/hurd-migr new file mode 100644 index 00000000..ce36c86c --- /dev/null +++ b/hurd-migr @@ -0,0 +1,141 @@ +Path: usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!swrinde!howland.reston.ans.net!E +U.net!Germany.EU.net!netmbx.de!sietec.de!news!jh +From: jh@poseidon.sietec.de (Jochen Roger Hayek) +Newsgroups: gnu.misc.discuss +Subject: HURD & migration facilities +Date: 24 Oct 1994 15:12:34 GMT +Organization: Sietec Systemtechnik, Berlin +Lines: 16 +Distribution: world +Message-ID: <JH.94Oct24161234@poseidon.sietec.de> +Reply-To: Jochen.Roger.Hayek@sietec.de +NNTP-Posting-Host: sunmiet3.sietec.de + +I read an article from acm's sigops vol. 28, number 4 this weekend, having the +title: + + a brief survey of systems providing + process or object migration facilities + by Mark Nuttall + +I found it very instructive. + +I think process / object migration should be considered for HURD, too, +and it's important to look at that before supporting / emulating +UNIX's fork and inherited open file descriptors, +because those features might get contradictory if not carefully designed. + +Regards esp. to the HURD folks + +JH + +Path: usenet.ee.pdx.edu!cs.uoregon.edu!sgiblab!spool.mu.edu!bloom-beacon.mit.ed +u!ai-lab!life.ai.mit.edu!mib +From: mib@churchy.gnu.ai.mit.edu (Michael I Bushnell) +Newsgroups: gnu.misc.discuss +Subject: Re: HURD & migration facilities +Date: 24 Oct 1994 18:10:25 GMT +Organization: Free Software Foundation, Cambridge, MA +Lines: 27 +Distribution: world +Message-ID: <MIB.94Oct24141025@churchy.gnu.ai.mit.edu> +References: <JH.94Oct24161234@poseidon.sietec.de> +NNTP-Posting-Host: churchy.gnu.ai.mit.edu +In-reply-to: jh@poseidon.sietec.de's message of 24 Oct 1994 15:12:34 + GMT + +In article <JH.94Oct24161234@poseidon.sietec.de> jh@poseidon.sietec.de (Jochen +Roger Hayek) writes: + + I think process / object migration should be considered for HURD, too, + and it's important to look at that before supporting / emulating + UNIX's fork and inherited open file descriptors, + because those features might get contradictory if not carefully designed. + +Process migration is not a problem for the Hurd--it's a problem for +Mach. If a Mach task can be correctly migrated, then there is no +problem. + +However, I want to do more than that with the Hurd; I want to have a +collection of machines (I think I'll call it a ``Collective'') appear +as a single machine. (Shades of amoeba here.) + +This is the first (and harder) task--making a single global space of +pids, etc. + +The second (and easier) task is migration. + + -mib +-- ++1 617 623 3248 (H) | En arche en ho logos, ++1 617 253 8568 (W) -+- kai ho logos en pros ton theon, +1105 Broadway | kai theos en ho logos. +Somerville, MA 02144 | Kai ho logos sarx egeneto, +mib@gnu.ai.mit.edu | kai eskenosen en hemin. + +Newsgroups: gnu.misc.discuss +Path: usenet.ee.pdx.edu!cs.uoregon.edu!reuter.cse.ogi.edu!psgrain!agora!hermes. +rdrop.com!erich +From: erich@uruk.org (Erich Boleyn) +Subject: Re: HURD & migration facilities +Sender: news@agora.rdrop.com (David Greenman) +Nntp-Posting-Host: uruk.org +Organization: RainDrop Laboratories +Message-ID: <ERICH.94Oct29093537@uruk.org> +References: <JH.94Oct24161234@poseidon.sietec.de> + <MIB.94Oct24141025@churchy.gnu.ai.mit.edu> +In-Reply-To: mib@churchy.gnu.ai.mit.edu's message of 24 Oct 1994 18:10:25 GMT +Date: Sat, 29 Oct 1994 16:35:37 GMT +Lines: 50 + + +In article <MIB.94Oct24141025@churchy.gnu.ai.mit.edu> mib@churchy.gnu.ai.mit.ed +u (Michael I Bushnell) writes: + + Process migration is not a problem for the Hurd--it's a problem for + Mach. If a Mach task can be correctly migrated, then there is no + problem. + + However, I want to do more than that with the Hurd; I want to have a + collection of machines (I think I'll call it a ``Collective'') appear + as a single machine. (Shades of amoeba here.) + +Great! (I think we talked about this before...) + + This is the first (and harder) task--making a single global space of + pids, etc. + +This point seems somewhat questionable. Maybe we're thinking about +the same idea in the long run, but I don't think that migrating +data about the whole system around would be very useful... +I mean, you still want a very large collective to work, though it +could well get bogged down by the details of huge amounts of info. + +I think a more optimal (and more practical) approach would be to: + +Create a model of a "user context" that keeps track across multiple +machines what resources and programs a user is working with. + +There would also be publically known "services" that would be advertised. +Note that "advertising" is a specific activity that is usually not +performed, unless one desires to do so. + +Anything else is really of little or no concern except to a local group of +machines (for resource-balancing issues). So machines would automatically +keep in touch with other nearby machines, but it would be modulated by +distance. + +The big question is this (and for that matter, other models) is that +of authentication in some kind of reasonably reliable manner. + + The second (and easier) task is migration. + +Agreed. + +Erich + +-- +Erich Stefan Boleyn \ Mad Genius wanna-be, CyberMuffin +Mathematician, Software Engineer \ slavering computer nerd +Internet E-mail: <erich@uruk.org> \ "Forget Artificial Intelligence, +Motto: "I'll live forever or die trying" \ I want the real thing!" diff --git a/hurd-name.html b/hurd-name.html new file mode 100644 index 00000000..79aa5b9d --- /dev/null +++ b/hurd-name.html @@ -0,0 +1,53 @@ +<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> +<HTML> +<HEAD> +<TITLE>What the name Hurd means - GNU Project - Free Software Foundation (FSF)</TITLE> +<LINK REV="made" HREF="mailto:webmasters@www.gnu.org"> +</HEAD> +<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD"> +<H3>What the name ``Hurd'' means</H3> +<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg" + ALT=" [image of a Hurd Metafont Logo] " + WIDTH="333" HEIGHT="80"> (jpeg 10k)</A> +<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A> +<A HREF="/philosophy/gif.html">no gifs due to patent problems</A> + +<P> + +"Hurd" stands for "Hird of Unix-Replacing Daemons". +And, then, "Hird" stands for "Hurd of Interfaces Representing Depth". + +<P> + +We have here, to my knowledge, the first software to be named by a +pair of mutually recursive acronyms. + +<P> + +---Michael (now Thomas) Bushnell + +<HR> + +Return to <A HREF="/home.html">GNU's home page</A>. +<P> +FSF & GNU inquiries & questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF. +<P> +Comments on these web pages to +<A HREF="mailto:webmasters@www.gnu.org"><EM>webmasters@www.gnu.org</EM></A>, +send other questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +<P> +Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc., +59 Temple Place - Suite 330, Boston, MA 02111, USA +<P> +Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved.<P> +Updated: +<!-- hhmts start --> +16 Feb 1998 tower +<!-- hhmts end --> +<HR> +</BODY> +</HTML> diff --git a/hurd-paper.html b/hurd-paper.html new file mode 100644 index 00000000..e98e5edf --- /dev/null +++ b/hurd-paper.html @@ -0,0 +1,792 @@ +<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> +<HTML> +<HEAD> +<TITLE>Towards a New Strategy of OS Design</TITLE> +<LINK REV="made" HREF="mailto:webmasters@www.gnu.org"> +</HEAD> +<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD"> +<H1>Towards a New Strategy of OS Design</H1> +<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg" + ALT=" [image of a Hurd Metafont Logo] " + WIDTH="333" HEIGHT="80"> (jpeg 10k)</A> +<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A> +<A HREF="/philosophy/gif.html">no gifs due to patent problems</A> +<P> +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 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 use the +underlying Mach device ports for terminals, which support moving large +amounts of data efficiently. + +<H3>Executing Programs</H3> +<P> +The implementation of the +<CODE>execve</CODE> +call is spread across three programs. +The +library marshals the argument and environment vectors. +It then sends a +message to the file server that holds the file to be executed. +The file +server checks execute permissions and makes whatever changes it desires in +the exec call. +For example, if the file is marked setuid and the fileserver +has the ability, it will change the user identification of the new image. +The file server also decides if programs which had access to the old task +should continue to have access to the new task. +If the file server is +augmenting permissions, or executing an unreadable image, then the exec needs +to take place in a new Mach task to maintain security. +<P> +After deciding the policy associated with the new image, the filesystem calls +the exec server to load the task. +This server, using the BFD (Binary File +Descriptor) library, loads the image. +BFD supports a large number of object +file formats; almost any supported format will be executable. +This server +also handles scripts starting with +<CODE>#!</CODE>, +running them through the indicated +program. +<P> +The standard exec server also looks at the environment of the new image; if +it contains a variable +<CODE>EXECSERVERS</CODE> +then it uses the programs specified +there as exec servers instead of the system default. +(This is, of course, +not done for execs that the file server has requested be kept secure.) +<P> +The new image starts running in the GNU C Library, which sends a message to +the exec server to get the arguments, environment, umask, current directory, +etc. +None of this additional state is special to the file or exec servers; +if programs wish, they can use it in a different manner than the Library. + +<H3>New Processes</H3> +<P> +The +<CODE>fork</CODE> +call is implemented almost entirely in the GNU C Library. +The new +task is created by Mach kernel calls. +The C Library arranges to have its +image inherited properly. +The new task is registered with the process server +(though this is not mandatory). +The C Library provides vectors of functions +to be called at fork time: one vector to be called before the fork, one after +in the parent, and one after in the child. +(These features should not be +used to replace the normal fork-calling sequence; it is intended for +libraries which need to close ports or clean up before a fork occurs.) +The C +library will implement both fork calls specified by the draft Posix.4a (the +proposed standard dealing with the threads extension to the real-time +extension). +<P> +Nothing forces the user to create new tasks this way. +If a program wants to +use almost the normal fork, but with some special characteristics, then it +can do so. +Hooks will be provided by the C Library, or the function can even +be completely replaced. +None of this is possible in a traditional Unix +system. + +<H3>Asynchronous Messages</H3> +<P> +As mentioned above, the process server maintains a +<DFN> +message port +</DFN> +for each +task registered with it. +These ports are public, and are used to send +asynchronous messages to the task. +Signals, for example, are sent to the +message port. +The signal message also provides a port as an indication that +the sender should be trusted to send the signal. +The GNU C Library lists a +variety of ports in a table, each of which identifies a set of signals that +can be sent by anyone who possesses that port. +For example, if the user +possesses the task's kernel port, it is allowed to send any signal. +If the +user possesses a special +<DFN> +terminal id +</DFN> +port, it is allowed to send the +keyboard and hangup signals. +Users can add arbitrary new entries into the C +library's signal permissions table. +<P> +When a process's process group changes, the process server will send it a +message indicating the new process group. +In this case, the process server +proves its authority by providing the task's kernel port. +<P> +The C library also has messages to add and delete uids currently used by the +process. +If new uids are sent to the program, the library adds them to its +current set, and then exchanges messages with all the I/O servers it knows +about, proving to them its new authorization. +Similarly, a message can +delete uids. +In the latter case, the caller must provide the process's task +port. +(You can't harm a process by giving it extra permission, but you can +harm it by taking permission away.) The Hurd will provide user programs to +send these messages to processes. +For example, the +<CODE>su</CODE> +command will be able +to cause all the programs in your current login session, to gain a new uid, +rather than spawn a subshell. +<P> +The C library will allow programs to add asynchronous messages they wish to +recognize, as well as prevent recognition of the standard set. +<H3>Making It Look Like Unix</H3> +<P> +The C Library will implement all of the calls from BSD and Posix as well as +some obvious extensions to them. +This enables users to replace those calls +they dislike or bypass them entirely, whereas in Unix the calls must be used +``as they come'' with no alternatives possible. +<P> +In some environments binary compatibility will also be supported. +This works +by building a special version of the library which is then loaded somewhere +in the address space of the process. +(For example, on a VAX, it would be +tucked in above the stack.) A feature of Mach, called system call +redirection, is then used to trap Unix system calls and turn them into jumps +into this special version of the library. +(On almost all machines, the cost +of such a redirection is very small; this is a highly optimized path in Mach. +On a 386 it's about two dozen instructions. +This is little worse than a +simple procedure call.) +<P> +Many features of Unix, such as signal masks and vectors, are handled +completely by the library. +This makes such features significantly cheaper +than in Unix. +It is now reasonable to use +<CODE>sigblock</CODE> +extensively to protect +critical sections, rather than seeking out some other, less expensive method. + +<H3>Network Protocols</H3> +<P> +The Hurd will have a library that will make it very easy to port 4.4 BSD +protocol stacks into the Hurd. +This will enable operation, virtually for +free, of all the protocols supported by BSD. +Currently, this includes the +CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO +protocols. +<P> +For optimal performance some work would be necessary to take advantage of +Hurd features that provide for very high speed I/O. +For most protocols this +will require some thought, but not too much time. +The Hurd will run the +TCP/IP protocols as efficiently as possible. +<P> +As an interesting example of the flexibility of the Hurd design, consider the +case of IP trailers, used extensively in BSD for performance. +While the Hurd +will be willing to send and receive trailers, it will gain fairly little +advantage in doing so because there is no requirement that data be copied and +avoiding copies for page-aligned data is irrelevant. + +<HR> + +Return to <A HREF="/home.html">GNU's home page</A>. +<P> +FSF & GNU inquiries & questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF. +<P> +Comments on these web pages to +<A HREF="mailto:webmasters@www.gnu.org"><EM>webmasters@www.gnu.org</EM></A>, +send other questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +<P> +Copyright (C) 1996 Trent Fisher +<BR> +Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc., +59 Temple Place - Suite 330, Boston, MA 02111, USA +<P> +Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved.<P> +Updated: +<!-- hhmts start --> +19 Dec 1998 jonas +<!-- hhmts end --> +<HR> +</BODY> +</HTML> diff --git a/hurd.html b/hurd.html new file mode 100644 index 00000000..56ff601b --- /dev/null +++ b/hurd.html @@ -0,0 +1,233 @@ +<!DOCTYPE html PUBLIC "-//IETF//DTD HTML 2.0//EN"> +<HTML> +<HEAD> +<TITLE>GNU Hurd information - GNU Project - Free Software Foundation (FSF)</TITLE> +<LINK REV="made" HREF="mailto:webmasters@www.gnu.org"> +</HEAD> +<BODY BGCOLOR="#FFFFFF" TEXT="#000000" LINK="#1F00FF" ALINK="#FF0000" VLINK="#9900DD"> +<H3>GNU Hurd information</H3> +<A HREF="/graphics/hurd_sm_mf.jpg"><IMG SRC="/graphics/hurd_sm_mf.jpg" + ALT=" [image of a Hurd Metafont Logo] " + WIDTH="333" HEIGHT="80"> (jpeg 10k)</A> +<A HREF="/graphics/hurd_mf.jpg">(jpeg 20k)</A> +<A HREF="/philosophy/gif.html">no gifs due to patent problems</A> +<P> + +The GNU Hurd is the <A HREF="/gnu/gnu-history.html">GNU project</A>'s +replacement for the architecture-independent services provided by the +Unix kernel. The Hurd is a collection of servers that run on top of a +microkernel (such as Mach) to implement file systems, network +protocols, file access control, and other features. +<P> + +<EM>NOTE:</EM> the Hurd still lacks many of the features you would +expect in a usable kernel, so please don't try using it unless you are +helping us to develop it. We will announce to the world when GNU 1.0 +is ready, and at that point the Hurd will be a viable alternative to +Unix-like kernels such as Linux or the BSD kernel. +<P> + +The current release of the Hurd is 0.2, released on June 12, 1997. See +the <A HREF="hurd-NEWS">NEWS file</A> for a list of changes and +improvements. +<P> + +In addition, we have a separate distribution of the Hurd's current +microkernel, derived from the "Mach 4" distributions made by the +University of Utah. Our distribution is called GNU Mach, the latest +version is 1.1.3. See the <A HREF="mach-NEWS">NEWS file</A> for a list +of changes and improvements. + +<P> + +<EM> +Some of these links are at other web sites not maintained by the FSF. +<BR> +The FSF is not responsible for the content of these other web sites. +</EM> + +<P> + +<H2>Binary Distributions</H2> + +In June 1997, we released GNU 0.2, a complete system image for PC AT +compatibles with 386 or later compatible processors. This image +corresponded to version 0.2 of the Hurd. Unfortunately, GNU 0.2 did +not have a package management system, and so it was difficult to install +and upgrade. + +<P> + +As of July 1998, we have joined forces with the <A +HREF="http://www.debian.org/">Debian Project</A> in order to create a +new binary distribution. GNU 0.3 will look like a Debian GNU/Linux +system, but will be called <A +HREF="/software/hurd/debian-gnu-hurd.html">Debian GNU/Hurd</A> to +reflect the fact that it uses the Hurd running on Mach instead of Linux. +<P> + +In the future, we plan on porting the Hurd to other kernels besides +GNU Mach. One possibility would be to modify Linux so that it is +capable of hosting the Hurd. +<P> + +<H2>General Information</H2> +<A HREF="hurd-icon.jpg"><IMG SRC="hurd-icon.jpg" + ALT=" [a spherical Hurd logo - small] " + WIDTH="69" HEIGHT="43"> (jpeg 2k)</A> +<A HREF="hurd-logo.jpg">(jpeg 8k)</A> +<P> +<DL> + <DT><A HREF="hurd-paper.html"><CITE>Towards + a New Strategy of OS Design.</CITE></A> + <DD>This paper also appeared in the + <A HREF="/bulletins/bull16.html">January 1994 GNU's Bulletin</A>. + + <DT>The <A HREF="http://www.corridor.com/~sfavor/debian-gnu-hurd-faq/gnu-hurd-faq.html">GNU Hurd FAQ</A>. + + <DT><A HREF="doc/doc.html">The GNU Hurd Reference Manual</A> +<DD>(draft from a recent release). + +<DT><A HREF="hurd-and-linux.html">The relationship between the Hurd and Linux.</A> + +<DT><A HREF="debian-gnu-hurd.html">The Debian GNU/Hurd project.</A> + +<DT><A HREF="/prep/mailinglists.html">Mailing-lists</A> are available for the Hurd: +<DD><UL><LI>Report Hurd bugs to + <A HREF="mailto:bug-hurd@gnu.org">bug-hurd@gnu.org</A>. + <BR>Subscribe to the list by asking + <A HREF="mailto:bug-hurd-request@gnu.org">bug-hurd-request@gnu.org</A>. + <LI>For discussion of the Hurd, use the mailing list + <A HREF="mailto:help-hurd@gnu.org">help-hurd@gnu.org</A>. + <BR> + Subscribe to the list by asking + <A HREF="mailto:help-hurd-request@gnu.org">help-hurd-request@gnu.org</A>. +</UL> + +<DT>The Hurd <A HREF="/prep/tasks.hurd.html">task list</A>. + +<DT><A HREF="hurd-name.html">The meaning of the name "Hurd"</A>. + +<DT><A HREF="byte-letter.txt">A letter to Byte magazine about the GNU Hurd</A> +<!-- uncomment and remove next line once todd's site comes on line grat 2.18.98 +written by <A HREF="http://www.gov.com/t">Todd Hutchinson</A>.--> + written by Todd Hutchinson. +<DD><A HREF="http://www.sypher.com/tbm">Martin Michlmayr</A> +also mentioned the Hurd in +an article in UNIXopen +(<A HREF="http://www.sypher.com/tbm/Publications/Welcome.html">listing of +articles</A>). + +<DT><A HREF="hurd-migr">Some discussion of processes migration +with the Hurd</A>.<DD> +Some of the <A HREF="http://www.cs.utah.edu/projects/flexmach/">Mach + research at University of Utah</A> is also relevant. + +<DT><A HREF="hurd-fs-org">Several messages about the filesystem +organization of the Hurd.</A> +</DL> + +<P> +<H2>Where to Get it</H2> +Here are some FTP URL's for the Hurd, GNUmach, and complete GNU binary +distributions. + +<DL> +<DT><a href="ftp://ftp.gnu.org/pub/gnu/hurd-0.2.tar.gz">Hurd 0.2 source</a> +<DT><a href="ftp://ftp.gnu.org/pub/gnu/gnumach-1.1.3.tar.gz">GNUmach 1.1.3 source</a> +<DT> <a href="ftp://ftp.nop.or.jp/pub/gnu-0.2/XFree86/3.3.2/">Xfree86-3.3.2 ported to the GNU Hurd.</a> Here are the local <a href="/software/hurd/Xfree86.html">details</a> and file descriptions. +<p> +<DT><a href="ftp://ftp.gnu.org/pub/gnu/gnu-0.2/README">GNU 0.2 information</a> +<DT><a href="ftp://ftp.gnu.org/pub/gnu/gnu-0.2/">GNU 0.2 binary distribution</a> +<p> +<DT><a href="ftp://alpha.gnu.org/gnu/hurd/">Directory of development snapshots.</a> +</DL> + +<A HREF="debian-gnu-hurd.html">Debian GNU/Hurd</A> has not yet been released. + +<P> +<H2>What if I'm having problems?</h2> + +First, check the FAQ (see the pointers above.) This FAQ contains +excellent advice about partition naming and many other common +problems. Then try the help-hurd mailing list mentioned above. + +<P> +<H2>Current and Past Announcements</H2> +<P> +These are all the announcements made over the years. +Most of them were either to <A HREF="news:gnu.announce">gnu.announce.</A> +<DL> +<DT><A HREF="hurd-flash15">Release 0.2 announcement (complete GNU system)</A> +<DT><A HREF="hurd-flash14">Release 0.2 announcement (Hurd)</A> +<DT><A HREF="hurd-flash13">Test release announcement (Aug 96)</A> +<DT><A HREF="hurd-flash12">Test release status (Jul 96)</A> +<DT><A HREF="hurd-flash11">Binary image available, Apr 96</A> <DD> This and +<A HREF="http://www.netbsd.org/">NetBSD</A> boot flopies should be enough +to get a working Hurd system! +<DT><A HREF="hurd-flash10">New Snapshot, Apr 96</A> -- NFS and lots else works! +<DT><A HREF="hurd-flash9">News Flash, Nov 95</A> -- ftp works! +<DT><A HREF="hurd-flash8">New Snapshot, Jul 95</A> -- ext2fs support +<DT><A HREF="hurd-flash7">New Snapshot, Apr 95</A> +<DT><A HREF="hurd-flash6">News flash, Nov 94</A> +<DT><A HREF="hurd-flash5">News flash, Sep 94</A> -- gcc runs! +<DT><A HREF="hurd-flash4">News flash, Aug 94</A> +<DT><A HREF="hurd-flash3">News flash, Jul 94</A> -- emacs runs! +<DT><A HREF="hurd-flash2">News flash, May 94</A> +<DT><A HREF="hurd-flash">News flash, Apr 94</A> -- it boots! +<DT><A HREF="hurd-announce2">GNU HURD announcement, Nov 93</A> +<DT><A HREF="hurd-announce">GNU HURD announcement, May 91</A> +</DL> +<P> +<H2>Other stuff and related projects</H2> +<DL> + +<DT><a href="http://www.uruk.org/grub/">Grub</a><DD> The GRand Unified +Bootloader, written by Erich Boleyn, is the standard boot loader used +for the Hurd. + +<DT><a href="http://www.cs.hut.fi/lites.html">Lites</a><DD> +A free Mach single server, based on BSD 4.4 Lite. +<A HREF="http://www.cs.utah.edu/projects/flux/lites/html/">A + more recent version</A> is available from the Mach4 people (q.v.) +<DT><A HREF="http://www.cs.utah.edu/projects/flexmach/mach4/html/Mach4-proj.html">Mach 4.</A> +<DD>The Hurd currently runs on top of Mach. This page documents the Utah release of Mach, from which the GNU Mach distribution came. +<DT><A HREF="http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html">CMU CS Project Mach Home Page</A> +<DT><A HREF="http://www.osf.org/os/os.coll.papers/">OSF Operating Systems Collected Papers</A> +<DT><A HREF="http://www.gr.osf.org/mklinux/">Linux on the OSF Microkernel</A> +</DL> + +<p> +Thanks to <A HREF="http://www.cs.pdx.edu:/~trent/">Trent Fisher</A> for +writing the initial version of this page, and to + +<A HREF="mailto:teddy@fukt.hk-r.se">Teddy Hogeborn</A> for the +icon. + +<HR> + +Return to <A HREF="/home.html">GNU's home page</A>. +<P> +FSF & GNU inquiries & questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +Other <A HREF="/home.html#ContactInfo">ways to contact</A> the FSF. +<P> +Comments on these web pages to +<A HREF="mailto:webmasters@www.gnu.org"><EM>webmasters@www.gnu.org</EM></A>, +send other questions to +<A HREF="mailto:gnu@gnu.org"><EM>gnu@gnu.org</EM></A>. +<P> +Copyright (C) 1996 Trent Fisher +<BR> +Copyright (C) 1996, 1997, 1998 Free Software Foundation, Inc., +59 Temple Place - Suite 330, Boston, MA 02111, USA +<P> +Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved.<P> +Updated: +<!-- hhmts start --> +19 Aug 1998 gord +<!-- hhmts end --> +<HR> +</BODY> +</HTML> diff --git a/old_hurd_faq.html b/old_hurd_faq.html new file mode 100644 index 00000000..00a49827 --- /dev/null +++ b/old_hurd_faq.html @@ -0,0 +1,318 @@ +<html> +<head> +<title>The Unofficial (and no longer maintained) GNU Hurd FAQ, Version 0.13 </title> +</head> + +<body> +<pre>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 Hurd FAQ? +Q1. What is the Hurd? +Q2. Where can I get a copy? +Q3. Why bother writing a new OS when we have Linux and 386/BSD? +Q4. What's all this about Mach 3.0 (and Mach 4.0)? +Q5. Where can I find more information? +Q6. What's a proper machine? +Q7. What sort of machines will run Hurd in the future? +Q8. What is the current development status? +Q9. What sort of system would we have if the Hurd was bootable today? + +============================== + +Q0. Where can I get the Unofficial GNU Hurd FAQ? + +The Unofficial Hurd FAQ (what you are reading now) is occasionally +posted to the USENET newsgroup, gnu.misc.discuss. It is also +available from + + http://www.enci.ucalgary.ca/~gord/hurd/hurd-faq.txt + +If you don't have WWW access, you may send mail to me, Gordon +Matzigkeit <gord@enci.ucalgary.ca> with a subject line that reads: + + Subject: send hurd-faq + +You should receive a PGP-signed copy of the current version of this +document in a matter of minutes. + + +Q1. What is the Hurd? + +The Hurd is the high-level operating system for GNU. It is currently +under development. GNU was designed as a replacement for Unix, so the +Hurd is multi-tasking and multi-user, POSIX-compliant, and will have +networking and X-windows and all that good stuff. + +Hurd is an acronym for ``Hird of Unix-Replacing Daemons''. Hird, in +turn, is an acronym for ``Hurd of Interfaces Representing Depth''. + + +Q2. Where can I get a copy? + +To put it simply, you can't. It is still under development (by +Michael Bushnell, Roland McGrath and Miles Bader). It is almost, but +not quite, at the point where you can do real work on it. Keep your +fingers crossed. + +Some people have actually bootstrapped it, but the work is not easy, +and the current snapshot won't work until a new multiserver boot +mechanism is made. + +If you *really* want to try it, beware that it is still pre-alpha +code, and that it will likely crash on you. See Trent Fisher's Hurd +pages (under question 5) for the latest information. + + +Q3. Why bother writing a new OS when we have Linux and 386/BSD? + +For one thing, Linux and BSD don't scale well. Hardware designers are +shifting more and more toward multiprocessor machines for performance, +and standard Unix kernels do not provide much multiprocessor support. +The Hurd, on the other hand, runs on top of the Mach 3.0 micro-kernel +[[1]] from CMU. Mach was designed precisely for multiprocessing +machines, so its portability should carry over nicely to the Hurd. + +In addition, the Hurd will be considerably more flexible and robust +than generic Unix. Wherever possible, Unix kernel features have been +moved into unprivileged space. Once there, anyone who desires can +develop custom replacements for them. Users will be able to write and +use their own file systems, their own `exec' servers, or their own +network protocols if they like, all without disturbing other users. + +The Linux kernel has now been modified to allow user-level file +systems, so there is proof that people will actually use features such +as these. It will be much easier to do under the Hurd, however, +because the Hurd is almost entirely run in user space and because the +various servers are designed for this sort of modification. + + +Q4. What's all this about Mach 3.0 (and Mach 4.0)? + +As mentioned above, Mach is a micro-kernel, written at Carnegie Mellon +University. A more descriptive term might be a greatest-common-factor +kernel, since it provides facilities common to all ``real'' operating +systems, such as memory management, interprocess communication, +processes, and a bunch of other stuff. Unfortunately, the system +calls used to access these facilities are only vaguely related to the +familiar and cherished Unix system calls. There are no "fork", +"wait", or "sleep" system-calls, no SIGHUPs, nothing like that. All +this makes it rather difficult to, say, port GNU Emacs to a Mach box. + +The trick is, of course, to write an emulation library. Unix programs +can then use (what they think are) POSIX system calls and facilities +while they are really using Mach system calls and facilities. + +The simplest way of going about this is to take an ordinary Unix +kernel, open it up, and rip out all the machine-specific guts; any +time the Unix kernel talks to the machine, replace the code with calls +to the Mach micro-kernel. Run this fake kernel on a Mach machine and +you end up with something that looks and acts just like Unix (even to +GNU Emacs). Note that the Unix kernel we have implemented is just one +Really Big Mach program (called a single-server). + +The Hurd, on the other hand, breaks the giant Unix kernel down into +various Mach programs running as daemons. Working in concert with +facilities placed in the C library, these daemons provide all of the +POSIX system-calls and features; from the outside they look just like +a standard Unix kernel. This means that, for practical purposes, +anything that you can port to Linux will also port to the Hurd. + +Of course, if a user wishes to run his own daemons, he can do that as +well.... + +Mach 4.0 is an enhanced version of Mach 3.0, put out by the people at +the University of Utah. They are working on another free operating +system, and part of it includes an enhanced, more flexible version of +Mach. The Hurd has moved to Mach 4.0, which is good, because it is a +lot easier to build than 3.0 was. + +You can find more information on Mach by browsing the Hurd pages given +in the next answer, or by looking at the Project Mach and Flux +homepages at: + +Carnegie Mellon University (for Mach versions before 4.0): + + http://www.cs.cmu.edu/afs/cs.cmu.edu/project/mach/public/www/mach.html + +the University of Utah (for Mach 4.0): + + http://www.cs.utah.edu/projects/flux/mach4/html/ + + +Q5. Where can I find more information? + +The June 1995 GNU's Bulletin contains the following official +information: + + The GNU Hurd now runs programs native. We have implemented both + shared libraries using ELF, & the popular `ext2' file system used + by Linux. It can run GCC, `make', Emacs, & most other GNU + utilities. Progress is being made so rapidly that by the time you + read this it probably does much more. It is right on the verge of + being self-hosting (able to run on its own well enough to compile + its own source code, & be used for its own development). We have + much better device supportm [sic] & some new utilities, including a + fancy `ps' & `settrans'. For a complete system we still have much + more work to do, but we will make an alpha release as soon as the + network software is finished & shared libraries have been well + tested. We have a mailing list to announce progress; to be added + to it, ask `hurd-announce-request@gnu.org'. + +The Portland State University CS department (via Trent Fisher) +maintains a WWW server with various Hurd documents, including Michael +Bushnell's Hurd paper, all the collected GNU's Bulletins, and various +announcements posted to "gnu.misc.discuss". The top-level GNU page is + + http://www.cs.pdx.edu/~trent/gnu/gnu.html + +and the Hurd page is + + http://www.cs.pdx.edu/~trent/gnu/hurd/hurd.html + +People in Europe might want to try the GNU WWW server for DESY +Germany, first: + + http://info.desy.de/gnu/www + +This site lacks culled, Hurd-specific information at the moment, but +it does have the last two GNU's Bulletins plus lots of general +information. + +There is a snapshot of the Hurd development tree on +"alpha.gnu.ai.mit.edu" in the "/gnu" directory. It is updated as +significant changes are made, and not guaranteed to run. + +You can subscribe to the Hurd announcement list by sending a request +to "hurd-announce-request@gnu.org". This is a moderated list +for distributing Hurd info to ``all and sundry'', and anyone can join. +In addition, there is a private (invitation-only) list for developers +to coordinate their efforts. It's not even worth thinking about +unless you (a) have a lot of free time on your hands, (b) know Unix +internals and Mach very well, and (c) have a proper machine. + + +Q6. What's a proper machine? + +A ``proper machine'', at the moment, means an x86 box running Mach 3.0 +(or 4.0), with FreeBSD 2.x, NetBSD 1.x, or Linux. + +A single-server OS is no longer required for development because by +the time the Hurd bootstrap mechanism is finished, the Hurd will +probably be self-hosting. + +Linux, FreeBSD, or NetBSD will only be required to splat the Hurd +binaries onto a partition of some sort, and to provide a way of +transferring files to the Hurd until the networking code is ready. + + +Q7. What sort of machines will run Hurd in the future? + +The first thing a prospective Hurd machine needs is a Mach 3.0 port. +According to the most recent "comp.os.mach" FAQ (which hasn't been +updated since February 1994), the following chips have redistributable +Mach micro-kernels and device drivers: + + Intel 80x86 (ISA and PS/2 buses) + Motorola 68000 (Sun 3) + Motorola 88000 (Omron Luna) + DEC Vax + DEC Pmax (DECstation 3100) + DEC Alpha + MIPS R4000 (DECstation 5000 et al.) + IBM RS/6000 + Apple Macintosh + +IBM is planning to run WorkplaceOS (the OS/2 successor) over Mach 3.0 +on the PowerPC chip (closely related to the RS/6000), so the PowerPC +will likely be added to this list soon. The University of Utah has +ported Mach 4.0 to the HP700, but it is not yet stable. + +Sun Sparc machines have a redistributable Mach microkernel, but the +device drivers require a SunOS 4.1.1 source license. + +In addition, any prospective Hurd machine needs a port of the GNU C +library. Version 1.07.4 of the library can handle the following +chips: + + Intel 80x86 (BSD, Dynix, Hurd, SCO, SysV) + Motorola 68000 (HP BSD, NEWS, Sun 4) + MIPS R4000 (Ultrix) + Sun Sparc (Solaris 2, Sun 4) + DEC Alpha (OSF/1, mostly finished) + +So if the next Hurd snapshot is self-hosting, we will be able to run +it (in theory) on Intel 80x86s, Motorola 68000s, MIPS R4000s and DEC +Alphas. + +People who can port the Mach micro-kernel to new architectures are +encouraged to do so. People who can port the GNU C library to new +chips (a much larger group) are also encouraged to do so. You can +help out here without knowing anything about Mach or having any +special machine. Note that once the GNU C library exists for a new +chip, for _any_ OS, making a Hurd port later is simple (and making +ports to other chips becomes easier as well---the effects are +cumulative). + +By current indications, the other hardware requirements (RAM, disk +space, and the like) will be about the same as those of BSD 4.4. + + +Q8. What is the current development status? + +Please see Trent Fisher's Hurd pages for details. + + +Q9. What sort of a system would we have if the Hurd was bootable +today? + +Quite likely, if you already use an end-user system like Linux, +FreeBSD, or NetBSD, you'll be disappointed with the Hurd. It will +take some time before the OS hackers really get to work on +applications and major enhancements. + +But, rest assured, Hurd development should proceed very rapidly. + +Of course, if you think you can help, or you just enjoy neat stuff, +then you'll probably like the Hurd. When you actually understand a +fraction of what's going on behind the scenes, it's very impressive. + +All I'm saying is that I'm not expecting all the Windows '95 users in +the world to switch to the Hurd right away. Wait a little while, +maybe 5-6 years (ample time for GNUStep and Guile to be in use), and +GNU users everywhere will be very happy that the FSF proceeded with +the Hurd. :) + + +============================== + +Footnotes: + +[[1]] Yes, I know that ``micro-kernel'' is about as apt a description +as ``Reduced Instruction Set Chip'', but we're stuck with it. + +</pre> +<P> +Updated: +<!-- hhmts start --> +23 Feb 1998 grat-w +<!-- hhmts end --> +<HR> + +</body> +</html> |