The Unix side of OS X

os x, unix

The great thing about OS X is that it has Unix under the bonnet. But, knowing where to put things can be confusing if you are new to it. Here's a quick guide to the Unix folders in OS X.

Using Apple Terminal

I assume you know how to use the Terminal to look around OS X. If not, then find Terminal in Applications / Utilities, go in the preferences to change the window background colours to something geekier, and have a look at one of the many Unix primers out there, like this UNIX Tutorial for Beginners from the University of Surrey. Or even better, Matisse Enzer gives away the PDF of the chapter covering the Terminal from his Unix for Mac OS X 10.4 Tiger book. The good thing about Unix - it doesn't change that much. Those guides are still relevant.

OS X uses a simple naming convention for folder names: if they start with an upper case letter (e.g., /Users) they are Apple ones, otherwise (e.g. /usr) they are Unix. More or less.

OS X folder structure

You should be already familiar with most of these.

/Applications
Cocoa and Carbon apps. OS X applications are in fact directories that looks like files. If you list them on Terminal you can see what's in these folders, for example: ls /Applications/Chess.app/Contents/ (you can also get to that by ctrl-clicking on the app in Finder and choosing 'show package content')
/Library
Frameworks and components for third party applications. It also includes a /Library/Fonts folder, with all the fancy fonts installed for all users.
/System/Library
Frameworks and components used by OS X. It also includes a /System/Library/Fonts folder, with the minimum set of system fonts shared by all users. If you delete any fonts from here you are in trouble.
/Users
Users' folders, hidden from each other. And yes - they also have their own fonts folder ( /Users/username/Library/Fonts ) which are loaded up when you login as that user.
/.Spotlight-V100
A hidden folder that stores Spotlight's indexed metadata. Each OS X file and folder is associated with metadata - you can view it in the command line with the command mdls, e.g. mdls ~/ You can query the metadata index created by spotlight directly on the command line with the command mdfind.

FreeBSD folder structure

Unix is an old system - when it was created every byte counted, which is why they called directories 'usr' and not 'user', to save just the one letter. It also made sense to keep what changed often and needed regular backing up separate from what changes rarely. After all, this was the equivalent of four floppy disk in those days. Mind you, that makes sense even today, as disk storage may be cheap but backing up isn't.

/
This should contain the minimum needed to boot, restore and repair the filesystem. The idea is to be able to have all the core files on small portable storage device.
/bin
binaries used by admins and normal users. This is not the complete set of all the commands available on the system - just the minimum needed for booting and restoring (the rest are in separate places, see below). For example, in OS X 10.6 these are: [ bash cat chmod cp csh date dd df domainname echo ed expr hostname kill ksh launchctl link ln ls mkdir mv pax ps pwd rcp rm rmdir sh sleep stty sync tcsh test unlink unrar wait4path zsh
/dev
devices - i.e., drivers. In Unix they are setup to look and act as if they were files
/etc
system configurations, specific for a machine. These are static, i.e. only changeable by admins, and are not executable binaries. Classic examples /etc/hosts, /etc/group, /etc/passwd
/opt
Application packages added on. Used, for example, by MacPorts
/sbin
system binaries. These are only used by root or the system. This is the minimum set needed for booting / restoring the system. The other system binaries are in /usr/sbin and /usr/local/sbin Typical examples include mount, reboot, fsck
/tmp
temporary files. These are deleted when the system reboots. /var/tmp is an alternative that doesn't.
/usr
Non root hierarchy. Static, i.e. shouldn't need to change unless an admin installs something.
/usr/bin
This is where most commands available to all users are. There's loads and loads of them, from python to who to calendar to ssh...
/usr/include
These are include libraries used by C programs. Of no interest to most users. C libraries get special treatment because at the time Unix was created C was 'the' programming language - indeed, early implementation of Unix were written in C, as opposed to assembly as it was then the norm.
/usr/lib
These are dynamic libraries used by packages and programs. Normally created as a side effect of installations.
/usr/local
This is where software for a specific machine should go. For example mysql, php5, etc. Within this folder the same hierarchy as root holds: /usr/local/bin for binaries,
/usr/local/etc for config files,
/usr/local/include for C libraries,
/usr/local/lib for shared binaries that are not exectuded directly,
/usr/local/sbin for system libraries run locally
/usr/local/share for read only libraries
/usr/share
Read only files, like man pages. If you install a geo-location library like GeoIP, its data could go here
/usr/X11 and /usr/X11R6
This is used by the X11 - a full on Unix windows system available on your Mac. You may have come across it if using Gimp, the free Photoshop alternative. X11R6 is a symbolic link to X11
/var
Variable data. The opposite of static, i.e. users (or the system) change them all the time
/var/lib
This is non-shareable state information for apps. Users shouldn't need to touch this
/var/log
Log files, for example from your Apache web server
/var/run
These are files related to a currently running instance of a program or package. Typically process id (.pid) files and such.
/var/spool
This holds queues of data that need to be dealt with at some stage by an admin or a package. It will be typically deleted after processsing. /var/spool/mqueue holds the outgoing mail queue, for example
/var/tmp
This is temporary data, but unlike /tmp it is preserved between system reboots

More information

That should give you a fair idea of what goes where, and why the Apache webserver config files are, say, in /etc/apache2/

There's plenty information online about Unix - for example you can start from the article Filesystem Hierarchy Standard.