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:

$ 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 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 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:

📝 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:

$ 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.

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:

💡 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, The Filesystem Explained, and the foundation, What an Operating System Is. Curious how the other side does it? Windows for Power Users is the companion tour.

← Phase 2: Apps, Bundles & Where Things Live · Guide overview