// linux fundamentals — capstone

Capstone — You're Ready for NixOS

Soren Brumbach · · 5 min read

This file is a final exam, a synthesis exercise, and a map of the road ahead. If you can clear it honestly, you have the complete foundation NixOS assumes — and more Linux understanding than most people who've used it for years.

Prerequisite: all nine modules, mastery checks passed. No new material is introduced here on purpose: if anything below feels unfamiliar, that's a pointer back, not a gap in this file.

Part 1 — The oral exam

Answer each out loud, without notes, in a few sentences. Every one is drawn from a module's mastery check; the module link is your remedy.

  1. Explain the kernel/userland boundary, what enforces it, and what a system call is. — Module 0 — What Linux Even Is, Module 2 — The Kernel
  2. When you type a command name, how does the shell find the program? — Module 1 — The Shell and the Command Line
  3. What is an inode, why is a filename not part of the file, and what does that make mv, hard links, and deletion? — Module 3 — Everything Is a File
  4. Recite the kernel's four-step permission check and read any ls -l line completely — special bits included. Predict any chmod, octal or symbolic. — Module 4 — Users, Groups, and Permissions
  5. Narrate fork/exec/wait for a shell running ls; explain what a zombie is and who reaps orphans. — Module 5 — Processes, Signals, and IO
  6. Describe every stage from power button to login prompt, and name the fallen stage for: no vendor logo · "no bootable device" · "cannot mount root" · hangs before login. — Module 6 — The Boot Sequence
  7. Sketch a .service unit from memory, distinguish Wants=/Requires=/After=, and recite the universal debugging loop. — Module 7 — systemd
  8. Recite the seven-rung network debugging ladder, and what getent vs. dig disagreement means. — Module 8 — Networking on Linux
  9. State the core structural problem of traditional package management in one sentence and derive its four pains. — Module 9 — Package Management and Shared Libraries
  10. Explain why the FHS is a convention rather than a law, and what a symlink is — precisely enough that a system built almost entirely out of symlinks into an immutable store sounds like engineering, not sorcery.

Part 2 — The practical exam

On a machine (ideally a fresh VM), cold, no notes:

  1. Recon: in ten minutes, produce: kernel version, distro, firmware type, init system, boot target, mounted filesystems and their types, all listening sockets with owning processes, all setuid binaries, and the five largest packages or directories. (Everything from Labs 0–8; if any step needs a search, that module's lab wants a redo.)
  2. Build and supervise: write a script that logs a timestamp to a file, wrap it in a systemd service + timer running every 5 minutes as a non-root user, verify via the journal, then cleanly remove all of it.
  3. Diagnose: plant (or have a friend plant) one fault — a stopped service, a hosts-file poison, a permission lockout on a directory path, a masked unit — and find it methodically, narrating which layer each check eliminates.
  4. Explain: give your five-minute "what actually happens between the power button and my prompt" talk, and your five-minute "why NixOS exists" talk, to a rubber duck or a patient human. Fluency here, more than anything else, is the real credential.

Part 3 — Synthesis: one story, nine modules

Read this paragraph and notice that every clause is now transparent to you:

You press the power button. Firmware finds the ESP and runs systemd-boot, which loads a kernel and initramfs and passes root=UUID=…. The kernel initializes memory management and scheduling, unpacks the initramfs, loads storage modules, mounts the real root, and execs PID 1. systemd resolves a dependency graph and forks/execs hundreds of services, each dropping to an unprivileged UID, stdout wired into the journal; fstab becomes mount units; udev loads drivers as devices appear. A getty offers a login; PAM checks your hash in /etc/shadow; a shell starts carrying your UID and environment. You type a command: the shell walks $PATH, forks, execs; the dynamic linker maps shared objects from /usr/lib; the process asks the kernel for files through syscalls, and on each open the kernel runs a four-step check of nine bits in an inode. Output flows through fd 1 into your terminal. Everything you see is a file; everything running is a process; everything installed is a package that unpacked files into a shared global tree — and that last clause is the one NixOS rewrites.

If any clause is fuzzy, its module number is practically audible. That paragraph is the curriculum.

Part 4 — The road into NixOS

You're done with foundations. The NixOS-specific path, in order, each step anchored to what you now own:

  1. The Nix language — the small functional language of build descriptions. (New material — but only syntax; the semantics land on Module 9's pure-function model.)
  2. The store and derivations — how a build description becomes an immutable /nix/store path. (Modules 3, 4, 9: inodes, read-only enforcement, hashed paths.)
  3. configuration.nix and NixOS modules — declaring an entire system: users, services, networking, boot. (Modules 4, 6, 7, 8 — you can already read every option's generated output.)
  4. Generations and rollback in anger — rebuild, break something on purpose, roll back from the boot menu. (Module 6, now as a lived experience.)
  5. Flakes and Home Manager — pinned inputs and per-user declarative config. (Module 9's reproducibility, taken to its conclusion.)

Suggested first mile: install NixOS in a VM, reproduce your Module 7 lab service declaratively, rebuild, roll back, and diff the generations. That single exercise touches every foundation in this vault.

Reference shelf

  • man 7 conceptual pages: signal, hier, capabilities, namespaces — plus man systemd.unit, man systemd.service
  • The Arch Wiki — the best plain-language documentation of Linux components, distro-agnostic in practice
  • The Linux Programming Interface (Kerrisk) — the authoritative depth behind Modules 2, 4, 5
  • How Linux Works (Ward) — this curriculum's territory in book form, good for a second pass
  • NixOS manual + nix.dev — the official road for Part 4
  • Your own vault: the essays and lab notes you wrote are the durable artifact. Keep writing them in NixOS-land.

You started this course unable to say what a kernel was. You can now trace a keystroke to a syscall, a power button to a prompt, and a design decision from 1969 to a distribution from 2006. Go build the system declaratively — and when something breaks, you'll know exactly which runner dropped the baton.

→ Next vault: NixOS.