lostecho/oldlinux-files
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

add directory docs

Browse Source
This commit is contained in:
gohigh
2024-02-19 00:23:35 -05:00
parent b50063d9b3
commit 9912ec445d
12689 changed files with 3135349 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

259
docs/linux-standards/fsstnd/old/FSSTND-FAQ Normal file
View File

@@ -0,0 +1,259 @@
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.