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]>
67 lines
3.5 KiB
Markdown
67 lines
3.5 KiB
Markdown
# 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.)
|