The Recipe vs. The Cooking
Think of a computer program — like ls, nginx, or python app.py stored on disk — as a cookbook recipe. It's a static list of instructions sitting on a shelf, doing nothing. It consumes no electricity, occupies no kitchen counter, and produces no food.
A process is what happens when the computer actively "cooks" that recipe. It's the live execution of a program, loaded into memory, with its own private workspace: a slice of RAM for data, a set of CPU registers tracking the current instruction, open file handles, and a unique identity number called a PID (Process ID). Two chefs can cook from the same recipe simultaneously — similarly, you can run two instances of python app.py at the same time, and each becomes a separate process with its own PID and its own memory.
In Linux, almost everything running is a process. The kernel itself spawns the very first process (PID 1, typically systemd or init), and every other process on the system descends from it in a tree. Understanding how processes are born, what states they move through, and how they die is foundational for debugging hangs, diagnosing high load, and writing reliable automation.
A key distinction worth internalizing early: a program is a file on disk (passive); a process is that program in execution (active). The same program file can give rise to many simultaneous processes, each completely independent.