Linux distributions and support lifecycles · Linux

The distribution you choose determines how long your hosts receive security updates, what package manager you use daily, and which vendor you call when something breaks. Choose deliberately.

The two production families

Trait	Debian family	RHEL family
Package format	`.deb`	`.rpm`
Package manager	`apt` / `apt-get` / `dpkg`	`dnf` / `yum` / `rpm`
Default firewall	`ufw` (Ubuntu) / `nftables`	`firewalld`
Mandatory access control	AppArmor	SELinux
Default filesystem	ext4	XFS
Init system	systemd	systemd
Release cadence	Ubuntu LTS every 2 years; Debian stable every ~2 years	RHEL major every ~3-4 years; minor every ~6 months
Vendor support length	Ubuntu LTS: 5 years standard, up to 10 with extended	RHEL: 5 years standard, up to 10 with ELS / add-ons

Both families ship roughly the same kernel and GNU userland. The differences are configuration defaults, packaging conventions, and the identity of the vendor you escalate to.

Read-only / Safedistribution identity— Always cite /etc/os-release and VERSION_CODENAME when asking for help or filing bugs.

$ cat /etc/os-release

NAME=Ubuntu
VERSION=24.04 LTS (Noble Numbat)
ID=ubuntu
VERSION_ID=24.04
VERSION_CODENAME=noble
UBUNTU_CODENAME=noble
SUPPORTED=1
PRIVACY_POLICY_URL=https://www.ubuntu.com/legal/terms-and-policies/privacy-policy

Support lifecycles

A distribution’s end-of-life (EOL) date is when the vendor stops issuing security updates. After EOL, every unpatched CVE on that distribution is a permanent vulnerability.

Distribution	Released	Standard EOL	Extended EOL
Ubuntu 22.04 LTS	2022-04	2027-04	2032-04 (Legacy)
Ubuntu 24.04 LTS	2024-04	2029-04	2034-04 (Legacy)
Debian 12 (Bookworm)	2023-06	~2026-06 (LTS through 2028-06)	–
RHEL 9	2022-05	2027-05	2032-05 (ELS)
Rocky Linux 9 / AlmaLinux 9	follows RHEL 9	follows RHEL 9	follows RHEL 9

Choosing a distribution

The decision matrix is mostly about support commitments and operational tooling. The technical differences are second-order.

Commercial support needed? RHEL has paid vendor support; Rocky/Alma are community rebuilds of RHEL. Ubuntu Pro is a paid add-on to Ubuntu
What does the rest of the estate run? Mixing families multiplies operational cost. Pick one family unless there is a strong reason not to
What are the upstream defaults your tooling assumes? Kubernetes, configuration management, and monitoring agents often assume one family
What is the kernel release cadence your hardware needs? Newer hardware often needs newer kernels; LTS distributions backport rather than upgrade
What is the security policy? SELinux (RHEL default) and AppArmor (Debian/Ubuntu default) are different. Standardise fleet-wide rather than disabling on a per-host basis

Upgrade paths

A distribution upgrade moves a host from one major version to the next (Ubuntu 22.04 → 24.04, RHEL 8 → 9). Distributions design these paths to be supported; jumping multiple majors or skipping releases is not.

The canonical upgrade commands:

Configuration changeUbuntu upgrade— Initiates an in-place upgrade to the next LTS. Run inside a screen/tmux session on the host console — not over SSH alone, in case the network drops.

# do-release-upgrade

Checking for a new Ubuntu release
No new release found

Illustrative output

Configuration changeRHEL upgrade— Bootstraps the upgrade workflow. Requires leapp and the appropriate upgrade repository. RHEL-family upgrades are heavier than Ubuntu do-release-upgrade.

# dnf system-upgrade

Last metadata expiration check: ...
Dependencies resolved.
...