feat(root01): author Computing & Linux Foundations, and the real 01->05 prerequisite chain

Adds all 6 ROOT 01 modules (how computers run software, the shell, filesystem navigation, files & text, processes, users & permissions foundations), each with a real lesson, demonstration/guided exercise, knowledge check where warranted, a hands-on Lab, and a reflection — 35 activities, 29 new content files. Adds 6 new hands-on Linux scenarios (linux-inspect-hardware, linux-shell-basics, linux-filesystem-navigation, linux-files-and-text, linux-process-management, linux-permissions-foundations) plus 2 MCQ scenarios, using the existing generic scenario/ validation engine (docs/ROOT_FOUNDATIONS_LAB_STRATEGY.md §1) — every one tested end-to-end via the real scenario setup/validate API, including negative tests confirming they correctly FAIL when not actually solved (e.g. the process-management scenario fails while the target process is still running; the permissions scenario is tested against a real `su - labuser` denial). Wires rootnode-linux-foundations-assessment (2 required + 4 random-draw scenarios) using the existing Phase 3B assessment engine. Adds a real, server-side ROOT 01->02->03->04->05 course prerequisite chain (courses.prerequisites) — verified live on two students: one who completed ROOT 01 sees ROOT 02 unlock; a fresh student sees ROOT 02 correctly locked while 03/04/05 stay vacuously satisfied (their own prerequisite courses are still empty). ROOT 06+ and the Capstone are unaffected. Co-Authored-By: Claude Sonnet 5 <[email protected]>
2026-08-26 12:59:52 -05:00
parent 87526bcf7f
commit 15b616274b
37 changed files with 1549 additions and 0 deletions
@@ -0,0 +1,66 @@
+# How Computers Run Software
+
+## Hardware, OS, and application: three different layers
+
+When you run a program, three distinct layers cooperate:
+
+- **Hardware** — the physical CPU, RAM, and storage. It has no idea what a "file" or a "process"
+  is; it just executes instructions and stores bits.
+- **The operating system (kernel)** — the layer that turns raw hardware into something usable:
+  it decides which program gets the CPU next, hands out memory, and organizes storage into
+  files and directories. Linux is a kernel plus a large set of standard tools around it.
+- **Applications (userspace)** — the programs you actually run. They ask the kernel for
+  resources (memory, files, network) through a well-defined interface (system calls) instead of
+  touching hardware directly.
+
+This module gives you just enough of this model to reason about what you're actually looking at
+for the rest of ROOT_ — not a full computer architecture course.
+
+## CPU: the thing that actually executes instructions
+
+A CPU has some number of **cores** — each core can run one stream of instructions at a time.
+`nproc` tells you how many cores/threads Linux believes it has available. When a system feels
+"slow," it's very often because more processes want CPU time than there are cores to give them.
+
+## RAM: fast, temporary, and finite
+
+RAM holds the data and code a running program is actively using. It's fast but **volatile** —
+its contents disappear when power is lost, which is exactly why persistent data lives on
+storage instead. `free -h` shows you total memory, how much is in use, and how much is free.
+
+## Storage: slower, but persistent
+
+Storage (an SSD/disk) keeps data even when the machine is off. It's organized into a
+**filesystem** — the tree of directories and files you already have some intuition for. `df -h`
+shows how much space exists and how much is used on each mounted filesystem.
+
+## Processes: a running program
+
+A **process** is a program actually being executed — code plus its own private memory, tracked
+by the kernel with a unique ID (a PID). One program can have many processes running at once
+(open two terminals running the same shell, and you have two separate processes). ROOT 01
+Module 5 goes much deeper into this; for now, just know: everything you run becomes a process
+the kernel is responsible for scheduling onto a CPU core.
+
+## Why this matters for everything after this module
+
+Every concept the rest of ROOT_ builds on is a refinement of this same idea. A container is
+(mostly) an isolated process with its own filesystem view. A Kubernetes Pod is a group of
+containers the scheduler places onto a specific machine's CPU/RAM. None of that will make sense
+as anything other than magic if you don't first have this base model of what a computer is
+actually managing.
+
+## Instructor Notes
+
+**Lesson goal:** Give students just enough of a mental model to stop treating "the computer" as
+an opaque box — without turning this into a full CS/architecture course.
+
+**Approximate timing:** 15 minutes read; 10 minutes live with discussion.
+
+**Common misconception to watch for:** students often conflate RAM and storage ("my computer
+has 8GB" meaning disk space). Draw the volatile-vs-persistent distinction explicitly and early.
+
+**Discussion question:** "Why can't a program just talk to the hardware directly instead of
+going through the kernel?" (Answer: the kernel is what lets many programs safely share one CPU/
+one block of RAM without stepping on each other — this is worth naming explicitly, as it's the
+root of why containers and Kubernetes are even possible.)
@@ -0,0 +1,35 @@
+# Guided Exercise: Predict Before You Look
+
+Before you run the real inspection commands in the Lab, commit to a guess — this is what makes
+the real numbers meaningful instead of just scrolling past them.
+
+## Your task
+
+On paper or in a scratch file, write down your best GUESS for:
+
+1. How many CPU cores does this machine have?
+2. How much total RAM, roughly, in GB?
+3. How much free disk space is on the root filesystem?
+
+Then think through: which of these three would you expect a "student Lab" environment to be
+MOST constrained on, and why? (Hint: think about what happens if 50 students are each running
+their own Lab on one shared physical machine at the same time.)
+
+## A worked shape to check yourself against
+
+There's no single right numeric answer here — the point is the habit of predicting first. A
+reasonable answer to the "most constrained" question: memory and CPU are typically the tightest
+shared resource on a multi-tenant host, since every additional Lab needs its own slice of both,
+while disk is comparatively cheap to over-provision.
+
+## Instructor Notes
+
+**Facilitation:** Have students commit to a number verbally or on a shared doc BEFORE anyone
+runs the real commands — the value is in noticing the gap between guess and reality, not in
+getting it right.
+
+**Approximate timing:** 5 minutes.
+
+**Optional extension:** ask what would happen to their guess if this were a "real" laptop
+they personally own vs. a shared cloud server — good primer for later resource-limit
+discussions (ROOT 06's resource requests/limits, ROOT 09's resource governance).
@@ -0,0 +1,27 @@
+# Reflection: You Just Looked Inside the Box
+
+## Reflection questions
+
+1. How close was your guess to the real numbers? What surprised you most?
+2. Name one thing you now understand about "the computer" that you couldn't have explained
+   before this module.
+3. When you eventually run `kubectl describe pod` and see `requests`/`limits` for CPU and
+   memory, what do you now expect those numbers to actually be constraining?
+
+## Real Ops takeaway
+
+**Every resource limit you'll ever configure — in Docker, in Kubernetes, in a systemd unit — is
+a promise about exactly the three things this module named: CPU, memory, and storage.** You
+can't reason well about "why did my container get killed" or "why is my Pod stuck Pending"
+without this base model. This module isn't computer-science trivia — it's the vocabulary the
+rest of ROOT_ assumes you have.
+
+This module is complete. Continue to the next module.
+
+## Instructor Notes
+
+**Discussion questions for a live classroom:** question 3 is worth spending real time on — it's
+the first moment students connect this abstract lesson to something they'll type as a real
+command many courses from now. Naming that connection explicitly here pays off later.
+
+**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.