Don't Panic — Linux Fundamentals

Linux is a kernel — the part of an operating system that talks to hardware, schedules work, and enforces the rules — plus a large, loosely federated pile of user-space software that somebody has to assemble into something you can actually install.

That somebody is a distribution, and this is the first thing that trips people up: there is no single "Linux," there are hundreds of distributions that share a kernel and disagree about almost everything built on top of it.

Before Linux, if you wanted a Unix-like system on ordinary PC hardware, your options were a restrictively licensed teaching operating system or an expensive commercial Unix you probably couldn't afford and definitely couldn't read the source of. Linux existed because a student wanted to run something Unix-shaped on his own machine and was willing to write the missing kernel himself. The GNU project had already spent most of a decade writing the user-space half of a free Unix and needed exactly this piece to finish the job.

Two ideas do most of the work in this course. First, everything you do gets routed through a small number of layers — kernel, filesystem, processes and services, shell — and diagnosing a problem is mostly a matter of working out which layer owns it before you touch anything. Second, a path is not a permission slip: /etc/shadow existing where you expect it tells you nothing about whether you're allowed to read it. That depends on who is asking, not where the file lives.

Here's the part that catches people who've read the manual and still get surprised: a permission denial doesn't tell you which layer denied you. Ordinary owner/group/other bits, ACLs, capabilities, and a mandatory-access system like SELinux or AppArmor each get an independent veto, and Linux hands back the same Permission denied regardless of which one used it. Fixing the layer you noticed first is not the same as fixing the layer that's actually in your way — you may need to check three more before the operation that "should just work" actually does.

Start with the Intro tab for the mental model that everything else here assumes: kernel, filesystem, processes, shell, in that order. The cheatsheet is where you go once you already know what you're looking for and want the exact permission table or the systemd command. Field Notes collects the judgment calls that don't fit either of those — what a sudo allow-list actually protects you from, and why "active" in systemctl status doesn't mean "ready." The quiz is a decent gut check on whether the four-layer model actually stuck, and the reference links are where you go once orientation stops being the problem and depth becomes the problem instead.

None of this makes you a systems administrator by itself. It gets you to the point where an unfamiliar Linux box is a system you can reason about instead of a wall of commands you're pattern-matching against.

Don't Panic — Linux Fundamentals

Relevant careers