260 lines
12 KiB
Plaintext
260 lines
12 KiB
Plaintext
This is a collection of Frequently Asked Questions (and answers!)
|
|
about the Linux FSSTND project and document. It was composed by Ian
|
|
McCloghrie <ian@ucsd.edu>. Questions, corrections, clarifications,
|
|
etc. about this FAQ should be directed to him.
|
|
|
|
Sun Oct 9 22:55:25 PDT 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 <Daniel.Quinaln@linux.org>
|
|
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, (Oct 9, 1994), Linux FSSTND 1.2 has been
|
|
released as an interim draft, 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.
|
|
|
|
Due to the fact that a significant number of Linux developers are
|
|
making use of standard drafts that came after the first version (back
|
|
in February), the decision was made to issue an interim version in
|
|
order to ensure that everyone is working from the same foundation.
|
|
|
|
|
|
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.
|
|
|
|
|
|
Q) Does the fact that Daniel Quinlan now works for Yggdrasil affect
|
|
his coordination of the FSSTND?
|
|
|
|
A) In short, no. In a bit more length, no, except for the fact that
|
|
he's now even more intimately familiar with the problems involved
|
|
in creating a distribution. (well, and that he's earning money and
|
|
can afford to buy food to eat, so has energy to spare worrying about
|
|
things like which directory cpio belongs in)
|
|
|
|
FSSTND is not distribution-specific, the fact that the coordinator is
|
|
employed by one distribution-provider does not affect this fact. Yggdrasil
|
|
does not have any special connection to FSSTND, and vice versa.
|
|
To simplify things, Dan would appreciate it if you could direct FSSTND-
|
|
related email to <Daniel.Quinlan@linux.org>.
|
|
|
|
|
|
========== 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) I like to have a small root partition (possibly with multiple
|
|
copies, so I can get the system back up when one of them crashes),
|
|
and I like to stuff everything else into one big partition (especially
|
|
since I only have one free). So, can /var be a symlink to /usr?
|
|
|
|
A) Making the /var hierarchy a part of a /usr filesystem is
|
|
preferable to making /var a part of the root filesystem when /var
|
|
cannot be made a separate partition.
|
|
|
|
This is preferable because it is easier to separate /var and /usr
|
|
at some point in the future, if you buy a second disk. The usual way
|
|
of doing this to make /var a symblink link to /usr/var.
|
|
|
|
|
|
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/<something>, 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 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.
|
|
|