FreeBSD

## What "base system" actually means FreeBSD is a single project that develops a kernel *and* a userland in one source repository (conventionally checked out at `/usr/src`). A release such as 14.1-RELEASE is a snapshot of that whole tree: the kernel, libc, `/bin/sh`, `ls`, `ps`, `sed`, the C compiler (Clang/LLVM), OpenSSH, the `pf` and `ipfw` firewalls, the `bhyve` hypervisor, DTrace, ZFS, the jail subsystem, and the manual pages that document all of it. Nobody "assembles" FreeBSD from independently-versioned upstreams the way a Linux distribution takes a kernel from one project, a libc from another, coreutils from a third and an init system from a fourth and integrates them. That difference is not philosophical trivia — it is visible on disk and it dictates your operational routine. ## Where the line is drawn on disk Base owns the traditional Unix paths: `/bin`, `/sbin`, `/lib`, `/usr/bin`, `/usr/sbin`, `/usr/lib`, its configuration in `/etc`, and its service scripts in `/etc/rc.d`. Everything third-party installs beneath `/usr/local`: binaries in `/usr/local/bin`, configuration in `/usr/local/etc`, service scripts in `/usr/local/etc/rc.d`. So an nginx installed with `pkg` reads `/usr/local/etc/nginx/nginx.conf`, not `/etc/nginx/nginx.conf`, and is started by an rc script in `/usr/local/etc/rc.d/nginx` enabled with a line in `/etc/rc.conf`. If you deleted `/usr/local` you would remove every package you ever installed and still have a bootable, fully functional operating system with a compiler and an SSH server. On a typical Linux distribution the package manager owns nearly everything under `/`, including the shell and coreutils, so no such line exists. ## Two update paths, two version numbers Because base and packages are separate, they update separately: ```sh # base: binary security/errata patches on a RELEASE branch freebsd-update fetch install # base: the from-source path make -C /usr/src buildworld buildkernel make -C /usr/src installkernel etcupdate -p && make -C /usr/src installworld && etcupdate -B # everything third-party, under /usr/local pkg upgrade ``` `freebsd-version -k` reports the installed kernel version, `-r` the running kernel and `-u` the userland — they can legitimately disagree between an update and the reboot that lands it. `pkg info` reports package versions, which follow their own upstreams and have nothing to do with the base number. ## What the model buys you **Coherence.** The kernel, the libraries and the tools were built and tested together, so ABI mismatches inside base do not happen, and the man page on the machine describes the binary on the machine. Kernel interfaces (KBI) stay stable within a major branch, so a module built for 14.0 loads on 14.1. **Predictability.** Any FreeBSD 14.1 host is the same host everywhere; the only variance is what you installed on top. That makes fleet reasoning, imaging and jail creation simple — a jail root is literally an extracted `base.txz` from a release. **One advisory stream.** Base problems arrive as project Security Advisories and Errata Notices covering the whole base; package problems are reported separately by `pkg audit`. ## What it costs you **You cannot cherry-pick base components.** If the OpenSSH in base needs a fix, you wait for the base patch (or install the `openssh-portable` port and disable the base daemon) — you cannot `pkg upgrade` it, because it is not a package. Base moves as a unit, on its branch's schedule. **Configuration merges.** `/etc` is shared: base ships defaults there and you edit the same files. Every base upgrade therefore includes a merge step (`etcupdate`, historically `mergemaster`) that reconciles your edits with the new base `/etc`. Package upgrades avoid this because their config lives under `/usr/local/etc` and packaged defaults are usually installed as `*.sample` files. **A smaller ecosystem.** One project maintaining a whole OS means fewer hands, and third-party vendors ship for Linux first. ## Interview framing The question is really testing whether you can operate a machine you did not build. A strong answer names the disk split, names the two upgrade commands, and then volunteers the trade-off honestly: coherence and predictability in exchange for coarse-grained patching plus an `/etc` merge on every upgrade.