Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Apr 2001 02:28:30 -0500
From:      Andrew Hesford <ajh3@chmod.ath.cx>
To:        "Albert D. Cahalan" <acahalan@cs.uml.edu>
Cc:        matt@fear.net, freebsd-questions@FreeBSD.ORG
Subject:   Re: How Is The FeeBSD OS Like and Different Than Say Redhat or Suse LINUX
Message-ID:  <20010424022830.A6085@cec.wustl.edu>
In-Reply-To: <200104240533.f3O5Xr304341@saturn.cs.uml.edu>; from acahalan@cs.uml.edu on Tue, Apr 24, 2001 at 01:33:54AM -0400
References:  <200104240533.f3O5Xr304341@saturn.cs.uml.edu>

next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, Apr 24, 2001 at 01:33:54AM -0400, Albert D. Cahalan wrote:
> 
> Thomas (Matt) Barton writes:
> 
> > Another great thing about the ports collection is that everything
> > gets installed in /usr/local.  I don't have to worry about /etc
> > getting cluttered, as well as /bin, /usr/sbin, etc.  There are a
> > few exceptions, of course, such as qmail which goes to /var/qmail,
> > but that is about it.
> 
> Every FHS-compliant Linux distribution reserves /usr/local
> for _you_ to use. It is for _local_ stuff only.
> 
> Doesn't this make sense? If you compile a home-grown or self-ported
> app for FreeBSD, where would you put it? I hope you don't dump it
> in /usr/local with all the stuff provided by FreeBSD! It looks like
> you need a /usr/local/local or /usr/local_I_REALLY_MEAN_IT for this.
> 
> Putting emacs under /usr/local is a relic from the days when
> you'd buy a real UNIX system without emacs. It made sense,
> since you were installing local (your site) additions. Now you
> get emacs on a CD-ROM along with the rest of your OS.
> 
> Why worry about /etc becoming "cluttered" anyway? You only push
> the problem into another location. Now /usr/local/etc is cluttered.
> If you simply want to cut the "/bin/ls" output in half, then you
> might do better with /1/etc /2/etc /3/etc... but why at all?
> If performance is a problem, work on the filesystem. If being hard
> to glance over is a problem, you don't gain anything by having
> more places for junk to collect.

No, the FHS doesn't reserve /usr/local for _you_ to use. It reserves
/usr/local for site-specific programs. You illustrate the ass-backwards
mentality that linux subscribes to, dumping every package into /usr. So
now, forced by foolishness into a lesson of what "site-specific" means,
here we go:

"Site-specific" means, quite simply, software that is individually
selected, and varies from system to system. This naturally includes
stuff you build, but it also includes stuff you install from packages.
It is important to note that "locally compiled" and "site-specific" are
NOT the same thing. This is where linux distributions, like RedHat and
Debian, seem to be confused. We know what comprises "locally compiled"
software, but what about "site-specific"? To demonstrate this, first
look at the complement of "site-specific": "site-inspecific".

Site-inspecific software is not software that "feels" like it is fairly
standard, and it is not what you and your buddies agree is universal. It
is software that is installed in the vast majority of systems of the
same type (in this case, FreeBSD). We will call this the "base system",
and in order to ensure that it is installed in the vast majority of
systems, it must be that this software must be explicitly removed if it
is not wanted.

The FreeBSD base (all the stuff in /usr/src) satisfies this condition.
When you install FreeBSD, all those programs are on your system. If you
don't want some of them, you must explicitly remove them by adding
entries to /etc/make.conf, and manually removing the files associated
with the programs you do not want. This means the FreeBSD base is
site-inspecific, which means it is not site-specific (the two are
mutually exclusive), so it does not belong in /usr/local. This is why
/usr/src programs install in / and /usr.

Packages, on the other hand, vary from system to system. Whether they
are compiled locally or by somebody else, they are site-specific, since
they are not located on the vast majority of systems. For instance, the
presence of GNOME or KDE can vary from system to system. I have GNOME
because I need it to run gnucash. If I didn't have gnucash, I wouldn't
have GNOME. I do not have KDE. Either way, these programs belong in
/usr/local, because they are not a part of the site-inspecific system.
Neither is gnucash; consequently, it belongs in /usr/local.

You will notice that vi is in /usr/bin. This is in the /usr/src tree and
is installed on every system unless manually removed. However, its
cousin vim may not be present on all systems (and must be explicitly
selected), and so vim goes into /usr/local/bin. I do not have emacs, and
you can bet a great deal of vim users don't keep emacs around. This is
why emacs goes in /usr/local: not because it has historically been put
there, but because it is site-specific.

Of course, even if you do take the ridiculous position that only
self-compiled programs belong in /usr/local, remember that every port is
locally compiled. Hence everything except the stuff in /usr/src belongs
in /usr/local by your own standard. The prebuilt packages are simply a
drop-in replacement for ports; it would be an administration nightmare
if locally-compiled ports were intalled in a different location than the
packages built from the ports tree.

That being said, I can tell you exactly why this poor placement practice
has been effected in the linux world. The answer is that linux has no
real base system. Pretty much the only thing you can count on between
distributions is the kernel, and the GNU file utilities. In fact, this
is just about all the Debian distribution leaves you with after install,
if you choose not to select packages. The result is that Debian's base
is about 20M, consisting of basic file utilities, a kernel, and the
necessary tools to install more packages. It would seem foolish to have
/usr populated with <20M worth of programs; hence they dump all packages
into /usr, and say /usr/local is reserved for self-built programs.


No reasonable mind can confuse "site-specific" with "locally-compiled".
What we see here is a practice of dumping everything in /usr because
linux distributions have no consistent base, and ad hoc explanation for
this practice to put people at ease. Over the years this practice has
been implemented, people have been brainwashed into thinking this is a
logical way of organizing a filesystem, but the truth is, where
everything is largely package-based as it is in Debian, the result is
virtually all programs are stored in /usr and almost nothing is kept in
/usr/local. This is highly disorganized. In this respect, it can be said
that FreeBSD follows the Linux Filesystem Standard better than any linux
distribution!

Before you attack me or try to explain the reasoning behind this lack of
organization, do take the time to consider:

1) /usr/local is reserved for site-specific software.
2) Everything in the ports tree (and the packages that represent ports)
qualifies as site-specific by any stretch of the imagination.
3) The Linux Filesystem Standard makes no provsion for self-compiled
software.

NOTE: FHS 2.1 states that /usr/local "is for use by the system
administrator when installing software locally." This does NOT mean
locally compiled (or else they would have said "compiled"), but instead
has the same meaning as site-specific. /usr/local must be protected from
overwriting when the system software is updated. For FreeBSD, this is
then everything not found in /usr/src, since /usr/src is the source for
the "system software", and is the only software updated during a system
update (make world). Hence the FreeBSD organization is logical even by
this consideration alone. It is equally logical for linux distributions
to store everything in /usr, then, because nobody has any idea where the
linux "system" ends and local software begins. 

The final result is that either way you look at it, the FreeBSD
organization is intelligent and logical. For linux, the virtue of
organization depends on how you look at /usr/local. If you follow the
FHS word-for-word, then linux does a reasonable job by virtue of its
lack of division between site-specific software and base software. If
you follow a reasonable definition of site-specific, linux is
ass-backwards.

--
Andrew Hesford
ajh3@chmod.ath.cx

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-questions" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20010424022830.A6085>