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. --- unsorted/hurd-fs-org | 219 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 219 insertions(+) create mode 100644 unsorted/hurd-fs-org (limited to 'unsorted/hurd-fs-org') 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 -- cgit v1.2.3