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]>
28 lines
1.3 KiB
Markdown
28 lines
1.3 KiB
Markdown
# Reflection: Structure Isn't Bureaucracy, It's Communication
|
|
|
|
## Reflection questions
|
|
|
|
1. Why might a real engineering team insist on a consistent directory structure across every
|
|
project, instead of everyone organizing files however they like?
|
|
2. Which of `/etc`, `/var`, `/home`, `/tmp`, `/usr`, `/proc` do you feel most confident you could
|
|
explain to someone else right now? Which one still feels fuzzy?
|
|
|
|
## Real Ops takeaway
|
|
|
|
**A predictable filesystem layout is what lets tools (and other engineers) reason about a
|
|
system without asking you first.** `/etc` always means configuration, `/var/log` always means
|
|
logs — this convention is exactly why a monitoring tool can be pointed at "check `/var/log`" on
|
|
any Linux machine and just work. Container images later inherit this same convention (an
|
|
nginx container still keeps its config at `/etc/nginx/nginx.conf`) — you're not learning a
|
|
one-off Linux fact, you're learning a convention that outlives this specific module.
|
|
|
|
This module is complete. Continue to the next module.
|
|
|
|
## Instructor Notes
|
|
|
|
**Discussion questions for a live classroom:** question 1 connects directly to why Kubernetes
|
|
namespaces and Git repository conventions matter later — a good moment to name that connection
|
|
without going deep yet.
|
|
|
|
**Approximate timing:** 5-8 minutes live discussion; 5 minutes self-paced writing.
|