You already know that Linux is a kernel and that its history explains its design. What remains is the indispensable intermediate step before installing anything: understanding what a distribution really is and why there are hundreds of them.

This lesson settles a doubt that blocks many people at the start: "which one do I choose?". The professional answer is not "the best one", because there is no such thing: it is "the one that fits what I am going to do, what my team already knows, and how many years I need it to last". You are going to see which pieces make up a distribution, how the three big families really differ, what LTS means and why it is decisive on a server, and how to choose with sound judgement. At the end we will reconstruct Tramontana S.L.'s decision step by step: why srv-tramontana runs Ubuntu Server 24.04 LTS and not something else.

1. What a distribution really consists of
2. The Debian family: Debian and Ubuntu
3. The Red Hat family: Fedora, RHEL, Rocky and Alma
4. The Arch family and the rolling release model
5. Other relevant families: SUSE and Alpine
6. Comparison table by criteria
7. LTS and why it matters on a server
8. Fixed releases versus rolling release
9. Special-purpose distributions
10. How to choose a distribution with professional judgement
11. Tramontana's decision and the RHEL equivalences

A distribution is an assembly. These are the pieces its maintainers choose, integrate, test and maintain:

Two of these pieces explain almost all the differences you will notice day to day.

It is the most visible difference. A package is a compressed file containing a program's binaries, its configuration files and some metadata declaring which other packages it depends on. The package manager resolves that dependency graph, downloads what is needed and installs it in the right place.

All three commands do the same thing: install the nginx web server with all its dependencies. The syntax changes, not the concept. In Module 5 you will work on package management in depth; here you only need to know that the package manager is the family's signature.

And there is an immediate practical consequence of this: the first thing you do when you land on an unknown server is find out which distribution it is, because which commands will work depends on that. The standard, portable way is to read a file that every modern distribution includes:

Output on srv-tramontana:

The three fields that really matter:

• ID=ubuntu: the exact identifier of the distribution.
• ID_LIKE=debian: the family. This field is gold when you administer heterogeneous machines, because it tells you which package manager to expect even if you do not know the specific distribution. On Rocky Linux you would see ID_LIKE="rhel centos fedora".
• VERSION_CODENAME=noble: the code name, which is what appears in the repositories and in many configuration commands.

This file is a systemd standard and it is present in Ubuntu, Debian, Rocky, Fedora, Alpine and practically any current distribution. That is why it is the check installation scripts use to decide whether to run apt or dnf.

It is process number 1, the first thing the kernel starts and the parent of all the rest. It is responsible for bringing services up in order, restarting them if they fall over and shutting them down cleanly.

Today systemd is the de facto standard: it is used by Ubuntu, Debian, RHEL, Fedora, Arch, SUSE and practically every general-purpose distribution. Its adoption between 2011 and 2015 was highly controversial because it broke with the Unix philosophy of "one program, one task" (systemd manages services, logs, networking, mounts, timers...), but it won by being much faster, more consistent and able to express dependencies between services. You will master it in lesson 05-05.

Alpine and some minimalist distributions use lighter alternatives (OpenRC, runit), which is a real difference and not a cosmetic one.

Notice one detail in the diagram that confuses many people: Fedora is upstream of RHEL, not downstream. Fedora is the laboratory where Red Hat tests innovations every six months; every two or three years a state of Fedora is frozen and out of it comes a RHEL version, which is stabilised and maintained for ten years. Rocky and Alma are built from the RHEL source.

It was born in 1993 and is the reference community distribution. There is no company behind it: it is governed by a project with thousands of volunteer developers, a social contract and a leader chosen by vote.

• Packages: .deb, managed with apt (high-level interface) and dpkg (low level).
• Branches: stable (the current one, rock solid), testing (the one that will become the next) and unstable/sid (where everything lands first).
• Philosophy: stability and freedom above novelty. A Debian stable may carry two-year-old software.
• Cycle: a new version roughly every 2 years, with around 5 years of support thanks to community LTS.
• Typical use: servers that must run for years without surprises, critical infrastructure.

Canonical, Mark Shuttleworth's company, created it in 2004 starting from Debian with a clear goal: making it usable and predictable. It is today the most widespread distribution on servers and in the cloud.

• It takes packages from Debian unstable, stabilises them, adds its own and publishes.
• Predictable cycle: a version every 6 months (April and October) and an LTS every 2 years in April.
• Intelligible numbering: 24.04 means 2024, month 04. 22.04 is from April 2022.
• LTS support: 5 years as standard, extendable to 10 or 12 with an Ubuntu Pro subscription (free for personal use and up to 5 machines).
• Flavours: Ubuntu Server (no desktop), Ubuntu Desktop (GNOME), Kubuntu (KDE), Xubuntu (XFCE), Ubuntu Core (IoT).

Strengths and criticisms, so you have the full picture:

Red Hat is the company that proved you could make money from free software (IBM bought it in 2019 for 34 billion dollars). Its model is not selling software: it is selling support, certifications and ten-year stability guarantees.

• Packages: .rpm, managed with dnf (successor to yum).
• Security: SELinux enabled by default, a mandatory access control system far stricter than classic permissions. It is their hallmark and also the main source of headaches for anyone coming from Debian.
• Firewall: firewalld instead of ufw (Module 6).

The four pieces of the ecosystem:

A recent piece of context worth knowing: in 2020 Red Hat turned CentOS (which was a free, stable rebuild of RHEL) into CentOS Stream, which runs ahead of RHEL instead of behind it. Thousands of companies were left without their free RHEL-equivalent server, and out of that Rocky Linux and AlmaLinux were born to fill the gap. If you come across old documentation recommending CentOS 7 or 8 for production, it is out of date.

Where this family is used: large enterprises, banking, public administration, environments with certification and contractual support requirements. If you work in a big corporation, you are very likely to run into RHEL.

Arch Linux (2002) is the distribution for anyone who wants total control and wants to understand every piece of their system.

• Packages: .pkg.tar.zst with pacman, which is very fast.
• AUR (Arch User Repository): a community repository with practically every piece of software in existence, in the form of build recipes. It is its great attraction and also its risk: it is not audited.
• Rolling release: there are no versions. You install once and update forever.
• Installation: manual and from the command line (although since 2021 archinstall exists to simplify it).
• Documentation: the ArchWiki is, without argument, the best technical Linux documentation there is, and it is useful even if you do not use Arch.

Who it is for: developer desktops that always want the latest, people who want to learn in depth how a system is assembled.

Who it is not for: production servers. An update may require manual intervention and bring changes that break your application at the worst possible moment. Nobody serious puts Arch on a company's production server, and Tramontana will be no exception.

A distribution of German origin (1994), very well established in Europe, especially in Germany, and in SAP environments.

• openSUSE Leap: the stable community version, aligned with SUSE Linux Enterprise.
• openSUSE Tumbleweed: a very well tested rolling release.
• SLES (SUSE Linux Enterprise Server): the paid product with support.
• It uses .rpm with the zypper manager and stands out for YaST, a unified administration tool with no equivalent in other distributions, and for its integration of Btrfs with automatic snapshots: you can roll back a failed update from the boot menu.

It is the interesting exception that breaks every mould:

• It does not use glibc but musl; it does not use GNU coreutils but BusyBox.
• It does not use systemd but OpenRC.
• Its own package manager: apk.
• A base image takes about 5 MB, against the ~75 MB of an Ubuntu base image.

That size has made it the standard distribution for containers. When you build Docker images in Module 7, you will see FROM alpine everywhere. Its downside is real: by using musl instead of glibc, some programs compiled for "normal" Linux fail or perform worse, and debugging those problems takes experience.

LTS stands for Long Term Support. An LTS version receives security fixes and fixes for serious bugs for years, with no functional changes.

That last part is the key and it is often misunderstood. LTS does not mean "software updated to the latest". It means exactly the opposite: the software is frozen at the version that existed on release day, and only backported security patches are applied to it. That is, Canonical takes the fix for an nginx 1.26 vulnerability and applies it on top of the nginx 1.24 that Ubuntu 24.04 ships, without changing the version.

Think about it from the business side: Tramontana Bookings invoices bookings of rural cottages. Every minute of downtime is money and reputation. A server that demands migration every nine months forces you to repeat the full cycle of testing, validation and deployment five times in five years. With LTS you do it once.

An important warning for your professional life: end of support means end of security patches. A server running an out-of-support distribution is not "a bit old": it is a server accumulating known, unfixed vulnerabilities. Writing the end-of-support date of every machine into the calendar is an administrator's task as basic as taking backups.

The decisive argument for a server is not risk: it is reproducibility. If you build a test server today and a production one tomorrow with a rolling release, they are not the same machine, because packages have changed in between. With Ubuntu 24.04 LTS, two installations six months apart are functionally identical. When you automate deployments with Ansible in Module 7, that property will go from convenient to indispensable.

Not every distribution aims to be general-purpose. Some solve one very specific problem and do it better than anyone:

Two practical warnings that save trouble:

• Kali is not a daily-driver distribution. It is an offensive toolbox: you boot it when you need it, ideally from a VM or a USB stick. Installing it as your main system is a very common beginner's mistake among people starting out in cybersecurity. You will see security tools in Module 6, and they install just as well on Ubuntu.
• Using the right specific distribution saves weeks. Building a NAS on Ubuntu by hand is possible and educational; building it with TrueNAS is an afternoon's work. Knowing when to use the specialised tool is part of professional judgement.

Questions in order of importance. Answer them in this order and the choice almost makes itself.

1. Server or desktop? It changes everything: priorities, installed software, resource usage.

2. How many years must it last without migration? Less than a year, anything will do. Five years, you need LTS. Ten years, RHEL or Ubuntu Pro.

3. What does my team already know? The cost of learning a new family is real and it is paid in incidents at three in the morning. If your team knows apt, do not hand them dnf without a strong reason.

4. What does the software I am going to run require or certify? Many commercial products only certify RHEL and Ubuntu LTS. If your database vendor only supports RHEL, the decision is made.

5. Do I need commercial support with an SLA? If a contract requires guaranteed response times, you need RHEL, Ubuntu Pro or SLES.

6. Where is it going to run? Cloud (Ubuntu and the RHEL derivatives are first-class citizens on AWS, Azure and GCP), container (Alpine or Debian slim), Raspberry Pi (Raspberry Pi OS), old hardware (Debian with XFCE).

7. What are the documentation and the community like? When you have a problem at 3 in the morning, how many people have had that same problem before you matters more than it seems.

And three criteria that should not weigh in a professional decision: which distribution is ideologically "purer", which has the prettiest desktop, and which the experts on the forums use to show off.

Let us apply the seven questions to the real case.

The srv-tramontana server:

Decision: Ubuntu Server 24.04 LTS for srv-tramontana, with support until April 2029.

Your work laptop: Ubuntu Desktop 24.04 LTS, with the user student. The reason is deliberate and deserves explaining: by using the same base version on the laptop and on the server, what you test locally behaves the same in production. Package versions match, configuration paths are the same, and a whole category of "it worked on my machine" incidents disappears.

Why this course uses Ubuntu, said openly: because it is what you are most likely to meet in the cloud and in small and medium companies, because it has the best documentation for learning, and because almost any tutorial you look up will be written for it. Not because it is technically superior to Debian or Rocky Linux.

If you change company tomorrow and find Rocky Linux or RHEL, 90 % of this course applies as it is. These are the differences you will have to translate. Keep this table: it is one of the most useful in the module.

What does not change, and it is the majority: the kernel, the directory structure (lesson 01-06), permissions, Bash and all the scripting, systemd and systemctl, journalctl, SSH, processes, pipes and the text tools. That is why the knowledge is transferable: what you are learning is Linux, not Ubuntu.

Of these differences, the only one that produces serious surprises is SELinux. On RHEL you can have apparently correct permissions and still get a "Permission denied" because SELinux blocks the operation by policy. It is the first thing you should suspect when migrating from Ubuntu.

• Looking for "the best distribution". It does not exist. What exists is the most suitable one for a context. Changing distribution constantly (distro-hopping) is entertaining and educational, but during this course stick with Ubuntu 24.04 LTS: learning the system and learning a new distribution at the same time multiplies the confusion.
• Putting a desktop distribution into production. Ubuntu Desktop on a server means gigabytes of unnecessary software, a desktop eating RAM and a much larger attack surface. Always use the Server edition.
• Using a non-LTS version on a server. Ubuntu 24.10 will stop receiving patches in July 2025. For a server, that date arrives in no time.
• Mixing repositories from different versions. Adding Ubuntu 25.04 repositories to a 24.04 system to get a newer version of a package breaks the system with admirable reliability. It is called a FrankenDebian and there is no comfortable fix.
• Copying tutorials without checking the distribution and version. A CentOS 7 tutorial uses yum, iptables and different paths. Before pasting a command, check which system it was written for.
• Installing Kali as your main system to "learn security". Learn Linux first on Ubuntu; Kali's tools can be installed afterwards on any distribution.
• Tip. Learn one family well and know the equivalences of the other. With the table in section 11 and a knowledge of apt, you can hold your own on RHEL from day one.
• Tip. Before choosing for a real project, always look up the end-of-support date of the candidate version and note it in the inventory. It is information that gets forgotten and badly missed three years later.

For each scenario, choose a distribution and justify the choice with at least two of the seven criteria from section 10:

1. A mail server for a small town council, which must run for 8 years with minimal intervention and whose tender requires contractual support.
2. A base image for a Docker microservice that is deployed 200 times a day.
3. A developer's laptop that needs the latest versions of Python, Rust and Node.js, and where spending time on the system is not a problem.
4. A home file server on a Raspberry Pi 5.
5. A second server for Tramontana S.L., intended to host the Tramontana Bookings database.

Marta has read on a blog that Ubuntu 24.10 "is more modern and therefore more secure" than Ubuntu 24.04 LTS, and proposes reinstalling srv-tramontana. Write the technical answer you would give her, explaining what LTS means, what security backports are, and what operational cost the proposal would have.

Tramontana signs a contract with a hotel chain that requires its billing software to run on Rocky Linux 9. You have only worked with Ubuntu. Prepare a translation table with the eight administrative tasks you will need most on day one, and point out which of the differences strikes you as the most dangerous and why.

Solution to Exercise 1

1. The council's mail server → RHEL (or SLES). Decisive criteria: how long it must last without migration (8 years is only covered by RHEL, with its 10-year cycle, or by Ubuntu Pro) and commercial support with an SLA, which the tender explicitly requires and which is only obtained with a subscription. A third one applies: public administration usually requires security certifications (Common Criteria, FIPS) that RHEL has documented. Rocky Linux would be technically equivalent but does not meet the contractual support requirement, which is what rules here.

2. Microservice base image → Alpine. Criteria: where it will run (a container) and size. With 200 deployments a day, the difference between 5 MB and 75 MB per image multiplies in bandwidth, start-up time and registry cost. On top of that, fewer packages means fewer CVEs to patch. A professional nuance: if the microservice is written in Python or Node with compiled dependencies, musl can cause compatibility and performance problems; in that case the right choice is debian:slim, which takes ~30 MB and uses glibc. Alpine is the default answer, not the automatic answer.

3. Developer laptop with the latest → Arch (or Fedora). Criteria: desktop, software freshness and time available to maintain it. Arch on rolling release always gives the latest versions and the AUR covers practically any tool. The condition "spending time on the system is not a problem" is what makes it viable. If that condition were not met, Fedora would be the right answer: software almost as recent, with 6-month cycles and far less manual maintenance.

4. File server on a Raspberry Pi 5 → Raspberry Pi OS. Criterion: where it will run. It is Debian adapted specifically to the board's hardware (GPIO, thermal management, boot, graphics acceleration), with a kernel and firmware maintained by the Raspberry Pi Foundation. Ubuntu Server for ARM also works and would be defensible if you were after uniformity with the rest of the estate, but hardware support is better in the native option.

5. Tramontana's database server → Ubuntu Server 24.04 LTS. Criteria: what the team knows and uniformity of the estate. Although technically Debian or Rocky would serve just as well, introducing a second family in a company with a single technician doubles the required knowledge, the procedures, the scripts and the update windows, without contributing anything. Uniformity has enormous operational value in small teams. Same version, same LTS, same backup scripts.

Solution to Exercise 2

An answer for Marta:

"The intuition that 'newer is more secure' is reasonable but it does not apply to server software, and it is worth explaining why.

What LTS means. Ubuntu 24.04 LTS receives security updates until April 2029, five years. Ubuntu 24.10 receives updates for nine months, until July 2025. After that date, a server running 24.10 stops receiving patches: it would accumulate known, published, unfixed vulnerabilities. The 'more modern' version would be, literally, the insecure one.

What security backports are. The fact that 24.04 ships nginx 1.24 instead of 1.26 does not mean it is missing fixes. Canonical takes every security patch published upstream and applies it to the version it distributes, keeping the version number. We get the fix without getting the functional changes. That is why a scanning tool that merely compares version numbers produces false positives on Ubuntu: you have to check the corresponding Ubuntu Security Notice (USN).

Operational cost of the proposal. Reinstalling with 24.10 would force us to migrate again in July 2025, and again every nine months. Each migration means: stopping the service, testing that Tramontana Bookings still works with the new versions of Python, PostgreSQL and nginx, reviewing configuration changes and being on hand in case something fails. That is several working days each time, multiplied by more than five over the period 24.04 covers with a single installation.

Recommendation. Keep 24.04 LTS and make sure security updates are applied automatically and verifiably. If at some point we need a more recent version of one specific component (Python, for instance), we solve it with that component's official repository or with a container, without dragging the whole operating system along. And we note April 2029 in the inventory so we can plan the migration in good time."

Solution to Exercise 3

Translation table for day one on Rocky Linux 9:

The most dangerous difference: SELinux.

It is the most dangerous for one concrete reason: it fails silently and misleadingly. The other seven differences produce obvious errors; if you type apt on Rocky, the system tells you the command does not exist and you fix it in three seconds.

SELinux, by contrast, produces a "Permission denied" when the permissions you see with ls -l are perfectly correct. You can have the file with the right owner, the right group and mode 644, and the service still cannot read it, because SELinux applies an additional policy based on contexts (labels attached to files and processes) that are not visible with the usual tools.

The classic case, and the one that wastes the most time: moving a web application's content to a non-standard directory. On Ubuntu it works; on Rocky, nginx cannot read it because the SELinux context of the new directory is not the one the policy expects.

What you need to know from the outset:

• Check whether SELinux is active: getenforce (returns Enforcing, Permissive or Disabled).
• Faced with an inexplicable "Permission denied", check /var/log/audit/audit.log or use ausearch -m avc -ts recent.
• Fix contexts with restorecon or semanage fcontext.
• What you must not do, however much every forum suggests it: disable SELinux. It is a valuable security layer, especially on an exposed server, and turning it off to solve a configuration problem is trading a problem for a risk.

The topic will be covered in Module 6, when we talk about hardening Linux systems.

To recap:

• A distribution is kernel + userland + package manager + init + release policy, integrated and maintained by somebody.
• The three big families are distinguished above all by the package manager: Debian/Ubuntu (.deb, apt), Red Hat (.rpm, dnf) and Arch (pacman, rolling). SUSE and Alpine complete the map.
• LTS means frozen versions with backported security patches for years. On a server it is not a preference: it is a requirement.
• Rolling release brings novelty and takes away reproducibility, which is why it does not fit in production.
• There are specialised distributions (Alpine, Kali, Raspberry Pi OS, Proxmox) that solve one specific problem better than any general-purpose one.
• You choose with criteria: time horizon, team knowledge, software requirements, support, target environment and documentation.
• Tramontana uses Ubuntu Server 24.04 LTS on srv-tramontana and Ubuntu Desktop 24.04 LTS on your laptop, with support until 2029, and the differences with RHEL are tabulated for when they are needed.

You now know what you are going to install and why. In the next lesson, Installing Linux, you will build the lab you will work with across the eight modules: we will compare virtual machine, WSL2, dual boot and cloud, you will download the Ubuntu Server 24.04 LTS ISO and verify its SHA256 sum and its GPG signature before installing it, you will walk through the installer step by step — including partitioning, which is where most people get stuck — and you will create the operator user. By the end you will have srv-tramontana booted and waiting for you.