*tap* *tap* *tap*
leam at reuel.net
Wed Sep 1 00:24:30 UTC 2010
On 08/31/2010 07:19 PM, Dennis J. wrote:
> On 09/01/2010 12:02 AM, Leam Hall wrote:
<snip for brevity>
> But /usr/local isn't the same as /usr. /usr tended to be mounted remotely
> using NFS on some sites which was also the reason why the split of /(s)bin
> and /usr/(s)bin was necessary. That way if /usr wasn't available because of
> e.g. network issues you still had all the basic tools available in /(s)bin
> to perform maintenance. So /usr pretty much handles the split between the
> core and the rest of the system already.
> The additional feature you propose is to contain the applications and their
> data in their own directory under /opt. I don't really see much of an
> advantage to this especially since you break virtually every tool under the
> sun that assumes the standard layout of the filesystem. If you really have
> the time as an admin to deal with such a system that so completely deviates
> from the name then consider yourself lucky but I will go on record that I
> don't have any aspirations to buy into something like this and I'm pretty
> sure I'm not the only one.
> Given the lack of manpower to accomplish the goals of this SIG I doubt that
> throwing all conventions over board will make things easier for this project.
Fedora curently steps outside of convention. What I'm advocating is
returning to them. You're right that the /usr filesystem is somewhat
less critical to server boot and control that /bin and /sbin. However.
the applications that the server hosts, like apache and sendmail, should
not be there.
Seperate the server from what it serves. We should be able to totally
keep the application unconcerned about the base OS. Maintaining them
intermingled as they are now makes support that much more difficult.
With isolation you don't have to worry about filesystem space
consumption, about changing the OS packages and hoping the upgrade
didn't whack the application's files anywhere, or about trying to
recover from a bad crash and remembering what all goes where at 3AM.
Yes, I realize the drift Linux people have made over the years will take
some work to fix. However, we're still looking to be FHS compliant and I
think that's a good thing. Whether or not it's doable with the people
who are or will be involved, I don't know. However, I'm fairly confident
that if we don't try to really do things right it'll be a waste of time
no matter how much we try.
More information about the server