Visual field notes for Linux

The machine makes more sense when you can see inside.

Durable explanations of the invisible work beneath everyday commands—drawn layer by layer, sourced from the system, and safe to test yourself.

Live model / command path

static-firstswipe →

A command moving through Linux system layersThe command ls moves from a keyboard to the shell, through the kernel and filesystem, then returns output to the terminal.01 / INPUTkeyboard02 / PARSEshell$ ls -la03 / EXECkernel04 / READfilesONE KEYPRESS / MANY LAYERSls -lastdout → pixels
The animation is orientation, not content. Each published figure includes a complete text explanation and remains meaningful without JavaScript.

Launch dossier / 001–005

Five systems worth seeing clearly.

Not command recipes. Working models you can carry from one distribution, incident, and machine to the next.

  1. 01

    command / beginner

    What happens when you press Enter?

    Follow ls -la from a terminal keystroke through shell parsing, command lookup, process replacement, filesystem calls, and pixels on screen.

    Published →

  2. 03

    pipe / intermediate

    What a pipe actually does

    Replace the punctuation model of `|` with connected processes, file descriptors, bounded kernel buffers, and backpressure.

    Published →

  3. 04

    disk / intermediate

    Why df and du disagree

    Reconcile filesystem allocation with files a directory walk can reach, then diagnose gaps without reaching for a cleanup command.

    Published →

  4. 05

    memory / intermediate

    Linux memory beyond used versus free

    Read RAM as anonymous memory, reclaimable cache, kernel state, swap, and pressure—then separate host capacity from cgroup limits.

    Published →

Our method

Inspect first.
Change second.

Linux rewards curiosity, but unexplained commands teach dependency. Every note starts with a mental model, shows the evidence, then offers a lab.

  1. 01
    Draw the boundary

    Name what is simplified and what is implementation detail.

  2. 02
    Follow the evidence

    Prefer man pages, kernel docs, project docs, and source.

  3. 03
    Make it testable

    Read-only inspection before mutation; warnings beside risk.