From ef7f0326b971806ce9061a71cd1874b7e0c279d0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 12:37:49 +0100 Subject: Three more documents I don't know what to do with. --- byte-letter.txt | 25 ------ hurd-fs-org | 219 ----------------------------------------------- hurd-migr | 141 ------------------------------ unsorted/byte-letter.txt | 25 ++++++ unsorted/hurd-fs-org | 219 +++++++++++++++++++++++++++++++++++++++++++++++ unsorted/hurd-migr | 141 ++++++++++++++++++++++++++++++ 6 files changed, 385 insertions(+), 385 deletions(-) delete mode 100644 byte-letter.txt delete mode 100644 hurd-fs-org delete mode 100644 hurd-migr create mode 100644 unsorted/byte-letter.txt create mode 100644 unsorted/hurd-fs-org create mode 100644 unsorted/hurd-migr diff --git a/byte-letter.txt b/byte-letter.txt deleted file mode 100644 index 20fa61a0..00000000 --- a/byte-letter.txt +++ /dev/null @@ -1,25 +0,0 @@ -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-fs-org b/hurd-fs-org deleted file mode 100644 index ba515623..00000000 --- a/hurd-fs-org +++ /dev/null @@ -1,219 +0,0 @@ -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 - 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 writes: - - mib> In article <40l8od$ia9@news4.digex.net> Rick Niles - mib> 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 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 deleted file mode 100644 index ce36c86c..00000000 --- a/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: -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: -References: -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@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: -References: - -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@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: \ "Forget Artificial Intelligence, -Motto: "I'll live forever or die trying" \ I want the real thing!" 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 + 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 writes: + + mib> In article <40l8od$ia9@news4.digex.net> Rick Niles + mib> 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 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: +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: +References: +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@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: +References: + +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@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: \ "Forget Artificial Intelligence, +Motto: "I'll live forever or die trying" \ I want the real thing!" -- cgit v1.2.3