*tap* *tap* *tap*

[Dennis J.]

On 09/01/2010 12:02 AM, Leam Hall wrote:
>
>
> On 08/31/2010 05:02 PM, Dennis J. wrote:
>> On 08/31/2010 10:34 PM, Leam Hall wrote:
>>>>> 2. Application packages that installed in FHS compliant application
>>>>> filesystems vice OS filesystems. For example, apachectl should not be in
>>>>> /usr/sbin but /opt/httpd/sbin or something similar. Logs should go in
>>>>> /opt/httpd/logs.
>>>>
>>>> Um, no. There are reasons why we don't package anything in /opt.
>>>
>>> Compared to /usr? I've not found a single one. Anything that the server
>>> must have to boot, care for itself, and let you log in and edit config
>>> files should be in /bin:/sbin:/usr/bin:/usr/sbin. Everything else goes
>>> in /opt. The point being that /opt is a seperate filesystem and you can
>>> unmount it, fsck it, and do whatever with it without taking down the server.
>>
>> Why are you trying to reinvent /usr and just call it /opt? The whole point
>> of dividing the path in (s)bin and /usr/(s)bin is so that (s)bin contains
>> "anything that the server must have to boot" and that /usr can be "a
>> seperate filesystem" and you can "unmount it, fsck it, and do whatever with
>> it without taking down the server".
>>
>> Also storing a application and all its data in /opt/<app>   defeats the
>> purpose of separating the two in /usr and /var.
>>
>> Have you previously been working in a Windows environment because you don't
>> seem to have any understanding of the filesystem layout on linux and why
>> the things are the way they are.
>>
>> I'm all for constructive change but what you are describing sounds like a
>> nightmare to me and would probably make Fedora Server unusable for most admins.
>>
>> Regards,
>>      Dennis
>
> Dennis,
>
> I have been working with Linux and some Unix versions for a bit. There
> is a differnce between "things the server needs to run" that go in /usr
> and "applications the server hosts" that go in /opt.
>
> Historically Linux stuff went into /usr/local, defined as local stuff
> for that environment/server/whatever. If we're putting together packages
> then they are by definition not local to that specific server or
> environment. However, things like apache don't go in /usr. Just because
> Linux does it doesn't mean the rest of the Unix version follow suit.
> Since I have worked in a mixed environment for a while I tend to find
> better work happening when things are reasonably similar.

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