Three more documents I don't know what to do with.

3 files changed, 385 insertions, 0 deletions

diff --git a/unsorted/byte-letter.txt b/unsorted/byte-letter.txt
new file mode 100644
index 00000000..20fa61a0
--- /dev/null
+++ b/unsorted/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/unsorted/hurd-fs-org b/unsorted/hurd-fs-org
new file mode 100644
index 00000000..ba515623
--- /dev/null
+++ b/unsorted/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/unsorted/hurd-migr b/unsorted/hurd-migr
new file mode 100644
index 00000000..ce36c86c
--- /dev/null
+++ b/unsorted/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!"