[nycbug-talk] Cool read about history of /bin /usr/bin/

[Pete Wright]

On 3/27/12 7:23 AM, Edward Capriolo wrote:
> That is interesting.
> I typically do not mount volumes (especially nfs) off / because
> programs like slocate need to be configured to skip them. (I know FTW
> slocate but I use it) Since slocate dodges /mnt and a couple other
> places I use those.
good point - although i generally either disable locate, or restrict it 
to several well defined locations.  but there is def. merit working 
with-in a systems default configuration.

regarding NFS - if i'm using autofs which is usually the case - i'll 
have a specific directory tree off of / (say /nfs) then mount my 
external volumes off of there.  in these cases if i am investigating a 
nfs related issue i know i can usually safely avoid hung mounts by not 
looking inside /nfs.  it also makes it pretty clear what amd or autofs 
is managing - as i may have /{cifs,dfs,smb} volume, /afs on the same box :)
>
> I did not know the /mnt temporary deal. It seems that like /usr/bin
> and /bin I have gotten a standard from the wrong way I always see
> things.
>
> I see what you are saying about /var/log and /var/lib/db. Your points
> are well taken with two caveats. Linear log writes in /var/log
> appending usually does not competes with a database. If there is
> contention you are likely logging to much anyway.

well my thoughts regarding /var/log/ was that you may want to mount with 
the sync option for example, which may be detrimental to performance of 
a database.

regarding how i view /bin /usr/bin/ and /usr/local/bin these days is 
that /bin should be statically linked (or at the very least linked 
against /lib), /usr/bin/ is for software provided by base OS (*bsd 
userland, linux distro packages for example) and /usr/local/bin is for 
software i build and distribute in my own environment.  fortunately i've 
seen more and more external packages working towards this direction too.
>
> I do agree that you always want to isolate the IO across devices
> considering cost and power, however in reference to the /var/lib
> conversation packages need a sensible default to persist stuff on a
> single disk system. In that regard I think /var/lib//${something} is
> an acceptable choice so is /usr/local/${something}.

oh yea i agree - and i think that was one of the initial design choices 
of /var/ - (cf. /var/spool/) - i guess i'm just grumpy from having to 
repackage, and reconfigure, software that wants to put www-root in 
/var/lib for example :)

i should also say - one of the best things about unix systems is that 
the power is really put in the users hand, right?  so if for you 
/var/lib/$my_software is a logical location for a specific dataset - go 
for it!  :)

having said that - one of the good things about guidelines is that if 
people tend to follow those conventions, it makes life easier for admins 
working on new systems or when they have to port new software to 
existing systems.  i guess that was my original point i was trying to 
illustrate :)

-pete

-- 
Pete Wright
pete at nomadlogic.org
www.nomadlogic.org