Linux concept: distribution

Nobody installs "Linux". You install Ubuntu, Debian, Fedora, Arch, or Alpine, and each one hands you the same kernel wrapped in a different set of programs, a different package manager, a different update rhythm, and a different idea of what a finished system should look like. Ask two administrators how to install a web server and you can get two different commands, both correct. The thing that decides which command is right on your machine is the Linux distribution, and once you understand what a distribution actually is, half of the confusing differences between Linux systems suddenly make sense.

2. Where the Name Comes From

The word distribution describes the original job quite literally. In the early 1990s, "installing Linux" meant collecting the kernel from one place, the GNU tools from another, a C library, a shell, and dozens of small programs from yet other places, compiling them, and making them fit together yourself. A distribution was someone who had already done that work and distributed the result as a ready-made set of disk images. You were not getting a different operating system, you were getting a delivery.

That is still the core of the word. A distribution writes very little of the software it ships. Its real product is the selection, the integration, the packaging, and the promise to keep delivering fixes. The short form distro is informal, but it is so common that you will see it in official documentation too.

The names of individual distributions often carry a story of their own:

• Debian is a contraction of the names of Debra and Ian Murdock, who founded the project. The project pronounces it "Deb-ee-en" (Debian FAQ).
• Ubuntu is, in the project's own words, "an ancient African word meaning 'humanity to others'" (ubuntu.com/about).
• Release codenames are a distribution habit, not a Linux one. Debian names its releases after characters from Toy Story (Debian 13 is trixie), Ubuntu uses an alliterating adjective and animal (24.04 is "Noble Numbat", codename noble). You will see these codenames in repository configuration files far more often than the version numbers.

4. Simple Use Cases

The first questions on any new server are always the same: what is this, which version, and how is it supported? The answers are all in a few files and commands.

4.1 Read os-release

You saw /etc/os-release above. It is the standard answer, and it exists on Debian, Ubuntu, Fedora, AlmaLinux, Arch and Alpine alike. Even a minimal container image ships it:

$ cat /etc/os-release        # inside an Alpine container
NAME="Alpine Linux"
ID=alpine
VERSION_ID=3.23.3
PRETTY_NAME="Alpine Linux v3.23"
...

If a server is so old that it has no /etc/os-release, that fact alone tells you something important: it has not been upgraded in a very long time.

4.2 hostnamectl and lsb_release

On a system that runs systemd, hostnamectl prints the distribution together with the kernel and the hardware, which is a quick overview of the whole machine:

$ hostnamectl
 Static hostname: xps
...
Operating System: Ubuntu 24.04.5 LTS
          Kernel: Linux 7.0.0-34-generic
    Architecture: x86-64

Older tutorials use lsb_release, where the -a flag (short for "all") prints everything it knows. It works on Ubuntu, but it is a separate package and is often missing on minimal and container installs, so do not rely on it in scripts:

$ lsb_release -a
Distributor ID: Ubuntu
Description:    Ubuntu 24.04.5 LTS
Release:        24.04
Codename:       noble

4.3 Distribution Version Is Not Kernel Version

This one confuses people constantly. The distribution has a version, and the kernel has a completely separate version:

$ grep VERSION_ID /etc/os-release
VERSION_ID="24.04"

$ uname -r
7.0.0-34-generic

24.04 is Ubuntu's release, named after its year and month: April 2024. 7.0.0 is the Linux kernel, which on this laptop is much newer than the distribution, because Ubuntu offers newer kernels to LTS releases for newer hardware. When a vendor asks "which Linux version?", they almost always want both numbers.

4.4 Finding Out How Long Your Release Is Supported

Every fixed release has an end date, after which it no longer receives security fixes. That date is the single most important fact about a server's operating system, and the numbers are very different per distribution:

Look up the date for your exact release on the distribution's own site, and write it down next to the server's name. A server that quietly passes that date keeps running perfectly; it simply stops getting fixed.

4.5 Moving to the Next Release

The way out of an ending release is an in-place upgrade to the next one, and each family has its own procedure. On Ubuntu it is one command, and Ubuntu's documentation adds that "you can only upgrade from one LTS release directly to the next sequential LTS release". Whether the tool even offers non-LTS releases is set in a small configuration file:

$ grep Prompt /etc/update-manager/release-upgrades
Prompt=lts

$ sudo do-release-upgrade          # Ubuntu: upgrade to the next release

Debian has no such tool. Its release notes tell you to change the codename in your APT sources (bookworm becomes trixie), then run apt update, apt upgrade --without-new-pkgs, and finally apt full-upgrade. Fedora uses a dnf command that downloads everything first and installs it during a reboot:

$ sudo dnf system-upgrade download --releasever=45   # Fedora: fetch the next release
$ sudo dnf system-upgrade reboot                      # install it during a restart

Whatever the family, read the release notes first and make a backup. A release upgrade replaces hundreds of packages at once, which is the riskiest moment in a fixed-release system's life.

6. Advanced Use Cases

The sections above were about reading. This section is about the places where distribution differences bite: scripts that must run everywhere, version strings you need to decode, containers, and binaries that refuse to run.

6.1 Writing Scripts That Know the Distribution

/etc/os-release is designed to be read by scripts. Its format is simple shell variable assignments, so a script can load it with the . command and then test the variables:

#!/bin/sh
. /etc/os-release

case "$ID" in
    debian|ubuntu)  pkg="apt-get install -y" ;;
    fedora|almalinux|rhel) pkg="dnf install -y" ;;
    opensuse-leap)  pkg="zypper install -y" ;;
    arch)           pkg="pacman -S --noconfirm" ;;
    alpine)         pkg="apk add" ;;
    *)              echo "Unknown distribution: $ID" >&2; exit 1 ;;
esac

That works until someone runs your script on a distribution you have never heard of. That is what ID_LIKE is for. The os-release manual says build scripts "should check this variable if they need to identify the local operating system and the value of ID= is not recognized". AlmaLinux, for example, declares three relatives, closest first:

$ grep -E '^(ID|ID_LIKE)=' /etc/os-release    # inside an AlmaLinux 9 container
ID="almalinux"
ID_LIKE="rhel centos fedora"

So a robust script checks ID first, then walks through ID_LIKE. A distribution derived from Ubuntu will usually say ID_LIKE contains ubuntu or debian, and your apt branch will just work. Note that the format deliberately supports no shell features beyond plain assignments, so other programs can parse the file without a shell. The full field list is in man os-release and on the systemd documentation site.

6.2 Reading a Distribution's Version String

A package version on a distribution is not the upstream version. It is the upstream version plus the distribution's own history of changes. Take the SSH client on Ubuntu 24.04:

$ dpkg -l openssh-client | tail -1
ii  openssh-client 1:9.6p1-3ubuntu13.19 amd64        secure shell (SSH) client, ...

Read 1:9.6p1-3ubuntu13.19 from left to right:

That one string tells the whole family story from section 3.1: upstream code, packaged by Debian, changed again by Ubuntu. RPM-based distributions encode the same idea differently; coreutils-9.10-5.fc44 means upstream 9.10, Fedora's fifth build, for Fedora 44.

6.3 Distributions in Containers

When you write FROM debian or FROM alpine in a Dockerfile, you are choosing a distribution. A container image contains a distribution's userland, its package manager and its /etc/os-release, but not a kernel. Every container on a host uses the host's kernel:

$ uname -r                                   # the Ubuntu host
7.0.0-34-generic

$ docker exec web uname -r                   # an Alpine container on it
7.0.0-34-generic

$ docker exec web grep PRETTY /etc/os-release
PRETTY_NAME="Alpine Linux v3.23"

This Alpine container is not a demo: it is the Apache container from my own local Joomla development stack, running on this Ubuntu laptop. The container honestly reports itself as Alpine, and it honestly runs on Ubuntu's kernel. Both are true, because a distribution and a kernel are different layers. This is the practical proof of the stack in section 1.2. The Docker article explains the kernel features that make this possible.

A virtual machine is the opposite case. It emulates a whole computer, so the guest boots its own kernel, and a Debian VM really does run a Debian kernel. If you need a different kernel version or kernel settings than the host, you need a VM, not a container.

A container image is also not always a complete distribution. Base images are trimmed hard, and the smallest ones may have no init system, no shell, or no package manager at all. That is normal: an image only has to run one application, not boot a machine.

6.4 When a Binary Will Not Run: glibc versus musl

Almost every distribution uses the GNU C library, glibc. Alpine is different: it is "built around musl libc and busybox". The C library is the layer that nearly every program calls for basic things such as opening files, so a program compiled against glibc expects glibc to be there. Copy the ls binary from Ubuntu into an Alpine container and try to run it:

$ file /usr/bin/ls
/usr/bin/ls: ELF 64-bit LSB pie executable, x86-64, ... interpreter /lib64/ld-linux-x86-64.so.2 ...

$ docker run --rm -v /usr/bin/ls:/tmp/ls:ro httpd:alpine sh -c '/tmp/ls /'
sh: /tmp/ls: not found

"Not found" for a file that clearly exists is one of the most confusing errors in Linux. The file is there. What is missing is the interpreter named inside it, /lib64/ld-linux-x86-64.so.2, glibc's program loader, which Alpine does not have. Alpine has its own, musl's:

$ docker exec web sh -c 'ls /lib/ld-musl*'
/lib/ld-musl-x86_64.so.1

The same thing happens with a downloaded binary built for one family and run on another, or with a pre-built language package (a PHP extension, a Python wheel, a Node module) that was compiled for glibc. The fix is to install the distribution's own package, or a build made for musl. That is what the PHP image of my own Joomla development stack does: it starts from php:8.3.26-fpm-alpine, installs g++, make and the ImageMagick -dev headers, and compiles the imagick extension with pecl inside the image, so the result links against musl rather than glibc. A binary is only portable between distributions that share its C library.

6.5 Alpine's Commands Are BusyBox

The apk info --who-owns answer in section 5.2 hinted at it: on Alpine, ls is not GNU ls at all. It is a symbolic link to BusyBox, one single program that behaves like ls, cp, sh and hundreds of other commands depending on the name it was called by:

$ docker exec web ls -l /bin/ls /bin/sh
lrwxrwxrwx    1 root     root            12 Jan 28  2026 /bin/ls -> /bin/busybox
lrwxrwxrwx    1 root     root            12 Jan 27  2026 /bin/sh -> /bin/busybox

$ docker exec web ls --version
ls: unrecognized option: version

That is why Alpine images are so small, and why GNU-only flags from a tutorial can fail inside them. The default shell differs per distribution too: on Debian and Ubuntu, /bin/sh is dash; on Fedora, it is bash; on Alpine, it is BusyBox. A script that starts with #!/bin/sh gets a different shell on each. The POSIX article explains how to write scripts that survive that.

6.6 Software That Bypasses the Distribution

Not everything on a modern system comes through the distribution's own repositories. Formats such as snap and Flatpak ship an application together with the libraries it needs, so the same package runs on many distributions. Ubuntu 24.04 goes further and delivers Firefox this way. The Firefox .deb is only a placeholder that points at the snap:

$ dpkg -l firefox | tail -1
ii  firefox        1:1snap1-0ubuntu5 amd64        Transitional package - firefox -> firefo...

$ snap list firefox
Name     Version  Rev   Tracking         Publisher  Notes
firefox  157.0-1  8995  latest/stable/... mozilla**  -

Look at the Publisher column: this Firefox is built and updated by Mozilla, not by Ubuntu. That changes who is responsible for the fixes. Everything section 7.1 says about distribution maintainers backporting security patches applies to the packages from the distribution's repositories. A snap, a Flatpak, a container image or a binary you downloaded is patched by whoever published it, on their schedule, and apt upgrade does not touch it. On a server, keep a list of what came from where, and check each source separately.

8. Best Practices

• Read /etc/os-release first. On any unfamiliar server, know the distribution, the release, and the family before you type a single install command.
• Choose a fixed-release LTS distribution for servers. Predictable versions and years of security fixes matter far more on a production machine than having the newest software.
• Write down the end-of-support date. Keep it next to the server's name and plan the upgrade well before it. A server past that date still runs; it just stops being fixed.
• Install software from the distribution's repositories. Its packages are signed, tested together, and receive backported security fixes. A program you compile or download yourself is a program you have to patch yourself.
• Judge security by package version, not upstream version. Check the distribution's security notices or the package changelog before trusting a scanner that only reads the upstream number.
• Use ID and ID_LIKE in scripts. Never parse PRETTY_NAME or /etc/issue; they are for humans and change format.
• Match the C library when you copy binaries or build images. A glibc binary will not run on Alpine, and a "not found" error for a file that exists usually means exactly that.
• Keep the same family across your servers when you can. One package manager, one set of paths, one set of habits: fewer surprises at three in the morning.
• Read the documentation. man os-release describes every field, and each distribution's own handbook or wiki is the reference for its tools.

$ man os-release        # every field of the identity file
$ man hostnamectl       # system identity on systemd distributions
$ man dpkg              # Debian family packages (rpm, pacman, apk elsewhere)

10. Summary

A Linux distribution is the complete operating system around the kernel: the userland, the C library, the package manager and repositories, the init system, the defaults, and the promise to keep it all patched for a defined number of years. The kernel is shared. Everything you notice in daily work, the commands, the versions, the update rhythm, is the distribution.

• A distribution (or distro) bundles the Linux kernel with upstream software, packages it, and maintains it; the name comes from literally distributing that bundle.
• /etc/os-release identifies the system: ID and VERSION_ID for scripts, ID_LIKE for the family, PRETTY_NAME for humans.
• There are so many distributions because each one strikes a different balance between stability, freshness, size, support length and governance.
• Most distributions belong to a family: Debian (apt, .deb), Red Hat (dnf, .rpm), SUSE (zypper, .rpm), or an independent one such as Arch or Alpine.
• Distributions also choose the security module: AppArmor on Ubuntu, SELinux on Red Hat Enterprise Linux.
• Slackware and Debian both started in 1993; Ubuntu followed in 2004, built on Debian; AlmaLinux and other rebuilds filled the gap after CentOS Linux 8 ended in 2021.
• Fixed releases freeze versions and backport fixes; rolling releases such as Arch update continuously and have no version number; image-based systems such as Fedora Silverblue and NixOS replace the whole system in one step and keep the previous one bootable.
• Every fixed release ends; do-release-upgrade, Debian's codename switch plus apt full-upgrade, and dnf system-upgrade move you to the next one.
• The distribution version and the kernel version are different numbers; you usually need both.
• Every file belongs to a package: dpkg -S, rpm -qf, pacman -Qo, apk info --who-owns.
• A distribution package version such as 1:9.6p1-3ubuntu13.19 contains the upstream version plus the distribution's own revisions, so an old upstream number can still be fully patched.
• Containers carry a distribution's userland but use the host's kernel; a virtual machine boots its own.
• Snaps, Flatpaks, container images and downloaded binaries bypass the distribution, so their publisher, not the distribution, is responsible for patching them.
• Binaries are tied to their C library: a glibc program reports "not found" on musl-based Alpine, whose commands are BusyBox.

This is the quick reference worth keeping:

cat /etc/os-release                 which distribution, release and family
. /etc/os-release; echo "$ID"       the distribution ID inside a script
hostnamectl                         distribution, kernel and hardware at once
uname -r                            the kernel version (not the distro version)
cat /etc/debian_version             Debian family: the parent release
dpkg -S FILE                        Debian/Ubuntu: which package owns a file
rpm -qf FILE                        Fedora/RHEL/SUSE: which package owns a file
pacman -Qo FILE                     Arch: which package owns a file
apk info --who-owns FILE            Alpine: which package owns a file
apt-cache policy PKG                Debian/Ubuntu: installed version and its repository
cat /sys/kernel/security/lsm        active security modules (apparmor, selinux)
snap list                           software that bypasses the distribution
sudo do-release-upgrade             Ubuntu: move to the next release
file BINARY                         which loader (glibc or musl) a program expects
man os-release                      every field explained

And if a security scan flags a server as dangerously out of date while every update has been installed, the answer is often a distribution that quietly backported the fixes and kept the old version number.