Prepare toolchain/logs/master branch.

1 files changed, 0 insertions, 141 deletions

diff --git a/unsorted/hurd-migr b/unsorted/hurd-migr
deleted file mode 100644
index ce36c86c..00000000
--- a/unsorted/hurd-migr
+++ /dev/null
@@ -1,141 +0,0 @@
-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!"