Most engineering work touches a Linux box eventually — a build server, a workstation, a robot’s onboard computer, a remote machine you SSH into to look at a log. If you’ve gotten by with copy-pasted commands and a vague feeling that you should really learn this properly someday, this guide is for you.
It’s structured the way I wish someone had taught it to me. No “Linux is a kernel and the kernel is…” opening. Instead: a clear mental model of what’s actually happening when you type a command, the dozen-or-so commands you’ll use 95% of the time, and the smaller set of techniques (pipes, redirection, finding files, processes) that compound the longer you use them.
What it covers
Five parts, about forty-five minutes to read.
Part I — The mental model. What Linux actually is. The shell as the program you’re talking to. Everything-is-a-file. Why this matters even when you’re just trying to run a script.
Part II — The file system. The tree, where stuff lives, paths absolute vs relative, the two or three commands you’ll use a hundred times a day to move around it.
Part III — Essential commands. ls, cat, cp, mv, rm, mkdir, grep, find, chmod, tar. What each one does, the flags worth knowing, and the combinations that make them powerful.
Part IV — Pipes, redirection, and processes. The Unix philosophy in practice. Piping output between commands. Redirecting to files. Backgrounding jobs and managing processes.
Part V — The handful that save real time. SSH, the basics of editor choice (vim vs nano vs VS Code remote), package managers, environment variables, the things that look advanced but pay back the learning cost in a week.
Every command has its own example block you can read at a glance.
Read it
The guide lives at its own URL with a lighter visual identity — wheat-colored paper, a deep ink-blue accent, code blocks designed to actually be readable. It’s the second in a small series of practical-tooling field notes.
← Back to Autonomy