Linux Explained — Architecture, Commands, and Major Distributions

The first thing to unpack is the layered nature of the word "Linux".

So "I installed Ubuntu" really means "I installed a distribution that combines the Linux kernel + the GNU toolchain + Debian-style packaging + Canonical-specific Snap / Netplan / configuration", all bundled together.

The core of Linux's design (and UNIX-family designs in general) is that kernel space and user space are physically separated by CPU privilege levels. User processes never touch hardware directly — they go through the defined entry point, the system call, to ask the kernel to do things on their behalf.

What to remember:

• The kernel is never part of any app. An application can only reach the kernel through one of about 400 syscalls — read(), write(), open(), fork(), socket(), and so on. The reason strace works at all is precisely because this boundary is explicit
• The GNU userland is a separate project from the Linux kernel. ls and cat come from GNU coreutils, developed independently from the kernel. Alpine Linux replaces these with musl + BusyBox for compactness — the same kernel can feel like a completely different OS depending on what's on top
• systemd is the modern glue between kernel and userland — a userspace PID 1 daemon that unifies process management, cgroups, logging, networking, DNS, and boot ordering
• Dynamic driver loading — kernel modules shown by lsmod are loaded on demand via modprobe. New hardware can be plugged in without rebooting

"Everything is a file" is the most influential design call in UNIX philosophy. Because regular files, directories, devices, pipes, sockets, and symlinks all use the same read() / write() / open() / close() API, programs can be composed without caring what's on the other end.

grep foo /var/log/syslog, grep foo < /dev/ttyS0 (a serial port), and cat hello | grep foo are all literally the same read() call — that's the heart of UNIX's simplicity and power.

Special filesystems — /dev /proc /sys #

• /dev — The doorway to hardware and virtual devices. echo "hello" > /dev/tty1 writes to the first virtual console; dd if=/dev/zero of=test.bin bs=1M count=100 creates a 100 MB zero-filled file — both are just normal file writes via the same syscalls
• /proc — A virtual FS the kernel generates on the fly. /proc/PID/maps shows a process's memory mappings; /proc/PID/fd/ shows its open file descriptors. None of this lives on disk — the kernel generates the text the moment you cat it
• /sys — Exposes the kernel's internal object hierarchy (devices, buses, classes) as a directory tree. Operations like changing a NIC's MAC with echo 02:11:22:33:44:55 > /sys/class/net/eth0/address are possible

Linux's process model inherits UNIX's distinctive design — "fork() to clone → exec() to replace yourself with another program".

This is the root of "every process descends from PID 1 in a single family tree". pstree lets you trace your way back from vim ← bash ← sshd ← systemd (PID 1). When a parent dies before its child, the child becomes an orphan and is adopted by PID 1 (systemd) — the classic "init reaping" rule, still in force.

Signals are asynchronous notifications between processes. SIGINT from Ctrl+C, the default SIGTERM from kill PID, the un-catchable SIGKILL from kill -9 PID (force termination), SIGSEGV for memory errors — 31 signals are defined.

A zombie (Z state) = a child that has exited but whose parent hasn't called wait() yet. Resources are released, but the PID and process-table entry are left. A zombie outbreak is a parent bug — exhausting PID space prevents new processes from being created.

The UNIX permission model starts simple — UID + GID + 9 rwx bits per file. The nine characters in ls -l's -rwxr-xr-x line up as "owner rwx / group rwx / other rwx". UID 0 = root is the all-powerful super-user; the modern norm is to operate as a non-root user and reach for sudo only when needed.

But "rwx alone isn't fine-grained enough" came up repeatedly, and the model has been extended in stages.

The productivity of Linux/UNIX boils down to chaining small single-purpose programs with | to do whatever you want. What makes this work is "everything is a file" + standard streams (stdin / stdout / stderr) + the pipe (|).

ls | grep '\.log$' | wc -l spawns three independent processes at once and wires each stdout into the next stdin to compute "how many .log files in the current directory" in one line. The kernel mediates via a pipe (FIFO buffer) — the processes share no memory.

Environment variables (PATH, HOME, LANG, LD_LIBRARY_PATH, etc.) propagate from parent to child processes by copying. export FOO=bar makes them visible to subsequently spawned children.

"Install Linux" really means "pick a distribution". The kernel is the same, but package manager, release cadence, default daemons, and community culture all differ.

When Docker and Kubernetes took over the late 2010s, what really happened inside Linux? The answer is "we just started combining two features that had been in the kernel all along".

• namespaces (PID / network / mount / UTS / IPC / user) — Show each process a different world
  • PID namespace — Inside the container, ps only shows the container's own processes
  • network namespace — Independent eth0 / routing table
  • mount namespace — A different / filesystem from the host's
  • user namespace — A container's root is non-root from the host's view (rootless containers)
• cgroups (control groups) — Limit and measure CPU / memory / I/O / pid count per process group

Combine these with overlayfs (layered FS) and you get "an independent miniature OS, per process, on top of the host OS" — a container. Docker initially used lxc to wire them together, then wrote its own runc, and today everything is standardised via OCI runtimes.

Kubernetes layers a cluster-level control plane on top — automatically scheduling, healing, and scaling containers. Two layers: Linux kernel runs the containers, Kubernetes manages them.

What started as "a kernel Linus Torvalds wrote as a hobby in 1991" has become the name for the OS ecosystem that supports more than half of the world's computing. Understanding it comes down to grasping the three-layer structure — "kernel = Linux proper", "userland = GNU + distros", "the two are physically split by syscalls" — and seeing how UNIX-inherited design choices — "everything is a file", "fork/exec", "pipe + exit code", "rwx → capabilities → namespaces" — are still alive in modern systems.

Whatever you dig into — cloud, containers, smartphones, serverless — you end up landing on Linux's syscalls and namespaces and cgroups. Understanding Linux once well lets you approach almost all of modern infrastructure with the same vocabulary.