# macOS Under the Hood > macOS is a polished Unix machine - Darwin and the XNU kernel underneath, a real Unix filesystem hiding beneath the Finder, apps that are secretly folders, and a Terminal that feels like Linux because it nearly is. --- # macOS Under the Hood You've used a Mac for years. You know the Dock, Spotlight, Finder, the satisfying *thunk* of the trash. But the first time you opened the Terminal, something felt strange - it looked exactly like the Linux boxes at work, the same `ls` and `cd` and `/usr/bin`, as if there were a whole second computer hiding behind the wallpaper. There is. macOS is a genuine Unix system wearing a beautiful coat, and once you can see the machine underneath, the Mac stops being a sealed appliance and becomes something you can actually reason about. This guide is the tour under the hood - not to make you a kernel hacker, but so the next time you open Terminal, install a tool, or hit a permission wall, you know *what you're standing on*. > ⏭️ New to operating systems in general? Read [What an Operating System Is](/guides/what-an-operating-system-is) > first - this guide assumes you know what a kernel and a process are, and builds on its > Windows-vs-macOS-vs-Linux comparison. ## How to read this - **Want the big idea fast?** Phase 1 is the one that reframes everything: macOS *is* Unix. Read it and the rest will click. - **Want it to finally make sense?** Read in order - each phase builds on the last, from the foundation up to the surface you already know. ## The phases 1. **[macOS Is Unix](01-macos-is-unix.md)** - the Darwin foundation, the XNU kernel, the BSD heritage, and the real Unix filesystem (`/`, `/usr`, `/etc`, `/Users`) hiding under the Finder's friendly view. 2. **[Apps, Bundles & Where Things Live](02-apps-bundles-and-where-things-live.md)** - why a `.app` is actually a folder, the several `Library` folders and what lives in each, and installing real CLI tools with Homebrew. 3. **[Under the Surface](03-under-the-surface.md)** - the Terminal and zsh, `launchd` as macOS's service manager, the security layers a power user meets (Gatekeeper, SIP, permission prompts), and a short "where macOS differs from Linux" wrap-up. > We deliberately stop at the *power-user* depth. Writing kernel extensions, code-signing your own apps, > and the deep guts of APFS are their own guides - this one gets you a true working mental model of the > Mac as a Unix machine, and stops there. --- # macOS Is Unix Here's the single idea this whole guide rests on, and it surprises almost everyone: **macOS is a real Unix system.** Not "Unix-like as a marketing word" - it's a certified Unix that ships with the nicest desktop in the business bolted on top. The Finder, the Dock, the gorgeous animations: those are the coat. Underneath is the same family of machine that runs most of the internet's servers. Once you believe that, a hundred small mysteries resolve at once - why Terminal feels like Linux, why developer tools "just work," why your files secretly live at paths like `/Users/you`. ## The layers under the Mac Apple has a name for the open-source Unix core of macOS: **Darwin**. Picture the Mac as layers, the same three-layer stack from [What an Operating System Is](/guides/what-an-operating-system-is), but with Apple's actual names filled in: ```mermaid flowchart TD See[The Mac you see
Finder, Dock, Spotlight, your apps - the coat] --> Frameworks[Apple's frameworks
Cocoa, Metal, the APIs apps call] Frameworks --> Darwin[Darwin = the Unix core
BSD userland + the XNU kernel] Darwin --> Hardware[The hardware
Apple silicon or Intel, RAM, disk, devices] ``` **What it actually is.** *Darwin* is the foundation layer - an open-source Unix operating system that Apple develops and releases. macOS (and iOS, iPadOS, and the rest) are Darwin plus Apple's closed, beautiful upper layers. When people say "macOS is Unix underneath," Darwin is the underneath they mean. πŸ“ **Terminology.** *Userland* = everything that runs in user space (the programs, command-line tools, and libraries) as opposed to the kernel. Darwin's userland comes largely from **BSD** - a venerable branch of the Unix family tree - which is why the commands on a Mac behave like classic Unix commands. ## The XNU kernel: where the heritage shows At the center of Darwin is its kernel, named **XNU**. Remember from the OS guide that the kernel is the core program that actually controls the hardware and enforces every rule. XNU is the Mac's. **Why people get this wrong.** People assume macOS and Linux must share a kernel because the terminals look identical. They don't. **Linux uses the Linux kernel; macOS uses XNU.** What they *share* is the Unix design and the BSD-style commands on top - the userland, not the engine. That distinction matters later: a binary compiled for Linux won't run directly on macOS, even though `ls` and `grep` feel the same. πŸ“ **Terminology.** *XNU* is the macOS kernel. (The name is a self-deprecating recursive joke from its authors - "X is Not Unix.") It blends a Mach microkernel core with BSD components, which is why Darwin carries so much BSD DNA. πŸ’‘ **Key point.** macOS and Linux are **siblings, not the same person.** Both are Unix-family systems with similar command-line worlds, but they have *different kernels*. Learn the shared Unix model once and you can move between them fluently - just don't expect their internals (or their binaries) to be interchangeable. ## The real filesystem hiding under Finder Open a Finder window and you see Documents, Desktop, Downloads, AirDrop, iCloud - a friendly, curated view. That view is a *lie of kindness*: Finder is deliberately hiding the actual Unix filesystem underneath, because most people never need it. But it's right there, and it's a textbook Unix layout. Open Terminal and ask where the top of the world is: ```console $ cd / $ ls -F Applications/ System/ private/ usr/ Library/ Users/ sbin/ var@ bin/ opt/ tmp@ cores/ dev/ etc@ ``` *What just happened:* you moved to `/` - the **root** of the filesystem, the single top folder everything else hangs beneath. (Unix has no `C:` drive; there's one tree, and `/` is its trunk.) The `/` after a name means "this is a folder"; the `@` means "this is a symbolic link" - a signpost pointing elsewhere. Here's what the important ones are, in plain terms: | Path | What lives there | |---|---| | `/` | **Root** - the top of the single filesystem tree. Everything is under here. | | `/Users` | Home folders - yours is `/Users/yourname` (what Finder calls "Home"). | | `/Applications` | Your `.app` programs (more on what those *really* are in Phase 2). | | `/System` | Apple's own OS files. Protected and read-only - you can't edit these (Phase 3 explains why). | | `/Library` | System-wide app support, preferences, and fonts shared by all users. | | `/usr` | Classic Unix: command-line programs and libraries. `/usr/bin` holds `ls`, `grep`, `python3`… | | `/bin`, `/sbin` | The most essential commands (`bash`, `ls`, `cp`) and system binaries. | | `/etc` | System configuration files (it's a symlink to `/private/etc` on macOS). | | `/var`, `/tmp` | Variable data (logs, caches) and temporary scratch space (both symlinks to `/private/...`). | | `/opt` | Optional add-on software - Homebrew lives here on Apple silicon (Phase 2). | | `/dev` | "Devices as files" - your disks and terminals appear here as file-like entries. | ⚠️ **Gotcha: this is the same layout you'd see on Linux - with a Mac accent.** `/usr`, `/etc`, `/var`, `/bin` are straight out of the Unix tradition and mean the same thing on a Linux server. But macOS adds its own capitalized folders (`/Users`, `/Applications`, `/Library`, `/System`) where Linux would use lowercase (`/home`, and no direct equivalents). It's *recognizably* Unix, not *identically* Linux - don't assume a path you memorized on Linux (`/home/you`) exists here; on a Mac it's `/Users/you`. πŸͺ– **War story.** The first script copied from a Linux tutorial onto a Mac fails instantly if it writes to `/home/me/output.log` - there is no `/home` on a stock Mac. That one swap (`/home` β†’ `/Users`) is the single most common papercut for a Linux person sitting down at a Mac. You can prove your home folder to yourself: ```console $ echo $HOME /Users/ada $ cd ~ $ pwd /Users/ada ``` *What just happened:* `$HOME` is the environment variable holding your home folder's path, and `~` is shorthand for it. On this machine the user is `ada`, so home is `/Users/ada` - exactly the friendly "Home" Finder shows you, just spelled in its true Unix path. Finder and the Terminal are looking at the *same* filesystem; they're only two windows onto one tree. **Why this saves you later.** Every confusing macOS moment that follows - "where did Homebrew put that?", "why can't I edit this file?", "what's a `.plist`?" - is really a question about *this* filesystem. Once you can see the real tree instead of Finder's curated highlights, you can navigate the Mac like a senior does: by knowing where things actually are. ## Recap 1. macOS is a **real Unix system**: Apple's open-source core is called **Darwin**, and the Mac is Darwin plus Apple's beautiful upper layers. 2. Darwin's kernel is **XNU** (Mach + BSD). It is *not* the Linux kernel - macOS and Linux are Unix **siblings with different kernels**, which is why the terminals feel alike but binaries don't transfer. 3. The Terminal feels like Linux because Darwin's **userland is BSD/Unix** - the same commands and the same filesystem shape. 4. Beneath Finder's friendly view is a **real Unix filesystem**: one tree rooted at `/`, with `/Users`, `/usr`, `/etc`, `/System` and friends. Your home is `/Users/you`, not `/home/you`. Next, we'll use this map to answer the most surprising "where do things live?" question on the Mac - what a `.app` *actually* is, and the maze of `Library` folders. --- # Apps, Bundles & Where Things Live On Windows a program is a `.exe` file. So when you drag a Mac app to the trash and it just… vanishes cleanly, with no installer and no uninstaller, it can feel like magic. It isn't. The Mac's approach to "where an app and its stuff live" is unusually tidy, but it only makes sense once you know two secrets: **an app is really a folder**, and **your settings live in a place called Library** - three of them, actually. ## A `.app` is a folder, not a file **What it actually is.** That `Safari.app` or `VLC.app` you double-click is not a single file. It's a **folder** - a special kind macOS calls a **bundle** - with a strict layout inside, holding the program, its icons, images, and everything else it needs. Finder *pretends* it's one icon so you can move it around as a single thing, but on disk it's a directory full of parts. πŸ“ **Terminology.** *Bundle* = a folder that macOS treats as a single object in the Finder. App bundles end in `.app`; there are other bundle types too (`.framework`, `.bundle`). The "it's one icon but really a folder" trick is the whole idea. **Prove it to yourself - the Finder way.** Right-click any app and choose **Show Package Contents**. Finder opens it like the folder it is. But the Terminal makes the truth even plainer: ```console $ cd /Applications $ ls -d Calculator.app Calculator.app $ ls Calculator.app/Contents Info.plist MacOS PkgInfo Resources _CodeSignature ``` *What just happened:* `Calculator.app` looked like a file in Finder, but `ls` walked right into it - it's a folder. Inside is a `Contents` directory with a predictable structure. The important parts: - `MacOS/` - the **actual executable**, the real program that runs. - `Resources/` - icons, images, sounds, translated text: the app's assets. - `Info.plist` - a settings file describing the app (its name, version, what it needs). We'll meet `.plist` files again in a moment. - `_CodeSignature/` - Apple's cryptographic signature proving the app hasn't been tampered with (Phase 3 covers why that matters). πŸ’‘ **Key point.** Because an app is a self-contained folder carrying everything it needs, **installing is just copying the folder into `/Applications`, and uninstalling is just dragging it to the trash** - no installer wizard, no registry, no leftover system files for the app itself. (Its *preferences* live elsewhere - coming up next - which is why a stray settings file can linger after you trash an app.) ## The Library folders: where your settings actually live If the app is a tidy self-contained folder, where do your preferences, caches, and saved data go? Not inside the app - that would get wiped on every update. They go into **Library**, and here's the part that trips everyone up: **there are several Library folders, at different levels.** ```text /System/Library ← Apple's own. Hands off. Protected by the OS (see Phase 3). /Library ← Shared by ALL users of this Mac. Needs admin to change. ~/Library ← YOURS. Your account's settings, caches, app data. Hidden by default. ``` **What each is for, in plain terms:** | Folder | Whose | What's in it | |---|---|---| | `/System/Library` | Apple's | Core OS components. You don't touch this; the OS won't let you. | | `/Library` | The whole machine | App support and preferences shared by every user; system-wide fonts. | | `~/Library` | Just you | **Your** per-app settings, caches, and saved data. This is the one you'll actually visit. | ⚠️ **Gotcha: `~/Library` is hidden on purpose.** Apple hides your personal Library so you don't wander in and break things - it won't show in a normal Finder window. To reveal it: in Finder press **Shift + Cmd + G** and type `~/Library`, or hold **Option** while clicking Finder's **Go** menu. From the Terminal it was never hidden at all: ```console $ ls ~/Library Application Support Caches Logs Saved Application State Application Scripts Containers Mobile Documents Preferences Autosave Information Fonts Preferences ... ``` *What just happened:* You listed your personal Library - the real home of your settings. The three folders worth knowing by name: - **`Preferences/`** - your app settings, one file per app, stored as `.plist` files. - **`Application Support/`** - an app's larger saved data (databases, profiles, plugins) - anything bigger than a few preferences. - **`Caches/`** - disposable temporary data an app keeps to be faster. Safe to lose; the app rebuilds it. πŸ“ **Terminology.** *plist* (property list) = macOS's standard settings-file format, ending in `.plist`. It's a structured key/value file (often XML or a compact binary form) storing one app's preferences. When you change a setting in an app's Preferences window, you're usually editing its `.plist`. Take a peek at one: ```console $ cd ~/Library/Preferences $ ls | grep -i finder com.apple.finder.plist ``` *What just happened:* that's the Finder's own settings file. Notice the naming convention: **reverse-DNS**, like `com.apple.finder` - vendor's domain backwards, then the app name. Every Mac app's preferences follow this `com.company.app.plist` pattern, so you can find any app's settings file by guessing its name. πŸͺ– **War story.** An app that keeps launching with a corrupted, broken window every time it opens, where reinstalling changes nothing, usually has the problem in its **preferences**, not its code - reinstalling only replaces the app folder. Deleting that one `com.vendor.app.plist` from `~/Library/Preferences` (the app rewrites a fresh one on next launch) fixes in seconds what an hour of reinstalling couldn't. **Why this saves you later.** "I trashed the app but its settings came back" and "the app is broken even after reinstalling" are the *same* lesson from two directions: the app folder and the app's Library data are separate. ## Installing real CLI tools with Homebrew macOS ships with a Unix userland (Phase 1), but Apple keeps it conservative and doesn't include everything a developer wants - and there's no built-in package manager like Linux's `apt` or `dnf` for adding more. The community filled that gap with **Homebrew**, the standard way Mac developers install command-line software. πŸ“ **Terminology.** *Package manager* = a tool that installs, updates, and removes software for you, handling dependencies (the other software a program needs). *Homebrew* (`brew`) is the de facto package manager for macOS. Installing a tool looks like this: ```console $ brew install wget ==> Fetching dependencies for wget: openssl@3 ==> Fetching wget ==> Pouring wget--1.25.0.arm64_sequoia.bottle.tar.gz 🍺 /opt/homebrew/Cellar/wget/1.25.0: 92 files, 4.5MB ==> Running `brew cleanup wget`... ``` *What just happened:* `brew` downloaded `wget` (and the dependency it needs, `openssl@3`), unpacked the prebuilt copy - Homebrew calls a prebuilt binary a **bottle** - into its own storage, and made it available to run. You didn't compile anything or hunt for an installer; one command did it. Notice the install path: `/opt/homebrew`. That ties straight back to Phase 1's filesystem map: ```text Apple silicon (M1/M2/M3/M4…) β†’ Homebrew installs under /opt/homebrew Intel Macs (older) β†’ Homebrew installs under /usr/local ``` ⚠️ **Gotcha: Homebrew keeps its world separate from Apple's.** It installs into its own prefix (`/opt/homebrew` or `/usr/local`) rather than mixing into Apple's `/usr/bin`. That's deliberate and good - Apple can update the system without clobbering your tools, and you can remove Homebrew cleanly. But it means your shell has to know to look there. On a fresh Apple-silicon Mac, after installing Homebrew you have to add it to your `PATH` (the list of folders your shell searches for commands) - the installer prints the exact lines to paste, and if you skip that step, `brew` "isn't found" even though it's installed. See [The Terminal & Shell](/guides/the-terminal-and-shell) if `PATH` is unfamiliar. **Why this saves you later.** When a tutorial says "just run `brew install ...`" and your Mac says `command not found`, you won't be stuck - you'll know Homebrew lives in its own prefix and exactly where to look. ## Recap 1. A **`.app` is a folder** (a *bundle*), not a single file - `Show Package Contents` (or `cd` into it) reveals the executable, resources, and `Info.plist` inside. 2. Because the app is self-contained, **installing = copy to `/Applications`, uninstalling = drag to trash** - but its settings live elsewhere. 3. There are **several Library folders**: `/System/Library` (Apple's, off-limits), `/Library` (machine-wide), and **`~/Library`** (yours - and hidden by default). 4. Inside `~/Library`: **`Preferences/`** (per-app `.plist` settings, named `com.company.app.plist`), **`Application Support/`** (bigger app data), and **`Caches/`** (disposable). 5. **Homebrew** is the package manager for real CLI tools - it installs into its own prefix (`/opt/homebrew` on Apple silicon, `/usr/local` on Intel), kept separate from Apple's `/usr`. Next, the surface you already touch every day - the Terminal and zsh - plus the service manager that keeps the Mac running and the security walls a power user runs into. --- # Under the Surface You've got the foundation (macOS is Unix) and the layout (apps are folders, settings live in Library). This last phase is about the parts you *operate* - the Terminal you type into, the invisible manager that keeps services running, and the security walls that occasionally stop you with a prompt or a flat "Operation not permitted." None of these are obstacles once you know what they're doing and why. ## The Terminal and zsh **What it actually is.** The **Terminal** is just a window. The thing that actually reads your commands, runs them, and prints results is a program running *inside* that window called the **shell**. On a modern Mac the default shell is **zsh** (the Z shell). It's the interpreter; Terminal is its screen. πŸ“ **Terminology.** *Shell* = the program that turns the text you type into actions (running programs, moving through folders, chaining commands). *zsh* is the shell Apple ships as the default. (Older Macs defaulted to **bash**; Apple switched the default to zsh, though bash is still present.) You can ask the system which shell is yours: ```console $ echo $SHELL /bin/zsh $ zsh --version zsh 5.9 (arm64-apple-darwin24.0) ``` *What just happened:* `$SHELL` is the environment variable holding the path to your login shell - here `/bin/zsh`, confirming zsh is the default. The version line even says `darwin24.0`: a quiet reminder that under this familiar shell sits **Darwin**, the Unix core from Phase 1. ⚠️ **Gotcha: your startup file is `.zshrc`, not `.bashrc`.** Coming from Linux (or old Macs), muscle memory says edit `~/.bashrc` to set up your shell. On a default Mac that file is ignored - zsh reads **`~/.zshrc`**. Put your aliases, your `PATH` additions (including the Homebrew line from Phase 2), and your prompt tweaks there. Editing the wrong file and wondering why nothing takes effect is a classic first-week-on-a-Mac afternoon lost. > ⏭️ If shells, `PATH`, aliases, and startup files are new, [The Terminal & Shell](/guides/the-terminal-and-shell) > is the dedicated guide - this section just names the macOS specifics (zsh, `~/.zshrc`). ## `launchd`: the manager that starts everything Back in [What an Operating System Is](/guides/what-an-operating-system-is) you saw that after the kernel boots, it starts **one first process** whose job is to start everything else. On macOS, that first process - and the manager that keeps services running for the rest of the time the Mac is on - is **`launchd`**. **What it actually is.** `launchd` is macOS's **service manager**. It's the very first process the kernel launches (process ID 1), and it's responsible for starting, stopping, and supervising background services - Spotlight indexing, Time Machine, networking helpers, and any background agents apps install. If a service it's watching dies, `launchd` can bring it back. **The Linux bridge.** If you know Linux, you know **systemd** - the thing you poke with `systemctl start ...`. `launchd` is **macOS's counterpart to systemd**: same role, different tool. They are *not* the same software and the commands differ, but the *concept* maps cleanly: | | macOS | Linux (systemd) | |---|---|---| | Service manager | `launchd` | `systemd` | | First process (PID 1) | `launchd` | `systemd` | | Command-line control | `launchctl` | `systemctl` | | A service is defined by | a `.plist` file | a `.service` unit file | πŸ“ **Terminology.** *Service* (also *daemon*, or on macOS an *agent*) = a program that runs in the background without a window, doing ongoing work - indexing, syncing, listening on the network. *`launchctl`* is the command-line tool for talking to `launchd`. You can watch `launchd` reporting on the services it manages: ```console $ launchctl list | head -n 5 PID Status Label 1234 0 com.apple.Spotlight - 0 com.apple.Safari.SafeBrowsing.Service 891 0 com.apple.Dock.agent ``` *What just happened:* `launchctl list` asked `launchd` for the jobs it's overseeing. Each row is a managed service: a `PID` if it's currently running (or `-` if loaded but idle), a status code (`0` means it exited cleanly last time), and a reverse-DNS **Label** - the same `com.company.thing` naming convention from preference files in Phase 2. **Why this saves you later.** When something background-y misbehaves - a sync agent stuck, a helper eating CPU - you now know there's a single manager responsible for it, with a tool (`launchctl`) to inspect and control it, and that it's the *same idea* as `systemctl` if you've used Linux. ## The security walls a power user meets macOS is locked down by default, and as a power user you'll bump into three protections. Each one looks like it's "in your way" until you understand it's protecting you. Here's the cheat-card; explanations follow. | You see this | What's doing it | Calm response | |---|---|---| | *"App can't be opened - unidentified developer"* | **Gatekeeper** | Verify the source, then allow it in **System Settings β†’ Privacy & Security**. | | *"Operation not permitted"* editing a `/System` file | **SIP** | That file is protected on purpose; you almost never should edit it. Find the right, unprotected place instead. | | *"App wants to access your Camera / Files / Desktop"* | **TCC permission prompts** | Grant or deny per app in **System Settings β†’ Privacy & Security**. | ### Gatekeeper - checking apps before they run **What it actually is.** **Gatekeeper** checks an app's signature and origin the first time you open it, to make sure it's from an identified developer and hasn't been tampered with. (This is what the `_CodeSignature` folder inside every `.app` from Phase 2 is *for*.) If an app fails the check - often because it's from an unidentified developer - Gatekeeper refuses to open it and shows a warning. ⚠️ **Gotcha:** the right move is *not* to reflexively disable security. When you trust the source, open **System Settings β†’ Privacy & Security**, where macOS shows an **"Open Anyway"** button for the just-blocked app - that allows that one app without lowering the wall for everything else. ### SIP - System Integrity Protection **What it actually is.** **SIP** (System Integrity Protection) is a kernel-enforced wall that stops *even the administrator* from modifying protected system locations like `/System`. This is why, in Phase 1, `/System` was "read-only" - SIP is the reason. It exists so that malware (or a careless command) can't corrupt the core OS, even with admin rights. πŸ“ **Terminology.** *SIP* = a protection that puts critical system files and processes off-limits to modification, enforced by the kernel itself rather than ordinary file permissions. It's why `sudo` sometimes *still* says "Operation not permitted." πŸͺ– **War story.** A Linux admin who tries to drop a file into a `/System` path the way they would on a server, hitting `sudo` first, still gets `Operation not permitted` - and assumes the Mac is broken. It isn't; that's SIP doing exactly its job. "Permission denied even with `sudo`" on a Mac usually isn't a permissions bug - it's SIP telling you the thing you're editing is protected on purpose. The fix is almost never "turn SIP off"; it's "put this where it belongs" (your `~/Library`, `/opt/homebrew`, `/usr/local`). ### Permission prompts - apps asking for access **What it actually is.** The "*[App] would like to access your Camera / Microphone / Photos / Desktop folder*" prompts come from a system that requires apps to get your explicit consent before touching sensitive things. (Apple's internal name for it is **TCC** - Transparency, Consent, and Control.) Every grant is recorded, and you can review and revoke them all in **System Settings β†’ Privacy & Security**. **Why this saves you later.** All three walls share one logic: *the system, not just file permissions, decides what's allowed* - Gatekeeper for app origin, SIP for system files, TCC for sensitive data. When one stops you, you'll know which one it is and the calm, correct response. ## Where macOS really differs from Linux You've seen how alike they are - same Unix shape, same shell feel, same service-manager concept. To close, here's a clear-eyed list of where the Mac genuinely goes its own way, so the similarities don't lull you into wrong assumptions: | | macOS | Linux | |---|---|---| | Kernel | XNU (Mach + BSD) | Linux | | Default shell | zsh | usually bash (varies by distro) | | Service manager | `launchd` (`launchctl`) | commonly `systemd` (`systemctl`) | | Package manager | Homebrew (not built in) | built in: `apt`, `dnf`, `pacman`, … | | An app is | a `.app` **bundle** (a folder) | usually files spread across `/usr/bin`, `/etc`, … | | Your home | `/Users/you` | `/home/you` | | Settings format | `.plist` files | mostly plain-text config in `/etc` and dotfiles | | Command flavor | BSD-style (e.g. BSD `ls`, `sed`) | GNU-style (GNU `ls`, `sed`) - flags can differ | πŸ’‘ **Key point.** macOS and Linux are close enough that your Unix instincts transfer, and different enough that the details will occasionally bite. Reach for what's the same (the shell, the filesystem shape, the service-manager concept), and stay alert where the Mac diverges (XNU, `.app` bundles, `.plist`, Homebrew, SIP). The instincts carry; verify the specifics. ## You can see the machine now The Mac isn't a sealed appliance anymore. Under the Dock and the wallpaper is **Darwin**, a real Unix system: a kernel (XNU) managing the hardware, a familiar shell (zsh) over a familiar filesystem, apps that are really folders, settings tucked in `~/Library`, services supervised by `launchd`, and security walls (Gatekeeper, SIP, TCC) standing guard for good reasons. You can open the Terminal and recognize every layer - a Mac you can *reason* about. ## Recap 1. The **Terminal** is a window; **zsh** is the default **shell** inside it. Your startup file is **`~/.zshrc`** (not `~/.bashrc`). 2. **`launchd`** is macOS's **service manager** and first process - the counterpart to Linux's **systemd**; control it with **`launchctl`**, services are defined by `.plist` files. 3. Three security walls: **Gatekeeper** (checks apps before they run), **SIP** (protects `/System` from everyone, even admin), and **permission prompts / TCC** (apps ask before touching sensitive data). Each has a calm, correct response. 4. macOS and Linux are **Unix siblings**: alike in shell, filesystem shape, and service concept; genuinely different in kernel, packaging, app format, and config style. > ⏭️ **Where next.** Go deeper into the parts this guide named: [The Terminal & Shell](/guides/the-terminal-and-shell), > [The Filesystem Explained](/guides/the-filesystem-explained), and the foundation, > [What an Operating System Is](/guides/what-an-operating-system-is). Curious how the *other* side does it? > [Windows for Power Users](/guides/windows-for-power-users) is the companion tour.