Tech & AI, Explained

operating-systems-intro

8 min read

Operating systems intro

Status: 🟩 COMPLETE Last updated: 2026-06-20 Plain-English tagline: The boss software on every computer. Manages memory, schedules programs, talks to hardware. The reason your apps don’t have to know what kind of disk you have.

In plain English

When you press the power button, the hardware comes alive but doesn’t know what to do with itself. The operating system (OS) is the program that takes over a few seconds in, sets up the system, and manages everything else.

Without an OS, every program would need to know how to talk to your specific keyboard, your specific display, your specific disk, your specific network card. Every program would need to handle running alongside other programs without stepping on their memory. Every program would have to do its own file management.

The OS does all of that, once. Apps ask the OS for what they need (“read this file,” “show this on the screen,” “give me 100 MB of memory”), and the OS handles the hardware specifics. Apps stay simple; hardware variety is contained.

The three operating systems you’ll encounter:

  • Windows — by far the most common consumer OS. Made by Microsoft. Runs everywhere from gaming PCs to office desktops to many laptops.
  • macOS — Apple’s OS for Macs. Built on a Unix foundation (under the hood it’s similar to Linux).
  • Linux — open-source, free, comes in many “flavors” (Ubuntu, Debian, Fedora, Arch, etc.). Runs ~95% of all internet servers, plus Android phones (Android is Linux underneath), plus most embedded devices.

You probably use Windows. Vercel runs Linux on its servers. macOS sits between them culturally — Unix-like enough for serious dev work, polished like Windows for daily use.

Why it matters

For building webapps, three things:

  1. Production runs Linux. Your code might work fine on Windows locally and break on Vercel because Linux has different conventions (case-sensitive filenames, different path separators, etc.). Knowing the differences saves debugging time.

  2. Tools assume Unix. Most dev tutorials use Bash, forward slashes, Unix utilities. On Windows you either install Git Bash, use WSL (Windows Subsystem for Linux), or use PowerShell with mental translation. None of this is hard once you know it’s a thing.

  3. The OS is what’s “between” your code and the hardware. When an app crashes, when memory fills up, when a network request fails — understanding which layer is responsible helps debug.

What an OS actually does

Five main jobs:

1. Boot the system

Wake up the hardware, initialize drivers, mount the disk, start the desktop or shell.

2. Manage memory

Decide which program gets which RAM, swap rarely-used memory to disk when full, isolate programs so one can’t read another’s memory.

3. Schedule processes

The CPU can only do one thing at a time per core. With dozens or hundreds of running programs, the OS rapidly switches between them, giving each a slice of CPU time. So fast it feels simultaneous.

4. Provide file systems

Files and folders aren’t a hardware concept — disks just store bytes. The OS imposes structure (NTFS on Windows, APFS on macOS, ext4 on Linux) so programs can deal with named files instead of raw byte ranges.

5. Talk to devices

Drivers translate “save this file” or “play this sound” into hardware-specific commands. The OS bundles drivers for common devices and lets manufacturers ship their own.

Bonus: Provide an API

Programs talk to the OS through system calls — things like read(), write(), open(), socket(). Languages like JavaScript abstract these further (fs.readFile), but underneath, it’s a system call.

The kernel

The kernel is the core of the OS — the part that runs with full hardware access. Memory management, scheduling, drivers, system calls — the kernel handles them.

Around the kernel are layers of user-space programs: window managers, desktop environments, shells, system utilities. The kernel is what you mean technically when you say “Linux” — Ubuntu and Debian use the same Linux kernel but different user-space layers.

Windows vs macOS vs Linux

A practical comparison for dev work:

AspectWindowsmacOSLinux
Default shellPowerShell, Cmdzsh (Bash older)Bash, zsh
Path separator\ (also /)//
Case sensitive filenamesNo (usually)No (by default)Yes
Line endingsCRLF (\r\n)LF (\n)LF (\n)
Package managerwinget, scoop, chocobrewapt, dnf, pacman, etc.
Dev environmentNative, WSL, Git BashNative (Unix-like)Native
Servers in productionRareRareDominant
GUI consistencyHighHighVariable (depends on distro)
CostPaid (mostly)Mac hardwareFree

For Claude Code on Windows (your setup), tools mostly Just Work, but you’ll see PowerShell-specific syntax occasionally and Linux paths in some examples.

A concrete example: what happens when you open VS Code

  1. You click the VS Code icon (a graphical event the OS captures)
  2. The OS looks up where VS Code’s .exe is on disk
  3. Loads the executable into RAM
  4. Allocates a new process for it; gives it a chunk of memory
  5. Starts executing the code at the program’s entry point
  6. VS Code’s code asks the OS for: a window, a font, the file ~/.vscode/settings.json
  7. OS opens the window via the display driver, returns a window handle
  8. OS reads the settings file via the file system driver, returns the bytes
  9. VS Code populates the window, registers event handlers (“tell me when keys are pressed”)
  10. You start working — every keystroke, click, scroll is the OS notifying VS Code

This loop, repeated thousands of times per second, is what “running an app” means.

Why Linux dominates servers

Three reasons:

  1. Free. You can deploy 10,000 Linux servers without paying for OS licenses.
  2. Lean. A server doesn’t need a desktop UI; Linux can run with just a kernel and the few programs you need.
  3. Designed for it. Linux’s heritage is Unix, which was built for multi-user shared servers. The features for that (users, permissions, processes, networking) are first-class.

Windows has Windows Server for these uses, but the vast majority of new server deployments are Linux. Every major cloud (AWS, GCP, Azure, Vercel, Cloudflare) runs Linux at the foundation.

Why your code might behave differently locally vs in production

You build a Next.js app on Windows. It runs fine. You push to Vercel. The build fails.

Common culprits:

  • Case sensitivity. import Button from './button' — works on Windows, breaks on Linux if the file is Button.tsx.
  • Path separators. './folder\\file.txt' works on Windows but fails on Linux. (Modern Node tools usually handle this transparently — but some scripts don’t.)
  • Line endings. Tools that care about line endings (some shell scripts, certain text processors) misbehave when CRLF files arrive on Linux.
  • Missing tools. A script that calls bash, curl, or other Unix utilities works on Linux but fails on Windows. The reverse holds for Windows-specific tools.
  • Permissions. Linux file permissions matter; Windows is more lax. Scripts may need chmod +x on Linux.

Best mitigation: develop with the production environment in mind. WSL (Windows Subsystem for Linux) lets you run Linux on Windows for development — a popular choice for Windows devs targeting Linux servers.

Common gotchas

  • macOS is Unix; Windows is not. macOS shares heritage and many tools with Linux. Code that works on macOS often works on Linux. Windows is its own world — Git Bash or WSL bridges most of the gap.

  • WSL is a great escape hatch for Windows users. “Windows Subsystem for Linux” runs a full Linux environment inside Windows. Many serious developers on Windows run their dev stack inside WSL to match the production environment exactly.

  • The OS isn’t an app. You don’t quit the OS like you quit Chrome. It’s the layer everything else runs on; shutting it down is shutting down the computer.

  • “OS update” can include security-critical changes. Keeping the OS current isn’t optional — patches close vulnerabilities. Auto-update on home machines is sensible.

  • Different distros, same Linux kernel. Ubuntu, Debian, Fedora, Arch all share the Linux kernel. They differ in package managers, default tools, philosophies. For server use, Ubuntu LTS or Debian is the safe default.

  • macOS hides Unix-y stuff by default. The Finder shows you “Documents” but the underlying path is /Users/yourname/Documents. Terminal shows the Unix view; both refer to the same files.

  • The / root on Linux/macOS is everything. Unlike Windows where there’s C:\, D:\, etc., Linux uses one tree from / down. External drives are “mounted” into paths in that tree.

  • Permissions trip people up. Linux/macOS have user/group/other read/write/execute permissions on every file. “Permission denied” on a file you own usually means the execute bit isn’t set: chmod +x file.

  • The OS schedules; it doesn’t multitask in parallel by default. A single CPU core does one thing at a time. The illusion of parallel work comes from rapid switching. True parallelism requires multiple cores.

  • Process vs thread. A process is an instance of a running program with its own memory. A thread is a unit of execution within a process. Multiple threads of one process share memory; multiple processes do not.

See also

Sources

Graph View

Backlinks