GNU vs. Linux FSSTND conflict?
Rick Niles
the Linux Filesystem Structure (FSSTND)?
I've heard on this newsgroup that the GNU std. is to elminate
the use of /usr. So:
/usr/include --> /include
/usr/bin --> /bin
/usr/local --> /local
etc.
I guess the first question is: Is this true?
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)
I could go either way myself, but I fear a conflict
could make life more difficult for everyone.
The following is quoted from the FSSTND:
-----------------------------------------
For several reasons, it is desirable
to keep the root filesystem small:
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.
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.
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.
--------------------------------------------
--
Rick Niles.
http://www.moscow.com/homepages/ni...@axp745.gsfc.nasa.gov.html
Michael I. Bushnell, p/BSG
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
Gord Matzigkeit
Hi!
>>>>> "mib" == Michael I Bushnell, p/BSG <m...@duality.gnu.ai.mit.edu> writes:
mib> In article <40l8od$i...@news4.digex.net> Rick Niles
mib> <ni...@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!
go...@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-----
Michael I. Bushnell, p/BSG
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
D. J. Bernstein
> 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.
``Scheme''? This isn't such a difficult problem.
Physical location:
/shared/dist/all/print-2.0/lpr.c, the lpr source code
/shared/syst/sunos-sun4/print-2.0/lpr, the compiled printing program
/shared/host/phoenix/print-2.0/lpd, the per-host printer spool directory
Virtual location:
/local/dist -> /local/dist/all
/local/syst -> /local/syst/sunos-sun4
/local/host -> /local/host/phoenix
A list of packages:
/shared/dist/all/*
Files in the print-2.0 package on this machine:
/local/*/print-2.0/*
Files in the print-2.0 package on all machines:
/shared/*/*/print-2.0/*
A sharing picture adequate for all of today's packages:
dist-----arch-----chip-
\ \ \
\ \ \
--oper-----syst-----kern-----host
syst is analogous to /usr under NFS; oper is mainly useful for packages
from the OS vendor; kern is analogous to /usr/kvm under NFS; arch refers
to machine language compatibility; chip takes CPU models into account;
dist and host are obvious.
---Dan
Michael I. Bushnell, p/BSG
Michael I. Bushnell, p/BSG <m...@duality.gnu.ai.mit.edu> wrote:
> 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.
Files in the print-2.0 package on this machine:
/local/*/print-2.0/*
Files in the print-2.0 package on all machines:
/shared/*/*/print-2.0/*
Whoops, here's the lose. These are not, in fact, filenames, shell
syntax not withstanding.
We want a scheme where there is a directory which holds the entire
print-2.0 distribution, for easy deletion and examination. So
something similar to your scheme is what is planned, with an
additional hook to satisy this need.
One cool bit will be similar to what (I'm told) Nextstep does: each
executable will also be a directory holding all the files that
executable needs; this will be accessible to the executable in some
trivial fashion.
One of the nice thing about shadow translators is that we can make all
these views completely real and independantly operable. The maze of
symlinks strategy does not work well, because it is difficult to
actually delete things--it's too easy to just delete the symlinks, or
only some of the symlinks, or something like that.
Michael
D. J. Bernstein
> The maze of
> symlinks strategy does not work well,
``Maze of symlinks''? Did you even read what I wrote?
All files are physically stored in /shared.
There is ONE symlink directory on each host, /local. It has seven links:
dist arch chip oper syst kern host. Example: dist -> /shared/dist/all.
That's a ``maze''?
/shared is organized in a way that lets you trivially split up the files
by host or system or CPU or whatever. It is also organized by package:
rm -rf /shared/*/*/print-2.0 will remove the entire print-2.0 package.
The point of /local is to supply a host-independent path for files that
are actually host-dependent or system-dependent or CPU-dependent. For
example, /local/syst is analogous to /usr under NFS, and /local/kern is
analogous to /usr/kvm under NFS.
> /shared/*/*/print-2.0/*
> Whoops, here's the lose. These are not, in fact, filenames, shell
> syntax not withstanding.
Sure they are. Which part of the system didn't you understand?
> We want a scheme where there is a directory which holds the entire
> print-2.0 distribution, for easy deletion and examination.
If you want to see all print-2.0 files relevant to your host, look in
/local/*/print-2.0.
If you want to see all print-2.0 files for all hosts, look in
/shared/*/*/print-2.0.
You can see the original distribution in /local/dist/print-2.0.
The (system-dependent) compiled programs are in /local/syst/print-2.0.
If you want to see the compiled programs for _all_ systems, look in
/shared/syst/*/print-2.0.
What else do you want to do?
By the way, here are three principles that make it easy to see how files
should be organized: 1. Have mercy on the designer. 2. Have mercy on the
sysadmin. 3. Have mercy on the user.
Have mercy on the designer: Programs should be able to locate data files
easily. Packages shouldn't have to know much about installation.
Packages should be able to take advantage of your file organization
without _requiring_ it.
Have mercy on the sysadmin: Packages should not be spread through the
filesystem. Package installation should be safe and reliable. It should
be easy to completely remove a package. Files in a package should have
appropriate permissions for a multiuser machine. After a package is
installed, it should be easy to remove all automatically generated files
that the users don't need. It should even be possible to remove all
source files that the users don't need. Packages should be shared among
machines as much as possible. Third parties should be able to supply
packages. Vendors should be able to supply packages as part of the
operating system. It should be easy to install a package designed
without knowledge of your file organization.
Have mercy on the user: Packages should have a uniform namespace. It
should be easy to find documentation for installed files.
How many of these goals does your ``scheme'' satisfy?
---Dan
Russell Nelson
All files are physically stored in /shared.
There is ONE symlink directory on each host, /local. It has seven links:
dist arch chip oper syst kern host. Example: dist -> /shared/dist/all.
[...]
By the way, here are three principles that make it easy to see how files
should be organized: 1. Have mercy on the designer. 2. Have mercy on the
sysadmin. 3. Have mercy on the user.
Gosh, sounds pretty damn sensible to me. A lot better than
/usr/lib/aliases, /etc/bootptab, /usr/man/pifflebif, /usr/doc/lilo,
/usr/lib/<package>, /usr/local/lib/<package>, /usr/local/public/lib/<package>,
etcetcetcetcetcetc.
Yes, it blows away most Unix administration books. So what? G-N-U.
The whole point is not to be as bad, but instead to be just as good.
--
-russ <nel...@crynwr.com> http://www.crynwr.com/~nelson
Crynwr Software | Crynwr Software sells packet driver support | PGP ok
11 Grant St. | +1 315 268 1925 (9201 FAX) | America is not a Christian, Jewish,
Potsdam, NY 13676 | Islamic, Buddhist, nor pagan nation. This is a good thing.
Michael I. Bushnell, p/BSG
Apparantly I said something that upset D. J. Bernstein. Sorry.
I said "scheme", and he suggested that the (sight-unseen) scheme I
referred to must be grotesquely complex. In fact, it's quite similar
to his. Not identical, but who cares?
His post said something like "why is a scheme required? all I do is
XXX". Of course, XXX was his scheme...that's why a scheme is
required. A scheme is a plan, a design, thought out, which doesn't
just happen by accident. The way things are now is the result of not
having a scheme. D. J. Bernstein and I will surely agree about the
need for a scheme.
Dan pointed out three requirements; I agree with all of them, and the
scheme rms and I worked out meets them, and isn't any more complex
than the one Dan worked out.
So what is there to fight about? Why all the harsh words?
Michael
D. J. Bernstein
Sorry. ``Maze of symlinks'' struck me as a bit extreme.
I'm curious to know how your approach differs from mine; we may see that
in some details one solution is clearly better than the other.
Beyond the question of where to put files there's the question of how to
manage them. I have conventions for several (optional) file lists, along
the lines of Makefile or MANIFEST: ATTRIBUTES lists important permission
information like ``dist script.sh executable'' or ``host safedir
unreadable''; DISPOSABLE lists source files that the users don't need;
TEMPORARY lists automatically generated files that the users don't need;
CRITICAL lists files that the users do need; SOURCE lists source files.
A package has to be able to find itself. The sysadmin can choose his own
names for the top-level directory (/local) and the individual packages
(e.g., print-2.0); the designer shouldn't have any control over this.
The unpacking/installation support program uses environment variables to
communicate these names to the package. This means that the sysadmin has
to type the package name exactly once during installation.
---Dan
Rick Niles
What's wrong with you! Don't you believe in the Internet!
Being horriable to one another is the whole purpose.
You must be a total loser if you don't know that.
--------
My comentary above was complete silly and a waste of bandwidth. :)
(Please flame me)
Michael I. Bushnell, p/BSG
> So what is there to fight about? Why all the harsh words?
Sorry. ``Maze of symlinks'' struck me as a bit extreme.
I'm curious to know how your approach differs from mine; we may see that
in some details one solution is clearly better than the other.
Mine integrates with other features of the Hurd, like making all the
binaries appear in /bin, all the libraries in /lib, etc. Mine will
also have the Next-step hack of having all the auxiliary files
associated with a program be in a directory that has the same name as
the executable. We will use shadow translators to make more of it
automatic for system administrators.
Beyond the question of where to put files there's the question of how to
manage them. I have conventions for several (optional) file lists, along
the lines of Makefile or MANIFEST: ATTRIBUTES lists important permission
information like ``dist script.sh executable'' or ``host safedir
unreadable''; DISPOSABLE lists source files that the users don't need;
TEMPORARY lists automatically generated files that the users don't need;
CRITICAL lists files that the users do need; SOURCE lists source files.
We don't do that; instead we have a variety of clean targets in any
GNU standard Makefile.
A package has to be able to find itself. The sysadmin can choose his own
names for the top-level directory (/local) and the individual packages
(e.g., print-2.0); the designer shouldn't have any control over this.
The unpacking/installation support program uses environment variables to
communicate these names to the package. This means that the sysadmin has
to type the package name exactly once during installation.
Yes; the GNU coding standards already provide for this.
Michael
Steven Bjork
>Mine integrates with other features of the Hurd, like making all the
>binaries appear in /bin, all the libraries in /lib, etc. Mine will
Steven replies:
Brrrr... I tend to want a package to be isolated from the OS
in its own little playground. For instance, I don't scatter
X11R6 all around my filesystem, with part in /usr/lib part in
/usr/bin etc. I have a R6 dir, with R6/bin, R6/lib etc.
Isn't this a matter for the sysadmins and not the software developers?
../Steven
hate the programmers, not the computer
Gord Matzigkeit
Hi!
>>>>> In article <41vsl4$d...@bug.rahul.net>, Steven Bjork
>>>>> <bj...@rahul.net> writes:
SB> [someone wrote:]
[someone being Michael Bushnell... the biggest of the big Hurd people]
>> Mine integrates with other features of the Hurd, like making all
>> the binaries appear in /bin, all the libraries in /lib, etc. Mine
>> will
SB> Steven replies:
SB> Brrrr... I tend to want a package to be isolated from the OS in
SB> its own little playground. For instance, I don't scatter X11R6
SB> all around my filesystem, with part in /usr/lib part in /usr/bin
SB> etc. I have a R6 dir, with R6/bin, R6/lib etc.
If you go back in the thread, you'll see that with the use of shadow
translators, as mib proposes, all three (or more) paradigms are
satisfied.
Err... I'm just begging for a black eye, here, but another part of the
earlier thread was a discussion of the abolition of the /usr
partition. Check out the URL below, for details.
You can look in /lib for all the libraries on the system, or you can
look in /package/X11R6/lib for the libraries relevant to X11 (note:
/package is my own invention: think nothing of the name), or you can
look in /disk/bartok.enci.ucalgary.ca/* for all the files exported
from bartok, or however else you want to collapse your filesystems.
SB> Isn't this a matter for the sysadmins and not the software
SB> developers?
Yup. There's nothing forcing you to use the scheme, but I think
you'll want to when you understand how superior it is. Honestly. All
mib is doing is giving a suggestion for a creative use of the shadowfs
(which will be the default setup, I hope/suspect).
I think that what mib is proposing is exactly what you want. Why, oh
why, would you ever want a PATH like:
PATH=~/bin:/package/X11R6/bin:/package/emacs-19.29/bin:/package....
when:
PATH=~/bin:/bin
suffices?
Under shadow translators, you can always look in
/package/emacs-19.29/bin when you really need to see which files are
part of the emacs distribution.
Let's not belabour the point. Michael says that his (and RMS's)
scheme works. I'll trust his word that it does, and eagerly
anticipate it. :)
Please see:
<URL:http://www.cs.pdx.edu/~trent/gnu/hurd/hurd-fs-org>
for the previous few articles. Of course, visit:
<URL:http://www.cs.pdx.edu/~trent/gnu/hurd/>
for more general information on the Hurd.
- --Gordon
- --
Gordon Matzigkeit | Heck, it was only a TOASTER... lighten up!
go...@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
iQCVAwUBMEOG9SFsfCEzmr65AQFF3gP/ddLRxyRPEBHVv2FcFxHrSNQK+9y/L0U/
lWMKKpG7bLtQ4Z5AUzfBvlVWxH44sVB2XJ7NlzaiowFT3Ak7gzqKsQS6wufozCMC
DMXJRVtdD8EAX22Zzptc3QgdUzHx77ROpfU1JREgoM+/55aEqPGf563FZ9UOdhGz
Whqcv5uTgQE=
=87Rc
-----END PGP SIGNATURE-----