*tap* *tap* *tap*

[Dennis J.]

On 09/01/2010 02:24 AM, Leam Hall wrote:
> 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.
>>
>> Regards,
>>      Dennis
>
>
> Dennis,
>
> 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.

Virtually all Linux distributions keep the applications in /usr and that 
makes it pretty much the convention. Unless you want to suggest that the 
server version of Fedora should stop being Linux and adopt the convention 
used elsewhere.

> Seperate the server from what it serves. We should be able to totally
> keep the application unconcerned about the base OS.

That's not really possible unless you suggest that each application should 
be compiled and packed with their own copies of all dependencies which 
would be a maintenance nightmare. If they are linked to their dependencies 
in the "base OS" then the application by definition can no longer be 
unconcerned about the bast OS.

 > Maintaining them
> intermingled as they are now makes support that much more difficult.

I don't really see that difficulty.

> 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.

Why don't you have to worry about filesystem space consumption? You can 
create separate filesystems right now for /usr, /var, /home, etc. as well 
and don't have to worry about this either. Putting the applications 
elsewhere doesn't change this at all and if a filesystems is full then it 
is full regardless how you shuffle around the files.

> Yes, I realize the drift Linux people have made over the years will take
> some work to fix.

No fixing necessary.

> 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.

So Red Hat has been wasting time all these years with RHEL because they've 
been doing it wrong the whole time?

What you are asking for is a complete overhaul of the entire system that 
would make it mostly completely incompatible with everything else that 
calls itself Linux out there. You'll have to come up with a pretty 
rock-solid and extensive rationale before this is worth considering.

Regards,
   Dennis