1️⃣Module 1 — What Linux Is

Two short outputs, one per command:

zaeem
Thu Sep  3 09:14:52 +08 2026

What to read out of it:

• whoami prints one word: your username. Yours will not be zaeem — it is whatever name you (or your cloud provider) created. On many cloud VMs it is ubuntu. If it says root, you are logged in as the all-powerful administrator — Module 4 explains why that deserves respect.
• The date line has six fields: weekday, month, day, time, timezone, year. The timezone is whatever your machine is set to — a cloud VM usually says UTC while a laptop says your local zone. Same moment, different label.
• Notice the double space between Sep and 3 — the day is padded to two characters. Small alignment quirks like this are normal in Linux output; later modules teach tools that handle them.
• After each command finishes, the prompt comes back. That is how you know the command is done and the shell is ready for the next one.

Linux
6.8.0-79-generic
Linux myhost 6.8.0-79-generic #79-Ubuntu SMP PREEMPT_DYNAMIC Thu Jul 24 21:15:23 UTC 2026 x86_64 x86_64 x86_64 GNU/Linux

What to read out of it:

• uname alone answers with the kernel's name: Linux. You have now confirmed, from the inside, what this machine runs.
• uname -r prints the kernel version. Yours will differ — 6.8.0-79-generic means kernel series 6.8, Ubuntu build 79. Any 5.x or 6.x kernel is modern.
• The -a line packs several fields together: kernel name, this machine's hostname, the release again, the build description, then the CPU architecture repeated (x86_64 on Intel/AMD machines, aarch64 on ARM — common on cloud servers and Apple hardware). The final word, GNU/Linux, previews Part D.
• Version numbers in this track will never exactly match yours. That is expected — read the shape of the output, not the digits.

PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
VERSION="24.04.4 LTS (Noble Numbat)"
VERSION_CODENAME=noble
ID=ubuntu
ID_LIKE=debian
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
UBUNTU_CODENAME=noble
LOGO=ubuntu-logo

What to read out of it (on another distro the values differ, the field names do not):

• ID=ubuntu — the machine-readable distro name. Scripts test this field, never the pretty one.
• ID_LIKE=debian — "treat me like a Debian system". This is how tools know Ubuntu belongs to the Debian family.
• VERSION_ID="24.04" — the release number. Ubuntu numbers releases by date: year 24, month 04. LTS means Long Term Support — five years of fixes, which is why servers run LTS versions almost exclusively.
• The URLs and logo lines are informational padding — real output is often messier than you need, and part of the skill is knowing which lines to ignore.

hello
/bin/bash
GNU bash, version 5.2.21(1)-release (x86_64-pc-linux-gnu)
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

What to read out of it:

• echo hello prints exactly its argument. Trivial now, indispensable later — echo is how you will check what the shell actually sees before running something dangerous.
• echo $SHELL did not print the word $SHELL. The shell swapped the variable for its value — /bin/bash, the address of the bash program — before echo even ran. That swap-then-run order is the single most important shell behaviour, and Module 5 is built on it.
• bash --version answers with a version block. The first line is the one you read: bash 5.2. The GNU prefix and the license lines are the history of Part D showing up in your terminal.
• If your $SHELL says /usr/bin/zsh or similar, you are in a different shell — everything in this module still works, but install a system with bash before Module 5.

The kernel is the core program of the operating system: the first real program to run at power-on and the only one with direct access to hardware. It schedules which program uses the CPU and when, manages memory, drives devices, and enforces the boundary between userspace and itself. Programs get hardware work done by making system calls — formal requests the kernel validates and performs.

The details that separate candidates: naming system calls as the precise boundary between userspace and kernel; knowing Linux is a monolithic kernel (drivers run inside it) that stays flexible through loadable modules; and pointing out that every distribution ships the same upstream kernel, differing mainly in version and patches. Average answers stop at "it connects software to hardware".

Linux is a family of open-source, Unix-like operating systems built on the Linux kernel. Strictly, Linux is the kernel; in practice, the name covers whole distributions. Key features: open source — the code is public and modifiable under the GPL; multi-user — several people can use one machine at once with their own files and permissions (Module 4 shows how); multitasking — the kernel shares the CPU across many running programs; portable — it runs on everything from a Raspberry Pi to the entire top-500 supercomputer list; and stable — servers routinely run for years without a reboot.

The details that separate candidates: saying "Linux is technically the kernel; distributions make it an OS" — it signals precision; and grounding "portable" in something concrete (x86_64 and ARM cloud instances, Android's kernel) rather than reciting adjectives.

Bottom to top: hardware — CPU, memory, disks, network; the kernel — owns the hardware, schedules everything, exposes system calls; system libraries — shared code (chiefly the C library) that wraps system calls so programs don't make them by hand; system utilities — the standard commands like date, cat, uname; and the shell — the interpreter between you and the rest. Applications sit on top.

The details that separate candidates: being able to place each layer in order and name the interface between adjacent layers (you → shell → programs → system calls → kernel → hardware). Candidates who can draw this diagram from memory rarely stumble on any follow-up.

The shell is a userspace program that reads command lines, interprets them by fixed grammar rules — expanding variables, splitting words — and runs the requested programs. It is not part of the kernel and not the terminal window. Common shells: bash (the server default nearly everywhere), zsh (macOS's default, popular interactively), ksh and tcsh (older, still in legacy shops), fish (friendly, not standards-compatible), and sh (the minimal POSIX baseline that scripts target for portability).

The details that separate candidates: the terminal/shell distinction stated crisply; knowing why sh still matters (portable scripts, and on many systems /bin/sh is a different, stricter program than bash — a classic source of "works on my machine" bugs, revisited in Module 9).

Thu Sep  3 09:14:52 +08 2026
Thu Sep  3 01:14:52 UTC 2026
09:14

What to read out of it:

• Line 1 vs line 2: the same instant, printed in your local zone and in UTC. The hour and the zone label change together — here, 09:14 in Malaysia is 01:14 UTC. Servers and logs live in UTC; your laptop lives in local time. Keeping those straight becomes second nature in DevOps.
• Line 3: the format argument took over completely. %H means hours, %M minutes, and everything else vanished. Options tweak behaviour; arguments can redefine the whole output.
• Nothing was printed about "success" anywhere — the output is the result.

one two three

What to read out of it:

• Your extra spaces are gone. The shell split the line into words — echo, one, two, three — and the number of spaces between words was thrown away in the process. echo then printed its arguments joined by single spaces.
• Lesson: the command never saw your spacing. The shell hands programs a list of words, not your original line. When quoting arrives in Module 5, this is the behaviour quotes exist to control.

Linux
Linux
6.8.0-79-generic
Linux 6.8.0-79-generic

What to read out of it:

• Lines 1 and 2 are identical — proof that -s and --kernel-name are the same switch in two spellings.
• Line 4 shows combining: -sr produced both values, space-separated, in one line. In scripts you will see the long forms on purpose: uname --kernel-name needs no comment explaining it.

bash: daet: command not found

(On a desktop or WSL Ubuntu you may instead see a friendlier, multi-line Command 'daet' not found, did you mean: command 'date'… — Ubuntu adds a suggestion helper on top of the very same failure. Same lesson either way. Inside scripts, bash also adds a line number.)

What to read out of it:

• The reporter is the shell, not a program — daet never ran, because the shell searched everywhere it knows for a program by that name and found nothing. Where exactly it searches is the PATH, a Module 5 topic with its own war stories.
• command not found therefore always means one of three things: you misspelled it, it isn't installed, or it lives somewhere the shell doesn't look. Diagnosing which is a five-second job by the end of Part C.

bash: Echo: command not found

What to read out of it:

• Same error as the typo — because to Linux, a wrong capital is a typo. Echo and echo are unrelated names.
• This applies to filenames too (Report.txt and report.txt are different files — Module 2), which is a genuine hazard for anyone arriving from Windows, where case doesn't distinguish names.

date: invalid option -- 'x'
Try 'date --help' for more information.

What to read out of it:

• The reporter this time is date itself — the shell found the program and ran it; the program then rejected the option. Compare with B3.1, where the shell never found anything to run. Asking "who is complaining?" is the first move in reading any error.
• The second line is the gift: the error names the exact next command to run. Well-behaved tools do this, and Part C is about taking them up on the offer.

Bash — the Bourne Again SHell — is the GNU project's command interpreter and the default shell on most Linux distributions. It reads command lines (interactively or from script files), applies the shell grammar — variable expansion, word splitting, redirection (Module 5) — and runs programs. The name is a pun: it replaced the 1970s Bourne shell (sh), staying compatible while adding history, tab-completion, arithmetic, and richer scripting.

The details that separate candidates: knowing bash is a shell, not the shell — and that on Debian and Ubuntu, /bin/sh is deliberately not bash but a smaller shell called dash, which is why some scripts break when run "the same way" on different systems (a story Module 9 finishes).

The ones to name: bash — default on most distros, the assumed shell of nearly every script; zsh — bash-compatible for daily use, better interactive comforts, macOS's default since 2019; ksh — the Korn shell, still common on legacy Unix; tcsh/csh — C-shell family, different grammar, mostly historical; fish — friendly but deliberately non-POSIX; dash — minimal and fast, used as /bin/sh on Debian-family systems for running scripts, not people.

The details that separate candidates: separating interactive shells (what humans prefer — zsh, fish) from scripting targets (what automation assumes — bash, POSIX sh), and knowing which shell a script gets is decided by the script itself via its first line (the shebang — taught properly in Module 9).

whoami prints the user the current shell is running as — the answer to "who am I, right here". The related who lists all users with open sessions on the machine, with their login times and where they connected from. The distinction matters: on a shared server the two answer different questions.

The details that separate candidates: mentioning that whoami reports the effective user — so after you switch identities with sudo (Module 4), whoami says root, which is exactly how you verify a privilege switch worked before running something irreversible.

The output starts like this (then continues with a long option list):

Usage: date [OPTION]... [+FORMAT]
  or:  date [-u|--utc|--universal] [MMDDhhmm[[CC]YY][.ss]]
Display date and time in the given FORMAT.
With -s, or with [MMDDhhmm[[CC]YY][.ss]], set the date and time.

What to read out of it:

• Line 1 decoded: date, optionally any number of options, optionally one format argument starting with +. That is everything you did in B1.1, formalised.
• Line 2 is an alternative form, and it contains a warning hidden in plain sight: date can also set the system clock. The same tool that reads the time can change it — reading usage lines carefully is how you notice such things before they happen.
• The [-u|--utc|--universal] group shows a third notation: | means "any one of these spellings".
• Scrolling output is clumsy — Modules 3 and 5 teach pagers and pipes, the proper tools for long text.

Your terminal switches into a full-screen reader beginning:

DATE(1)                          User Commands                         DATE(1)

NAME
       date - print or set the system date and time

SYNOPSIS
       date [OPTION]... [+FORMAT]

What to read out of it:

• The title line DATE(1) shows the page name and, in parentheses, its section number — the subject of C3. User Commands is that section's title.
• /universal jumped you to the -u option's documentation — searching inside man pages beats scrolling every time.
• If you seem stuck in the viewer: press q. Nothing is broken. "How do I get out of this?" is every beginner's first man-page memory.
• If instead you got man: command not found or a "minimized system" notice — read the next callout; your machine is a minimal build.

passwd (1)           - change user password
passwd (5)           - the password file

Then man 5 passwd opens with:

PASSWD(5)               File Formats and Configuration               PASSWD(5)

NAME
       passwd - the password file

What to read out of it:

• whatis returned two lines — two different manuals behind one name. The one-line summaries alone tell you which you want.
• In the section-5 page's title bar, File Formats and Configuration confirms you are reading about a file, not a command. Glancing at that title bar every time you open a man page is a habit that costs nothing and prevents real mistakes.
• On some systems whatis passwd shows extra entries (e.g. openssl-passwd(1ssl)) — more installed software means more manuals. Read the section numbers, not the count.

No manual entry for date in section 9

What to read out of it:

• A precise error: not "date is unknown", but "not in that section". The page exists in section 1; you asked the wrong shelf.
• Compare the three failures you have now collected: shell can't find a command (B3.1), program rejects an option (B3.3), manual lacks a page (here). Three different reporters, three different fixes. Matching the error to its reporter is diagnosis.

who (1)              - show who is logged on
whoami (1)           - print effective user name
echo is a shell builtin
man is /usr/bin/man
date is hashed (/usr/bin/date)

(Your apropos who list may be longer — every match containing "who" appears, sometimes including things like w(1).)

What to read out of it:

• apropos found commands you already know and, in one line each, told you what they do. This is how you discover tools without leaving the terminal.
• type echo says builtin: when you run echo, no separate program starts — the shell does it internally.
• type man gives an address on disk: /usr/bin/man — a real separate program. (Addresses like this are Module 2's subject.)
• date is hashed (...) is the messy, realistic case: "hashed" means the shell already looked date up earlier and cached the location so it needn't search again. It is the same kind of answer as man's, plus a performance note. Real output has texture like this; read past it to the substance. (In a brand-new terminal it would say date is /usr/bin/date — the hashed note only appears once you have run date in that session, as you did earlier.)

man displays the reference manual for a command, file format, or system facility, straight from files installed on the machine — no network involved. Usage: man name for the default page, man 5 name to pick a section explicitly, man -f name (or whatis) to list all sections a name exists in, and man -k keyword (or apropos) to search summaries by topic. Inside the page: / searches, n repeats the search, q quits.

The details that separate candidates: explaining the section system unprompted — especially that man passwd and man 5 passwd are different documents — and noting that man pages document the installed version, which makes them more authoritative than web tutorials during an incident on that host.

man command — e.g. man uname. Two neighbours worth naming in the same breath: command --help for the quick usage summary printed inline, and apropos keyword for when the name itself is unknown.

The details that separate candidates: an average answer stops at "man". A strong one presents the three help tools as a method — apropos to find the name, --help for a fast reminder, man for depth — and mentions that minimal servers and containers often ship without man pages, so relying on --help under pressure is a real operational habit, not laziness.

GNU/Linux

What to read out of it:

• Your machine itself names the two halves: GNU userland, Linux kernel. The 1983 and 1991 stories, in one word of output.
• Compare uname -s from B2.1, which printed only Linux — the kernel's name. Options select which question you are asking, and precision about the question is precision about the answer.

x86_64

What to read out of it:

• x86_64 means Intel/AMD 64-bit. The other answer you will meet constantly is aarch64 — 64-bit ARM, which is Apple Silicon Macs, Raspberry Pi, and the cheap ARM instance families at every cloud provider.
• Why care: pre-built software is compiled per architecture. A program built for x86_64 will not run on aarch64. When a download page offers two Linux versions, this command is how you pick.

zaeem
myhost
Linux 6.8.0-79-generic
x86_64
PRETTY_NAME="Ubuntu 24.04.4 LTS"
NAME="Ubuntu"
VERSION_ID="24.04"
...

What to read out of it:

• Five commands answer the five identity questions you will ask of every unfamiliar machine for the rest of your career: who am I on it, what is it called, what kernel, what architecture, what distribution. Fifteen seconds, complete picture.
• hostname is new but true to its name — machines have names so that humans and networks can refer to them; Module 13 shows how names resolve to addresses. myhost is illustrative too: yours prints whatever the machine was named, and cloud VMs often show something like ip-172-31-8-14.
• If every line's output matched your prediction, Module 1 has done its job.

Unix is the original 1969 Bell Labs operating system and its licensed commercial descendants (AIX, Solaris, HP-UX); the name is a trademark tied to certification. Linux is a Unix-like kernel written independently by Linus Torvalds in 1991 — it shares Unix's design philosophy and follows POSIX, but contains none of Unix's code and is free software under GPLv2. Unix development is vendor-controlled; Linux is developed publicly by thousands of contributors and packaged by distributions. Today Linux utterly dominates servers and cloud; certified Unix survives mostly in legacy enterprise systems — and in macOS.

The details that separate candidates: "shares the design, not the code" — that one sentence shows real understanding; naming POSIX as the compatibility glue; and knowing macOS is a certified Unix, which surprises interviewers pleasantly and explains why Mac terminals feel Linux-ish.

The kernel. It is the lowest software layer, the bridge between hardware and everything else: it schedules the CPU, manages memory, drives devices, and serves system calls from userspace. Remove the kernel and nothing else can run; replace the parts around it and you simply have a different distribution.

The details that separate candidates: not stopping at the one-word answer — briefly walking the layer model (hardware → kernel → libraries and utilities → shell → user) shows you hold the whole map, not a flashcard.

Precisely: the Linux kernel — not the whole operating system, and not the tools around it. In 1991, as a Helsinki student, he released it under the GPL; combined with the GNU project's existing tools it became the complete free OS the world now runs on. (He later created git, which is a fine bonus point.) The kernel is written in C, with recent additions of Rust in drivers.

The details that separate candidates: the discipline of saying "the kernel, not the OS" — this question exists to catch exactly that imprecision — and the git remark, which reliably lands well in DevOps interviews since the same person built two tools you use daily.

Ticket text: "For the audit sheet we need: OS distribution + exact version, kernel version, CPU architecture, and the hostname as the system reports it. Screenshot or paste output."

Worked answer — four commands, run on the box:

hostname
cat /etc/os-release      # record PRETTY_NAME and VERSION_ID
uname -r                 # kernel release
uname -m                 # architecture

Paste the output and record: hostname as line 1; distribution from PRETTY_NAME (e.g. Ubuntu 24.04.4 LTS); kernel from uname -r; architecture x86_64 or aarch64. Two habits make this professional: use VERSION_ID/ID rather than retyping the pretty name (audit tools compare the machine-readable fields), and paste command output verbatim instead of paraphrasing — auditors, like debuggers, want evidence, not summaries.

Ticket text: "I typed HELP like on Windows and got HELP: command not found. Then help printed something confusing. How do I find out how to use commands here?"

Worked answer — three things to explain, gently:

1. Linux is case-sensitive: HELP and help are different names, which is why the capitals version failed outright.
2. There is no single help command; help is per command. The working method: somecommand --help for a quick summary; man somecommand for the full manual (q exits the reader — say this or they will be stuck); apropos keyword when they don't know a command's name yet.
3. Their lowercase help did run — it is a bash builtin describing the shell's own commands, which is genuinely confusing on day one and safe to ignore until Module 10.

A strong reply also includes one worked example (date --help, then man date) rather than instructions in the abstract.

Ticket text: "Our runbook says 'see man 5 passwd for the file layout'. An engineer ran man passwd, read about the password-changing command, and got confused about what the runbook wanted. What went wrong, and how do we stop it recurring?"

Worked answer: the manual has numbered sections, and passwd exists in two of them — section 1 (the passwd command) and section 5 (the format of the accounts file, /etc/passwd). Plain man passwd returns the first match in man's section search order (section 1 comes first on Ubuntu), so the engineer read the command's page — authoritative-looking, and irrelevant. man 5 passwd was the page the runbook meant. Verify with whatis passwd, which lists both. Prevention: runbooks should always write man references with the section — passwd(5), crontab(5) vs crontab(1) — and reviewers should treat a bare man foo in a runbook as a bug. The title bar of every man page shows its section; glancing at it is free insurance.

Ticket text: "We added Rocky Linux hosts to a fleet that was all Ubuntu. The provisioning runbook fails early on them. Before touching anything: how do we tell, per host, exactly what we're on, and why would Ubuntu instructions fail on Rocky?"

Worked answer: identify each host with cat /etc/os-release — on the new machines ID=rocky with ID_LIKE="rhel centos fedora", versus ID=ubuntu, ID_LIKE=debian on the old ones. That ID_LIKE field is the explanation in miniature: Rocky belongs to the Red Hat family, Ubuntu to the Debian family, and family-specific tooling — starting with the software-installation commands most runbooks are full of — differs between them (Module 9 covers both families' tools). The everyday commands of this module behave the same on both. Professional fix: make the runbook check ID/ID_LIKE and branch, or state its supported distro on line 1 — and never infer a host's OS from its name or its age.