Tech & AI, Explained

operating-systems-overview

12 min read

Operating systems — overview

Status: 🟩 COMPLETE Last updated: 2026-06-19 Plain-English tagline: An OS is the program that runs ALL your other programs — handles memory, CPU scheduling, files, networking, and security. Linux dominates servers; Windows dominates desktops; macOS punches above its weight among developers; iOS + Android dominate mobile.

In plain English

When you press the power button on a computer, BIOS / UEFI fires up the hardware, then loads the operating system (OS). The OS then loads everything else.

The OS is the program that:

  • Decides which program runs at which moment (CPU scheduling)
  • Manages how much RAM each program gets (memory management)
  • Reads and writes files on disk
  • Talks to network hardware (sends/receives packets)
  • Controls input devices (keyboard, mouse, touchscreen)
  • Handles security (user permissions, process isolation)
  • Provides a way for programs to ask for any of the above (system calls)

WITHOUT an OS, your applications would each need to handle these directly. WITH one, applications just call the OS and let it sort things out.

Modern operating systems are enormous — millions of lines of code. The dominant ones in 2026:

OSWhere it dominatesNotes
LinuxServers, cloud, embedded, Android baseOpen-source, free, many distros (Ubuntu, Debian, Fedora, Arch)
WindowsDesktops, gaming, enterpriseMicrosoft; biggest consumer share by far
macOSMac desktops + laptopsApple; popular with developers, designers
iOSiPhones, iPadsApple; mostly cousin of macOS
AndroidMost non-Apple phonesGoogle; built on Linux kernel
ChromeOSChromebooksGoogle; also Linux-based

For Bible Quest-style work: George uses Windows (with WSL for some Linux interop). Vercel deploys to Linux containers. Supabase runs on Linux. macOS is what most JS tutorials assume.

Understanding what an OS does (and roughly how) demystifies:

  • Why your laptop slows down when you have 50 tabs open
  • What “process” means
  • Why Linux and Mac development feels different from Windows
  • Why some apps only work on certain OSes

This entry is a CONCEPT-level overview, not a deep dive. For Windows-specific dev tips, see Windows dev environment.

Why it matters

Three concrete reasons:

  1. Tutorials assume an OS. Most assume macOS/Linux. Knowing what’s different on Windows (paths, line endings, shells) saves frustration.

  2. Servers run Linux. Your code WILL run on Linux when deployed. Local dev environment differences are a real source of “works locally, fails in production” bugs.

  3. OS-level concepts EXPLAIN higher-level ones. Containers share the host OS kernel. Browsers are user-space processes. Files have OS-level permissions. Each is opaque without the underlying model.

The trade-off: full OS knowledge is a whole CS subfield. This entry is enough to recognize concepts and look up details when they matter.

What an OS actually does

Six core responsibilities:

1. Process management

A process is a running program. The OS decides:

  • Which process gets CPU time, when, for how long
  • How to handle process creation (fork/exec on Unix; CreateProcess on Windows)
  • How processes communicate (pipes, shared memory, sockets)
  • How processes are isolated from each other (different memory spaces)

When you “run a program,” the OS creates a process. The kernel scheduler switches between processes thousands of times per second, giving the illusion of simultaneity even on a single-core CPU.

2. Memory management

The OS gives each process a “virtual address space” — the process thinks it has the whole RAM to itself. The OS maps virtual addresses to physical RAM (and to disk swap if RAM is exhausted).

This abstraction:

  • Prevents one process from reading/corrupting another’s memory
  • Lets the OS over-commit (programs can ask for more memory than physically exists)
  • Enables swapping (move idle pages to disk)

See Memory: stack vs heap for the within-process view.

3. File system

The OS organizes disk storage into files and directories. Provides operations like open, read, write, delete, list. Handles permissions (who can read what), metadata (timestamps, owner), and the on-disk representation (ext4, NTFS, APFS).

4. Networking

Sending and receiving packets across networks. TCP/IP, DNS, sockets — all in the OS’s networking stack. Applications open sockets (via system calls); the OS handles the wire protocol.

5. Device drivers

Each piece of hardware (keyboard, USB, GPU, network card) needs code to communicate with it. The OS provides this — usually loaded dynamically as kernel modules.

6. User + permission management

Multiple users on one machine; each with files, processes, permissions. The OS enforces “user A can’t read user B’s files” (unless explicitly permitted).

These six are the kernel’s job. Around them, the OS includes a user-space (shell, system utilities, GUI) layered on top.

The Linux dominance on servers

If you’ve never touched Linux directly, here’s the picture: Linux runs the internet. Estimates suggest 90%+ of public web servers, 100% of the top supercomputers, the major clouds, Android phones — all Linux underneath.

Why Linux won the server:

  • Free — no per-machine licensing fees
  • Open source — companies can modify, redistribute, support themselves
  • Stable — robust, long-running uptimes
  • Server-optimized — minimal GUI; everything scriptable
  • Massive ecosystem — every tool, library, language is well-supported

For Bible Quest: Vercel functions run in Linux containers. The Postgres in Supabase runs on Linux. When you “deploy to the cloud,” you deploy to Linux.

The relevant Linux distros (different “flavors”) for development:

  • Ubuntu / Debian — the most-common server distros; “apt” package manager
  • Fedora / RHEL / CentOS — Red Hat’s family; “dnf”/“yum”
  • Alpine — extremely minimal; used in containers (~5MB)
  • Arch — rolling release; for tinkerers
  • NixOS — declarative configuration; reproducible

You usually don’t pick. Cloud images come with Ubuntu or Alpine by default; Vercel uses its own internal Linux; Docker base images are tagged with their distro.

Kernel vs user space

The OS has two zones:

  • Kernel space — the core OS code with full hardware access. Process scheduling, memory, drivers.
  • User space — applications running with restricted access. Browsers, editors, your node server.js.

When an application needs to do something privileged (open a file, send a packet, allocate memory), it makes a system call — a controlled jump from user space to kernel space, execute, jump back.

This separation is what prevents one buggy app from crashing the whole machine. A user-space crash terminates the app; a kernel crash crashes everything (the “blue screen” on Windows, “kernel panic” on Linux/macOS).

A concrete example: what happens when you run node server.js

The chain of OS interactions:

  1. You type node server.js in a terminal.
  2. Terminal calls fork() + exec() — system calls to create a new process running node.
  3. OS creates a process. Allocates memory, assigns a process ID (PID), sets up the address space.
  4. Node starts executing. Reads server.js (file system call), parses it, starts running.
  5. Code calls http.listen(3000). Node makes a socket() + bind() + listen() system call.
  6. OS opens TCP port 3000. Reserves it for this process.
  7. Browser connects. OS receives the TCP SYN, hands it to Node.
  8. Node handles the request. Reads files, calls databases, etc.
  9. Node writes response. OS sends the bytes back over TCP.
  10. Process keeps running until you Ctrl+C → SIGINT signal → Node cleanly shuts down.

Every one of those steps involves the OS. As a developer, you just write http.listen(3000). The kernel handles the rest.

Differences between Windows, macOS, Linux

The headline differences a developer experiences:

AspectLinuxmacOSWindows
KernelLinuxMach + BSDNT
ShellBash / ZshZsh (default since 2019)PowerShell
Path separator//\ (though / often works)
Line endings\n (LF)\n (LF)\r\n (CRLF)
Case-sensitive filesystemYesNo (default; HFS+/APFS)No (NTFS)
Permission modelPOSIX (user/group/other)POSIXNTFS ACLs
Package managerapt / dnf / pacmanbrewwinget / choco
Default text editorvim, nanovim, nanonotepad (terrible)
GUI under the hoodX11 / WaylandAquaWin32

The case-sensitivity issue is the #1 cross-OS developer pain. Button.tsx and button.tsx are the SAME on Mac/Windows, DIFFERENT on Linux. Vercel deploys to Linux — case mismatches in imports work locally and break in production.

See Windows dev environment for the full Windows-specific story.

POSIX — the Unix-family standard

POSIX (Portable Operating System Interface) is a standard that defines a common API across Unix-like operating systems. Linux, macOS, BSD all implement POSIX.

That’s why a shell script written for Mac usually works on Linux: both implement the same POSIX commands (ls, grep, find, awk, sed).

Windows is NOT POSIX-compliant natively. WSL (Windows Subsystem for Linux) provides a POSIX environment INSIDE Windows.

Common gotchas

  • “It works on my Mac” → fails on Linux. Usually: case sensitivity (filenames), case-sensitive imports, hard-coded /Users/... paths.

  • “It works on my Windows” → fails on Linux. Line endings (CRLF vs LF), backslash paths, missing POSIX tools, case sensitivity.

  • Linux is case-sensitive; Mac/Windows aren’t (by default). Always match file case in imports. Use ESLint rules to enforce.

  • Path separators differ. Use path.join() in Node, NOT string concatenation. Forward slashes work in MOST Windows contexts but not all.

  • Line endings break shell scripts. A .sh file with CRLF endings fails on Linux with “bad interpreter.” Use .gitattributes + core.autocrlf to normalize.

  • chmod +x script.sh is meaningless on Windows. Permissions don’t translate. WSL provides this; native Windows doesn’t.

  • The default shell varies. Bash on most Linux. Zsh on macOS (since Catalina). PowerShell on Windows. Different syntax, different built-ins.

  • macOS’s BSD utils differ from Linux’s GNU utils. sed -i syntax differs. grep flags differ. Scripts that work on Linux can fail on Mac.

  • Process IDs (PIDs) are not globally unique. They’re per-OS, recycled after process death. Don’t use PIDs as long-term identifiers.

  • The shell’s $PATH is critical. Determines which executable runs when you type a command. PATH issues cause “command not found” — see Windows dev environment.

  • sudo is for one-off privileged commands. Logging in as root is heavy-handed and risky. Use sudo command instead.

  • rm -rf / is real, and deletes everything on a Linux system. (Modern bash refuses to do it by default, but the warning is real.) Never run privileged delete commands without certainty.

  • Symlinks behave differently per OS. Linux/Mac: native, transparent. Windows: works with Developer Mode on; awkward otherwise.

  • The Linux kernel is not “Linux.” Linux (the kernel) + GNU utilities + a distribution’s installer + a desktop environment = a Linux DISTRO. RMS-era pedantry calls Linux “GNU/Linux”; mostly ignored in practice.

  • macOS shares ancestry with BSD Unix, not Linux. They diverged decades ago. Most concepts transfer; specific commands sometimes don’t.

  • Process scheduling is preemptive on modern OSes. The OS can interrupt any process at any moment to run another. This is why your music keeps playing while you compile.

  • Memory paging means RAM “usage” is fuzzy. Linux uses spare RAM as disk cache; appears “high usage” but is freed instantly when an app needs it. Don’t panic about RAM utilization on Linux.

  • Containers share the host kernel. A Linux container on Linux runs natively. A Linux container on Mac/Windows runs in a small VM (Docker Desktop’s vm).

  • The “Unix philosophy” is small composable tools. ls, grep, wc, sort — each does ONE thing. Piped together they solve complex problems. Modern devs lean on this constantly.

  • Windows has WSL2 — a full Linux kernel runs INSIDE Windows. It’s not a VM; it’s tightly integrated. Allows true Linux dev environment on Windows hardware.

  • macOS’s Terminal shares many Linux behaviors but is BSD underneath. Most things work the same; details occasionally surprise.

  • ChromeOS is Linux with Chrome as the only GUI. Modern versions allow native Linux apps via Crostini.

  • Mobile OSes are heavily customized. iOS is Darwin-based (related to macOS). Android is Linux-kernel + Google’s userspace. Both restrict what apps can do compared to desktop OSes.

  • Servers usually have NO GUI. A Linux server is text-only by default. SSH in, run commands, get out.

  • OS-level monitoring tools exist for diagnosing. top, htop, iotop, netstat, ss, lsof, strace (Linux). Activity Monitor (macOS). Task Manager (Windows). When something’s wrong, these tell you what.

  • Linux distros are mostly the same OS with different defaults. Ubuntu vs Debian vs Fedora differ in package manager + default desktop. Underneath: same kernel.

  • The kernel updates without reboot on some systems (kpatch). Production servers can patch security holes without restarting.

  • Process limits matter. A Linux process can’t open more than ~1024 file descriptors by default. Web servers handling many connections need to raise this (ulimit -n).

  • Different filesystems have different limits. Some can hold 16 EB of data; some max at 4 GB per file. NTFS, ext4, APFS, ZFS, btrfs — each has trade-offs. Rarely a concern for webapp work.

  • The Linux desktop “war” was lost; the Linux server war was won decisively. Linux on desktop is fine but niche; Linux on servers is dominant.

  • AI agents like Claude Code run wherever you do. On Windows, in PowerShell. On Mac, in Zsh. Issues like path separators come up; the agent usually handles them, but knowing the underlying difference helps.

  • A “headless” install means no GUI. Common for servers, cloud VMs, embedded devices.

  • OS updates can break code. A new macOS release deprecates an OpenSSL version; a Linux distro upgrade changes Python’s default; Windows 11 changes PowerShell behavior. Pin OS versions for production-critical work.

When you need to know more

For typical webapp work, “I know what an OS does in broad strokes” is enough. Dive deeper when:

  • You’re hosting on raw cloud VMs (need Linux admin skills)
  • You’re debugging weird production issues (process limits, file descriptors)
  • You’re optimizing performance at the edge of OS limits
  • You’re working with system tools (Docker, Kubernetes, security audits)

Good entry points:

See also

Sources

Graph View

Backlinks