diff options
Diffstat (limited to 'unsorted')
| -rw-r--r-- | unsorted/SavannahProjects.mdwn | 1 | ||||
| -rw-r--r-- | unsorted/byte-letter.txt | 25 | ||||
| -rw-r--r-- | unsorted/changelogs.html | 107 | ||||
| -rw-r--r-- | unsorted/hurd-fs-org | 219 | ||||
| -rw-r--r-- | unsorted/hurd-migr | 141 |
5 files changed, 493 insertions, 0 deletions
diff --git a/unsorted/SavannahProjects.mdwn b/unsorted/SavannahProjects.mdwn index 3024ed64..b1111ed5 100644 --- a/unsorted/SavannahProjects.mdwn +++ b/unsorted/SavannahProjects.mdwn @@ -7,6 +7,7 @@ * [pthreads](http://savannah.gnu.org/projects/pthreads) - porting of thread library for glibc * [hurd-iso](http://savannah.gnu.org/projects/hurd-iso) - CD-ROM images * [gnumach-alpha](http://savannah.gnu.org/projects/gnumach-alpha) - port for Alpha processor machines +* [hurd-alpha](http://savannah.gnu.org/projects/hurd-alpha) - provide a working implementation for the Alpha architecture * [[Hurd/THUG]] - Toronto Area GNU/Hurd User Group and their [documentation page](http://www.freesoftware.fsf.org/thug/docs.html) * [francine](http://savannah.gnu.org/projects/francine) - "secure, colourful and themeable login program" 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/changelogs.html b/unsorted/changelogs.html new file mode 100644 index 00000000..7689484e --- /dev/null +++ b/unsorted/changelogs.html @@ -0,0 +1,107 @@ +[[meta copyright="Copyright © 2001, 2002, 2006, 2008 Free Software Foundation, +Inc."]] + +[[meta license="""[[toggle id="license" text="GFDL 1.2+"]][[toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled +[[GNU_Free_Documentation_License|/fdl]]."]]"""]] + +<H3>ChangeLogs</H3> +<P> +As the Hurd sources are kept and maintained in a CVS repository that +is accessible via the web, you can follow the progress of development +closely. We maintain ChangeLogs, in which we record every change to +the source code at the time it is committed. The links below lead you +directly to the ChangeLog files in the Hurd and its associated packages. +<P> +If you want to follow the development of the Hurd closely, we suggest +that you subscribe to the <A +HREF="http://lists.gnu.org/mailman/listinfo/commit-hurd/">commit-hurd mailing +list</A> to which notifications about changes to the Hurd source code +are sent. The <A HREF="/software/hurd/download.html">complete source +code</A> is also available, of course. +</P> +<H4>The Hurd</H4> +<P> +The Hurd source tree contains many independent parts, and therefore +has one ChangeLog for each directory. There is one <A +HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ChangeLog">ChangeLog +in the main directory</A>, and one in each of the following +subdirectories: +</P> +<UL> +<LI>Translators and other servers: +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/auth/ChangeLog">auth</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/exec/ChangeLog">exec</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ext2fs/ChangeLog">ext2fs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ftpfs/ChangeLog">ftpfs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/hostmux/ChangeLog">hostmux</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/init/ChangeLog">init</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/isofs/ChangeLog">isofs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/mach-defpager/ChangeLog">mach-defpager</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/nfs/ChangeLog">nfs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/nfsd/ChangeLog">nfsd</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/pfinet/ChangeLog">pfinet</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/pflocal/ChangeLog">pflocal</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/proc/ChangeLog">proc</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/storeio/ChangeLog">storeio</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/term/ChangeLog">term</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/tmpfs/ChangeLog">tmpfs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/trans/ChangeLog">trans</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ufs/ChangeLog">ufs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/usermux/ChangeLog">usermux</A> +<LI>Utilities: +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/benchmarks/ChangeLog">benchmarks</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/boot/ChangeLog">boot</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/bsdfsck/ChangeLog">bsdfsck</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/fstests/ChangeLog">fstests</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/sutils/ChangeLog">sutils</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ufs-fsck/ChangeLog">ufs-fsck</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/ufs-utils/ChangeLog">ufs-utils</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/utils/ChangeLog">utils</A> +<LI>Boot code and system programs: +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/login/ChangeLog">login</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/config/ChangeLog">config</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/daemons/ChangeLog">daemons</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/serverboot/ChangeLog">serverboot</A> +<LI>Release scripts and packaging: +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/debian/ChangeLog">debian</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/release/ChangeLog">release</A> +<LI>Documentation: +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/doc/ChangeLog">doc</A> +<LI>Interface definitions: +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/hurd/ChangeLog">hurd</A> +<LI>Support libraries: +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libdiskfs/ChangeLog">libdiskfs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libfshelp/ChangeLog">libfshelp</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libftpconn/ChangeLog">libftpconn</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libhurdbugaddr/ChangeLog">libhurdbugaddr</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libihash/ChangeLog">libihash</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libiohelp/ChangeLog">libiohelp</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libnetfs/ChangeLog">libnetfs</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libpager/ChangeLog">libpager</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libpipe/ChangeLog">libpipe</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libports/ChangeLog">libports</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libps/ChangeLog">libps</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libshouldbeinlibc/ChangeLog">libshouldbeinlibc</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libstore/ChangeLog">libstore</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libthreads/ChangeLog">libthreads</A>, +<A HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/hurd/libtrivfs/ChangeLog">libtrivfs</A> +</UL> +<H4>GNU Mach</H4> +The <A +HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog">GNU +Mach ChangeLog</A> covers all changes to GNU Mach and <A +HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog?rev=1.128.2">GNU +Mach 1 branch ChangeLog</A> those on the <SAMP>gnumach-1-branch</SAMP>. +Changes before March 1997 are listed in <A +HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog.0">ChangeLog.0</A> +and <A +HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/gnumach/ChangeLog.00">ChangeLog.00</A>. +<H4>MIG</H4> +The <A +HREF="http://cvs.savannah.gnu.org/viewcvs/~checkout~/hurd/mig/ChangeLog">MIG ChangeLog</A> +covers all changes to MIG. 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!" |