Exercise 3: Why Alpine and Raspberry Pi OS Didn't Need to Be Included — Possible Solution ==================================================================== WHAT THIS CHAPTER'S OWN SCOPE NOTE SAYS ------------------------------ Per this chapter's own warn-box, "Alpine (Chapter 5) and Raspberry Pi OS (Chapter 10) both already received their own dedicated, hardware/ footprint-specific treatment and don't need a fourth or fifth repetition of the same basic install-a-service exercise." WHY REPEATING THE SAME EXERCISE FOR ALPINE WOULD ADD LITTLE ------------------------------ Chapter 5 already covered Alpine's own real distinguishing traits in depth - musl vs. glibc, BusyBox, OpenRC instead of systemd, and its role as a minimal Docker base image. Installing Nginx via apk and managing it via OpenRC's own rc-service tooling would be a genuine, real difference worth noting once - but Chapter 5 already made exactly that point conceptually, and a fourth capstone repetition demonstrating it again wouldn't reveal anything new beyond what that chapter already established. WHY REPEATING THE SAME EXERCISE FOR RASPBERRY PI OS WOULD ADD LITTLE ------------------------------ Chapter 10 already covered Raspberry Pi OS's own genuinely distinguishing traits - being directly derived from Debian (meaning its package-manager behavior would essentially duplicate the Debian/Ubuntu step already shown in this capstone), plus its own hardware-specific boot process and GPIO/camera integration, none of which a simple static-website exercise would meaningfully exercise or reveal anything new about. WHY THIS ISN'T AN OVERSIGHT ------------------------------ An oversight would mean forgetting these two families existed or failing to give them adequate treatment anywhere in the course. Neither is true here - both received dedicated chapters specifically built around what's genuinely different about them, which is a more substantive treatment than folding them into a generic three-way service-installation walkthrough would have been. Explicitly naming this choice in the scope note, rather than silently omitting the two families, is itself the sign that this was a deliberate decision rather than something simply forgotten. WHY THIS REFLECTS GOOD SCOPING JUDGMENT ------------------------------ Choosing Debian/Ubuntu, Fedora, and Arch for this specific capstone makes sense because those three are the families where package manager, firewall tooling, and security-model differences are the most instructive to compare directly - Alpine and Raspberry Pi OS's own real differences (footprint/libc choice; hardware integration) are better demonstrated through the dedicated material those chapters already provide. WHY THIS WORKS AS AN ANSWER ------------------------------ It cites this chapter's own explicit scope note, explains specifically why repeating the same basic exercise for Alpine or Raspberry Pi OS would add little beyond what Chapters 5 and 10 already covered, and distinguishes a deliberate scoping decision from an oversight.