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.