Drew wrote:
>> Not quite. It is more a matter of a standard only being useful if
>> everyone does what it says. Picking a new location that no one
>> currently uses is always the worst possible choice.
>
> So are revolutions but those seem to work well on occasion. :-)
Only for the survivors.
>>> My argument is that those same Unix admins no doubt placed it there
>>> because it made functional sense at the time.
>> It is not a functional thing. It's a name.
>
> A name is a way to for a person to remember an object or a concept.
Yes, and once they have been established it is simply confusing to
invent a bunch of new terms for the same things.
> Names can then be arranged and organized. How names are organized is
> important in the context of how and where the users and admins
> interact with them.
Yes, but keep in mind that these same users and admins are very likely
to interact with systems that are not Linux and LSB compliant also.
> It may not make a functional difference to apache
> that the website resides in /srv/www instead of /var/www but it may
> matter to the admin that client facing data stays away from machine
> files.
The name of the place they stay is irrelevant. And it's still not clear
what you mean by a client, or how one piece of data is different from
another.
>> Aren't all files 'client facing' if the machine has a purpose? What
>> other reason would you have for any files?
>
> How about performance logs, access logs, and audit logs?
How about them? If I want to access them through a web interface, does
that make me a client? How is it different than using ssh and cat?
> All of which
> are stuff you would put in /var and I'm sure we can agree you wouldn't
> want the client to see those until they've been processed. So not
> everything faces the client.
What kind of server these days doesn't process everything before
displaying it? Besides, am I not a client? Does a web service have to
serve different people than other kinds of services? How does the type
of service relate to the type of data involved? Yes, I want ways to
isolate different users and groups of users, but it is very likely that
I'll want the same service protocols serving different sets and the
categories won't fit neatly under something a committee makes up.
>>> I agree with you on standardizing libraries but I fail to see how that
>>> has any relevance to where an admin should place their client facing
>>> files.
>> Standardizing libraries would be a functional reason to embrace the LSB.
>> Otherwise it makes about as much sense as having a committee make up
>> new names for your kids. If mount points and volume sizes were also
>> standardized, it might be reasonable to standardize what goes where, but
>> they aren't and shouldn't be because the machines will differ in size
>> and purpose.
>
> I don't think you're understanding my argument here. I'm not arguing
> against library standardization, in fact I'm for it, nor am I arguing
> about the purpose of the LSB. What I am trying to ask is what
> relevance does the LSB's existence and/or library standardization have
> to do with the FHS, and specifically the /srv folder?
OK, so what relevance does /srv have? What works after you go to the
trouble of moving things to this new location that didn't work exactly
the same way wherever you had it before?
> As far as I'm
> concerned the FHS could have been written by RedHat, IBM, or Oracle
> and would in no way impact discussing the relevance of the /srv
> folder.
It doesn't have any relevance by itself. Things will work if you put
them under /srv. They will work if you don't put them there. What's to
discuss about it? What we do need in package-oriented distributions are
places that are clearly out of scope for package installations, and it
would be sort-of nice if 3rd party repos had non-conflicting locations
for each to drop potentially conflicting items. But the committee
didn't address the stuff we actually need.
--
Les Mikesell
lesmikesell@xxxxxxxxx
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
