FSSTND 1.0 FAQ, from ibiblio.org

-
 * Source: http://www.ibiblio.org/pub/Linux/docs/fsstnd/old/fsstnd-1.0/FSSTND-FAQ
 * Copyright status: not clear

This is a collection of Frequently Asked Questions (and answers!) about the Linux FSSTND project and document. It was composed by Ian McCloghrie . Questions, corrections, clarifications, etc. about this FAQ should be directed to him.

Mon Mar 14 13:56:28 PST 1994

Note: This FAQ is wrtten by me, personally, as an attempt to help out the FSSTND project. This FAQ reflects my personal views and, while I am a member of the FSSTND project, should not be construed as necessarily reflecting the views of everyone on the project.

General Questions
Q) Who wrote the FSSTND, and where can I get in contact with them?

A) The FSSTND is a consensus effort of many Linux activists; the main arm of their discussion takes place on the FSSTND mailing list. The principal co-ordinator is Daniel Quinlan . Any questions you may have regarding the standard should be directed to him or to any of the contributors listed in the FSSTND document or this FAQ.

The FSSTND discussion mailing list is "linux-fsstnd@ucsd.edu"; if you wish to participate in future expansion of the standard, you can subscribe to this list by sending mail to "listserv@ucsd.edu", with the body of "add linux-fsstnd".

Q) What's the current status of the FSSTND?

A) As of this writing, (Feb 21, 1994), Linux FSSTND 1.0 has been released, and is available for anonymous FTP from tsx-11.mit.edu in /pub/linux/docs/linux-standards/fsstnd PostScript, dvi, and ascii text versions are available.

The release of 1.0 does not mean that work on FSSTND has stopped, however. We are still discussing issues that were not deemed essential enough to be worth holding up the release of 1.0.

Q) Why 'FSSTND' anyway?  That's a horrible abbreviation.

A) Yes, 'FSSTND' is a horrible abbreviation of "Filesystem Standard". Unfortunately, that's the name that was given to the initial channel of the niksula.hut.fi mailing list, and it's kinda stuck.  Changing it would create more confusion than it's really worth.

Q) I've got a great new idea for how to organize the filesystem; why don't we...

A) If you really think you've got something revolutionary, by all means, we'd love to see it.  In practice, a lot of "great new" ideas have been raised (and dropped, for one reason or another) on the mailing list already.  As such, we suggest you send mail to one of the contributors privately first, and get his/her reaction to it, before making a general proposal.

Q) Why did you do it *THIS* way?  Why not do what Sun did and...

A) The FSSTND draws ideas from POSIX, 4.4BSD, SVR4, SunOS 4, MCC, Slackware, SLS, (in no particular order) and many other systems.  We have not followed any one operating system layout in entirety. Instead we have tried to take the best of each filesystem layout and combine them into a homogenous whole, well suited to the needs of Linux users everywhere.  In some cases, we may not have been completely successful; however, we think we've done a fairly decent job.

Q) You *&^% idiots, don't you know that foo goes in /bin, not in /usr/bin?

A) Think about it.  Does foo *really* need to go on the root partition?  Constructive suggestions are welcomed.  Flames are not.

We have tried to decide upon a set of binaries that is an effective compromised between functionality and space restrictions. The root partition needs to contain enough functionality to boot the system, mount the /usr partition, and to enable a systems administrator to repair things on /usr if something goes wrong. If you have a local boot-time system that absolutely requires other binaries to be used in the mounting of /usr, the suggested solution is to move them to /bin and to make a symbolic link from /usr/bin/foo to /bin/foo.

Specific Questions
Q) The distinction between the root partition and /usr is that the root is used for files that are 'essential'.  What constitutes 'essential'?

A) essential to clean, create, prepare, check, find and mount other filesystems (possibly on remote machines).  There are other definitions, but this is a general definition that most people will at least incorporate into their own.

Q) Why is networking spread out across the filesystem in 4 separate directories instead of all being nicely put in /usr/inet?

A) It is the opinion of the FSSTND project (and, in fact, of much of the UNIX community in general) that networking is not an "optional package" in the traditional sense, but rather an integrated part oF the operating system.  Binaries such as telnet, ftp, and ping have more similiarity to standard unix utilities such as grep, sed, and vi than to applications like emacs or WordStar.  As such, they are spread across /bin, /sbin, /usr/bin, and /usr/sbin, depending upon their use.

Q) I'm running a HUGE network with 10 different platforms and 20 different OS's.  I *need* to share things.  Why isn't there a /usr/share?

A) At the moment, Linux is only really available for the PC-architecture 80386 machines.  (although this may change soon with Amiga systems). There is no single existing "cross-platform" standard for /usr/share; those that do exist have usually been come up with by a single vendor wanting to share certain files between their OS running on multiple hardware platforms.  There are many problems involved in the sharing of files, maybe obvious sharable files that are, upon closer examination, not sharable at all.  (For example, /usr/man could be thought completely sharable, yet some pages (such as fsck.1) are completely different from any other UNIX-like operating system).

/usr/share would be nice, yes, and we plan to include something like this in a future version of the FSSTND. However, until such a time as an implementation can actually be tested, no specifications will be released. Anything in /usr/share will be "pointed to" by the use of symlinks from other areas in the filesystem, such as /usr/man, /usr/lib/, etc. Applications should use these locations when they reference files, not the /usr/share location, as this may change. Things like OSI have shown the problems with standards specified without a real clue as to how they'd be implemented.

Q) Why are there so many/so few symbolic links in the filesytem? Couldn't we make it easier to understand/more orthogonal by removing/adding some links?

A) In general, we've tried to minimize the number of symbolic links present in the FSSTND.  The symlinks that are present in the document are the ones we considered essential to maintaining a properly orthogonal, and yet still somewhat compatible, filesystem layout. /lib/cpp and /usr/lib/sendmail are symbolic links kept for compatiblity reasons.

Q) What about statically linked binaries?  Shouldn't we have a statically linked copy of mount, unmount, sh, cp, mv, vi, emacs, gcc, X11R5, and WABI in /sbin?

A) Statically linked binaries are a local issue.  Most users, those with home systems with small amounts of memory and disk and a single user on console, do not have any need for any statically linked binaries (with the possible exception of ln, sync, and/or ldconfig, to fix shared library problems).  Some larger sites, with more disk to spare, may wish to install backup, statically-linked versions of some applications.  If you have the need and space to do this, go right ahead, we're not stopping you.  But we don't require any, because (we feel) that most people don't need them.  Dynamically linked versions should still be available, for regular usage, however.

Q) Why does X11 get its own directory tree when there aren't any other such "packages" in the FSSTND?  Why not spread it out over /usr/bin/X11, /usr/lib/X11, etc.

A) X11 is just about the largest 'package' in common use on Linux systems.  It resides in /usr/X386 as this is the directory name choice of the XFree86 developers, to protect against namespace conflicts with other X11 packages on any of the dozen or so PC-unix platforms they support.  The symbolic links in /usr/bin/X11, /usr/lib/X11 and /usr/include/X11 are for user's convenience, these are the closest things that exist to "standard" locations for the X11 files.

Q) Why aren't the locations of home directories required in the standard?

A) On many linux systems, all home directories exist as /home/ .  This is fine for small home systems (and is what I, personally, would recommend for such a system).  For larger systems, where the number of users exceeds 50 or so, or in an NFS-environment, where different people have home directories on different machines, all cross-mounted, a simple scheme like this is woefully inadequate, and something more complex is required.  (As a side note, in such situations, automounter programs (like amd) are quite useful.) Applications should consult the password file (or $HOME) to determine a user's home directory, and not rely on a direct path.

Q) Why isn't there a package format laid out in the FSSTND?

A) Many proposals have been discussed for package layouts on the fsstnd mailing list.  As yet, no consensus has been reached about which (if any) of these proposals is best.  Work continues, and there will probably be mention of 'packages' in version 1.1.

Q) What about /usr/local/bin/X11?  Should I use this for local X11 programs?  Or is /usr/local/X11/bin better?

A) The standard doesn't specify; we feel that the contents of /usr/local are exactly that, local, and so we try to specify as little as possible about it.  Put them wherever you want.  Personally, I use /usr/local/bin/X11.  However, since xmkmf doesn't seem to like placing files into anywhere other than where the existing X files are (ie, /usr/X386/*), my libs for local apps usually end up being in /usr/X386.  Ugly, yes, but not worth (to me) the effort of trying to move them.  Your mileage may vary.

Q) Why doesn't the standard specify the system-level users/groups and proper ownerships/permissions/setuid bits for everything?

A) We feel that this is, primarily, a local issue.  Many sites have their own local user-id/group-id setup, and linux boxes will have to be integrated with those.  What's more, there is very little gain from standardizing these across all linux machines, as it typically is not essential to allow binary distributions.

Q) Why not just symlink /bin to /usr/bin the way Sun, SVR4, and a few others do?

A) This has several technical problems, aside from the fact that many consider it ugly.  First, it requires placing all the utilites necessary to mount /usr into /sbin, and either making copies of them in /usr/bin or having every user put /sbin into their $PATH.  Second, if /lib is symlinked to /usr/lib in the same way, it requires statically linking all the binaries in /sbin.  This results in /sbin taking up more space on the root partition, for a great reduction in functionality, thus increasing the number of cases in which one has to go dig out a boot/root floppy instead of just booting the hard disk in single-user mode.