Filesystem Hierarchy Standard (FHS) compliancy?

[James Ralston]

On Fri, 11 Aug 2000, Brandon Hume wrote:

> In MY experience, in *serious* deployments, a news machine does
> news, nothing else.

I would tend to agree.  Excepting extremely small installations, this
is the manner in which I have built all of my news machines, and the
manner in which I see most other machines built.

I don't see, however, why the fact that a machine is a "dedicated
service" machine should make the FHS superfluous.  I'd much rather
have a single, generalized FHS-style approach to the administration of
[n] machines, than having [n] different service machines, with [n]
completely different ways of "doing things".

> This is the first I've heard of this with regards to anything but
> Linux.  [...]  Which BSDs are actually doing this?

The beginning of the 2.1 FHS specification attributes the evolution of
the FHS (from the FSSTAND) as being a product of both the Linux and
BSD development community.  I interpret this (perhaps incorrectly) as
an indication that both communities endorse it and plan to implement
it.

In terms of Linux/*BSD distributions that are currently employing the
FHS, I honestly don't know.  I know that Red Hat is intending to make
7.0 FHS-compliant, but beyond that, I don't know any vendors'
particular timetables for conformity.

For the time being, I'll retract my statement about lumping *BSD with
the FHS.  (I suspect it'll happen eventually, but since I don't have
concrete information, I can't assert that with confidence.)

> That was my point!  Its nearly impossible to define what the "core"
> OS is with Linux.  Why should a mail server or web server, or
> graphics workstation, have INN installed at all - much less
> installed in FHS-sanctioned locations?

If that was your point, then I don't understand it.  The important
case isn't when INN is unnecessary, but when it is.  In that case, it
needs to go *somewhere*.  The FHS dictates as to where.

> Sun's inclusion of Perl in Solaris 8 places Perl in /usr/perl5, with
> only a couple of wrappers outside that base.

Actually, with Sun's track record, I'm surprised they didn't put it
in:

   /usr/dragged/into/the/mid-90s/kicking/and/screaming/perl5

;)

(And this is coming from a former Solaris snob, too.)

> And I find it ironic that /etc/<a>, /usr/lib/<a>, /usr/share/<a>,
> etc is somehow considered "easier" than /usr/local/<a>/*.

I find nothing ironic about consistency.  That is the raison d'etre of
the FHS.  I find nothing "easy" about dealing with [n] different
software packages, and having [n] different directory hierarchies to
remember.

> > components of INN where they belong and where currently competent
> > and future system administrators will look for and expect them."
> 
> I'd be careful with statements like this.  Since its already been
> stated by a few people here that your proposal is NOT where they
> expect the components of INN, you imply that they are not competent.
> A pretty cheeky risk to take, when at least one of those people is
> one of the core architects of INN itself.

You omitted from that quote Russ' equally cheeky statement to which I
responding (the "scattering INN to the winds" comment).  ;)

Besides, that particular subtopic was spawned by Russ' complaint that
he gets pestered with configuration questions from Red Hat
administrators who can't figure out where Red Hat put the config
files.  Honestly, I would doubt the competency of an "experienced" Red
Hat administrator who neither could intuit the FHS nor knew enough to
use "rpm -qc inn" to simply enumerate INN's config files.

> My thoughts are that this whole discussion is dangerously close to
> "Linux does it this way, therefore everyone should".  Which might
> just be me being excessively sensitive, since I've been in more than
> a couple of those arguments lately.

Actually, I think it's dangerously closer to "my method of system
administration is better than yours."  ;)

However, given that there seems to be very little (if any opposition)
to the slight restructuring of /usr/local/news that is necessary in
order to provide an easy way for an installer to choose to install
with FHS conformity, it seems to be a mostly moot point anyway...

(I debated just scrapping this message without sending it, but I just
didn't want to pass up an opportunity to say
/usr/dragged/into/the/mid-90s/kicking/and/screaming/perl5...)

James