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

Charles Sprickman spork at bway.net
Tue Mar 27 11:08:08 EDT 2012


On Mar 27, 2012, at 10:51 AM, Pete Wright wrote:

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

Just for reference, that's /etc/locate.rc, and the stock file has the following:

# directories unwanted in output
#PRUNEPATHS="/tmp /usr/tmp /var/tmp /var/db/portsnap"

> 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 :)

Semi-hijack…  I recently decided that I trust nfs enough to mount a few things at boot, and at the same time I started thinking about whether I should mount all the nfs stuff under one directory and then symlink in.  Oddly enough, I decided on /nfs.  Any comments on the wisdom of that are welcome.  I have the following mount options:

rw,bg,failok,soft,intr

"bg" can cause some funniness it seems, but this config results in a maximum boot delay of 2 minutes if the nfs server is unreachable (tried in vmware with the host totally down as well as up, but without nfs/portmap/mountd stopped).

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

I'm quite partial to "/var/db/pgsql|mysql".  It makes sense (to me) and everywhere I work this seems to lead to no confusion amongst the folks working on these hosts.  The "/var/lib" thing really stumps me.  I can think of no sound logic to explain why databases would live under a directory called "lib" - traditionally a directory named "lib" would contain… libraries.  Crazy stuff.

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

Thank goodness.  The /usr/local separation makes it easy for someone unfamiliar with a box to find what's been added beyond the base OS (if your OS has a "base").

>> 
>> 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 :)

Can't start talking about software developed only for one specific free unix-like OS.  It hurts.

Charles

> 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
> 
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> http://lists.nycbug.org/mailman/listinfo/talk

--
Charles Sprickman
NetEng/SysAdmin
Bway.net - New York's Best Internet www.bway.net
spork at bway.net - 212.982.9800




More information about the talk mailing list