💻 Operating System Preparation for Development

Before you install a single framework, your operating system needs to be ready for the job. A well-prepared machine — updated, with a package manager, a good terminal, and clean environment variables — saves you from a hundred small, mysterious failures later. This lesson gets Windows, macOS, or Linux into fighting shape.

🎯 Learning Objectives

By the end of this lesson, you will be able to:

Explain why OS setup is the foundation of a smooth workflow
Update your system and install a package manager (Chocolatey/winget, Homebrew, or apt)
Set up a Windows machine for development with WSL and a modern terminal
Configure PATH and environment variables correctly on any OS
Generate an SSH key and apply basic security good practice
Diagnose the most common setup problems (PATH, permissions, dependencies)

Estimated Time: 30–40 minutes • Difficulty: Beginner

Hands-on: Fully prepare your own machine — package manager, terminal, and an SSH key — following the steps for your OS.

In This Lesson

Why Setup Matters

Configuring your OS is like prepping a kitchen before cooking. When the knives are sharp, the counters clear, and every ingredient is within reach, the meal comes together smoothly. When the kitchen is a mess, even a simple dish becomes a fight. A well-prepared development machine gives you four quiet superpowers:

Efficiency — the tools you need are one command away
Consistency — projects behave predictably instead of "working on my machine only"
Compatibility — tools cooperate instead of colliding
Performance — resources go to your work, not to clutter

graph TD A[OS Preparation] --> B[System updates] A --> C[Package manager] A --> D[Good terminal] A --> E[Environment config] B --> B1[Security patches] C --> C1[One-command installs] D --> D1[Fast, pleasant workflow] E --> E1[Tools found on PATH] E --> E2[SSH keys for Git]

💡 One-time cost, lasting payoff: The hour you spend here is repaid every single day you code afterward. Skipping it doesn't save time — it defers the cost to future-you, usually at the worst possible moment.

Three Platforms, Three Personalities

Web development happens across all three major operating systems. Each can absolutely get the job done; they just differ in what comes easy and what needs a workaround.

OS	Strengths	Watch-outs	Key setup step
Windows	Ubiquitous, superb IDE support	Some Unix tools need help	Install WSL for a real Linux shell
macOS	Unix-based, polished dev experience	Hardware cost	Homebrew + Xcode command line tools
Linux	Open, native web-server environment	Steeper learning curve	Install build tools & dev libraries

A helpful frame: they're three vehicles. Windows is a versatile truck, macOS a refined sports car, Linux a custom-built hot rod. All reach the destination — the ride just feels different. Notably, macOS and Linux are both Unix-like, so their commands often match; Windows closes that gap with WSL.

System Updates First

Before installing anything, bring your OS current. Updates deliver security patches and fix compatibility issues that would otherwise bite you halfway through an install.

Windows

Open Settings → Windows Update and install everything, or from an admin PowerShell:

# Check for and install updates (needs the PSWindowsUpdate module)
Get-WindowsUpdate
Install-WindowsUpdate -AcceptAll

macOS

softwareupdate -l      # list available updates
softwareupdate -ia     # install all available updates

Linux (Ubuntu/Debian)

sudo apt update        # refresh the package lists
sudo apt upgrade -y    # install available upgrades

✅ Like an oil change

Keeping the system updated is routine maintenance — cheap, quick, and it heads off problems before they start. Make it the first thing you do on any new machine.

Package Managers

A package manager installs and updates software from the command line — no hunting for download pages, no clicking through installers, and updates for everything with one command. It's the single biggest upgrade to your workflow in this whole lesson.

📖 Definition

A package manager is a tool that downloads, installs, updates, and removes software (and its dependencies) from a curated registry, using simple commands like install and upgrade.

Windows — Chocolatey or winget

winget now ships with Windows, so it's the easiest start. Chocolatey has a larger catalog. Installing Git, Node.js, and VS Code:

# winget (built in) — run in a normal PowerShell
winget install Git.Git OpenJS.NodeJS Microsoft.VisualStudioCode

# — or — Chocolatey, after installing choco in an admin PowerShell
choco install git nodejs vscode -y

macOS — Homebrew

# Install Homebrew (the de-facto macOS package manager)
/bin/bash -c "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

# Install the essentials
brew install git node
brew install --cask visual-studio-code

Linux — apt (Ubuntu/Debian)

For Node.js, prefer the NodeSource repository or nvm over the older apt package, which often lags versions:

sudo apt update
sudo apt install git -y

# Node.js LTS via nvm (recommended — easy version switching)
curl -o- https://raw.githubusercontent.com/nvm-sh/nvm/v0.40.1/install.sh | bash
# restart your shell, then:
nvm install --lts

🛒 Your personal shopper: A package manager is like a shopper who knows exactly where each item lives, verifies its quality, and handles the whole install for you — then keeps everything up to date on request.

Windows: WSL & Terminal

Most web tooling grew up on Unix, so Windows developers get the smoothest ride by running a Linux environment inside Windows via the Windows Subsystem for Linux (WSL). You get native Linux tools without leaving Windows or dual-booting.

flowchart LR A[Windows 11] --> B[WSL 2] B --> C[Ubuntu shell] C --> D[Native Linux tools] A --> E[Windows Terminal] E --> C A --> F[VS Code] F -->|Remote - WSL| C

Install WSL with Ubuntu

# One command in an admin PowerShell installs WSL 2 + Ubuntu
wsl --install -d Ubuntu
# Reboot when prompted, then set a Linux username and password

A modern terminal

Windows Terminal gives you tabs, splits, and easy access to PowerShell and your Ubuntu shell in one window. On recent Windows it's preinstalled; otherwise:

winget install Microsoft.WindowsTerminal

💡 Do your project work inside WSL

Keep your code in the Linux filesystem (e.g. ~/projects), not on the Windows C: drive, and open it with VS Code's Remote – WSL extension. File watching and install speeds are dramatically better this way. macOS and Linux users are already in a Unix shell, so they skip this step entirely.

Environment Variables & PATH

Environment variables are named values your OS and tools read at runtime. The most important one is PATH — the list of folders your shell searches when you type a command. If a tool is installed but "not found," a broken PATH is the usual culprit.

Figure 1 — When you type a command, the shell walks the folders in PATH from first to last and runs the first matching executable it finds. "Command not found" means no folder on PATH contained it.

Windows

Use the GUI (search "Environment Variables" → Edit the system environment variables), or PowerShell for a persistent value:

# Set a persistent machine-level variable
[System.Environment]::SetEnvironmentVariable('NODE_ENV', 'development', 'User')
# Open a new terminal for it to take effect

macOS / Linux

Add exports to your shell config (~/.zshrc on modern macOS, ~/.bashrc on many Linux systems):

# Append to ~/.zshrc, then reload
echo 'export NODE_ENV=development' >> ~/.zshrc
echo 'export PATH="$HOME/.local/bin:$PATH"' >> ~/.zshrc
source ~/.zshrc        # apply changes to the current session

📖 Variables you'll meet often

PATH — folders searched for executables. NODE_ENV — development or production. HOME — your home directory. Frameworks also read secrets from a project's .env file — never commit that file to Git.

Security & SSH Keys

A development machine deserves basic hygiene. Two habits matter most from day one: don't run everything with admin/root rights, and use SSH keys instead of passwords for Git and servers.

Generate an SSH key

An SSH key is a pair of files: a private key you guard, and a public key you hand out (e.g. to GitHub). The same command works on all three platforms:

# Create a modern ed25519 key pair
ssh-keygen -t ed25519 -C "your_email@example.com"

# Start the agent and add your key (macOS/Linux/WSL)
eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519

# Copy the PUBLIC key to paste into GitHub → Settings → SSH keys
cat ~/.ssh/id_ed25519.pub

⚠️ Guard the private key

Share only the .pub file. The private key (no extension) never leaves your machine and never goes into a repository. Anyone who gets it can act as you. Also prefer a per-user tool install over admin/root wherever you can — least privilege limits the blast radius of mistakes.

Credential managers

Let your OS store tokens and passwords securely rather than typing them repeatedly: Windows Credential Manager, macOS Keychain, or GNOME Keyring on Linux. Git can be configured to use them so you authenticate once.

Common issues & fixes

Symptom	Likely cause	Fix
"command not found" after install	Tool's folder isn't on `PATH`	Add it to PATH; open a fresh terminal
"Permission denied" during install	Insufficient rights or wrong scope	Use sudo/admin, or install at user level
Conflicting dependency versions	Two projects need different versions	Isolate with nvm, venv, or Docker
Slow installs / file watching (Windows)	Code living on the Windows drive under WSL	Move the project into the Linux filesystem

Hands-on Exercise

🏋️ Prepare Your Machine

Objective: Get your own computer genuinely ready for the rest of the course.

Instructions (do the steps for your OS):

Update your operating system fully and reboot if asked.
Install a package manager (winget/Chocolatey, Homebrew, or confirm apt) and use it to install Git.
Windows only: install WSL with Ubuntu and open it once to set your username.
Generate an SSH key and print the public key with cat ~/.ssh/id_ed25519.pub.
Verify Git is on your PATH by running git --version in a new terminal.

💡 Hint

If git --version fails right after installing, the fix is almost always to close and reopen your terminal so it re-reads PATH. Still failing? Confirm the install location is actually listed in your PATH.

✅ What success looks like

git --version prints a version number in a fresh terminal. cat ~/.ssh/id_ed25519.pub prints a line starting with ssh-ed25519. On Windows, wsl -l -v lists Ubuntu at version 2. You now have a clean base to install the rest of your tools onto.

🎯 Quick Quiz

Question 1: You installed a tool, but typing its command gives "command not found." What's the most likely cause?

Question 2: Why do Windows developers commonly install WSL?

Question 3: After running ssh-keygen, which file should you paste into GitHub?

Summary & Quiz

🎉 Key Takeaways

A prepared OS buys you efficiency, consistency, compatibility, and performance — a one-time cost with a daily payoff.
Update first, then install a package manager so future installs are one command.
On Windows, WSL plus a modern terminal gives you the Unix tooling most of the web is built on.
PATH is the folder list your shell searches; most "command not found" errors trace back to it.
Use SSH keys (share only the .pub), a credential manager, and least-privilege habits from day one.

📚 Further Reading

🚀 What's Next?

Your operating system is ready and armed with a package manager. Next we'll put it to work in Essential Development Tools Installation — setting up VS Code, Node.js, Git, and the rest of the everyday toolkit you'll live in for the rest of the course.

🎉 Foundation laid!

Your machine is clean, updated, and ready. Every tool you install from here will feel effortless.