Chapter 24 — The Filesystem Hierarchy Standard, and why `/etc` isn't random

In one sentence

Linux's top-level directory layout (/etc, /var, /usr, /home, and the rest) follows a documented, decades-old convention — the Filesystem Hierarchy Standard — specifically so that any tool, script, or engineer can predict where something lives without having to ask.

Why this matters

Knowing this layout by MEANING, not by memorised list, means a Linux box you've never touched before is still navigable in minutes.

How it actually works

   THE CORE DIRECTORIES, and WHY each one exists (this is the part worth
   actually remembering -- the meaning, not just the name):

     /etc      "editable text configuration" -- system-wide config files.
              Nothing here should be a compiled binary or a program's
              own data; it's SETTINGS.
     /var      "variable data" -- files that CHANGE while the system
              runs: logs (`/var/log`), databases, mail queues, caches.
              The opposite of "static."
     /usr      historically "Unix System Resources" (not "user"!) --
              the bulk of installed software: binaries (`/usr/bin`),
              libraries (`/usr/lib`), shared data. On modern systems,
              `/bin` and `/sbin` are often just SYMLINKS into
              `/usr/bin` (see the real-world example).
     /home     personal directories for each human user.
     /root     the root user's OWN home directory -- deliberately
              SEPARATE from `/home`, partly so root's home still exists
              and is usable even if `/home` is a separate, unmounted
              filesystem.
     /tmp      temporary files -- may be CLEARED on every reboot (often
              literally a RAM-backed filesystem, tmpfs) -- never store
              anything here you can't afford to lose.
     /opt      "optional" -- self-contained third-party software that
              doesn't want to scatter itself across `/usr`.
     /dev, /proc, /sys   the virtual filesystems from Chapter 23.
     /boot     the kernel, bootloader config, and other files needed
              extremely early in Chapter 21's boot process.

   THE OVERALL PRINCIPLE: separate STATIC from VARIABLE, separate
   SYSTEM-PROVIDED from USER-INSTALLED from USER-PERSONAL, and put
   things a script can DEPEND ON in a small number of PREDICTABLE
   places. This predictability is the entire point -- it's a decades-old
   social/technical CONVENTION (documented as the "Filesystem Hierarchy
   Standard," maintained by the Linux Foundation), not a technical
   requirement the kernel enforces.

Real-world example

   Around 2012-2020 (adoption spread gradually across distributions),
   many major Linux distributions -- including Fedora (an early mover,
   around 2011-2012) and later Debian and Ubuntu -- carried out what's
   widely known as the "UsrMerge": consolidating `/bin`, `/sbin`, and
   `/lib` (which had historically been SEPARATE top-level directories,
   for a specific historical reason -- ensuring critical early-boot
   binaries were available even if `/usr` was on a separate filesystem
   that hadn't mounted yet) into being SYMLINKS pointing into
   `/usr/bin`, `/usr/sbin`, and `/usr/lib` respectively.
   This is a genuinely useful, real example of TWO things this chapter
   teaches: first, that the FHS is a living, evolving convention (not
   an immutable law) that distributions can and do change when the
   original justification (limited early-boot filesystems) stops being
   relevant to how modern systems actually boot (initramfs-based
   early boot made the original separation largely unnecessary); and
   second, that the CONVENTION'S PREDICTABILITY survived the change --
   `/bin/ls` still works exactly as every script assumed it would, even
   though it's now "really" `/usr/bin/ls` underneath, specifically
   because the migration preserved backward compatibility via symlinks
   rather than breaking decades of scripts that hard-coded the old
   paths.

Try it yourself

# See the top-level layout, and notice which of these are symlinks
ls -la /

# Confirm whether YOUR system has done the UsrMerge
ls -la /bin    # if this shows "-> usr/bin", you're on a merged system

# Explore what actually lives in each key directory
ls /etc | head -10        # configuration
ls /var/log | head -10    # logs (Chapter 34)
du -sh /usr /var /etc /tmp 2>/dev/null   # relative sizes -- /usr is
                                        # usually by far the biggest

Common mistakes

Storing important data in /tmp. It can be wiped on reboot (and often is, by design) — use /var or a dedicated data directory instead.
Guessing paths instead of checking. which <command>, man hier (the FHS's own man page), and ls beat memorised assumptions, especially across different distributions that may vary slightly.
Assuming the FHS is identical on every Unix-like system. macOS and BSD systems follow RELATED but not identical conventions — don't assume Linux paths transfer directly.

Check yourself

What's the meaningful difference between /etc and /var?
Why does /root exist separately from /home?
What was the "UsrMerge," and why did it happen?

Chapter 24 — The Filesystem Hierarchy Standard, and why /etc isn't random