ced4568andClaude Sonnet 5
15b616274b
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]>
3.5 KiB
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.)