ACPI administration advocacy advocacy advocacy opinion alsa amarok apache apple apt aptitude audio audo authentication automount avi awk bash BIOS boot business cache calendar calibre cdr cdrecord censorship commandline computerscience console convert cron cut database date debian degree design desktop development disk dpkg dvd economics education emacs email europe exim faad ffmpeg file files firefox firewall flash foss freedom ftp fun fuse git gnumeric graphics grep growisofs grub gtkpod hardware hardware html idiocy image imagemagick images installation ip iphone ipod iptables iso itunes ivman kde kernel keyboard knoppix lame laptop latex linux locale lockin longlines m4a microsoft mimetypes minitab mount mp3 mp4 mplayer multimedia music mysql network nfs nfs4 nmap openbox openoffice opinion opinion partition pdf perl php politics postgresql printing privacy programming rant remote rhythmbox rss rsync rxvt scp screengrab screenshot script scripting scsi security sed server shell siteadmin sitenews sitesoftware skype skype slackware sound sox spam spreadsheet ssh statistics subversion sudo svk swap t23 t43 terminal text thinkpad thunderbird time timezone ubuntu udev upgrade usb usbmount users uuid versioncontrol vfat video vnc windows wine wordpress wordprocessing X40 xwindows xwindows youtube
There is a fantastic article on the Hive Logic Narrative about using /usr/local/.
The FHS defines the /usr/local as the “tertiary hierarchy for local data installed by the system administrator.” Translated into English, this means put apps you build yourself here.
Think of /usr/local as a “safe haven” for command-line, open source, and similar utilities and programs you download or build yourself. Just like Santiago in A Few Good Men ... it is not to be touched.
Using the /usr/local folder as the destination when compiling and installing command-line software (such as Ruby, Rails, Lighttpd, wget, Apache, etc.) is critical for many reasons but there’s one big one we’ll discuss here: System Updates and their system-wide impact.
Basically, when you automatically update your system, the apps in /usr/local/ won't get over-written.
Mac OS X, Windows, commercial UNIX systems, and Linux distributions all make use of software updates to deliver newer (and theoretically improved) versions of their software to their users.
This process involves an automatic or manual process where the operating system checks for an update from the mothership, and then downloads and installs the update, which usually consists of newer versions of applications, bugfixes, files, etc.
These new components are often moved into place with brute force … regardless of what was there before. It’s possible (and probable) that any customizations one may have made to the system’s files, binaries, executables, or Applications can and will be overwritten at will by the software update … but only if these files were placed outside of their safe haven, /usr/local.
There is one bit in the article that I found a trifle confusing:
In the old days (and today too, if needed), setting mount points for drives was usually a manual process. One would edit a file like /etc/fstab (still around on most UNIX systems, but managed automatically) and hard-code the mount points for each drive.You mean there are people who don't edit /etc/fstab manually? There are tools to manage it automatically? How peculiar. I always edit mine by