Metadata Card

• Prerequisites: Can use a computer, can open a browser
• Estimated time: 35 min
• Core difficulty:
• Reading mode: Easy stroll
• Completion marker: Can explain the relationship between programs, files, processes, and memory; knows how to find them in the operating system

Your Progress

You stand before a massive iron door. Two lines are carved into the lintel:

You are about to enter the Developer Workshop. Before you know your tools, know yourself — and your equipment.

The iron door swings open slowly, revealing a brightly lit workshop inside. Tools of all kinds hang on the walls — but before you reach for one, the master of the workshop clears his throat.

"Newcomer, do you actually know what a computer is?"

Your Task

You say "I know" — isn't it just a glowing box? But you can't really tell what's going on inside. Every time you double-click an icon, tens of thousands of parts perform billions of operations in a single second. You open a browser, write a document, play music, close it — a whole city thrives and falls silent on a chip.

This chapter's task is simple: before you set out, know what's inside your equipment. What is a program? What is a file? What is the magic that lets a dozen windows run at once?

You don't need to dive into CPU microarchitecture or memorize memory addresses. You just need to know: when you double-click a .exe or run a command, what actually happens inside?

After reading this chapter, you'll be able to answer: "What is actually running inside this computer right now?"

Chapter Layers

• Required reading: What is a program, what is a file, the difference between a process and a program, the role of memory, how the OS makes multiple programs "run"
• Optional reading: Using ps aux and top to view system processes, free -h to check memory, understanding PID
• Advanced: Zombie processes and signals (SIGTERM/SIGKILL), parent-child process relationships

This chapter will NOT require you to understand

• The difference between threads and processes — processes are enough for now
• Implementation details of virtual memory and paging
• CPU scheduling algorithms or process scheduling strategies

The Breakthrough · Tracing the Origins

Act 1: A Program Is Just a File

"In the workshop there's a good hammer, and a blueprint of a hammer — what's the difference between them?"

The workshop master asks you out of the blue. You pause — no matter how finely drawn the hammer blueprint is, it can't drive a nail. But if you build the design from the blueprint, it becomes a usable hammer.

"It's the same with a program." He hands you a small box. "This is a calculator program. It lies quietly on the hard drive — like a blueprint. But when it's launched, it comes alive in memory."

You sit at a desk in front of a monitor. You click an icon called calc — the calculator pops up.

Looks like magic? Not really.

A calculator is essentially just a file. A long list of machine-readable instructions stored on the hard drive. On Windows it's called calc.exe; on Mac it's hidden inside /Applications/Calculator.app. It lies there silently, like a closed book — you open it, and it starts working.

Cross-platform note: Commands in this chapter mainly target Linux/macOS systems. Windows users are encouraged to use WSL (Windows Subsystem for Linux) for a consistent terminal experience. Install WSL: wsl --install (Admin PowerShell), then restart. If you don't want to install WSL for now, each command block will note the Windows alternative.

Open your terminal (don't be afraid of it — Chapter 2 will explain in detail) and run this:

# On Linux / Mac, check the type of an executable file
file /bin/ls

# Expected output:
# /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (SYSV)

Language: Shell (Bash) How to run: Open terminal, paste and press Enter Expected output: Shows that /bin/ls is an ELF format executable, 64-bit, running on x86-64 architecture Try it: Replace with /bin/bash, /usr/bin/python3, or any executable path

The output means simply that the file /bin/ls doesn't contain text or images — it contains instructions that the machine can execute directly.

Program = a file stored on the hard drive. Its content isn't human-readable text — it's machine instructions.

This is fundamentally no different from a .txt file — both are just strings of bytes on the hard drive. But .txt is read by your text editor and displayed as text; .exe is read by the OS, loaded into memory, and executed instruction by instruction.

So every icon you see on your desktop is backed by one or more files. They lie quietly on the hard drive, waiting for you to open them.

Act 2: Files Are Information

"You just picked up a copper plate from the material shelf, but have you thought about what the marks on that copper plate actually are?"

The workshop master hands you a stone slab. "I've carved three words on this slab: 'Shopping List'. Would you call this a file?"

You nod. "And what if I draw a flower on this slab? Is it still a file?" he asks again. You're not so sure.

"A file isn't about what you carve on it," he pats the slab, "it's about where it's placed, what it's called, and how long it is."

Before we go further, let's confirm the most fundamental thing: files.

You probably already know what a file is: double-click a Word document, you can edit it; double-click a photo, it displays. But if you look a little closer, what really is a file?

File = a name on the hard drive + a sequence of bytes.

The workshop master puts it more directly: a file is the smallest container of information. Every file has a path, a size, a type. The OS manages them through the file system — the file system is a large index on the hard drive, like a library's card catalog, telling you where each book (file) is on which shelf (directory).

You can look at your files in the terminal:

# List all files in the current directory with details
ls -lh

# Sample output (your files will differ):
# -rw-r--r-- 1 steven steven 1.2K Jun 23 10:00 README.md
# drwxr-xr-x 2 steven steven 4.0K Jun 23 09:30 src
#
# First column: file permissions (- for regular file, d for directory)
# Third, fourth columns: file owner and group
# Fifth column: file size
# Last column: file name

Language: Shell (Bash) How to run: Open terminal, type ls -lhExpected output: All files and subdirectories in the current directory, with size, modification time, and permissions Try it: ls -lh / to view the root directory and see system files

To the operating system, everything is a file. Your documents, programs, hardware devices (like keyboard input), process information — all are exposed as "files." This isn't a metaphor; it's the core of Unix design philosophy.

For now, just remember: files are the information units on the hard drive. Programs, documents, pictures, music — they're all files. The only difference is who interprets those bytes.

Act 3: Pull the Handle — A Process Is Born

"Okay, we know a program is a file — a blueprint lying on the hard drive. So how does it come to life?"

The workshop master puts the calculator icon on the table and points at it. "You've got this blueprint. Now tell me, can you use it to drive a nail?"

You shake your head. "Unless... you turn it into a hammer?"

"Exactly!" He slaps the table. "To go from blueprint to hammer, you need one step: pull the handle. Double-click — pull the lever."

You double-click the calculator icon.

The OS does several things:

1. Find the calc.exe file on the hard drive
2. Read its content — that long list of machine instructions
3. Carve out a region in memory
4. Copy the instructions in
5. Prepare a "control panel" to track everything about it (process ID, status, resource usage)
6. Tell the CPU to start executing the first instruction

In that moment, the program becomes a process.

A program is static, a process is dynamic. A closed book is a program; an open book being read is a process.

# View all currently running processes
ps aux

# Expected output (simplified):
# USER       PID  %CPU %MEM    START   TIME COMMAND
# steven    1234   0.1  2.3   10:00   0:02 /usr/bin/gnome-terminal
# steven    5678   0.0  0.5   10:05   0:00 /usr/bin/calc
#
# PID = Process ID, unique number the OS assigns to each process
# %CPU = How much CPU this process is using
# %MEM = How much memory it's using
# COMMAND = What program it's running

Language: Shell (Bash) How to run: Open terminal, type ps aux or ps aux | head -20 to only see the first 20 lines Expected output: List of all running processes, including PID, CPU/memory usage, start time, full command path Try it: Open a program in another window (like Notepad or browser), run ps aux again and see what new line appears

Windows alternative: Get-Process (PowerShell) or open Task Manager (Ctrl+Shift+Esc) → Processes tab

That list of processes you see is everything your computer is doing right now — every window, every background service, every update-checking applet — all recorded in one line.

See that PID? It's the Process ID, the ID card the OS gives to every process. You'll use it a lot in your workshop adventures ahead — to check, kill, watch, and trace.

Act 4: Memory — The Workshop Workbench

"The program has become a process, right? So where does the process live?"

The workshop master takes you to a wall of tools. On the wall are slots of various sizes — screwdrivers, wrenches, pliers, files, all neatly arranged.

"This is my workbench." He gestures around. "Every time I work, I take the tools I need from the cabinets and put them on the table. When I'm done, I put them back. The cabinet is big but inconvenient — you have to walk over and rummage. The tabletop is right at hand, but there's only so much space."

"A process is the same. It needs a workbench."

Remember what we said in Act 3 about "carving out a region in memory"?

Memory is the process's workbench.

Imagine your desktop (a physical desk, not a monitor). When you're doing something, you put the tools you need on the desk. Memory is that desk. The hard drive is your storage cabinet — lots of space but slow; you have to bend over and rummage for things. Memory is the workbench — limited space but fast, everything within reach.

When you open a program, the OS copies its instructions from the hard drive (storage cabinet) into memory (workbench), and then the CPU (your hands) starts fetching instructions one by one to execute.

# View system memory usage
free -h

# Expected output (numbers may vary):
#               total        used        free      shared  buff/cache   available
# Mem:           15Gi       5.2Gi       3.1Gi       512Mi       6.7Gi       9.1Gi
# Swap:         2.0Gi       0.0Gi       2.0Gi
#
# total = total physical memory
# used = being used by processes
# free = completely idle
# available = usable (including reclaimable cache)

Language: Shell (Bash) How to run: Type free -h (-h for human-readable format) Expected output: Total memory, used, free, available, etc. Try it: Open a large program (or many browser tabs) and run again to watch used and available change

Windows alternative: In PowerShell: Get-CimInstance -ClassName Win32_OperatingSystem | Select-Object FreePhysicalMemory,TotalVisibleMemorySize, or Task Manager → Performance → Memory

Two key points here:

1. Memory is finite. With 15GB total memory, opening a few big programs can use it all up. So the OS will "swap" — move temporarily unused data back to the hard drive. When memory runs low, the computer slows down.

2. Each process has its own memory space. Program A can't directly access program B's memory. This is a safety mechanism enforced by the OS — if one program crashes, it won't take others down with it.

This is why taking a photo takes a few MB, but opening Photoshop eats several GB — the program itself lives in memory, and the data it operates on also lives in memory.

Act 5: Once It's Running

"Good, now you've pulled a few levers — a few windows have lit up on the dashboard: Material Measuring Tool, Finished Products Catalog, Workshop Console. They've all become processes. So let me ask you: are these processes all working?"

The workshop master smiles and holds out both hands. "I'm drawing a circle with my left hand and a square with my right — do you think I'm drawing them well?"

He moves both hands and the two shapes come out crooked. "Much worse than doing them one at a time, right?" He puts his left hand down and draws a perfect circle with his right. "Because my brain can only focus on one thing at a time. Your computer is the same — except it switches so fast, you think it's doing everything at once."

You open a browser: five tabs. You open the terminal. You open VS Code. And WeChat.

Now open Task Manager (Windows: Ctrl+Shift+Esc, Mac: Activity Monitor, Linux: htop or top), and you see a long list.

Windows friends: top is the terminal version of Task Manager. In PowerShell, use Get-Process | Sort-Object CPU -Descending | Select-Object -First 10 to see the top CPU-consuming processes.

Every entry is a process. Five browser tabs might be five processes (modern browsers isolate each tab into its own process to prevent one crash from taking everything down). Plus terminal, editor, chat tools, system services...

Your computer is running dozens or even hundreds of processes.

But they're not all executing at once — the OS is "putting on a show."

Your CPU might have 4 or 8 cores, and each core can execute only one task at a time. But the OS slices the CPU time into tiny pieces (time slices, about tens of milliseconds) and rapidly switches between all ready processes. Switch to process A for 30ms, switch to process B for 30ms, switch back...

Because the switching is so fast, what you perceive is "running." This is called concurrency.

# Real-time view of running processes (like Task Manager)
top -o %CPU

# Press q to quit

Language: Shell (Bash) How to run: Type top or htop (some systems need sudo apt install htop first) Expected output: Real-time updating process list, default sorted by CPU usage, press q to quit Try it: Run yes > /dev/null & to create a CPU-hogging process, observe it in top, then kill it with kill %1 (ask before using)

Here you can visually see: which processes are using CPU (instructions being executed), which are using memory, which consumed the most I/O. These are real system metrics.

Common Pitfalls

Trap 1: Task Manager closes it, but it's still running in the background

You delete a program or close a window, thinking it's gone. But some programs (especially installers and background services) continue running in the background as daemons.

That pile of systemd, cron, dbus-daemon you see in ps aux — they don't have a window like the calculator, but they're always there.

What to do: If you want to completely shut down a background process, use kill <PID> or pkill <process_name>.

Trap 2: A process is consuming a full CPU core

Your computer's fan is spinning like crazy, but you only see one process running hard. This isn't necessarily a virus — more likely the program has an infinite loop.

In top, press P (capital P) to sort by CPU, find the PID, then kill it with kill <PID>. If it won't die, add -9:

# First find the PID, then
kill -9 12345 # Replace 12345 with the actual process ID

Wait — kill -9 is violent. It won't let the process clean up temp files or close network connections. Use kill <PID> whenever possible, only use -9 if it really won't die.

Advanced Adventure

Processes Are More Than Just Calculators

You'll encounter these concepts later. For now, just know they exist:

• Parent-child processes: A process can create child processes. When you run ls in the terminal, the terminal process creates a child process to execute ls. When the child finishes, the terminal regains control.
• Zombie process: A child process has ended, but the parent hasn't "confirmed" its exit state. The process record is stuck there, becoming a zombie — in ps aux, its status shows as Z.
• Signals: kill isn't just about "killing" processes; it's about sending signals. kill <PID> sends SIGTERM (request graceful termination), kill -9 sends SIGKILL (force kill, cannot be blocked). Other signals include SIGHUP (hang up), SIGINT (triggered by Ctrl+C).

You don't need to dive into these now. Just know they exist — when you encounter them, you'll at least recognize the names.

Curious Experiment

The following isn't required for the main path. Feel free to try when curious, but skipping it won't affect your progress to the next chapter.

File deleted but space not freed — who's still using it?

You deleted a large file, but disk space hasn't been freed.

Why: A process might still be using that file. In the OS, deleting a file only removes the name; the actual data isn't truly freed until the last process that has it open closes it.

# Find files opened by processes that have been deleted
lsof | grep deleted

# If you don't have lsof, use /proc to inspect
ls -la /proc/*/fd/ 2>/dev/null | grep deleted

Language: Shell (Bash) How to run: lsof | grep deleted (install lsof first with sudo apt install lsof on Linux, or use built-in on macOS) Expected output: Shows files that have been deleted but are still held open by a process, along with their PID

Who's listening on my port?

# Check which processes are listening on port 80 (HTTP service)
lsof -i :80

If there's no output, no web service is running.

Why be curious? lsof and /proc are the ultimate embodiment of the Unix philosophy of "everything is a file" — even network ports and process file handles are managed as files.

Common Pitfalls

True Story: Where did I delete things?

Once I wrote a script that output a bunch of files with ls and I wanted to delete the old ones. I typed rm -rf ./*.log — but my current directory was / (the root directory).

Fortunately, modern systems have protection and gave me:

rm: it is dangerous to operate recursively on '/'

But if you add --no-preserve-root, the system will actually do it.

Lesson: Before running rm, mv, or overwriting files, use echo or ls to first see what you'll be touching. Preview first, then execute.

Final Challenge

• Warm-up (5 min, required)

1. Open terminal, run ps aux | wc -l to see how many processes are running on your computer. Normal systems typically have 100-300.
2. Run free -h to see total memory, how much is used, and how much is left.
3. Run ls -la ~ to see what files are in your user directory (especially hidden files, starting with .).

• Challenge (30 min, optional)

1. Open a browser with 5 tabs. Run ps aux | grep chrome (or firefox or safari) to see how many processes there are. Modern browsers typically have one process per tab.
2. Run a test with an infinite loop:

# In one terminal, run:
python3 -c "while True: pass" &
# This creates a Python process that loops forever.

# In a second terminal:
top -o %CPU -p $(pgrep -f "while True")

# To kill the test:
kill %1

3. Use ps aux | grep -E "chrome|firefox|safari" to check your browser's process count.

Checklist

• [ ] You can explain in one sentence "the difference between a program and a process."
• [ ] You know what a Process ID (PID) is and where to find it.
• [ ] You can open a terminal and use ps aux, free -h, top to check system status.
• [ ] You can explain why a computer can "run" many programs — time-slice switching.
• [ ] You know that files are collections of bytes on the hard drive, managed by the file system.

Common Sticking Points

"I ran free and it says 80% used — is there not enough memory?" — Not necessarily. Linux uses free memory for caching (cache/buffers) and releases it to programs when needed. available is the truly usable amount; what free shows is absolutely idle, which is usually very small.

"Why is there so much junk I don't understand in ps aux?" — Many are the OS's own daemons. Just focus on the PID and program names you recognize (like bash, chrome, code). As you read more, you'll gradually get to know the system processes too.

"What's the difference between a process and a thread?" — This chapter kindly avoids answering that question. For now, just know processes exist. A thread is a "lightweight subtask" within a process — multiple threads can share the same memory space. Master processes first; threads will be thoroughly covered in Vol 3.

No Need to Understand Now

• Exactly how the CPU executes instructions (pipeline, out-of-order execution, branch prediction) — covered in Vol 3
• Details of virtual memory and memory paging — same
• Low-level file system implementations (ext4, NTFS, Btrfs differences)
• Process scheduling algorithms (CFS, time slice tuning)
• What threads are — this chapter only covers the process level

Traveler's Notes

A program is a file stored on the hard drive, static and unmoving; A process is a running program, dynamic, with an ID number, using memory and CPU; A file is the basic unit of information — everything is a file; Memory is the process's workbench — limited, fast, independently isolated; The OS switches between CPU cores so fast you perceive it as "running."

Six words: Program → Process → Running

→ Preview of Next Stop

Now you know what's inside your computer — but you don't know how to use it yet. Your tools are quietly waiting in the terminal. Next chapter, we'll open the gates to the terminal and learn the first words of communicating with your computer. Remember what the workshop master said — "Pulling the handle"? That handle is called the Enter key.

Wait — first you need to learn to type.