1. Why there are so many distros

Linux isn’t an operating system. It’s a kernel. A distribution is the kernel plus everything around it that turns it into something you can actually boot, log into and use.

That “everything” is a long list of decisions: a userland (the GNU coreutils, or BusyBox, or something in between), a package manager and its format (.deb, .rpm, source ebuilds, gzipped tarballs), a release cadence (frozen point releases, true rolling, hybrid), an init system, a service model, defaults for filesystems and networking, an opinionated security posture, and a community to maintain it all. Each of those is a meaningful choice, and reasonable people kept making different ones.

Most surviving distros descend from one of three commercial-grade lineages, all started in the early 1990s: Debian (1993), Red Hat (1994), and SUSE (1994, branching off Slackware). A handful of independent projects built their own thing from scratch (Slackware itself, Arch, Gentoo), plus two specialists with strong opinions about how a Linux system should be assembled: Alpine and NixOS. That covers most of what matters in 2026.

What follows walks through them roughly in order of age. For each one: where it came from, what makes it distinct, who runs it, and the trade-offs.

2. Slackware (1993)

Slackware is the oldest surviving Linux distribution. Patrick Volkerding cut the first release in July 1993, predating Debian by a month and Red Hat by more than a year. It’s still maintained, still released by the same person, still recognizably itself thirty-plus years later.

Slackware’s design choice is to do less for you. Packages are gzipped tarballs with a tiny installer script. The default package tools (pkgtool, installpkg, slackpkg) do not resolve dependencies: if you install something that needs another library, you install the library yourself. Configuration files are not auto-generated by helper scripts; you edit them. Init is BSD-style rc scripts, not systemd, not OpenRC. Nothing on the system happens behind your back.

This sounds like 1995 because in many ways it is. The payoff: you configured it, so you can fix it. People who run Slackware in 2026 tend to know exactly what’s on their machines down to the file.

The release cadence is glacial: Slackware 15.0 shipped in February 2022, six years after 14.2. Don’t run it for fresh packages. Consider it if you want a small, transparent, conceptually simple Linux that doesn’t try to be clever.

3. Debian (1993)

Ian Murdock announced Debian in August 1993, a month after Slackware. The name is a portmanteau of his then-girlfriend Debra’s first name and his own. What he wanted was a distribution built openly, by volunteers, with explicit policies about how packages enter the system and what quality bar they have to meet. That governance model is roughly what every serious distribution uses today.

Debian’s reputation is stability. The stable branch freezes for months before each release and only carries well-tested package versions; you trade fresh software for the certainty that apt upgrade on a production server won’t surprise you. Testing is what stable will become, and unstable (codename “sid”, permanently) is the rolling integration branch where new package versions land first.

The .deb package format and the apt/dpkg ecosystem are Debian’s other lasting contributions. A large fraction of the distros people actually run are downstream of Debian: Ubuntu first, and then everything downstream of Ubuntu (Linux Mint, Pop!_OS, Elementary OS, Zorin). Direct Debian derivatives include Kali (the standard penetration-testing distribution), Raspberry Pi OS (the official OS for the Pi family), Tails (a privacy-focused live distribution that routes all traffic through Tor) and Devuan (Debian with systemd removed).

Debian also holds the firmest free-software stance of any major distribution, codified in the Debian Free Software Guidelines and the Social Contract. Nothing non-free ships in the default install. The practical concession, added in 2022, is that the installer can pull in non-free firmware on request, because wireless radios don’t run on principles.

4. Red Hat and RHEL

Red Hat Enterprise Linux (RHEL) is the commercial Linux distribution that defines what enterprise Linux means in practice. Marc Ewing started Red Hat Linux in 1994. The name comes from a red Cornell lacrosse cap his grandfather had given him, which he wore in the computer science labs at university to the point that people associated him with it. Bob Young joined the next year, the company incorporated as Red Hat Software, and the product went on to become the reference point everyone else in the RPM world targets.

The original Red Hat Linux ran through 1999 and was discontinued in 2003. Red Hat split the product line that year: Fedora became the community-facing fast-moving distribution, and Red Hat Enterprise Linux (RHEL) became the paid, long-supported enterprise product. RPM, Red Hat’s package format, became the second universal Linux packaging format after .deb.

RHEL’s pitch is predictability. A major release is supported for ten years. The ABI is held stable across the support window so commercial software vendors can certify their products against, say, “RHEL 9” exactly once and trust the contract. The kernel ships with backported fixes rather than new minor versions. Regulated industries (banks, governments, telecoms, hospitals, aerospace) run RHEL on this promise.

IBM acquired Red Hat in 2019 for $34 billion, the largest open-source-company acquisition in history at the time. The product, in 2026, remains the dominant commercial Linux distribution. Almost everything serious in the RPM world descends from or targets compatibility with RHEL.

5. Fedora

Fedora is where new Linux technology lands first. It was spun out of Red Hat Linux in 2003 to give the community a fast-moving distribution and to give Red Hat a public proving ground for what would eventually make it into RHEL. The dual role still holds.

The release cycle is six months. Each version is supported for roughly thirteen months: long enough to use, short enough to keep the project moving. Fedora Workstation has been the reference platform for upstream GNOME development for over a decade.

Look at the systems-software change log of the last fifteen years and Fedora keeps showing up. systemd became the default init here in 2011, three years before Debian adopted it. Wayland replaced X11 as the default session in 2016, btrfs became the default filesystem on Workstation in 2020, and PipeWire replaced PulseAudio as the default audio server the following year. If a new piece of desktop-Linux plumbing is becoming a default, Fedora usually shipped it first.

Beyond Workstation, the project ships Fedora Server, Fedora CoreOS (a minimal, container-host OS with automatic atomic updates), and Fedora Silverblue (an immutable desktop variant where the root filesystem is a versioned, signed image you rebase onto rather than a directory tree you mutate). The Silverblue model is increasingly where Linux desktops are heading, and Fedora is the one shipping it as a first-class option.

The “first to ship” posture has a flip side. In 2024, Red Hat developers proposed adding telemetry to Fedora Workstation; the initial draft was opt-out, and community pushback was loud enough to rework it into opt-in (a checkbox during initial setup). Even the opt-in form stayed controversial: Linux distributions traditionally don’t ship telemetry, and Fedora’s IBM/Red Hat ownership raises questions about long-term scope. Privacy-leaning users have since drifted toward distributions without any telemetry path at all.

Roughly: Fedora is what RHEL will look like in two or three years.

6. CentOS, Rocky, and AlmaLinux

Rocky Linux and AlmaLinux are the two community RHEL rebuilds that emerged after CentOS pivoted to a rolling preview in 2020. For most of the 2010s, if you wanted RHEL without paying for it, you ran CentOS. The project, started in 2004, rebuilt RHEL’s source packages bit-for-bit, stripped the trademarks, and shipped a binary-compatible free distribution. Universities, hobbyists, and a non-trivial fraction of small companies ran CentOS in production. Red Hat acquired CentOS in 2014, mostly to bring its development in-house.

That arrangement ended abruptly in December 2020. Red Hat announced that CentOS Linux 8 would end at the close of 2021, ten years earlier than the original commitment, and that CentOS Stream, a rolling preview of what would become the next RHEL minor release, would replace it. The community read this as the end of free RHEL, and that wasn’t entirely wrong.

Two rebuilds appeared within weeks. Rocky Linux, founded by Greg Kurtzer (one of the original CentOS founders), and AlmaLinux, founded by CloudLinux, both promised what CentOS had been: a free, bug-for-bug RHEL clone. Both were running stable releases by mid-2021 and quickly absorbed most of the migrating CentOS user base.

Then a second wave hit in mid-2023. Red Hat restricted access to RHEL source RPMs, breaking the rebuild workflow both projects had been using. Rocky pivoted to reconstructing sources from publicly available RHEL components: UBI images, CentOS Stream, customer source access via small RHEL subscriptions. AlmaLinux took a different tack and declared they’d no longer chase 1:1 binary compatibility, instead shipping an ABI-compatible distribution drawing from CentOS Stream. SUSE forked a separate project, SUSE Liberty Linux, to provide commercial RHEL-compatible support for the same audience.

The practical situation in 2026: Rocky and AlmaLinux are both healthy and usable as free RHEL alternatives, with the caveat that “free RHEL” comes with rougher edges than it used to. If RHEL compatibility is what you want and you don’t want to pay Red Hat, those are the choices.

7. SUSE and openSUSE

SUSE is the third major lineage, less visible to American developers but enormous in Europe and in SAP shops everywhere. Four German students started the company in 1992 as Software und System-Entwicklung, a Unix consultancy. They shipped a German translation of Slackware as their first product, gradually replaced more of it, and by the late 1990s SUSE Linux was a fully independent RPM-based distribution with its own engineering and a strong commercial business.

The corporate product, SUSE Linux Enterprise (SLE), competes directly with RHEL. The community side has two flavors: openSUSE Leap, a stable point-release distribution that shares its codebase with SLE, and openSUSE Tumbleweed, a true rolling-release distribution that’s surprisingly stable for what it is. Tumbleweed is one of the few rolling distros people regularly run on production servers without flinching.

What SUSE is known for, beyond its corporate footprint, is two pieces of software. YaST is a unified system-configuration tool that covers package management, network, firewall, users, services, partitioning, and a dozen other things under one interface (CLI or GUI). It’s the closest thing the Linux world has to a coherent “control panel”. snapper takes btrfs snapshots before every package transaction, so that zypper dup followed by a broken boot is recoverable from the GRUB menu by selecting the pre-transaction snapshot. It’s the most polished implementation of “filesystem snapshots as system rollback” in any mainstream distribution.

The corporate parent changed hands several times: Novell (2003), Attachmate (2011), Micro Focus (2014), EQT (2018). SUSE is now standalone and publicly traded again, and the distribution outlived all the corporate drama.

8. Gentoo

Gentoo is source-based. You don’t install precompiled packages; you install Portage, which downloads source tarballs and compiles them on your machine with the compiler flags and optional features you’ve configured for that system.

Daniel Robbins released Gentoo Linux 1.0 in 2002. The name comes from the Gentoo penguin, the fastest-swimming species, picked because Robbins originally optimized the distribution heavily for performance via target-specific compile flags. Portage itself is conceptually similar to FreeBSD ports: ebuilds (text scripts describing how to build a package) live in a single repository that you sync, and the emerge command resolves dependencies, fetches sources, applies patches, and runs the build.

USE flags are the part Gentoo is famous for. A package built with USE="ssl postgres -mysql" includes SSL support and PostgreSQL backends and explicitly excludes MySQL ones. The same compile-time switching applies to roughly every package on the system. You can build a remarkably stripped-down or remarkably feature-rich version of any piece of software without ever leaving the package manager. Want PulseAudio support stripped out of every package that touches audio? One global USE flag and a full rebuild.

The trade-off is the obvious one: compiling everything takes time. A full emerge --update --deep world can take hours on a slow machine and overnight on a Raspberry Pi. People run Gentoo anyway for two reasons: they want the configurability, and the act of compiling the system end-to-end teaches them how it fits together. “The distro that taught me Linux” is a reputation both Gentoo and Arch claim, and both are deserved for different reasons.

Gentoo’s influence outside its own user base is bigger than it looks. Chrome OS is built on Chromium OS, which uses Portage and Gentoo’s build infrastructure underneath. Funtoo, started by Robbins after he left Gentoo’s foundation, is a fork that experimented with Git-backed Portage and a few other ideas.

9. Arch

Arch Linux is a rolling-release distribution built around minimalism and direct exposure to upstream software. Judd Vinet released the first version in 2002. The design philosophy, later formalized as “the Arch Way”, picks five principles: simplicity, modernity, pragmatism, user-centrality, and versatility. The word “simplicity” in Arch’s vocabulary specifically means “without unnecessary abstraction” rather than “easy for beginners”. This distinction matters: Arch tries hard not to wrap upstream software in distro-specific configuration layers.

Arch is rolling-release. There are no major versions, just a continuous stream of upstream package updates that you pacman -Syu whenever you feel like it. Packages reach Arch fast, usually within days of upstream release. The base install is intentionally minimal: early Arch had no installer at all, just a base tarball and a long installation guide on the wiki; the archinstall script only landed in 2021 and is still entirely optional. The expectation is that you read the docs and assemble your own system.

The AUR (Arch User Repository) is Arch’s other defining feature. It’s a community-maintained collection of build scripts (PKGBUILDs) for software that isn’t in the official repositories. Wrappers like yay and paru let you install AUR packages with the same ergonomics as official ones. If a piece of software exists on Linux, it’s probably in the AUR.

The Arch Wiki deserves its own mention. It’s arguably the best technical documentation in the Linux ecosystem, regularly consulted by people running entirely different distributions. If you’ve ever searched for a kernel module name or a systemd unit option and ended up reading an Arch Wiki page on Debian, you’ve already used Arch.

Notable derivatives: EndeavourOS gives you Arch with a friendly installer and tasteful defaults while staying close enough to upstream that the Arch Wiki applies directly. Manjaro delays Arch’s package updates by about a week to add a stability buffer. The choice is contentious (Arch users argue it combines rolling-release fragility with point-release staleness), but it has a real audience. CachyOS is a newer entrant tuning the kernel and toolchain specifically for desktop performance.

10. Ubuntu

Ubuntu is the Debian derivative that made desktop and cloud Linux mainstream, backed by a commercial sponsor and a predictable release cadence. Mark Shuttleworth founded Canonical in 2004 and released the first Ubuntu (4.10, “Warty Warthog”) in October of that year. The pitch was Debian, but with predictable six-month releases, a friendly installer, sensible desktop defaults, and a commercial entity behind it that would answer the phone if you paid them. The marketing tagline at the time, “Linux for human beings”, reads as dated now but accurately captured how different that proposition was from the Debian or Slackware experience of 2004.

Ubuntu became the way most non-technical users encountered Linux for a decade. It also became the default operating system for cloud images: every major cloud provider ships official Ubuntu AMIs, and “Ubuntu LTS” became the de facto target for server-side software that needed a base OS to install onto.

The release cadence is six months for interim releases and two years for LTS (Long Term Support) versions. LTS gets five years of standard support, extendable to ten years with Ubuntu Pro (free for personal use up to a small number of machines). Most Ubuntu in production is LTS.

The contentious bits are mostly around snap, Ubuntu’s universal package format and store, which Canonical pushes aggressively (apt-installing Firefox on recent Ubuntu installs a snap behind the scenes). Snaps are slower to start than native packages, use more disk, and the store backend is proprietary. They also work, and they make life easier for software vendors trying to ship one binary across distributions, so the criticism is real but not decisive.

Notable derivatives group along two axes. The Windows-refugee polish lane: Linux Mint takes Ubuntu LTS, removes snap, and ships Cinnamon (a traditional GNOME 2-style desktop) by default, which is why it’s the distribution most often recommended to people switching from Windows. Zorin OS sits in the same lane, targeting Windows refugees with a layout switcher and a polished installer. Elementary OS chases a macOS-like aesthetic instead, shipping its own Pantheon desktop. The hardware-and-environment lane: Pop!_OS, from hardware vendor System76, ships with sensible NVIDIA support out of the box and is developing COSMIC, a Rust-based desktop environment built specifically for it. KDE neon pairs Ubuntu LTS with the latest upstream KDE Plasma.

11. Alpine

Alpine is a small, security-focused Linux distribution built on musl libc and BusyBox. The base container image is about five megabytes, compared to Ubuntu’s eighty-plus and Debian slim’s thirty-plus. That number is the reason most container images on the internet have an “Alpine variant”, and why Alpine is by a long way the most-pulled Linux distribution on Docker Hub.

The size comes from two architectural choices: musl libc instead of glibc, and BusyBox in place of the GNU userland. musl is a clean-room C standard library implementation focused on correctness and small size. BusyBox is the embedded-Linux convention of replacing all the standard userland utilities (ls, cp, sh, awk, sed, dozens more) with a single multi-call binary. Both choices make Alpine smaller and reduce its attack surface, and both come with real compatibility trade-offs.

The most common trade-off in practice: prebuilt binaries compiled against glibc don’t run on Alpine. This bites people running Alpine-based containers for Node.js, Python, or .NET, where the set of official prebuilt wheels and native modules assume glibc. Workarounds exist (install a glibc compatibility shim, build from source against musl, switch base image) and production teams often end up picking debian:slim over alpine for this single reason.

Alpine has uses far beyond containers. The original target was embedded systems; the project started in 2005 as a fork of the Linux Router Project, and Alpine still runs on routers, firewalls, and small appliances. postmarketOS, a Linux distribution aimed at running on retired Android smartphones, is built on Alpine.

The apk package manager is unrelated to Android’s APK format — Alpine’s predates Android by several years. It’s fast and the official repository is smaller than apt’s or dnf’s but actively maintained.

12. NixOS

NixOS is the most architecturally different distribution on this list. The premise: the entire system (every installed package, every service configuration, every user account, every kernel parameter) is described declaratively in a configuration file. When you change the configuration, you don’t mutate the running system. You build a new version of the whole system and atomically switch to it.

The project started with Eelco Dolstra’s 2003 PhD work at TU Delft on the Nix package manager. NixOS, the distribution built on top of Nix, reached 1.0 in 2013. The central data structure is /nix/store, a content-addressed directory where every package version is installed at a path like /nix/store/<hash>-<package-name>-<version>/. The hash is computed from every input that went into building the package: source, dependencies, compiler version, build flags. Change anything in the inputs, get a different hash and a different path.

The consequences are interesting. Multiple versions of the same package coexist without conflict because their store paths differ. A package and its dependencies are uninstallable as a unit by garbage-collecting unreferenced store paths. The system’s current state is defined by a single file (/etc/nixos/configuration.nix), so reproducing a machine elsewhere is mostly a matter of copying that file over and running one command. nixos-rebuild switch builds a new “generation” of the system; the bootloader keeps the last several generations around, so booting back into yesterday’s working system after a botched upgrade is a menu selection at boot.

A representative slice of a configuration file:

{ config, pkgs, ... }: {
  imports = [ ./hardware-configuration.nix ];

  networking.hostName = "thinkpad";
  time.timeZone = "Europe/Istanbul";

  services.openssh = {
    enable = true;
    settings.PasswordAuthentication = false;
  };

  environment.systemPackages = with pkgs; [
    git tmux ripgrep firefox
  ];

  users.users.emre = {
    isNormalUser = true;
    extraGroups = [ "wheel" "networkmanager" ];
  };

  system.stateVersion = "25.05";
}

That’s the entire system. Apply it, and your machine has those packages, that hostname, that SSH config, and that user. Copy the file to another machine, apply it, and you get the same machine.

Flakes, an opt-in mechanism that’s become the de facto standard, take this further by requiring every external input to be pinned by hash, including the Nixpkgs revision that provides most of the packages. A flake-based system is bit-for-bit reproducible across machines and across years.

The trade-off is the learning curve. The Nix language is a small lazy functional language with idiosyncratic syntax. Packaging anything not already in nixpkgs (the central package collection, currently the largest in the Linux world) takes real work. Standard FHS-assuming software doesn’t always cooperate because executables aren’t at the paths it expects; NixOS provides escape hatches (buildFHSEnv, steam-run, and friends), but each one is friction.

Run NixOS if you like the design and want the reproducibility, or if you want per-project development environments that are fully defined in version control and identical across machines. Don’t pick it expecting it to feel like another Linux. It doesn’t, by design, and the people who use it tend to consider that the point.