Distributions and Release Models

A distribution is the kernel plus an assembled, supported product: a package manager and its signed repositories, an init system, a curated set of software at chosen versions, and — the part people underweight — a written policy for how long that set gets security patches. The kernel is nearly the same code everywhere; what separates Debian from Ubuntu from Red Hat is the userland defaults, the package tooling, and the support contract.

For a server, the decision that matters is the package ecosystem and the support lifecycle, not the desktop. A distribution with a five-year patch window and a documented end-of-life date is a different operational commitment than one that asks you to upgrade across the whole world every six months. Pick on those grounds and you spend your time running services; pick on desktop polish and you inherit an upgrade treadmill the server never needed.

The Major Families

Three lineages cover almost everything you will meet on a server, plus two specialists. Debian and its largest derivative Ubuntu use dpkg for single-package installs and apt for dependency resolution against .deb repositories — this is the family this course leads with. The Red Hat line — RHEL, its rebuilds Rocky and AlmaLinux, and the upstream Fedora — uses rpm and dnf against .rpm repositories. The two worlds are structurally identical (low-level tool plus a dependency-resolving front end) but share no packages: a .deb does not install on RHEL, and the package names diverge (apache2 on Debian, httpd on RHEL).

Arch uses pacman and ships a rolling release with no version numbers — there is one Arch, always current. Alpine uses apk, builds its userland on musl libc and BusyBox instead of glibc and GNU coreutils, and produces a base image around 5 MB — which is why it dominates container images even on fleets that run Debian or Ubuntu on the host. The musl swap is the catch: glibc-only binaries and a handful of locale and DNS edge cases behave differently, so Alpine is a deliberate container choice, not a drop-in host replacement.

Release Models

A fixed (point) release freezes a snapshot of every package, then ships only security and critical bug fixes to that snapshot for years. Debian stable and RHEL work this way: the version of PostgreSQL you install on day one is the version you keep until the next major release, with security patches backported into it. The trade is predictability for staleness — nothing shifts under your running services, but you do not get new upstream features without an explicit upgrade.

A rolling release has no snapshot. Arch delivers each package at upstream's latest as soon as it is built; pacman -Syu moves the whole system forward continuously. You get current software the day it lands and never face a wrenching version jump — at the cost of a moving target, where any update can change behavior and there is no "this release is frozen and tested as a unit" guarantee. Ubuntu sits between the two: it cuts a release every six months, but designates one in four as LTS (Long-Term Support) on a two-year cadence — 20.04, 22.04, 24.04 — with a far longer support window than the interim releases.

Support Lifecycle and EOL

Every fixed release has an end-of-life date, after which no more security patches ship. Past that date the box keeps running, but each new CVE in its packages stays open forever — the single most common way a long-lived server quietly becomes the weakest machine on the network. Ubuntu LTS carries 5 years of standard security support; Debian stable gets roughly 3 years of full support plus about 2 more of community LTS; RHEL runs a 10-year maintenance lifecycle, the longest of the mainstream options.

For workloads that outlive the standard window, both major vendors sell an extension. Ubuntu's ESM (Expanded Security Maintenance), part of Ubuntu Pro, stretches an LTS to 10 years and patches packages in the larger universe set that standard support never covered; RHEL offers Extended Update Support phases on top of the base lifecycle. The practical rule for a server fleet: know each machine's EOL date before you deploy it, and have the next release validated and scheduled before that date arrives — not after an auditor or an incident forces the question.

The Stable-versus-Current Trade-off

Choosing a distribution is choosing where to sit on one axis: old-but-patched packages versus latest-but-unfrozen ones. Debian stable will hand you a database release that is two or three years behind upstream, with every known security fix backported into that old version — the version string looks dated, the security posture is current. That is exactly right for a service you want to leave alone, and exactly wrong when you genuinely need a feature that only exists in a newer upstream release.

When the gap bites, the answer is rarely to switch the whole distribution to a rolling model. It is to pull the one component you need from a vendor-maintained repository — the upstream project's own apt repository, a backports suite, or a container that pins that version — while the base system stays on the stable, patched track. Trading the entire machine's predictability for one newer package is a bad bargain you can almost always avoid.