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]>
1.2 KiB
Reflection: You Just Stopped a Real Process, Not a Simulation
Reflection questions
- Before checking
kill -0after yourkill, how confident were you the process was actually gone? What would you have done if it hadn't stopped? - Why do you think SIGTERM-before-SIGKILL matters more for a real production service than for a throwaway script in a Lab?
Real Ops takeaway
"I ran the kill command" is not the same as "I confirmed the process is gone." This module's Lab required you to verify state, not just take an action and assume it worked — that verification step is exactly what separates a confident operator from someone hoping for the best. You'll repeat this exact pattern (act, then verify) constantly for the rest of ROOT_, starting as soon as ROOT 04's containers and continuing all the way through Kubernetes troubleshooting.
This module is complete. Continue to the next module.
Instructor Notes
Discussion questions for a live classroom: question 2 is a good bridge to ROOT 06's later
discussion of graceful shutdown/terminationGracePeriodSeconds — plant the idea now without
naming Kubernetes specifics yet.
Approximate timing: 5-8 minutes live discussion; 5 minutes self-paced writing.