Understanding the bin, sbin, usr/bin, usr/sbin split (2010)

Original Article ↗ Hacker News Discussion ↗

Unix-like operating systems still carry a complex filesystem layout (/bin, /sbin, /usr, /var, /opt, etc.) rooted in decades‑old hardware and multi‑user constraints, even though many of those original reasons no longer apply. Commenters contrast historical justifications (separate disks, minimal boot partitions, static system binaries) with modern practices such as initramfs, the /usr merge, containers, and immutable or alternative distros like NixOS and GoboLinux that experiment with app‑centric or per‑package trees. The exchange highlights a tension between standards‑driven continuity and the desire to simplify or redesign the hierarchy for contemporary systems, while also debating what constitutes a “base system” in Linux versus BSD.

Historical origins of the split

  • Several comments note the layout is mostly historical inertia: early Unix had tiny, separate disks for /, /usr, later others, so binaries and libs were split by what lived on which spindle.
  • /bin and /sbin were for tools needed to boot and fix the system; /usr/bin and /usr/sbin for everything after other filesystems were mounted.
  • /etc originally meant “miscellaneous stuff”, including binaries; sbin appears later (likely BSD/System V) as a place to move “system” binaries out of /etc.
  • There is disagreement over whether the “s” in sbin ever officially meant “static”; some recall that rationale emerging later rather than being original.

Initramfs and the relevance of /bin and /sbin

  • With initrd/initramfs containing all drivers and tools needed to mount real filesystems, several argue /bin and /sbin are effectively obsolete.
  • Others see initrd as a fragile, distro-specific kludge that can break boot if misbuilt, and would prefer a simpler model with more built-ins or fewer moving parts.
  • Embedded-use fans like initramfs for bundling tiny installers or recovery environments.

Modern /usr merge and filesystem simplification

  • Many major distros have done the “/usr merge”: all binaries under /usr/bin, with /bin, /sbin, /usr/sbin kept as symlinks to avoid breaking shebangs and hardcoded paths.
  • Some see this as sensible modernization and easier network/shared mounting; critics view it as adding indirection instead of truly cleaning up legacy.

Roles of /usr/local, /opt, /var, /srv, etc.

  • Common view:
    • /usr = distro/base system;
    • /usr/local = site- or admin-installed software following system layout;
    • /opt = self-contained or commercial packages with their own trees.
  • Others argue this is confused on Linux, where there is no single “base system” in the BSD sense.
  • Debate over /var: some think of it as expendable, others stress it’s for important writable data (DBs, mail queues, caches) vs /tmp / /var/tmp.
  • /srv is liked by some as a home for service data (e.g. web roots), but many packages still default to /var.

Alternative layouts and package models

  • Various projects are cited as attempts to escape legacy: GoboLinux (per-app dirs like /Programs/App/Version), NixOS/Guix (content-addressed, isolated store), TinyCore (mountable .tcz packages), sta.li, containerized formats (Flatpak, Snap, AppImages).
  • These promise better isolation, parallel versions, and simpler dependency management, but are often non-mainstream or require learning new tools/languages.

Base system vs. “hodgepodge” and user-local trees

  • There is a lively dispute over whether a Linux distro constitutes a coherent “base system” or merely a kernel plus replaceable packages.
  • XDG’s $HOME/.local/... hierarchy is criticized as redundant with $HOME, but others appreciate the consistent, namespaced layout (e.g. .local/share).