// linux fundamentals — module 00

Module 0 — What "Linux" Even Is

Soren Brumbach · · 11 min read

Thesis: "Linux" is used to mean at least three different things — a kernel, a family of operating systems, and a culture. Untangling them now means nothing later will be mysterious about which layer you're looking at.

Prerequisite: none. This is the beginning.

0.1 What an operating system is for

Start from bare metal. A computer is a CPU, some RAM, and a collection of devices — disks, network cards, keyboards, screens. The CPU is breathtakingly literal: it fetches an instruction from memory, executes it, and moves to the next one, billions of times per second. It has no concept of a "program," a "file," a "user," or a "window." Those are all inventions — software fictions layered on top of the hardware to make it usable.

The operating system is the software that creates and maintains those fictions. Concretely, it solves three problems that every computer has:

  1. Sharing. You want to run many programs, but there's one CPU (or a few cores) and one pool of RAM. Something has to slice CPU time and parcel out memory so that programs can coexist without trampling each other.
  2. Abstraction. Every disk, network card, and keyboard speaks its own hardware dialect. Something has to hide that mess behind uniform ideas like "file" and "network connection," so a program can say read this file without knowing or caring which manufacturer's disk it lives on.
  3. Protection. A buggy or malicious program must not be able to crash the whole machine, read another program's memory, or scribble over the disk. Something has to enforce boundaries.

The single program at the center of all three jobs is called the kernel.

0.2 The kernel

The kernel is one program — on Linux systems, literally a file on disk (you'll find it later as something like /boot/vmlinuz-…) — that is loaded into memory when the machine starts and then never exits until you shut down. It is the only software on the system that talks to hardware directly. Everything else runs on top of it and must go through it.

The kernel's responsibilities, which you will meet one by one in this course:

  • Process management — deciding which program runs on which CPU core, and for how long (Module 2, Module 5)
  • Memory management — giving each program the illusion of its own private memory (Module 2)
  • Filesystems — turning "spinning platters" or "flash cells" into files and directories (Module 3)
  • Device drivers — the hardware-dialect translators (Module 2, Module 6)
  • Networking — the entire TCP/IP stack lives in the kernel (Module 8)
  • Security enforcement — checking permissions on every single access (Module 4)

Here is the crucial part. When Linus Torvalds released "Linux" in 1991, this kernel is all that "Linux" meant — and in precise usage, it's all it means today. The kernel alone is not a usable system. It boots, and then sits there with nothing to run. Everything you actually touch — the shell, the text editor, the web browser, even the login prompt — is not the kernel.

0.3 Kernel space vs. user space

This is the single most important boundary in this entire course. Nearly every concept in Modules 2–7 lives on one side of it or the other, and knowing which side you're on tells you what rules apply.

Modern CPUs have (at least) two privilege modes, built into the silicon:

  • Kernel mode (also called supervisor mode): the CPU will execute any instruction, including ones that talk to hardware, remap memory, or disable interrupts. The kernel runs here.
  • User mode: the CPU refuses privileged instructions. Try one, and the CPU itself traps and hands control to the kernel, which typically kills your program. All normal programs run here.

We call the code and memory of the kernel kernel space, and everything else user space (or userland). The boundary is enforced by hardware — it is not a convention or a politeness; a user-mode program physically cannot touch the disk controller.

So how does anything get done? If your program can't touch the disk, how does it save a file? It asks the kernel to do it on its behalf. The mechanism for asking is called a system call — a controlled, well-defined doorway through the boundary. Your program says, in effect, "kernel, please open the file called notes.txt," the CPU switches to kernel mode, the kernel checks whether you're allowed (Module 4), does the work, and returns the result. Then the CPU drops back to user mode.

You'll examine system calls closely in Module 2 — and even watch a program make them, one by one. For now, fix the picture:

┌─────────────────────────────────────────────────┐
│  USER SPACE                                     │
│  shell · editors · browsers · servers · daemons │
│  — every program you will ever run —            │
└────────────────────┬────────────────────────────┘
                     │ system calls (the only doorway)
┌────────────────────▼────────────────────────────┐
│  KERNEL SPACE                                   │
│  scheduler · memory manager · filesystems ·     │
│  drivers · network stack · permission checks    │
└────────────────────┬────────────────────────────┘
                     │
              hardware (CPU, RAM, disks, NICs…)

Why the boundary exists: stability (a crashing program can't take down the machine, because it never had its hands on the machine) and security (the kernel checks every request against the permission rules, and there is no way around the checkpoint).

0.4 Userland: the other 95% of your system

Everything above the line needs a name: userland. It includes:

  • The shell — the program that reads your commands and runs them. Note carefully: the shell is not the kernel, not the terminal window, and not "Linux." It is one ordinary user-space program among thousands, and you could swap it for a different one. Module 1 is devoted to it.
  • Core utilities — the small tools like ls, cp, cat, grep. On most distributions these come from the GNU project (more on that in the history section), which is why pedants say "GNU/Linux."
  • Libraries — shared code that programs use, most importantly the C library (libc), which wraps raw system calls in friendlier functions. (This becomes a main character in Module 9.)
  • Daemons — background service programs (web servers, network managers, login handlers). The name is old Unix whimsy; think "helpful background spirit."
  • The init system — the very first user-space program the kernel starts, which then starts everything else. Ancestor of all. On modern systems it's called systemd, and Module 7 is devoted to it.
  • Graphical stack — the display server, window manager, desktop environment. All userland; the kernel neither knows nor cares that windows exist.

The takeaway: when something happens on your system, your first diagnostic question from now on is "is this the kernel's doing, or a userland program's?" That one question routes you to the right rules, the right documentation, and the right fix.

0.5 What a distribution is

The kernel is developed by one community. The GNU tools by another. systemd, the desktop environments, the ten thousand applications — all separate projects by separate people. Nobody hands you a box labeled "Linux."

A distribution (distro) is a project that does the assembling. A distro is, concretely:

  1. A kernel, built with a chosen configuration
  2. An init system (nearly always systemd today)
  3. A userland — the core utilities, libraries, and a curated catalog of applications
  4. A package manager — the tool that installs, upgrades, and removes software (Module 9)
  5. Defaults and glue — the filesystem layout, the preinstalled configuration in /etc, the installer, the release schedule, the security update pipeline

Debian, Ubuntu, Fedora, Arch, and NixOS are all distributions. They share the kernel (approximately) and most of the userland; they differ in packaging, defaults, philosophy, and release rhythm. This is why "Linux" can feel wildly different between two machines while being the same thing underneath: the kernel/userland split means the identity of the system mostly lives in userland choices.

One sentence to memorize: a distribution is an opinionated pile of files, placed at standard paths, maintained by a package manager. That sentence is bland now. It becomes explosive in Module 9, because NixOS's entire reason for existing is a disagreement with the words pile, standard paths, and maintained by mutation.

0.6 The Unix philosophy

Linux is a member of the Unix family — it reimplements the design of Unix, an operating system born at Bell Labs in 1969. Along with the design came a culture, usually summarized as the Unix philosophy:

  1. Write programs that do one thing and do it well. ls lists files. It does not also edit them, compress them, or email them.
  2. Write programs that work together. Small tools compose into big solutions.
  3. Use text as the universal interface. Programs read and write plain text streams, so any tool's output can become any other tool's input.

You will feel this philosophy physically in Module 5, when you chain tools together with pipes and a one-line command does something no single tool could. It also explains an aesthetic you'll notice everywhere: configuration lives in plain-text files, system state is exposed as readable text (Module 2's /proc), and the command line remains the primary interface because text composes and pictures don't.

0.7 A short, load-bearing history

You don't need dates memorized, but the lineage explains why things are named and shaped the way they are:

  • 1969 — Unix is created at Bell Labs (Ken Thompson, Dennis Ritchie). Its design — everything is a file, small composable tools, the process model — is the design Linux still follows. When Module 3 says "everything is a file," that's a 1969 idea, still winning.
  • 1983 — GNU ("GNU's Not Unix") is launched by Richard Stallman: an effort to build a complete, free (as in freedom) reimplementation of Unix. GNU produced the compiler, the C library, the shell (bash), and the core utilities — a whole userland. But its kernel wasn't ready.
  • 1991 — Linux. Linus Torvalds, a Finnish student, writes a Unix-like kernel as a hobby and releases it under the GNU license. GNU's finished userland + Linus's kernel = a complete free operating system. This is why the pairing is sometimes written GNU/Linux, and why "Linux" ambiguously means "the kernel" or "the whole system" depending on who's talking.
  • 1990s–2000s — the distro explosion. Debian, Red Hat, and hundreds of others take on the assembly job from §0.5, each with different opinions.
  • 2003 — Nix, and 2006 — NixOS: a research project asks what if installing software never mutated anything? and eventually rebuilds the entire "distribution" layer around that answer. NixOS keeps the kernel, keeps systemd, keeps the userland programs — and replaces the assembly model. That's your destination.

0.8 → NixOS

Everything NixOS does differently happens in the distribution layer — layer by layer:

  • The kernel: same Linux kernel as everyone else (you'll get to choose and declare its version).
  • systemd: same init system as everyone else (you'll generate its configuration instead of editing it).
  • The userland programs: the same bash, ls, and grep (they'll just live in unusual places).
  • The assembly: completely different. Instead of a package manager mutating a shared pile of files, NixOS builds the entire system from a single declarative description, like a compiler building a program from source code.

You cannot appreciate what NixOS changes until you know what a conventional distro does — which is what Modules 1 through 9 teach.

Lab 0

Do these on any Linux machine (a VM is perfect). Type the commands yourself — no copy-paste. The typing is part of the learning.

  1. Identify your kernel. Run:

    uname -a

    You'll get one dense line. Find the piece that looks like 6.9.1 or similar — that's the kernel version, the version of the one program from §0.2. Also find your machine's architecture (x86_64 or aarch64). Everything else on that line is labeling.

  2. Identify your distribution — and notice it's a separate fact. Run:

    cat /etc/os-release

    This file is how the distribution identifies itself: name, version, homepage. Observe that nothing here overlaps with uname's output. Kernel version and distro version are independent — the same kernel could power any distro, and one distro ships many kernels over its life. Two commands, two layers.

  3. Meet your shell — and see that it's just a program. Run:

    echo $SHELL

    You'll get a path like /bin/bash or /run/current-system/sw/bin/zsh. That path points to an ordinary file — the shell is a program on disk like any other, not a built-in part of "Linux."

  4. Count the userland. Run:

    ls /usr/bin | wc -l

    (Read it as: "list that directory, count the lines." Pipes get their full treatment in Module 5.) The number — likely in the thousands — is a rough census of userland programs installed on your machine. Exactly one program on the whole system is the kernel. Everything you just counted is not.

  5. Write the three sentences. In this vault or on paper, write one sentence each, in your own words, defining: the kernel, the shell, and a distribution. If any sentence is fuzzy, re-read the matching section. These three sentences are the foundation stone of the entire course.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

  1. What are the three jobs an operating system exists to do?
  2. What is the kernel, and what makes it different from every other program on the system?
  3. A user-space program wants to read a file from disk. Why can't it do so directly, and what does it do instead?
  4. What enforces the kernel/user boundary — software convention, or something stronger?
  5. Name four things a distribution bundles besides the kernel.
  6. Someone says "Linux is the operating system." Someone else says "Linux is just the kernel." Explain what each means and why both usages exist.
  7. State the three tenets of the Unix philosophy.

And perform cold:

  • Determine the kernel version and the distro name of any Linux machine you're handed, using two commands.

When all of that is effortless: Module 1 — The Shell and the Command Line