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