Lecture 1
01 / 00

Page ↑ / Page ↓ to move · scroll works too

Linux & DevOps — Lecture 1 of 8

Mental Model

Before opening a terminal,
where did Linux come from?
and how will the pieces we use fit together?

All slides available at
slides.raafat.io

What we’re building toward

git push Todo app repo
→
Webhook GitHub Actions
→
VM listener Python / Bash
→
Pull latest git
→
Build image Podman
Metrics & alerts Grafana
←
Drain old slot graceful stop
←
Switch traffic nginx / Caddy
←
Health check before switch
←
Deploy idle slot blue/green
01

Where Linux Came From

  • One codebase, many descendants
  • Unix to Linux, 1969–1991
  • Where it all ended up

Some History

Unix (1969)

BSD

1977, UC Berkeley
  • FreeBSD
  • macOS (Darwin)

System V

1983, AT&T
  • Solaris, AIX
  • HP-UX, IRIX

Minix

1987, teaching OS
  • inspired Linux (1991)

Linux and GNU are Unix-compatible reimplementations, built from scratch rather than from Unix’s original source — commonly drawn on the same tree, technically a parallel branch. The timeline, next.

More History

1969

Unix

  • Thompson & Ritchie, Bell Labs
  • Built small, on a spare PDP-7
  • Name jokes at Multics's expense
1972*

Rewritten in C

  • Ritchie's new language
  • Suddenly portable to any hardware
1983

GNU

  • Stallman, MIT — free software
  • Full toolset, no kernel yet
1991

Linux

  • Torvalds, Helsinki — a hobby kernel
  • Working name: "Freax"
  • + GNU tools = GNU/Linux

*C itself was created in 1972; Unix’s full rewrite into C wrapped up the following year, 1973.

Linux everywhere

Supercomputers

the world's top 500 fastest supercomputers all run Linux since 2017.

Android

all Android phones, tablets, smart TVs… are built on Linux.

The cloud

most cloud infrastructure runs on Linux

IoT devices

smart fridges, security cameras, military drones, and more run Linux.

02

Kernel, Userland & Init

  • What the kernel actually does
  • Userland: the "GNU" in GNU/Linux
  • How a server actually boots
  • From SysV init to systemd

Four layers, one machine

Applications the Todo app, your scripts
Userland shell, coreutils, libraries
system calls
Kernel process, memory, drivers
Hardware CPU, RAM, disk, network

What the kernel is actually for

The kernel manages the machine’s shared resources on behalf of every running program — who gets what, and when:

CPU Memory Disk Network

Every request a program makes for any of this goes through a single narrow interface — a system call.

Userland is where you actually live

The shell you type into, the core utilities you run constantly, and the system libraries programs link against all run in less-privileged user space, not inside the kernel:

bash ls cp grep glibc

This is, largely, the “GNU” half of GNU/Linux from Part One.

How a server actually boots

Before “PID 1” means anything, the machine has to get there — four stages, every single time the power comes on:

Power on Firmware / UEFI, POST
→
Bootloader GRUB2 loads the kernel
→
Kernel loads inits hardware
→
PID 1 hands off to init

PID 1 and serial booting

Service A starts
→
Service B waits its turn
→
Service C waits its turn

More than an init system

In 2010, Red Hat engineers released systemd as PID 1’s replacement and more

Service management

Starts, stops, and supervises services from declarative unit files — and restarts whatever crashes.

Parallel boot

Starts services concurrently based on a dependency graph, not a fixed sequence — this is where the speed comes from.

Centralized logging

journald collects every service's output into one structured, queryable store, read back with journalctl.

Resource control

Uses cgroups to cap CPU, memory, and I/O per service, so one runaway process can't starve the rest.

On-demand activation

Socket and timer units start a service only when something actually needs it, instead of leaving it always running.

Targets

Named states — multi-user, graphical, rescue — the flexible replacement for numbered runlevels.

Adopted by Fedora in 2011, then RHEL 7 in 2014.

03

Distributions & Why RHEL

The kernel is shared. Almost everything wrapped around it is a choice

  • What a "distribution" actually bundles
  • The RPM family vs. the Debian family
  • rpm vs. dnf
  • Why production pays for RHEL

What a “distribution” actually is

A Linux distribution (“distro”) is just this, bundled into one coherent, installable system:

Kernel
+
Userland tools, libraries
+
Package manager
+
Installer
+
Defaults conventions
→
A distribution

The kernel is nearly identical across distributions. Almost everything else is a set of choices someone else made for you.

One kernel, three family trees

Almost every distro you’ll run into traces back to one of three originals:

Debian
1993 — apt / dpkg
  • Ubuntu
  • Linux Mint
  • Kali Linux
  • Raspberry Pi OS
Red Hat Linux
1994, split 2003 — dnf / rpm
  • Fedora
  • RHEL
  • Rocky Linux
  • AlmaLinux
  • Bazzite
Arch Linux
2002 — pacman
  • Manjaro
  • CachyOS
  • SteamOS

Red Hat Linux split in 2003 into Fedora (community, fast-moving) and RHEL (enterprise) — Rocky Linux and AlmaLinux exist as free RHEL-compatible rebuilds, and Bazzite is a gaming-focused spin of Fedora’s immutable desktop. This course runs on RHEL, the middle tree.

rpm

  • The low-level package format and tool
  • Installs, queries, and verifies individual .rpm files
  • Doesn't resolve dependencies for you

dnf

  • The high-level tool you'll actually type
  • Resolves dependencies, talks to repositories
  • Successor to yum

What enterprises are actually paying for

  • A long, predictable lifecycle — roughly a decade of support per major version, so nothing breaks under you mid-project.
  • Backported security fixes instead of forced upgrades — you get the patch without the surprise new version.
  • Certification — hardware vendors and software vendors test and support their products specifically against RHEL.
  • A support contract — an SLA and a phone number to call when production is actually down.
04

Virtualization, Containers & Bare Metal

Two different bets on isolation — and this course stacks both of them, one inside the other.

  • Bare metal, and why it's rarely the answer here
  • Hypervisors, and where Proxmox fits
  • VMs vs. containers, layer by layer

Bare metal: no layer in between

An OS installed directly on physical hardware, with nothing abstracting the machine underneath it. Maximum performance, zero flexibility — one operating system per box, full stop.

Fine for a single dedicated server.

A physical server rack in a data center
A physical server rack — hardware with an OS on it, nothing virtual about it.
Photo: Carl Lender, CC BY 2.0

Virtualization

A hypervisor lets one physical machine host several independent guest machines, each behaving as though it owns real hardware outright:

1 physical host

VM 1

guest OS
  • own kernel
  • own userland

VM 2

guest OS
  • own kernel
  • own userland

VM 3

guest OS
  • own kernel
  • own userland

Virtual CPU, RAM, disk, and network hardware — real to the guest, carved out of the one host underneath.

Proxmox QEMU

Type 1 — bare-metal

Runs directly on hardware, no host OS underneath it. Proxmox VE — built on KVM, the Linux kernel’s own virtualization module, plus QEMU — is Type 1. This is what runs on the rented VPS behind this course.

VirtualBox

Type 2 — hosted

Runs as an ordinary application on top of a general-purpose host OS — VirtualBox on your laptop, for instance. Simpler to install, with more overhead.

Containers don’t virtualize hardware

Instead of simulating a whole machine, containers isolate processes that all share one real, already-running host kernel. There’s no guest OS to boot — a container starts about as fast as any other process on the machine, because it essentially is one.

Virtual machine

  • Own kernel, own full OS
  • Strong isolation boundary
  • Boots in tens of seconds
  • Images measured in gigabytes

Container

  • Shares the host kernel
  • Weaker isolation boundary than a VM
  • Starts in a fraction of a second
  • Images measured in megabytes

Two ways to slice one machine

Same hardware underneath — a different number of layers between it and your app:

Virtual machine

App
Guest OS own kernel
Hypervisor
Host hardware

Container

App
Container runtime Podman
Host OS shared kernel
Host hardware

One fewer layer, and no guest kernel to boot — Podman is the container engine this course uses: daemonless, rootless by default, and — unlike Docker’s original architecture — with no single long-running root process managing every container.

05

The DevOps Lifecycle

A loop, not a line — and a name for every stage this course maps a tool onto.

  • What "DevOps" is actually pointing at
  • The eight-stage loop

Development and operations, one job

DevOps is a set of practices and a culture aimed at closing the gap between building software and running it in production.

A loop, not a line

It’s a loop because what you learn from operating and monitoring a system feeds straight back into planning the next change. There’s no finish line — only another lap:

Plan
→
Code
→
Build
→
Test
Monitor ↻ back to Plan
←
Operate
←
Deploy
←
Release
06

The Capstone Target

  • Two identical slots, one live
  • The zero-downtime switch

Two identical slots, one live

Blue/green deployment keeps two identical environments — call them slots — and only ever touches one of them:
Blue live — real traffic
Green idle — new version lands here

A new version deploys only to the idle slot — the live one is never touched until the new version has proven itself.

The switch

New version image built
→
Deploy to idle slot green
→
Health check idle slot only
→
Switch proxy nginx / Caddy upstream
→
Drain old slot graceful stop

If the health check fails, the switch simply never happens — the old slot just keeps serving traffic, completely unaffected.

07

Lab & Logistics

  • Where to find these slides again

Fin

All slides available at
slides.raafat.io