Appearance
2.10 — Windows & macOS in Practice
Part 2 has taught the operating system largely through the Unix/Linux lens — because that's what servers, containers, and the cloud run on, and because its model is clean. But you spend your own working day on Windows or macOS, and they are not merely "Linux with a prettier face." They embody genuinely different design decisions — a different kernel lineage, a different philosophy of where configuration lives, a different kind of shell, a different way of building the user interface. This closing chapter of Part 2 demystifies the two desktop OSes you actually use, answering a cluster of real everyday curiosities along the way: why does Ctrl+Alt+Del always work even when the machine is frozen? What's the real difference between cmd and PowerShell? Why are there "system" and "user" environment variables? What is the registry? How do Windows apps get their look if not with CSS? How did Notepad's plain .txt ever gain styling? Each answer is a window into how these systems are built — and every concept rests on the OS fundamentals you now own.
1. The Windows NT kernel: a different lineage
Windows you use today descends not from MS-DOS but from Windows NT (New Technology, 1993), a from-scratch OS led by Dave Cutler (who had built VMS at DEC). Its kernel makes a different architectural choice than Linux's (2.1). Recall the monolithic-vs-microkernel spectrum: Linux is monolithic (everything in one privileged kernel). NT is a hybrid kernel — a microkernel-influenced core with a privileged "Executive" layer holding the major subsystems (memory manager, process manager, I/O manager, and the object manager), sitting below environment subsystems that present different OS "personalities" to programs. This subsystem design is why, historically, NT could run OS/2, POSIX, and Win32 programs — and it's the same mechanism behind the modern WSL (Windows Subsystem for Linux): Windows presents a Linux-compatible interface so real Linux binaries run on the NT kernel. Under the different surface, though, the deep concepts are identical to what you've learned: NT has processes and threads (in fact NT scheduled threads as the primary unit before it was fashionable), virtual memory with paging (2.5), a privilege boundary with syscalls (2.1), and device drivers. The vocabulary differs (a "handle" is NT's version of a file descriptor; the pagefile is its swap); the fundamentals are the ones you already hold.
macOS is even more familiar underneath than it looks: its core, Darwin, is built on the XNU kernel — a hybrid of the Mach microkernel and a BSD (Unix) layer. So macOS is, genuinely, a certified Unix: it has the same processes, the same fork/exec (2.2), the same "everything is a file" heritage, and a real Unix shell in Terminal. When you use bash/zsh on a Mac, you're using the 2.8 model directly. The polished Aqua interface sits atop a Unix core — which is exactly why macOS became beloved by developers: a friendly desktop with a real Unix underneath.
2. Ctrl+Alt+Del: the Secure Attention Sequence
Here's a genuine mystery worth solving properly. Why does Ctrl+Alt+Del reliably summon a menu (and Task Manager) even when the machine seems completely frozen, and why was it historically the way you logged in? The answer is a beautiful piece of security design, not an accident.
Ctrl+Alt+Del on Windows is a Secure Attention Sequence (SAS) — a key combination the kernel itself intercepts at the lowest level, and which, by design, no ordinary application can capture or fake. That's the whole point. Consider the attack it defends against: a malicious program draws a fake login screen (pixel-perfect), you type your password into it, and it steals your credentials. How can you know the login box is the real one from the OS and not an impostor app? The rule: the genuine login is only ever shown after you press Ctrl+Alt+Del, because that sequence is guaranteed to be handled by the trusted kernel, not by any app — no application can intercept it or simulate the secure desktop it triggers. So pressing it is your guarantee you're talking to Windows itself. ⚑Why does Task Manager always open with Ctrl+Alt+Del even under heavy load? [EQ-127b]
And why does it work when everything else is frozen? Because the sequence is handled by a high-priority path in the kernel, essentially at the interrupt level (2.7) and above normal application scheduling (2.3) — so even if every user application is hung (blocked, spinning, thrashing), the kernel still receives and processes the keystroke and can bring up Task Manager, which runs at high priority so you can kill the offending process. It's an escape hatch deliberately wired to bypass the very application layer that might be stuck. Task Manager itself is just Windows' friendly front-end to the 2.2 process table and 2.3/2.5 scheduler/memory stats — the same information Linux's top reads from /proc (2.8), presented graphically, with a "End task" button that sends the process a terminate request (escalating to a forceful kill — the 2.2 SIGKILL equivalent — if it won't close).
3. cmd vs PowerShell: text streams vs objects
Windows has two very different command-line shells, and the distinction is a genuinely deep one, not a matter of looks. cmd.exe (the "Command Prompt") is the old DOS-heritage shell: it runs commands and, like the Unix shell (2.8), pipes text between them. PowerShell (2006) is a modern shell built on .NET, and its defining innovation is that its pipeline carries objects, not text.
This is a bigger idea than it sounds. In a Unix/cmd pipeline, every program outputs text, and the next program must re-parse that text (with grep, awk, cut) to extract fields — powerful, but fragile (change the output format and the parsing breaks). PowerShell pipes structured objects with real, typed properties: Get-Process outputs process objects, and Get-Process | Where-Object CPU -gt 100 | Stop-Process filters on the actual .CPU property and pipes the objects onward — no text parsing at all. It's the Unix pipe philosophy (2.8) evolved for a typed, object world: compose small commands (called cmdlets, in Verb-Noun form like Get-Content, Set-Item), but pass rich objects instead of text streams. The trade-off: PowerShell is more robust and powerful for structured data and system automation, at the cost of being more verbose and heavier than the terse Unix pipes. For a developer, the practical takeaway: use PowerShell for real Windows automation (it can reach the whole .NET framework and Windows management APIs); cmd survives mostly for legacy scripts. And the worlds are converging — PowerShell now runs on Linux and macOS too. ⚑Difference between cmd and PowerShell and their use cases. [EQ-67]
4. Environment variables: system vs user
You've met the idea implicitly; here's the full picture, since it's a daily point of confusion. An environment variable is a named value the OS makes available to processes — part of the environment every process inherits from its parent (2.2 — a child inherits the parent's environment). Programs read them for configuration: PATH (the list of directories the shell searches for commands), HOME/USERPROFILE (your home directory), TEMP, and countless app-specific ones (JAVA_HOME, NODE_ENV). They're the standard, language-agnostic way to configure a program from outside without editing it — which is why they're central to 2.1-style configuration, twelve-factor apps, containers (2.9), and secret injection (Part 8/13).
On Windows, they come in two scopes, and the distinction trips up everyone at least once. System (machine) environment variables apply to all users and all processes on the machine (set them for something every account needs). User environment variables apply only to your account. When a process starts, Windows composes its environment by combining both (with user values generally taking precedence for the same name, and PATH notably being concatenated — system PATH plus user PATH). This is why installing a tool "for all users" vs "for me" changes which scope its PATH entry lands in, and why a freshly-installed command sometimes isn't found until you open a new terminal (environments are captured at process start — 2.2 — so already-running shells don't see the change). The Unix equivalent is the same concept without the formal two-scope UI: system-wide values in /etc/environment or /etc/profile, per-user values in your shell's ~/.bashrc/~/.zshrc. ⚑What are system vs user account environment variables and what difference do they make? [EQ-64]
5. The registry: centralized config vs scattered files
Here's one of the deepest philosophical differences between Windows and Unix. On Unix, configuration lives in plain-text files scattered across the filesystem — system config in /etc/*, per-app config in dotfiles in your home directory (2.8). Simple, greppable, versionable, editable with any text editor — very much the Unix "everything is a file, in text" ethos. Windows took the opposite approach: the Registry, a single, centralized, hierarchical database holding almost all system and application configuration — settings, file associations, installed-software metadata, hardware info, user preferences — in a tree of keys (like folders) and values (typed data), organized under root hives like HKEY_LOCAL_MACHINE (machine-wide) and HKEY_CURRENT_USER (per-user, echoing the system/user split from section 4).
The trade-off is real and instructive. The registry's advantages: one consistent, fast, structured, transactional store with a uniform API, proper typing, and per-user/per-machine scoping built in — no hunting across dozens of differently-formatted config files. Its disadvantages: it's a single point of failure (corruption can be serious), opaque (not human-readable or easily version-controlled like text files), and prone to accumulating orphaned cruft from uninstalled programs. This is a genuine design tension you'll see echoed throughout engineering — a centralized structured store (easy to query and manage uniformly, but a monolith with a single failure domain) versus distributed plain files (simple, transparent, resilient, but inconsistent and scattered). It's the same tension as a central database vs many small services' local state (Part 10), or a monorepo vs many repos. Neither is universally right; each optimizes different things.
6. SMB, NTFS, and Active Directory: the enterprise Windows stack
Three related pieces you'll meet constantly in corporate environments, each answering "how do Windows machines share files and manage identity at scale?"
- NTFS (New Technology File System) is Windows' journaling file system (2.6) — its inode-equivalent is the Master File Table (the very structure WizTree reads, 2.6). It supports permissions (ACLs — access control lists, finer-grained than Unix's rwx), encryption, compression, and journaling for crash recovery.
- SMB (Server Message Block) is the network protocol for file and printer sharing on Windows networks — it's what makes a network drive (
\\server\share) work: your machine sends SMB requests over the network to read/write files on a remote server as if they were local. (Its open cousin, Samba, lets Linux speak SMB, which is how Linux servers share files with Windows clients.) When you map a network drive at work, SMB is the protocol underneath. ⚑What is SMB protocol and Windows NTFS? [EQ-42] - Active Directory (AD) is Microsoft's directory service — the centralized identity and access-management system that runs virtually every corporate Windows network. It stores all the accounts (users, computers, groups) and policies for an organization in a central directory, so that one login works across the whole network, administrators can enforce policies org-wide (Group Policy), and resources check AD to decide who's allowed what. Under the hood it speaks LDAP (a directory-query protocol) and Kerberos (a secure authentication protocol) — and this is precisely where Part 2's OS knowledge hands off to Part 8's identity chapters: AD, LDAP, Kerberos, and their cloud successor Entra ID (formerly Azure AD) are covered in depth in 8.4.8 and 8.4.9. For now, hold the shape: AD is the corporate "phone book + bouncer," the single source of truth for who exists and what they may access across an entire organization's machines. ⚑What is Microsoft Active Directory in the context of SMB/NTFS? [EQ-42b]
7. The OS "design language": how the UI is built (and why not CSS)
A real curiosity: when Microsoft revamped Windows 10 into 11, or Apple redesigns macOS, what are they changing, and how is that UI built — surely not with CSS like a website? The answer introduces the idea of a design language — a documented, coherent system of visual and interaction rules (shapes, spacing, motion, typography, color, iconography) that gives an OS its consistent "feel." Microsoft's is called Fluent Design (the rounded corners, translucency/"acrylic," and soft shadows of Windows 11); Apple's is expressed through its Human Interface Guidelines and the Aqua/current aesthetic. A "redesign" like Windows 10 → 11 is largely a new design language applied across the system.
And how is it rendered? Not with CSS, but with native UI toolkits (frameworks). A desktop app's buttons, windows, and menus are drawn by the OS's own graphics frameworks — on Windows, historically Win32/GDI, then WPF, and now WinUI; on macOS, Cocoa with AppKit/SwiftUI. These toolkits draw controls using the GPU and the OS's rendering stack, not a web browser's HTML/CSS engine. The distinction matters: web UIs are described in HTML/CSS and rendered by a browser engine (Part 6); native desktop UIs are built by calling these platform frameworks directly, which is why native apps can feel faster and more "of the system" than web-based ones. (The lines blur — Electron apps like VS Code and Slack do wrap a whole browser engine to render their UI with web tech, trading native-ness for cross-platform reuse; and the frameworks themselves increasingly borrow declarative, CSS-like styling ideas.) The takeaway: an OS's look is a design language implemented by native rendering frameworks — a parallel universe to web styling, solving the same "make it look consistent and good" problem with different tools. ⚑What is a design language of an OS? Windows 10→11, macOS — they don't use CSS, so what? [EQ-36]
8. Plain text vs rich text: the Notepad story
One last everyday curiosity that neatly ties back to 1.4. Why is Notepad's .txt "plain," and how did text ever gain styling like bold and italics? A plain text file (.txt) contains only the character codes (1.4 — the actual letters as Unicode/UTF-8 bytes) and nothing else — no font, no size, no color, no bold. There is simply nowhere in the file to store "this word is bold," because it holds only characters. That's the whole nature of plain text, and it's a feature: universal, tiny, readable by any program forever.
Rich text gains styling by storing additional formatting instructions alongside the characters — markup or control codes that say "from here, bold." Different formats do this differently: RTF (Rich Text Format) intersperses control words (\b for bold) with the text; a Word .docx is actually a zip of XML files describing text plus elaborate formatting; HTML wraps text in tags (<b>). In every case, the styling is extra data the plain-text file never had. So the progression from Notepad (plain .txt) to WordPad (RTF) to Word (.docx) is a progression in how much formatting metadata travels with the characters — and it's the same "meaning lives in the agreed interpretation of the bytes" lesson from 1.4: a .txt file and a .rtf file might contain the same words, but the .rtf also carries a codebook of formatting the reading program knows how to apply. (Modern Notepad has gained some features, but the .txt format itself remains pure characters — which is exactly why programmers love it for code: no hidden formatting to corrupt the meaning.) ⚑How did Notepad/.txt gain rich text? How can a plain .txt capture styling? [EQ-200]
9. The expert lens
Knowing multiple OS models makes you a better engineer, not just a more portable one. Each OS made different bets, and seeing the contrast teaches the underlying trade-offs better than any single system could. Registry vs scattered text files is the centralized-vs-distributed-config debate in miniature. PowerShell's object pipeline vs Unix's text pipeline is the typed-vs-untyped, structured-vs-simple debate. NT's hybrid kernel vs Linux's monolith is the 2.1 isolation-vs-performance spectrum. When you understand why each system chose as it did, you can reason about the same trade-offs when they reappear in your own designs — because they will, at every scale.
The worlds are converging, and that's the real trend. WSL runs genuine Linux on Windows; PowerShell runs on Linux and macOS; macOS was always Unix underneath; containers (2.9) make the deployment target Linux regardless of your desktop; VS Code (an Electron app) gives an identical dev experience everywhere. The practical upshot for a modern engineer: you'll develop on Windows or macOS and deploy to Linux, so you need fluency in both worlds — the Unix model for servers/containers/cloud (Parts 2, 13), and the Windows/macOS specifics for your daily machine and for the enterprise environments (AD, SMB, Entra) you'll integrate with (Part 8). The boundaries that once made these separate universes are dissolving.
The fundamentals are universal; only the vocabulary changes. This is the liberating conclusion of Part 2. A "handle" (NT) is a file descriptor (Unix). The "pagefile" (Windows) is "swap" (Linux). Task Manager reads the same process/scheduler/memory data as top. NTFS's MFT plays the role of Unix inodes. Every OS has processes, threads, virtual memory, a privilege boundary, a scheduler, and a file system — because these solve universal problems that any OS on any hardware must solve. Learn the concepts once (as you now have), and every operating system becomes a set of named variations on ideas you already understand deeply. That's why this whole part was worth it: not to memorize one OS, but to own the ideas beneath all of them.
Part 2 complete. From the privilege boundary and the system call, through processes, threads, scheduling, concurrency, virtual memory, file systems, and I/O, to Linux, virtualization, containers, and now the desktop OSes — you've built the operating system from the ground up and can reason about any of them. Part 3 climbs the next rung: the languages, compilers, and runtimes that turn the source code you write into the processes this part knows how to run — starting with how a compiler transforms text into the machine code of 1.5.
Recall
- Windows runs the NT hybrid kernel (Executive + environment subsystems, the mechanism behind WSL); macOS runs Darwin/XNU (Mach microkernel + BSD) — a real Unix. Different surfaces, but both have the processes, threads, virtual memory, syscalls, and file systems of Part 2 (a "handle" = file descriptor; pagefile = swap).
- Ctrl+Alt+Del is a Secure Attention Sequence the kernel handles and no app can fake (so the login screen after it is guaranteed genuine); it works when frozen because it runs above application scheduling. Task Manager is a GUI over the 2.2/2.3/2.5 process/scheduler/memory data (like
top). - cmd pipes text (like Unix); PowerShell pipes typed objects (cmdlets in
Verb-Nounform) — more robust for structured automation. Environment variables configure processes (inherited from the parent); Windows splits system (all users) vs user (your account) scopes. - The Registry is Windows' centralized config database (hives → keys → values) vs Unix's scattered plain-text config files — the centralized-vs-distributed trade-off. NTFS/SMB/Active Directory are the enterprise stack (file system / network file-sharing protocol / central identity directory via LDAP+Kerberos → Part 8).
- An OS's look is a design language (Fluent, Aqua) rendered by native UI toolkits (WinUI, Cocoa/SwiftUI), not CSS (except Electron apps). Plain text (
.txt) stores only characters (1.4); rich text (RTF,.docx, HTML) adds formatting metadata alongside them.
Self-test: Why can no application fake Ctrl+Alt+Del, and why does it work when the machine is frozen? What's the fundamental difference between the cmd and PowerShell pipelines? What is the registry, and what Unix approach does it contrast with? What is Active Directory for? How does a .rtf file store "bold" when a .txt can't?
Quiz Bank
FoundationalHow do the Windows and macOS kernels relate to the Unix model taught in this part?
Windows uses the NT hybrid kernel — a microkernel-influenced privileged "Executive" (memory/process/I/O managers) with environment subsystems presenting OS "personalities" (which is how WSL runs Linux binaries). macOS uses Darwin/the XNU kernel — a hybrid of the Mach microkernel and a BSD Unix layer, making macOS a genuine Unix (real fork/exec, Unix shell, "everything is a file"). Despite different surfaces and vocabulary (NT "handle" = Unix file descriptor; "pagefile" = "swap"), both have the same fundamentals as Linux: processes, threads, virtual memory + paging, a syscall/privilege boundary, and a file system — because those solve universal OS problems.
AppliedWhy can no application fake Ctrl+Alt+Del, and why does it work even when the machine is frozen?
Ctrl+Alt+Del is a Secure Attention Sequence: the kernel intercepts it at a low level and, by design, no user-space application can capture or simulate it. That guarantees the login/security screen shown after it is the genuine OS screen, not a malicious app's fake login harvesting your password — pressing it proves you're talking to Windows itself. It works when the system seems frozen because it's handled on a high-priority kernel path (essentially interrupt-level, above normal application scheduling), so even if every user app is hung, the kernel still processes the keystroke and can launch the high-priority Task Manager to let you kill the stuck process.
AppliedWhat is the fundamental difference between cmd and PowerShell?
cmd pipes text between commands (like the Unix shell), so downstream commands must re-parse text to extract fields. PowerShell pipes typed objects: cmdlets (in Verb-Noun form like Get-Process) output structured objects with real properties, so you filter/act on actual fields (Get-Process | Where-Object CPU -gt 100 | Stop-Process) with no text parsing — more robust and powerful for structured data and system automation, built on .NET. It's the Unix pipe philosophy evolved for a typed object world. cmd persists for legacy scripts; PowerShell is the modern automation shell (and now cross-platform).
AppliedWhat's the difference between system and user environment variables on Windows?
Environment variables are named values processes inherit from their parent and read for configuration (PATH, HOME, JAVA_HOME…). On Windows, system (machine) variables apply to all users and processes; user variables apply only to your account. At process start Windows merges both (user generally overriding system for the same name; PATH is concatenated). Consequences: "install for all users" vs "for me" changes which scope gets the PATH entry, and a newly-installed command isn't found in already-open shells because a process captures its environment at start — you must open a new terminal. Unix does the same conceptually via /etc/environment (system) vs ~/.bashrc (user).
InterviewWhat is the Windows Registry, and how does it contrast philosophically with Unix configuration?
The Registry is Windows' single, centralized, hierarchical database of system and application configuration — a tree of keys and typed values under root hives (HKEY_LOCAL_MACHINE machine-wide, HKEY_CURRENT_USER per-user). Unix instead scatters configuration across plain-text files (/etc/* system-wide, dotfiles per-user). The trade-off: the registry gives one consistent, fast, structured, scoped store with a uniform API — but is opaque, hard to version-control, and a single failure domain (corruption is serious). Unix's text files are transparent, greppable, versionable, and resilient — but inconsistent and scattered. It's the centralized-structured-store vs distributed-plain-files tension that recurs across engineering (central DB vs local service state, monorepo vs many repos).
InterviewWhat are NTFS, SMB, and Active Directory, and how do they relate?
NTFS is Windows' journaling file system (2.6); its central structure is the Master File Table (its inode equivalent), and it supports ACL permissions, encryption, and journaling. SMB (Server Message Block) is the network protocol for file/printer sharing — it's what makes \\server\share network drives work, sending file requests to a remote server (Linux speaks it via Samba). Active Directory is Microsoft's centralized directory service / identity system for corporate networks: it stores all users, computers, groups, and policies centrally so one login works network-wide and admins enforce org-wide policy, using LDAP (directory queries) and Kerberos (authentication) underneath. Together: NTFS stores files locally, SMB shares them over the network, and AD controls who is allowed to access what across the organization (deep-dived in Part 8).
StaffA developer asks why their cross-platform desktop app 'feels less native' than a true Windows/macOS app, and whether that matters. Explain using this chapter.
The likely cause: the app is built with a web-based cross-platform framework like Electron (Chromium + Node), which renders its entire UI with HTML/CSS/JS inside a bundled browser engine rather than with the platform's native UI toolkits (WinUI/Cocoa/SwiftUI) that draw controls using the OS's own rendering stack and design language (Fluent/Aqua). Native toolkits produce widgets that match the system's exact look, animations, accessibility, and input behaviors, and are typically lighter (no bundled browser); web-based frameworks reuse one codebase everywhere but approximate native look-and-feel and carry a whole browser engine's memory/startup cost — hence "less native" feel and heavier resource use (the classic Electron critique, seen in Slack/VS Code). Does it matter? It's a trade-off, not a verdict:
cross-platform reach + one codebase + web-developer velocity (Electron/Flutter/React Native-desktop) vs native fidelity + performance + smaller footprint (WinUI/SwiftUI, or cross-platform-native like Qt). Choose by priorities: a tool used all day by power users on one platform argues for native; a product needing to ship to Windows/macOS/Linux fast with a small team argues for the web-based approach — often mitigated by careful theming, respecting OS conventions, and native modules for hot paths. The staff framing: "native feel" is really "rendered by the OS's own design-language toolkit vs a bundled browser," and the right call follows from weighing platform fidelity against development reach and cost.
Flashcards
FlashWindows NT vs macOS kernel lineage
Windows: NT hybrid kernel (Executive + subsystems; WSL runs Linux on it). macOS: Darwin/XNU (Mach microkernel + BSD) — a real Unix.
FlashWhy Ctrl+Alt+Del is trustworthy
It's a Secure Attention Sequence handled by the kernel that no app can fake — so the login screen after it is guaranteed genuine; runs above app scheduling, so it works when apps are frozen.
Flashcmd vs PowerShell pipeline
cmd pipes text; PowerShell pipes typed objects (cmdlets, Verb-Noun) — robust structured automation, no text parsing.
FlashSystem vs user environment variables
System: apply to all users/processes. User: only your account. Merged at process start; PATH concatenated. Captured at start (reopen terminal to see changes).
FlashWindows Registry vs Unix config
Registry: one centralized hierarchical database (hives/keys/values). Unix: scattered plain-text config files. Centralized-structured vs distributed-transparent trade-off.
FlashNTFS / SMB / Active Directory
NTFS: Windows file system (MFT). SMB: network file-sharing protocol (\server\share). AD: central identity/directory service (LDAP + Kerberos).
FlashOS design language & how UI is rendered
Design language = coherent visual/interaction system (Fluent, Aqua). Rendered by native toolkits (WinUI, Cocoa/SwiftUI), not CSS — except Electron apps (bundled browser).
FlashPlain text vs rich text
.txt stores only characters (no formatting possible). Rich text (RTF/.docx/HTML) adds formatting metadata alongside the characters.
Scenario Drill
DrillYour team develops on Windows and macOS laptops but deploys to Linux containers. A bug 'only happens in production.' Using this chapter and Part 2, list the OS-level differences that could cause dev/prod divergence and how you'd neutralize them.
The root risk is environment divergence between your desktop OS and the Linux deployment target — exactly the problem containers exist to solve, but only if used consistently. OS-level differences that bite: (1) File systems & paths — Windows paths (\, drive letters, case-insensitive NTFS) vs Linux (/, case-sensitive ext4) — a file imported as User.js but referenced as user.js works on Windows/macOS and fails on Linux (2.6); (2)
line endings — Windows CRLF vs Unix LF can break scripts/parsers; (3) environment variables & config — different scoping/availability (section 4), and secrets present on your machine but not in the container; (4) process/signal behavior — graceful shutdown relies on SIGTERM (2.2), which behaves differently or isn't sent the same way outside Linux; (5)
permissions — Unix rwx/user model (2.6) vs NTFS ACLs; (6) case/locale/timezone and available system libraries — the container's minimal Linux userland differs from your full desktop OS; (7) resource limits — the container has cgroup CPU/memory caps (2.8) your laptop doesn't, so memory-hungry code that's fine locally gets OOM-killed in prod (2.5/2.9).
Neutralize by making dev match prod: develop inside the same container image you deploy (via WSL2/Docker Desktop, or VS Code Dev Containers) so the kernel, filesystem semantics, libraries, and env are identical; enforce LF and case-correct imports in CI; run tests in the target container with production-like cgroup limits; inject config/secrets the same way in both. The chapter's lesson applied: the fundamentals are universal, but the specifics (paths, case sensitivity, signals, limits, ACLs) differ per OS — and "ship the environment, not just the code" (2.9) is precisely how you erase dev/prod OS divergence.