Linux Fundamentals

Strictly speaking, "Linux" is a kernel — the core program that manages a computer's CPU, memory, and hardware devices, and mediates every request a program makes to use them. It was started by Linus Torvalds in 1991 as a personal project to build a free, Unix-like kernel for his own PC, and released it publicly so others could use and improve it. The kernel by itself is not something you install and use directly; it has no file manager, no package installer, no login screen.

What most people call "Linux" — Ubuntu, Fedora, Debian, and so on — is technically a Linux distribution: the kernel bundled with the GNU userland tools (the shell, core utilities like `ls` and `grep`, compilers), a package manager, and usually a desktop environment or server tooling on top. This is why some people insist on saying "GNU/Linux": the kernel provides the low-level engine, but the GNU Project's tools (started years before Linux existed, aiming to build a free Unix-like operating system) provide most of what you actually type at a command line every day.

The practical reason this distinction matters: when someone says "which Linux are you running", they almost always mean the distribution (Ubuntu 24.04, Rocky Linux 9, etc.), not the kernel version — but when you're debugging something at the level of device drivers, filesystems, or system calls, you're dealing with kernel behavior that can be identical across very different-looking distributions running the same kernel version.

A distribution ("distro") takes the Linux kernel and GNU tools and adds a package manager, default configuration, release cycle, and often a specific philosophy. Distributions cluster into families based on shared packaging systems and ancestry, and knowing the family tells you far more about how a system behaves than its name alone. The two families you will meet constantly in system administration are the Debian family and the Red Hat family.

The Debian family uses the `.deb` package format and the `apt`/`dpkg` tooling. Debian itself is the upstream project; Ubuntu is built on top of Debian with its own release cadence, defaults, and commercial backing from Canonical; Ubuntu Server is the variant used heavily in cloud and DevOps environments. The Red Hat family uses the `.rpm` package format and `dnf`/`rpm` tooling. Red Hat Enterprise Linux (RHEL) is the commercial, support-backed product; Rocky Linux and AlmaLinux are community rebuilds that aim for bug-for-bug compatibility with RHEL (both emerged after CentOS changed its model in 2020, ending CentOS as a free RHEL rebuild); Fedora is Red Hat's faster-moving upstream distribution where newer features land before eventually reaching RHEL. Amazon Linux is AWS's own RHEL-family-adjacent distribution, optimized for and defaulted to on EC2.

Outside those two families: Arch Linux uses `pacman` and a rolling-release model (no fixed version numbers — the system continuously updates), popular for its minimalism and the depth of the Arch Wiki. Kali Linux is a Debian-based distribution purpose-built for penetration testing and security research, pre-loaded with security tooling — it is not intended as a general-purpose server or desktop OS. This course teaches Ubuntu Server (Debian family) as the default hands-on environment and calls out RHEL-family differences explicitly wherever a command or concept diverges, rather than pretending the two families are interchangeable.

The Linux kernel is licensed under the GNU General Public License version 2 (GPL v2), one of the foundational open-source licenses. In practice, this means the kernel's source code is freely available, anyone can study, modify, and redistribute it, and — the key "copyleft" clause — anyone who distributes a modified version must also make that modified source code available under the same license. This is different from a permissive license (like MIT or Apache 2.0), which allows closed-source modification and redistribution.

Most GNU userland tools are also GPL-licensed, which is why the free-software movement historically insisted on the "GNU/Linux" naming — the license and philosophy of the GNU tools are a deliberate, foundational part of the system, not an afterthought bolted onto the kernel.

For a system administrator, the practical relevance isn't writing license text — it's understanding that "free" here means freedom (to inspect, modify, and redistribute), not merely "free of charge", and that this is exactly why the same kernel underlies wildly different commercial and community products: RHEL is a paid, support-backed product built on the same freely-licensed kernel that Debian ships at no cost.

Every Linux system is split into two protection domains: user space and kernel space. User space is where your applications, the shell, and almost everything you interact with directly runs — it has restricted, mediated access to hardware. Kernel space is where the kernel itself runs, with full, direct access to memory and hardware. This separation exists for stability and security: a crashing application in user space cannot normally bring down the whole system, because it never had direct hardware access to break in the first place.

When a user-space program needs something only the kernel can provide — reading a file, opening a network socket, allocating memory, creating a process — it makes a system call (syscall), a strictly defined request that crosses from user space into kernel space, gets serviced by the kernel, and returns a result. Every single file read, every network packet sent, and every process you start ultimately happens through a system call, whether or not the program you're running makes that visible to you.

The shell (commonly `bash` on Linux) is a user-space program like any other — it is not part of the kernel. It reads the command you type, parses it, and either runs a built-in behavior itself or launches an external program, which in turn makes system calls to actually do its work. This is the full chain: you type a command into a terminal (the program that displays the shell and handles keyboard/screen I/O) → the shell parses and executes it → the resulting program makes system calls → the kernel services those calls → the kernel talks to the hardware. Understanding this chain is what lets you reason about *where* a problem actually lives — a "command not found" error is a shell-level problem, while a "permission denied" reading a file is a kernel-enforced permission check surfaced back up through a syscall's return value.

You cannot learn system administration by reading about it — every lesson from here on assumes you have a real, disposable Linux system you can break, fix, and reset without consequence. You have three realistic options, and this course is written against the first one.

A local virtual machine (VirtualBox, VMware Workstation/Fusion, or Hyper-V on Windows) running Ubuntu Server is the most controllable option: fully isolated from your host machine, snapshot-able so you can revert a lab that went badly, and free. A cloud VM (a small instance on any major provider) is closer to real production administration — you'll manage it entirely over SSH from day one, which is realistic, but it costs money while running and isn't as easy to snapshot/reset for free. WSL (Windows Subsystem for Linux) is the fastest to start with zero setup, but it deliberately blurs some boundaries with the Windows host (shared filesystem access, a different init/service model in WSL1 and partial systemd support in WSL2) that make certain lessons in this course — full systemd administration, boot process work, LVM — behave differently or not work as described. Use WSL for quick command-line practice; use a real VM for anything involving services, storage, or boot behavior.

Before installing, the boot chain matters conceptually even if you never touch it directly during a normal install: your computer's firmware (legacy BIOS or modern UEFI) runs first and hands control to a bootloader (GRUB, on almost all Linux systems), which loads the Linux kernel and an initial RAM filesystem (initramfs) into memory, and the kernel then hands control to `systemd` (PID 1 on virtually all modern distributions), which brings the rest of the system up through a sequence of boot targets and services. You'll revisit this exact chain in more depth in the Boot Process lesson later in the course — for now, just recognize the names.