A history of Linux distributions

What a Linux distribution actually is

The history of Linux distributions starts with a gap: the Linux kernel on its own does nothing a person can use. It boots and finds hardware. Then it stops. Someone has to add a userland, choose how software gets installed and updated, and promise to keep fixing it for years. A distribution is that set of choices, plus the group of people who stay around afterwards.

It has five parts. Change any one of them and you have a different distribution, even when most of the binaries match:

• A kernel, at a version the project picked, with the patches and drivers it added.
• A userland: the C library, the shell, the init system, the standard commands.
• A package format, and the tool that installs it.
• A release policy: what may change, how often, and how long each release is fixed.
• People: package maintainers, a security team, and someone who answers when a package breaks.

The kernel is the shared part, so two Linux distributions sit far closer to each other than either sits to another Unix. That is worth holding on to when you compare Linux and FreeBSD as server platforms, where the kernel and the base userland are built by one project and released together. On Linux those pieces come from separate upstreams, and the distribution is the thing that makes them agree.

A history of Linux distributions in three families

Three projects started in 1993 and 1994 became families: Slackware, Debian and Red Hat. Almost every image in a VPS control panel today is one of them or a descendant of one. A descendant inherits the package format, the file layout and usually the release habits, which is why a Debian derivative still feels like Debian after the branding is gone.

The independents deserve their own line, because they forked from nobody. Arch, Gentoo, Alpine, NixOS and Void each wrote their own package manager and their own rules. Two of them, Arch and Alpine, ended up on your provider's image list anyway, for reasons that had nothing to do with the desktop.

1992: the distributions before the families

MCC Interim Linux appeared in February 1992, assembled by Owen Le Blanc at the Manchester Computing Centre. It put the kernel and the GNU (GNU's not Unix) tools onto a pair of floppy images with a menu driven installer. It existed because doing that by hand cost a day of work.

SLS (Softlanding Linux System), released by Peter MacDonald in 1992, went further and added X (the X Window System) and TCP/IP networking. SLS is the reason the word distribution means what it means. It was also buggy and slowly maintained, and in 1993 two people separately decided to fix that. One rebuilt it. The other started again with written rules.

Slackware, 1993: the oldest family still shipping

Patrick Volkerding released Slackware 1.00 on 16 July 1993, built from SLS with the bugs taken out. It is still maintained, which makes it the oldest surviving Linux distribution.

A Slackware package is a compressed tar archive with an install script inside it. There is no dependency resolution: nothing checks that the library your new package needs is already on disk. That single decision shaped everything else. If the tool will not resolve dependencies, the shipped set has to be coherent by construction, so releases stay rare and conservative. Slackware 15.0 arrived in February 2022, six years after 14.2.

The family is small. SUSE's earliest releases in the mid 1990s were built on Slackware, before the project went its own way with YaST and, later, the RPM package format. That last part confuses people. SUSE and openSUSE use RPM packages, and they are not Red Hat derivatives. The format travelled. The lineage did not.

Debian, 1993: a social contract and a three suite pipeline

Ian Murdock announced Debian on 16 August 1993, three weeks after Slackware and for the same reason. The name joins his partner Debra to his own. The Debian Manifesto followed in January 1994 and set the terms: this distribution would be maintained in the open by volunteers, not by a company.

Debian then wrote the terms down. The Debian Social Contract and the DFSG (Debian free software guidelines) were adopted in July 1997, and the DFSG became the basis of the Open Source Definition in 1998. A document written to settle what belongs in one distribution ended up defining a licence category for the whole industry. It is also why your sources.list has components: main holds software that meets the guidelines, contrib and non-free hold what does not, and Debian 12 added non-free-firmware so a laptop with a wireless card could install without a scavenger hunt.

The tooling is the other inheritance. dpkg installs one package and refuses when something is missing, printing dpkg: dependency problems prevent configuration of. APT (advanced package tool), which became the default with Debian 2.1 in 1999, is the layer that works out what else to fetch and in what order. Every apt command on every Debian derivative descends from that work.

The release machine has three suites and one rule. A maintainer uploads to unstable, permanently codenamed sid. A script migrates the package into testing after roughly 5 to 10 days, if it built on the release architectures and picked up no new release critical bug. Testing then freezes, the release team clears what is left, and stable ships when the bug list is short enough. Not on a date. That is why Debian stable looks old and behaves well: the version numbers stop at the freeze while security fixes keep being backported into them.

Governance is written down too, with an elected project leader and binding general resolutions. In 2014 that machinery chose systemd as the default init system, and the people who disagreed forked Devuan, which made its first release in 2017. The larger descendants are Ubuntu, Raspberry Pi OS, Proxmox VE, Kali and Linux Mint.

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

Marc Ewing released the first Red Hat Linux around Halloween 1994. Bob Young's company bought it in 1995, and the two built the first Linux business that sold support instead of software. Red Hat went public on 11 August 1999. IBM closed its acquisition of the company in July 2019 for about 34 billion dollars, so the distribution most enterprise software is certified against has been IBM property ever since.

The lasting technical contribution is RPM (Red Hat package manager), written by Erik Troan and Marc Ewing for Red Hat Linux 2.0 in 1995. An RPM declares its dependencies, and it is produced from a spec file, a build recipe anyone can run. That second property is what later made independent rebuilds of Red Hat's enterprise product possible at all.

Red Hat Linux 9 in 2003 was the last of the original line. The company cut it in two: Fedora Core 1 in November 2003 as the fast community release, and RHEL (Red Hat Enterprise Linux), which had begun as Advanced Server 2.1 in 2002, as the slow paid one. The cause is plain. One product cannot be both the place new versions get tried and the platform a bank runs untouched for ten years. The two halves are linked: a RHEL major version branches from a Fedora release, gets stabilised, then gets frozen. The package tool moved on the same schedule, from yum in the 2000s to dnf as the Fedora default in 2015, with rpm underneath both.

Why CentOS stopped being a free RHEL rebuild

CentOS started in 2004 with a simple job: take the source packages Red Hat published, remove the trademarks, rebuild them, give the result away. It became the default free server distribution for a decade, and Red Hat took the project in house in 2014.

On 8 December 2020 Red Hat announced that CentOS Linux 8 would end on 31 December 2021, eight years earlier than the published date, and that the name would live on as CentOS Stream. Stream is not a rebuild. It is the branch that RHEL minor releases are cut from, so it runs ahead of RHEL instead of behind it. For a machine you intend to keep for years, ahead is the wrong direction, because you receive changes before Red Hat's paying customers do.

Two rebuilds appeared in 2021. Rocky Linux was started by Gregory Kurtzer, who co-founded CentOS. AlmaLinux was funded by CloudLinux. In June 2023 Red Hat stopped publishing RHEL sources anywhere except CentOS Stream and its customer portal. Rocky kept aiming at identical rebuilds. AlmaLinux changed its goal to ABI (application binary interface) compatibility, which means software built for RHEL runs, without a promise that the bug list matches line for line. Oracle, SUSE and CIQ set up OpenELA later that year to publish shared sources.

If a provider's image list still says CentOS, find out which one it means before you build on it.

cat /etc/os-release

NAME="CentOS Stream" is a rolling development branch that leads RHEL. NAME="AlmaLinux" or NAME="Rocky Linux" is a rebuild that follows it, with a ten year window.

Ubuntu, 2004: a snapshot of Debian unstable, on a calendar

Ubuntu 4.10 shipped on 20 October 2004, funded by Mark Shuttleworth. Its relationship to Debian is mechanical rather than sentimental. Each cycle opens by importing packages from Debian unstable into the new Ubuntu release. Those imports run until the Debian Import Freeze partway through the cycle, and after that Ubuntu carries its own changes. Many Ubuntu packages are the Debian package plus a delta, and the changelog says which.

The other half is the calendar. Debian ships when it is ready. Ubuntu ships in April and October, and the version number is the date: 24.04 came out in April 2024. Every second April release is an LTS (long term support), which is what a provider means when it lists Ubuntu with no qualifier. Which of the two belongs on a server is the whole subject of choosing between Ubuntu LTS and interim releases, and moving from one LTS to the next has its own procedure, covered in the 24.04 to 26.04 upgrade.

One detail catches server admins every year. Ubuntu's archive is split into components. main is maintained by Canonical for the full support window. universe is community maintained, and its security coverage is a different promise. apt install prints nothing about the difference. One command shows it:

apt-cache policy nginx

A repository line ending in /main means Canonical's security team owns that package. A line ending in /universe means the community does. Check it for anything that faces the internet.

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

Judd Vinet released Arch 0.1 on 11 March 2002, with a package manager he wrote himself, pacman, and build recipes that are plain shell scripts. Arch has no versioned releases at all. The install media are dated snapshots of the same rolling repositories, so a machine installed in 2019 and updated every week is running the same Arch as one installed today. The AUR (Arch user repository) holds build recipes contributed by users. They are recipes, not reviewed packages, so reading a PKGBUILD before running it is part of the job.

Rolling has one failure mode, and it is self inflicted every time. Installing a single package with pacman -Sy foo refreshes the package database and then installs one new binary linked against libraries newer than the ones on disk. Programs 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 is pacman -Syu, which updates everything together. The project also posts news entries that say manual intervention is required before certain upgrades, and running the upgrade without reading them can leave a machine that does not boot.

That makes Arch a poor choice for a server you plan to ignore. A box updated weekly is fine. A box updated once, a year later, hands you every skipped intervention in a single run.

Alpine: a small distribution that containers made famous

Alpine began around 2005 as a fork of LEAF (Linux embedded appliance framework), itself descended from the Linux Router Project, and Natanael Copa built it for appliances rather than for desktops. It replaces most of the usual userland: musl in place of the GNU C library, BusyBox in place of the GNU core utilities, OpenRC in place of systemd, and apk as the package manager. Alpine 3.0 in 2014 was the release that moved to musl.

Containers made it popular. An Alpine base layer is a small fraction of the size of a Debian or Ubuntu base, so from 2016 onward it became a common base image, and a great many people who never installed Alpine ran it every day.

The cost is that musl is not glibc, and the gap shows up as bugs that look unrelated. A binary linked against glibc fails on Alpine with a message that sends people looking for a file that is already there:

sh: ./myapp: not found

The program exists. Its ELF interpreter does not, because glibc's loader is absent. Python is the other regular surprise: prebuilt wheels built for manylinux will not install on musl, so pip falls back to compiling from source and stops when no compiler is installed. The musllinux wheel standard from 2021 fixed that for projects that publish those wheels, and for nobody else.

As a host operating system on a VPS, Alpine installs small and updates fast, and it puts you off the path that most documentation assumes. Every guide that tells you to run systemctl enable needs translating to rc-update add.

The immutable generation: atomic updates and image based servers

The newest branch changes the update model instead of the package list. An ostree based system keeps /usr read only. An update is a complete new filesystem tree, downloaded, staged, and switched to at the next reboot. The previous tree stays behind as a boot entry, so a bad update is undone by rebooting into the old one.

Fedora Silverblue brought that to the desktop in 2018 and Fedora CoreOS brought it to servers in 2019, after Red Hat bought CoreOS in 2018. Flatcar Container Linux continued the original Container Linux when that was retired in 2020. openSUSE MicroOS reaches the same place through btrfs snapshots and transactional-update. In 2024 Red Hat added an image based mode to RHEL, built on bootc, where the operating system ships as a container image and a machine is updated by pointing it at a new tag. Talos Linux goes furthest and removes the shell and SSH entirely: the machine is configured through an API, so there is nothing to log in to. NixOS, first released in 2007, arrives from a different direction. The whole system is built from one declarative configuration, and previous generations stay bootable.

Your provider probably offers none of these as a one click image, because they expect to be configured at first boot by Ignition or cloud-init rather than by an administrator editing files over SSH. They pay off across many identical machines, which is the situation you are in once you are managing several Linux servers at once and need each one to be provably the same as the others.

How long is one release supported?

The release policy is the part of a distribution you live with longest, and it is published as a number of years. Here are the 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 supports each 3.x branch for 2 years, which is why it fits a container image you rebuild often better than a host you leave alone. Debian's security team covers a stable release for about 3 years, and the LTS team then carries the common architectures to roughly 5 years in total. An Ubuntu LTS gives you 5 years for packages in main, and an Ubuntu Pro subscription extends that to 10 years, free for personal use on a small number of machines. RHEL 10 publishes 10 years, which the paid extended life cycle support add on stretches to 13. AlmaLinux 10 matches the RHEL window of 10 years with no subscription at all, which is the entire reason the rebuilds exist.

Arch has no row here, because a rolling distribution has no release to support. The number that matters for Arch is how long you can leave a machine untouched, and that is measured in weeks.

Why your VPS image list looks like this

A provider ships the images customers ask for by name and that install unattended on its hypervisor. That is why nearly every list opens with an Ubuntu LTS and a Debian stable, adds AlmaLinux or Rocky for people whose software is certified against RHEL, and keeps Alpine, Arch and Fedora further down the page. Once you know what a VPS is and how the image reaches the disk, the pattern reads clearly: the provider is picking operating systems that survive an unattended install and stay supported longer than the average customer keeps the server.

The choice commits you to more than a package manager. It sets the upgrade you will run in three years, and those differ completely by family. Debian and Ubuntu support in place major upgrades. The Red Hat family runs them through leapp. Arch has no upgrade because it has no version. Alpine's is editing /etc/apk/repositories and running apk upgrade --available. The choice also sets which software you can install without adding a third party repository, who ships the patch when a CVE (common vulnerabilities and exposures) entry lands on something you run, and which init system and C library your future software will assume is present.

There is one more effect that is easy to underrate. Most answers written on the internet assume a Debian family path or a Red Hat family path, so picking outside those two means translating instructions for the life of the machine. Pick the family whose release policy matches how often you are willing to touch the server, then keep it. Changing the packages on top is easy. Changing the distribution under them means rebuilding the box.

FAQ

Which Linux distribution family is my server in?

Run cat /etc/os-release. The ID field names the distribution and ID_LIKE names its family, so an Ubuntu machine reports ID_LIKE=debian and an AlmaLinux machine reports ID_LIKE="rhel centos fedora". The package manager is the other tell. apt and dpkg mean the Debian family, dnf and rpm mean the Red Hat family, apk means Alpine, and pacman means Arch.

Is CentOS still a free version of RHEL?

No. CentOS Linux 8, the last rebuild of that name, ended on 31 December 2021, and CentOS Linux 7 reached the end of its life on 30 June 2024. The surviving project, CentOS Stream, is the branch RHEL minor releases are built from, so it gets changes before RHEL does rather than after. The free rebuilds that took over the old role are AlmaLinux and Rocky Linux, both with ten year windows.

Why does Debian stable ship such old version numbers?

Because the version number freezes while the fixes keep coming. Debian backports security patches into the version it released instead of importing a newer upstream release, so a package that reads 2.4.57-2+deb13u1 can carry a fix published last week. The suffix after the upstream version is the Debian revision, and apt changelog <package> lists what went into it. Judging a Debian server's security by its version numbers gives the wrong answer every time.

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

Only if you will update it on a schedule. A rolling distribution assumes every machine converges on the current package set, so updating one package with pacman -Sy foo leaves mismatched libraries and errors such as cannot open shared object file. Run pacman -Syu regularly, read the project news page before each run, and the system is stable. Leave it for a year and the first upgrade becomes the risky one.

What does an immutable or atomic distribution actually change?

It changes when updates apply and how you undo them. /usr is mounted read only, an update is staged as a complete new tree, and the switch happens at reboot, with the previous tree kept as a boot entry for rollback. You get a machine that is either fully updated or fully not, with no half applied state. You give up installing software by editing files in place, so applications move into containers or into layered packages.