Installing and Configuring Linux already teaches how to install and configure a Linux system well — generically, without dwelling on what makes one distribution genuinely different from another. Windows 11 Fundamentals 1's own OS-landscape table went further, positioning "Linux" as a single row: CLI-first by tradition, with a GUI desktop environment as one optional layer on top. This course exists specifically to open that one row up — Linux isn't one philosophy wearing different outfits, it's several genuinely different philosophies, and this chapter names exactly what actually varies between them.

Five Components, Not One "Look"

A distribution is a specific combination of five real components — and the one most beginners notice first is, genuinely, the least defining:

• Kernel — almost every mainstream distribution runs the same Linux kernel (with its own specific version and patch set), so this is rarely the real differentiator between them.
• Package manager & format — how software actually gets installed, removed, and tracked; a genuinely load-bearing difference this course's own Chapter 6 covers directly, side by side.
• Init system — what actually starts services at boot and supervises them afterward; overwhelmingly systemd today, with one real, living exception covered in Chapter 5 and Chapter 8.
• Release model — point releases, a continuous rolling model, or a multi-year enterprise support window; covered in full in Chapter 7.
• Default desktop environment — GNOME, KDE Plasma, XFCE, or none at all — the single most swappable, least defining component of the five, despite being the first thing anyone actually sees.

Why the Desktop Environment Is the Weakest Signal

Two machines running GNOME can be running genuinely different distributions underneath — different package managers, different init systems, different release philosophies — while looking nearly identical on screen. Conversely, the same distribution can run several different desktop environments, or none. Judging "how different is this distro" by its default wallpaper and icon theme is judging the single most interchangeable piece of the whole picture.

A First Look at the Four Families This Course Covers

Notice that three of the four share the same init system — the real, still-living exception is exactly where Chapter 5 (Alpine) and Chapter 8 (init systems generally) pick the story back up.

This Course's Own Roadmap

Debian/Ubuntu and Fedora/RHEL next, then Arch, then Alpine — one chapter each, going deep on what genuinely distinguishes it. Then package managers, release models, init systems, and governance compared directly across all four at once. Raspberry Pi OS gets its own chapter as a genuine Debian derivative worth understanding on its own terms. A practical decision framework and a real, worked capstone — the same service, deployed three different ways — close out the course.

Hands-On Exercises

The first of this course's own four families, and the one whose stated goal is, quite literally, to be unexciting. Debian's release process, Ubuntu's own relationship to it, and the dpkg/apt tool pairing all serve one consistent underlying value — reliability, chosen deliberately over freshness.

Debian's Three Tiers — a Real Pipeline, Not Just Labels

New and updated packages enter Unstable (nicknamed "Sid") first. A package that survives there for a set minimum period with no new critical bugs migrates automatically into Testing. When Testing is judged mature enough, a snapshot of it is frozen and eventually released as the next Stable — after which Stable receives only security patches and critical fixes, nothing else, for the rest of its multi-year lifetime.

"Boring" as an Explicit, Stated Value

Debian's own community has long described its goal, without irony, as being "boring" — a Stable release roughly every two years, package versions frozen at release time regardless of how much newer upstream software becomes during that release's own multi-year support window. This isn't neglect; it's the deliberate trade-off this whole chapter's own title names — stability chosen consciously over having the latest version of everything.

Ubuntu — Built From Debian, Released on Its Own Terms

Ubuntu takes packages directly from Debian's own Unstable/Testing pool, applies its own patches and branding, then releases on a schedule entirely its own: an interim release every six months (9 months of support), and a Long Term Support (LTS) release every two years, supported for five years by default — extendable further through Ubuntu's own Extended Security Maintenance.

dpkg vs. apt — Low-Level Tool, High-Level Wrapper

dpkg is the low-level tool that actually installs a single .deb file — it has no concept of fetching a package from anywhere, and no automatic dependency resolution; handing it a package whose dependencies aren't already present simply fails. apt is the high-level tool built on top of it — it resolves dependencies, fetches packages (and their dependencies) from configured repositories, and calls dpkg underneath to actually perform the install.

Hands-On Exercises

Chapter 2 covered Debian feeding a slower, stable identity into a faster downstream (Ubuntu). Fedora and RHEL run the relationship in reverse — and that reversal is the single most important thing to understand about this family before anything else.

The Direction Runs the Opposite Way From Debian/Ubuntu

This isn't just organizational trivia — systemd itself, now the near-universal default across this entire course (Chapter 1), was first adopted as Fedora's own default init system in 2011, years before most other major distributions followed. Fedora's own explicit identity is built around shipping new upstream technology quickly, specifically so it can be battle-tested before RHEL ever touches it.

Fedora's Own Cadence

A new Fedora release roughly every six months, each version maintained for about 13 months total (giving a brief overlap window between consecutive releases) — genuinely fast by this course's own standards, though still meaningfully more conservative than Arch's continuous model, covered next in Chapter 4.

RHEL & CentOS Stream — the Enterprise Side

RHEL releases major versions roughly every three years, each supported for a full decade through a subscription-based commercial support model — Red Hat's own business, covered further in Chapter 9's governance material. CentOS Stream — worth knowing about specifically because its role changed in a widely discussed 2020 shift — used to be a free, downstream rebuild of finished RHEL releases; today it sits instead as a public "midstream" between Fedora and RHEL, previewing what the next RHEL minor version will actually contain rather than rebuilding what's already shipped.

dnf & rpm — the Same Pairing Pattern as Chapter 2

.rpm (Red Hat Package Manager) is the package format; dnf is the modern high-level tool (successor to the older yum) — the exact same low-level-format/high-level-manager relationship Chapter 2 established for .deb and apt, just with different names.

SELinux — Enabled and Enforcing by Default

SELinux (Security-Enhanced Linux) is a mandatory access control system, enabled and set to Enforcing by default on Fedora and RHEL — a genuinely different, more restrictive security model than Debian/Ubuntu's own default use of AppArmor. This is a real, common source of confusion: a service can have entirely correct standard Unix file permissions and still be denied access, because SELinux enforces an additional, separate policy layer on top of ordinary permissions.

Hands-On Exercises

Chapters 2 and 3 both covered distributions built around discrete versions — Debian Stable's own frozen releases, Fedora's ~13-month cycles, RHEL's multi-year majors. Arch has none of that at all — no version number to even ask about — and its own installation philosophy is just as deliberately different.

Rolling Release — There Is No "Arch 15"

Arch has no discrete releases in the way every distribution covered so far does. Packages update continuously, directly from upstream, with no periodic freeze-and-snapshot cycle at all — the system genuinely is whatever's currently in the repositories, all the time. There's no equivalent to "Fedora 40" or "Debian 12" to name, because the entire concept of a numbered release doesn't apply here.

pacman & the AUR

pacman is Arch's own package manager — pacman -S installs, pacman -R removes, pacman -Syu performs a full system update. The philosophy is frequent, small, incremental updates rather than the big periodic jumps Chapters 2 and 3 both described.

The AUR (Arch User Repository) is community-submitted — but critically, it doesn't hold pre-built binary packages the way the official repositories do. It holds PKGBUILD scripts, community-written build instructions that fetch source code and compile it locally.

The Arch Wiki — Respected Well Beyond Arch Itself

The Arch Wiki is genuinely well regarded across the entire Linux world — detailed enough that users of completely different distributions regularly consult it for generic Linux configuration and troubleshooting information, adapting package-manager-specific steps to their own system as needed.

"You Configure Everything Yourself"

Installing and Configuring Linux covers a guided installer making sensible decisions on a user's behalf — partitioning, package selection, bootloader setup, all handled with reasonable defaults. Arch's own traditional installation process is the deliberate opposite: partitioning, mounting, base package selection, and bootloader configuration are all performed explicitly, one command at a time, with no default assumed unless the installer using it chose one on purpose. (A newer, official archinstall script offers a guided path today, but the manual process remains the canonical, most-documented route — and still the one the Arch Wiki's own installation guide centers on.)

Hands-On Exercises

Chapter 1's own compare-table already flagged Alpine as the one family in this course not using systemd. This chapter explains why — Alpine isn't Debian/Fedora/Arch with some things removed; nearly every major component is deliberately swapped for a smaller alternative, minimalism chosen as a first-class goal rather than an afterthought.

musl vs. glibc — A Different C Standard Library Entirely

Every other family in this course — Debian, Ubuntu, Fedora, RHEL, Arch — uses glibc (the GNU C Library), the long-standing, feature-complete standard most software is built and tested against. Alpine uses musl instead — a much smaller, simpler, more strictly standards-compliant C library.

BusyBox — Dozens of Utilities, One Small Binary

Instead of the full GNU coreutils most distros ship, Alpine uses BusyBox — a single, compact executable providing simplified implementations of dozens of standard Unix utilities (ls, grep, sed, mount, and many more) at once. The trade-off is real: a dramatic size reduction, in exchange for a reduced feature set and occasionally different flag behavior than the full GNU version of the same command — a script written assuming GNU-specific sed or grep flags can behave differently under BusyBox's own trimmed implementation.

OpenRC — Delivering on Chapter 1's Own Named Exception

Alpine uses OpenRC rather than systemd, consistent with its broader minimalism-first philosophy — systemd bundles a much larger set of daemons and components alongside pure init functionality, exactly the kind of added surface area Alpine's own design goal explicitly avoids. Chapter 8 covers init systems across all four families in full; this is the "real, living exception" that chapter (and Chapter 1) already named.

apk — Alpine's Own Package Manager

apk add, apk del, and apk update round out Alpine's own package tooling — small, fast, and consistent with the same minimalism running through every other component covered so far.

Why Alpine Dominates Docker Base Images

A full Ubuntu base image commonly runs 70+ MB; Alpine's own base image is typically in the 5–8 MB range — a direct, concrete consequence of musl, BusyBox, and OpenRC all replacing much larger equivalents at once. Smaller images pull faster, deploy faster, and offer a genuinely smaller attack surface — exactly why so many official images on Docker Hub offer a dedicated "-alpine" variant, and why the Docker courses' own image-size and layer-optimization material is really the same underlying theme, just expressed at the individual-image level rather than the whole-OS level this chapter covers.

Hands-On Exercises

Chapters 2 through 5 each introduced one package manager on its own terms. This chapter puts all four side by side, doing the exact same real tasks — and covers a real dependency-resolution policy difference worth knowing before it causes a genuinely broken system.

The Same Tasks, Four Different Commands

Dependency Resolution — Not All Equally Permissive

apt and dnf both resolve dependencies against repository metadata and are relatively tolerant of partial upgrades — installing one new package without a full system update generally works fine on either. pacman is meaningfully stricter, for a reason directly tied to Chapter 4's own rolling-release material.

Ansible's Package Module — Abstracting Over All Four

Ansible's ansible.builtin.package module detects whichever package manager is actually present on a target host and calls it automatically — the exact differences this whole chapter just catalogued, abstracted away behind one generic interface:

This generic module only supports the lowest common denominator across all four — install/remove/ensure-latest by name. Anything more specific to one package manager (an Arch AUR helper, a Fedora module stream) still requires that manager's own dedicated Ansible module rather than the generic one.

Hands-On Exercises

Debian's own three tiers, Ubuntu's interim/LTS split, Fedora's ~13-month cadence, RHEL's decade-long support window, and Arch's rolling model have all appeared already, one chapter at a time. This chapter puts them on a single, named spectrum — and corrects a real oversimplification worth catching before it causes a bad decision.

One Spectrum, Not Three Unrelated Categories

Every family this course has covered sits somewhere on this one axis — not in three or four unrelated buckets, but at genuinely different points along the same underlying trade-off.

Ubuntu's Own Hybrid Position

Ubuntu is worth calling out specifically because it doesn't occupy just one point on the spectrum — it deliberately offers two, within a single project. LTS releases sit further toward the stability end (five years of support, minimal disruption); interim releases sit further toward the freshness end (six-month cycles, newer software, a much shorter nine-month window). Choosing Ubuntu doesn't commit to one position on the axis at all — it commits to choosing between two of Ubuntu's own offerings, each occupying a different point.

This hedge isn't unique to Ubuntu — openSUSE, outside this course's own four covered families, runs the same pattern explicitly with two separately named products: Tumbleweed (rolling) and Leap (point release), worth knowing exists even though it isn't covered here in depth.

Matching a Model to a Real Use Case

Chapter 11 turns this same table into a concrete decision framework, applied to several real scenarios.

Hands-On Exercises

Chapter 1's own table, Chapter 3's Fedora-first systemd history, and Chapter 5's OpenRC material have all pointed toward this chapter without covering it fully. This is where the init-system thread finally comes together — plus a related "defaults" story worth telling alongside it: why Fedora quietly made one of the more interesting filesystem decisions in recent Linux history.

systemd — Revisited, Not Retaught

systemd in Depth already covers PID 1, unit files, parallelized boot, and journald in full detail — this chapter doesn't repeat that. What matters here is who uses it: Debian and Ubuntu adopted systemd starting around Debian 8 / Ubuntu 15.04, Fedora adopted it earliest (2011, per Chapter 3), and Arch made it the default around 2012–2013. Three of this course's own four families converged on the same init system — a real, genuine point of agreement this course keeps returning to.

Ubuntu's Own Forgotten Alternative — Upstart

Before adopting systemd, Ubuntu ran its own genuinely different init system for nearly a decade: Upstart, an event-based init system Ubuntu itself developed and used from roughly 2006 to 2015. Ubuntu didn't simply wait for systemd to appear — it built and maintained an entirely separate alternative first, before eventually converging with the rest of this course's systemd-using families anyway.

OpenRC — The Real, Living Exception, Recapped

Chapter 5 already covered Alpine's own use of OpenRC as part of its broader minimalism theme. The core difference worth restating here: OpenRC uses simpler, dependency-based service scripts without systemd's own much larger bundle of additional components (no built-in equivalent to journald — Alpine uses traditional syslog instead — nor to logind, timedated, or resolved).

Default Filesystems — a Related "Defaults" Story

Historically, ext4 has been the safe, boring default across most of this course's own families — and it still is for Debian, Ubuntu, and Alpine (consistent with Alpine's own simplicity-first theme from Chapter 5). Fedora broke from that pattern in a genuinely notable way.

Arch's own installer, consistent with Chapter 4's "you configure everything yourself" philosophy, doesn't default to any filesystem at all — the installer using it chooses explicitly, same as every other installation decision that chapter already described.

Hands-On Exercises

Every prior chapter compared technical decisions — package managers, init systems, release cadences, default filesystems. This chapter steps back to a genuinely different axis: who actually decides what goes into each distribution, and how each project is funded and sustained.

Debian — Volunteer-Democratic

The Debian Project is a genuine volunteer nonprofit — an annually elected Debian Project Leader (DPL), with major decisions formalized through the Debian Constitution and settled by General Resolutions, a real, structured voting mechanism open to Debian's own registered developers. It's one of the largest and longest-running examples of genuinely democratic open-source governance anywhere.

Ubuntu — Commercially Directed

Canonical Ltd., a private company founded by Mark Shuttleworth, owns and directs Ubuntu's development. Community contributions are genuinely welcomed, but final decision-making authority rests with Canonical, not a democratic vote of contributors the way Debian's own governance works.

Red Hat — a Hybrid Model Behind Fedora and RHEL

Red Hat (acquired by IBM in 2019) runs a genuine commercial open-source business: RHEL itself is the paid product — subscriptions, certification, SLA-backed support. Fedora, by contrast, is governed by the Fedora Council, a genuine mix of Red Hat employees and independently elected community members — neither purely volunteer-democratic like Debian nor purely corporate-directed like Ubuntu, but something in between.

Arch — Minimal Governance

No foundation, no formally elected leader in Debian's own sense — a small, informal team of trusted package maintainers and developers, making decisions with deliberately low bureaucracy. This extends Chapter 4's own DIY philosophy one level further: not just "you configure your own system," but "the project itself runs with minimal formal structure too."

Alpine — Small and Volunteer-Driven

Alpine is maintained by a small nonprofit development team — closer in spirit to Debian's own volunteer model, just at a considerably smaller scale, consistent with Chapter 5's own minimalism theme extended here to organizational simplicity as well.

Hands-On Exercises

A genuine derivative rather than a fifth independent family — but worth its own chapter precisely because it's directly relevant to Raspberry Pi Projects and More Raspberry Pi Projects, both already on this site and both quietly assuming everything this chapter actually explains.

Built Directly on Debian — Not Just "Similar To"

Raspberry Pi OS (historically named Raspbian) is literally derived from Debian's own package base — not an independent distribution inspired by Debian's style. This means Chapter 2's own apt/dpkg material transfers directly, with nothing new to learn: apt install works exactly the same way here as on any other Debian-family system.

What's Actually Different — ARM & Hardware Integration

Raspberry Pi hardware runs on ARM processors, not the x86/x86-64 architecture most desktop and server distributions primarily target. Raspberry Pi OS packages are specifically compiled for ARM (armhf for older 32-bit models, arm64 for newer 64-bit-capable ones), and the distribution bundles a custom kernel with Pi-specific hardware support — the camera module, GPIO pin access, and hardware-accelerated video decoding all depend on kernel and driver integration a generic ARM build simply doesn't include.

A Genuinely Different Boot Process

Every other family in this course cares about BIOS/UEFI and a bootloader like GRUB. The Raspberry Pi's own boot process is entirely different hardware territory: the Pi's GPU itself initializes first and reads a plain text configuration file, /boot/config.txt, before the Linux kernel is even loaded — no BIOS/UEFI screen, no GRUB menu, no equivalent to anything covered in GRUB & Multibooting at all.

Why This Chapter Matters for Raspberry Pi Projects & More Raspberry Pi Projects

Every project in those two courses assumes exactly the hardware integration this chapter describes. Raspberry Pi Projects 6's own GPIO and physical computing material, in particular, depends directly on the kernel-level GPIO support Raspberry Pi OS provides — none of it would function on a generic, non-Pi-specific Linux image at all.

Hands-On Exercises

Chapter 7 promised this chapter would turn its own spectrum table into a real decision framework. Every chapter since has added another axis worth weighing — SELinux, footprint, governance, hardware needs. This chapter brings all of it together and applies it to five genuinely different real scenarios.

The Framework — Six Questions

1. What's the actual use case? Server/production, personal desktop, a container base image, or dedicated embedded/Pi hardware.
2. Where does this task sit on Chapter 7's own stability-vs-freshness spectrum? A production system tolerates far less disruption than a personal experimentation machine.
3. Who's maintaining it, and how much ongoing attention can they realistically give it? Chapter 7's own warn-box named this directly — rolling release demands real, sustained maintenance discipline.
4. Does it need a specific security model? Chapter 3's SELinux-by-default is a real, distinguishing factor for certain compliance or hardening requirements.
5. Does minimal footprint or fast startup genuinely matter? Chapter 5's musl/BusyBox trade-offs are worth it specifically when size and attack surface matter more than broad compatibility.
6. Is dedicated hardware integration required? Chapter 10's own Raspberry Pi material applies directly whenever the answer is yes.

Applying the Framework to Five Real Scenarios

Hands-On Exercises

One real service — a small static website served by Nginx — deployed identically in intent across Debian/Ubuntu, Fedora, and Arch. The goal isn't the website itself; it's documenting precisely where eleven chapters' worth of differences actually show up in practice, and — just as tellingly — where they don't.

Step 1 — Installing Nginx (Where the Package Manager Chapter Pays Off)

This is the single most visible divergence across the whole capstone — three genuinely different commands, exactly as Chapter 6 catalogued, for the identical underlying action.

Step 2 — Enabling & Starting the Service (Where It's Genuinely Identical)

Step 3 — Firewall Configuration (A New, Real Divergence)

Fedora runs firewalld active by default, requiring an explicit rule to permit HTTP traffic (sudo firewall-cmd --add-service=http --permanent && sudo firewall-cmd --reload). Debian/Ubuntu commonly use ufw, if installed and enabled at all (sudo ufw allow 'Nginx HTTP'). Arch, consistent with Chapter 4's own "you configure everything yourself" philosophy, has no firewall active by default at all — nothing to configure here unless one was deliberately set up beforehand.

Step 4 — SELinux, Fedora Only (Chapter 3's Own Payoff)

Serving files from Nginx's own default document root works immediately on Fedora. Serving files from a custom, non-standard directory instead requires setting the correct SELinux context first — exactly the extra, genuinely necessary step Chapter 3 warned about:

Neither Debian/Ubuntu nor Arch require this step at all, since neither runs SELinux by default — a direct, concrete instance of Chapter 3's own warning finally showing up in a real deployment.

Step 5 — Verifying the Service (Identical Again)

Hands-On Exercises