Linux distros: Slackware, Debian and Red Hat family tree

Wetin Linux distribution really be

The history of Linux distributions start with one gap: Linux kernel by itself no fit do anything wey person fit use. E boot and find hardware. Then e stop. Somebody must add userland, choose how to install and update software, and promise say dem go continue fix am for years. Distribution na that set of choices, plus the group of people wey remain around afterwards.

E get five parts. If you change any one of dem, you get different distribution, even when most of the binaries match:

• A kernel, for the version wey the project choose, with the patches and drivers wey e add.
• A userland: the C library, the shell, the init system, and the standard commands.
• A package format, plus the tool wey install am.
• A release policy: wetin fit change, how often e fit change, and how long dem go fix each release.
• People: package maintainers, security team, and somebody wey go answer when package spoil.

Kernel na the shared part, so two Linux distributions dey much closer to each other than either one dey to another Unix. You need remember this when you compare Linux and FreeBSD as server platforms, where one project build and release the kernel and base userland together. For Linux, those parts come from separate upstreams, and na the distribution make dem work together.

History of Linux distributions for three families

Three projects wey start for 1993 and 1994 later become families: Slackware, Debian and Red Hat. Almost every image wey dey VPS control panel today na one of dem or descendant of one. Descendant dey inherit package format, file layout and usually release habits. Na why Debian derivative still dey feel like Debian even after dem remove the branding.

The independent distributions deserve their own line because nobody fork dem. Arch, Gentoo, Alpine, NixOS and Void each write their own package manager and their own rules. Two of dem, Arch and Alpine, still end up for your provider image list, but the reason no relate to desktop.

1992: the distributions wey come before the families

MCC Interim Linux show for February 1992. Owen Le Blanc assemble am for Manchester Computing Centre. E put the kernel and GNU (GNU's not Unix) tools for two floppy images, with menu-driven installer. E exist because to do all that by hand fit take one full day work.

Peter MacDonald release SLS (Softlanding Linux System) for 1992. E go further by adding X (the X Window System) and TCP/IP networking. SLS na why the word distribution get the meaning wey e get today. But e get plenty bugs and maintenance slow. For 1993, two people separately decide to fix am. One rebuild am. The other start again with written rules.

Slackware, 1993: family wey still dey release till today

Patrick Volkerding release Slackware 1.00 on 16 July 1993. E build am from SLS after e remove the bugs. Dem still dey maintain am, so na the oldest Linux distribution wey still survive.

Slackware package na compressed tar archive wey get install script inside. Dependency resolution no dey happen: nothing dey check whether the library wey your new package need don already dey disk. That one decision shape everything wey follow. If the tool no fit resolve dependencies, the package set wey dem release must make sense by itself. So releases dey come rarely and dem dey conservative. Slackware 15.0 arrive for February 2022, six years after 14.2.

The family small. SUSE first releases for middle of the 1990s build on Slackware, before the project take its own direction with YaST and, later, the RPM package format. Na this last part dey confuse people. SUSE and openSUSE dey use RPM packages, and dem no be Red Hat derivatives. The format travel. The lineage no travel with am.

Debian, 1993: social contract and three-suite pipeline

Ian Murdock announce Debian on 16 August 1993, three weeks after Slackware and for the same reason. The name join im Debra, e partner, with im own name. Debian Manifesto follow for January 1994 and set the terms: volunteers go maintain this distribution openly, no be company.

Debian later write the terms down. Dem adopt Debian Social Contract and DFSG (Debian free software guidelines) for July 1997, and DFSG become the basis of Open Source Definition for 1998. Document wey dem write to settle wetin fit enter one distribution later define licence category for the whole industry. Na why your sources.list get components: main hold software wey meet the guidelines, contrib and non-free hold software wey no meet dem, and Debian 12 add non-free-firmware so laptop wey get wireless card fit install without plenty searching.

The tooling na the other inheritance. dpkg install one package and refuse if anything dey missing, then print dpkg: dependency problems prevent configuration of. APT (advanced package tool), wey become the default for Debian 2.1 in 1999, na the layer wey work out wetin else to fetch and the order to fetch dem. Every apt command for every Debian derivative come from that work.

The release machine get three suites and one rule. Maintainer upload package to unstable, wey always get codename sid. Script migrate the package enter testing after roughly 5 to 10 days, if e build for the release architectures and no new release critical bug enter. Testing then freeze, release team clear wetin remain, and stable release when the bug list don short reach enough. E no dey follow date. Na why Debian stable look old and work well: version numbers stop for the freeze, while security fixes dey backport into dem.

Dem write governance down too, with elected project leader and binding general resolutions. For 2014, that machinery choose systemd as the default init system, and the people wey disagree fork Devuan, wey make im first release for 2017. Debian no be the first distribution to make that change, and e no be the last. The reasons why this change keep happening, together with the objections wey later turn out to dey correct, dey traced for the account of how systemd replaced SysV init. The bigger descendants na Ubuntu, Raspberry Pi OS, Proxmox VE, Kali and Linux Mint.

Red Hat, 1994: RPM, then the split into Fedora and RHEL

Marc Ewing release the first Red Hat Linux around Halloween 1994. Bob Young company buy am for 1995, and the two of dem build the first Linux business wey sell support instead of software. Red Hat go public for 11 August 1999. IBM close the acquisition of the company for July 2019 for about 34 billion dollars, so the distribution wey most enterprise software dey certified against don remain IBM property since then.

The technical contribution wey last na RPM (Red Hat package manager), wey Erik Troan and Marc Ewing write for Red Hat Linux 2.0 for 1995. RPM dey declare its dependencies, and dem dey produce am from spec file, wey be build recipe anybody fit run. Na this second property make independent rebuilds of Red Hat enterprise product possible later.

Red Hat Linux 9 for 2003 na the last for the original line. The company split am into two: Fedora Core 1 for November 2003 as the fast community release, and RHEL (Red Hat Enterprise Linux), wey start as Advanced Server 2.1 for 2002, as the slow paid one. The reason clear. One product no fit be both the place wey new versions dey get tested and the platform wey bank dey run untouched for ten years. The two sides dey linked: RHEL major version dey branch from Fedora release, dem stabilise am, then freeze am. The package tool move on the same schedule, from yum for the 2000s to dnf as Fedora default for 2015, with rpm underneath both.

Why CentOS stop to be free RHEL rebuild

CentOS start for 2004 with one simple work: take the source packages wey Red Hat publish, remove the trademarks, rebuild dem, then give the result out free. E become the default free server distribution for one decade, and Red Hat bring the project inside the company for 2014.

For 8 December 2020, Red Hat announce say CentOS Linux 8 go end for 31 December 2021, eight years before the date wey dem publish before, and say the name go continue as CentOS Stream. Stream no be rebuild. Na the branch wey dem dey use cut RHEL minor releases from, so e dey ahead of RHEL instead of behind am. If you plan keep a machine for years, ahead no be the correct direction, because you go receive changes before Red Hat paying customers receive dem.

Two rebuilds show for 2021. Gregory Kurtzer start Rocky Linux; na him co-found CentOS. CloudLinux fund AlmaLinux. For June 2023, Red Hat stop publishing RHEL sources anywhere except CentOS Stream and its customer portal. Rocky continue to target identical rebuilds. AlmaLinux change its goal to ABI (application binary interface) compatibility. This mean software wey dem build for RHEL go run, but dem no promise say the bug list go match line by line. Oracle, SUSE and CIQ set up OpenELA later that year to publish shared sources. The complete sequence, from the 2003 split reach the 2023 source change and wetin each rebuild promise now, dey explained for the longer explanation of Red Hat, CentOS, Rocky and AlmaLinux.

If provider image list still say CentOS, find out which one e mean before you build on top of am.

cat /etc/os-release

NAME="CentOS Stream" na a rolling development branch wey dey lead to RHEL. NAME="AlmaLinux" or NAME="Rocky Linux" na a rebuild wey follow am, with ten-year window.

Ubuntu, 2004: Debian unstable snapshot wey dey follow calendar

Ubuntu 4.10 release on 20 October 2004, with funding from Mark Shuttleworth. The relationship between am and Debian na mechanical one, no be emotional matter. Every cycle dey start by importing packages from Debian unstable go the new Ubuntu release. Dem imports dey continue until Debian Import Freeze for middle of the cycle. After that, Ubuntu dey carry its own changes. Plenty Ubuntu packages na the Debian package plus one delta, and changelog dey show which one.

The other half na the calendar. Debian dey release when e ready. Ubuntu dey release for April and October, and version number na the date: 24.04 come out for April 2024. Every second April release na LTS (long term support), and na this one provider mean when e list Ubuntu without any qualifier. Which of the two one suppose use for server na the main matter for choosing between Ubuntu LTS and interim releases, and moving from one LTS go the next one get its own procedure, wey dem cover for the 24.04 to 26.04 upgrade.

One detail dey catch server admins every year. Ubuntu archive dey split into components. main na Canonical dey maintain am for the full support window. universe na community dey maintain am, and its security coverage get different promise. apt install no show anything about the difference. One command fit show am:

apt-cache policy nginx

Repository line wey end with /main mean say Canonical security team dey responsible for that package. Line wey end with /universe mean say community dey responsible. Check am for anything wey dey face the internet.

Arch, 2002: rolling releases and the cost of a partial upgrade

Judd Vinet release Arch 0.1 on 11 March 2002, with package manager wey e write by himself, pacman, and build recipes wey be plain shell scripts. Arch no get versioned releases at all. The install media na dated snapshots of the same rolling repositories, so machine wey dem install for 2019 and update every week dey run the same Arch as machine wey dem install today. AUR (Arch user repository) hold build recipes wey users contribute. Dem na recipes, no be reviewed packages, so reading PKGBUILD before you run am na part of the work.

Rolling get one failure mode, and na user dey cause am every time. If you install one package with pacman -Sy foo, e go refresh package database and then install one new binary wey link against libraries newer pass the ones wey dey disk. Programs go then fail like this:

error while loading shared libraries: libcrypto.so.3: cannot open shared object file: No such file or directory

The supported operation na pacman -Syu, wey dey update everything together. The project still dey post news entries wey explain when manual intervention dey required before some upgrades, and if you run the upgrade without reading dem, e fit leave machine wey no go boot.

Because of this, Arch no too good for server wey you plan to ignore. Machine wey you update every week dey okay. Machine wey you update once, then wait one year, go bring every skipped intervention come for one run.

Alpine: small distribution wey containers make popular

Alpine start around 2005 as one fork of LEAF (Linux embedded appliance framework), wey itself come from Linux Router Project. Natanael Copa build am for appliances, no be for desktops. E replace most of the usual userland: musl instead of GNU C library, BusyBox instead of GNU core utilities, OpenRC instead of systemd, and apk as the package manager. Alpine 3.0 for 2014 na the release wey move go musl.

Containers make am popular. Alpine base layer small well-well compared with Debian or Ubuntu base. So from 2016, e become common base image, and plenty people wey never install Alpine still dey run am every day.

The problem be say musl no be glibc, and the difference fit show as bugs wey look unrelated. Binary wey link against glibc go fail for Alpine with message wey make people search for file wey already dey there:

sh: ./myapp: not found

The program dey there. But e ELF interpreter no dey, because glibc loader no dey installed. Python na another common surprise: prebuilt wheels wey build for manylinux no go install for musl. So pip go fall back to compiling from source and stop when compiler no dey installed. musllinux wheel standard from 2021 solve this for projects wey publish those wheels, but e no solve am for other projects.

As host operating system for VPS, Alpine install small and update fast. But e go move you away from the setup wey most documentation assume. Any guide wey tell you make you run systemctl enable need translation to rc-update add.

The immutable generation: atomic updates and image based servers

The newest branch dey change update model instead of package list. An ostree based system dey keep /usr read only. Update na complete new filesystem tree wey system go download, stage, then switch to am for next reboot. The previous tree still dey as boot entry, so if update bad, you fit undo am by rebooting into the old one.

Fedora Silverblue bring this model come desktop for 2018, and Fedora CoreOS bring am come servers for 2019, after Red Hat buy CoreOS for 2018. Flatcar Container Linux continue the original Container Linux after dem retire am for 2020. openSUSE MicroOS reach the same result through btrfs snapshots and transactional-update. For 2024, Red Hat add image based mode to RHEL, built on bootc, where operating system dey ship as container image and machine update happen by pointing am to new tag. Talos Linux go furthest and remove shell and SSH completely: API dey configure the machine, so nothing dey to log in to. NixOS, wey first release for 2007, come from another direction. The whole system dey build from one declarative configuration, and previous generations still dey bootable.

Your provider likely no offer any of these as one-click image, because dem expect Ignition or cloud-init to configure am for first boot instead of administrator editing files over SSH. Dem become useful across many identical machines. Na the situation you dey inside once you dey manage several Linux servers at once and need proof say each one be exactly like the others.

How long one release dey get support?

Release policy na the part of a distribution wey you go live with for the longest time, and dem dey publish am as number of years. Here be the support windows for 5 current server releases.

[
  {
    "distro": "Alpine 3.x",
    "standard_years": 2,
    "extended_total_years": 2
  },
  {
    "distro": "Debian 13",
    "standard_years": 3,
    "extended_total_years": 5
  },
  {
    "distro": "Ubuntu 26.04 LTS",
    "standard_years": 5,
    "extended_total_years": 10
  },
  {
    "distro": "AlmaLinux 10",
    "standard_years": 10,
    "extended_total_years": 10
  },
  {
    "distro": "RHEL 10",
    "standard_years": 10,
    "extended_total_years": 13
  }
]

Alpine dey support each 3.x branch for 2 years. Na why e fit better for container image wey you dey rebuild often pass host wey you leave untouched. Debian security team dey cover stable release for about 3 years. After that, the LTS team dey carry the common architectures reach about 5 years altogether. Ubuntu LTS dey give you 5 years for packages inside main. Ubuntu Pro subscription dey extend am reach 10 years, and personal users fit use am free for small number of machines. RHEL 10 dey publish 10 years. Paid extended life cycle support add-on dey extend this reach 13. AlmaLinux 10 get the same RHEL window of 10 years without any subscription. Na the whole reason why the rebuilds dey exist.

Arch no get row here because rolling distribution no get release wey need support. For Arch, the number wey matter na how long you fit leave machine untouched. Dem dey measure am in weeks.

Why your VPS image list dey look like this

Provider dey release the images wey customers ask for by name and wey fit install without supervision for its hypervisor. Na why almost every list dey start with Ubuntu LTS and Debian stable, add AlmaLinux or Rocky for people wey their software get certification against RHEL, then keep Alpine, Arch and Fedora further down the page. Once you know wetin VPS be and how the image reach the disk, the pattern clear: provider dey choose operating systems wey fit survive unattended install and remain supported longer than the average customer dey keep the server.

The choice commit you to more than package manager. E set the upgrade wey you go run after three years, and the upgrade process dey completely different for each family. Debian and Ubuntu support major upgrades in place. Red Hat family dey run dem through leapp. Arch no get upgrade because e no get version. Alpine upgrade na to edit /etc/apk/repositories and run apk upgrade --available. The choice also set which software you fit install without adding third-party repository, who go release the patch when CVE (common vulnerabilities and exposures) entry land on something wey you dey run, and which init system and C library your future software go assume say dey available.

One more effect dey wey easy to underrate. Plenty answers wey people write for internet assume Debian family path or Red Hat family path, so if you choose outside those two, you go dey translate instructions for the whole time wey the machine dey run. Choose the family wey its release policy match how often you ready to touch the server, then stick with am. Changing the packages on top easy. Changing the distribution underneath dem mean rebuilding the box.

FAQ

Which Linux distribution family is my server in?

Run cat /etc/os-release. The ID field dey name the distribution, while ID_LIKE dey name the family. So, Ubuntu machine go report ID_LIKE=debian and AlmaLinux machine go report ID_LIKE="rhel centos fedora". The package manager na the other clue. apt and dpkg mean Debian family, dnf and rpm mean Red Hat family, apk mean Alpine, and pacman mean Arch.

Is CentOS still a free version of RHEL?

No. CentOS Linux 8, wey be the last rebuild with that name, end on 31 December 2021. CentOS Linux 7 reach end of life on 30 June 2024. The project wey remain, CentOS Stream, na the branch wey dem dey build RHEL minor releases from. So e dey receive changes before RHEL, no be after am. The free rebuilds wey take over the old role na AlmaLinux and Rocky Linux. Both get ten year windows.

Why does Debian stable ship such old version numbers?

Because the version number dey freeze while the fixes still dey come. Debian dey backport security patches into the version wey e release instead of importing newer upstream release. So package wey read 2.4.57-2+deb13u1 fit carry fix wey dem publish last week. The suffix after the upstream version na the Debian revision, and apt changelog <package> list wetin enter inside am. If you judge Debian server security by the version numbers, you go always get wrong answer.

Should I run a rolling release like Arch on a VPS?

Only if you go update am on schedule. Rolling distribution assume say every machine go converge on the current package set. So, if you update one package with pacman -Sy foo, e fit leave mismatched libraries and errors like cannot open shared object file. Run pacman -Syu regularly. Read the project news page before every run, and the system go stable. If you leave am for one year, the first upgrade go become the risky one.

What does an immutable or atomic distribution actually change?

E change when updates dey apply and how you fit undo dem. /usr dey mount read only. Update dey stage as complete new tree, and the switch happen when system reboot, while dem keep the previous tree as boot entry for rollback. You get machine wey either fully update or fully no update, with no half-applied state. You no fit install software by editing files in place again, so applications dey move into containers or layered packages.