<aside> 1️⃣

Module 1 — What Linux Is

Every machine you will touch in DevOps — cloud instances, CI runners, Kubernetes nodes — runs Linux. This module builds the mental model everything else stands on: what an operating system is, what the kernel does, what a distribution is, and how to talk to Linux through a shell.

Legend used throughout: 🧠 concept → 🧩 analogy → 🧪 exercise → ✅ expected result (hidden) → 🎯 interview questions (hidden)

</aside>

<aside> 🚦

Before you start

This is the first module — nothing else is required, and no prior knowledge is assumed. You do need a Linux command line to practice on. Any one of these works: the Terminal app on a Linux desktop, an Ubuntu virtual machine, Windows Subsystem for Linux (install guide), or a free-tier cloud VM. All expected outputs in this track come from Ubuntu 24.04. macOS's Terminal is close but not Linux — most commands here work there, but outputs differ in small ways.

</aside>

<aside> ℹ️

This page uses Mermaid diagram blocks. Notion shows them as code by default — click the block and set it to Preview to see the diagram. This reminder appears once per page.

</aside>

Part A — What Linux actually is

A1. What an operating system does

<aside> 📖

Official docs: The Linux Kernel documentation — the kernel's own manual, maintained by the people who write it.

</aside>

🧠 A computer, by itself, is astonishingly dumb. The processor (CPU) executes instructions. Memory (RAM) holds data while the power is on. The disk stores data permanently. The network card moves bytes in and out. None of these parts knows what a file is, what a user is, or what a program is. Something has to coordinate them.

That something is the operating system (OS). It is software that starts when the machine powers on and stays running until shutdown. It has three jobs:

Run programs. Load them into memory, give each a fair slice of CPU time, clean up when they finish.
Own the hardware. Programs never talk to the disk or the network card directly. They ask the OS, and the OS does it on their behalf.
Keep order. One misbehaving program must not overwrite another program's memory or read data it should not see.

Linux is an operating system. So are Windows and macOS. All three do these same three jobs, with different designs and histories.

<aside> 🧩

Real-world analogy — the building manager

A large office building has one building manager. Tenants (programs) do not rewire the electricity or reprogram the lifts themselves — they file requests, and the manager's staff does the physical work. The manager also assigns offices (memory), schedules the loading dock (disk access), and evicts tenants who damage the building (misbehaving programs).

Where the analogy stops working. A building manager makes a few decisions an hour and can be argued with. The OS makes millions of decisions per second, and a program cannot negotiate, bribe, or sneak past it — the CPU hardware itself enforces who is in charge.

</aside>

🧪 Exercise A1.1 — Meet your terminal

# Open your terminal application. You will see a line of text ending in $ — the prompt.
# Type each command below and press Enter after each one.
whoami   # prints the name of the user you are logged in as
date     # prints the current date and time

✅ Expected result — click to reveal

A2. The kernel and everything above it

<aside> 📖

Official docs: The Linux Kernel documentation · intro(1) — introduction to user commands

Goes deeper: the kernel/userspace boundary and system calls get a full theory module in the companion track — Module 01 — Kernel, User Space & the System Call Boundary. Read it after finishing this module, not instead of it.

</aside>

🧠 Inside the operating system, one program matters more than all the others: the kernel. It is the first real program to run at power-on, and it never exits. The kernel is the only software allowed to touch hardware directly. Everything else — your terminal, your commands, every application — runs in userspace: a fenced-off area with no direct hardware access.