Growing Up With a Defence Geek Dad

My dad is the kind of guy who sees a fighter jet fly in a movie and doesn't just go "cool plane"—he goes "that's an F-35 Lightning II, or thats the B2 stealth bomber, you can tell by the way it's flying in that holding pattern, and speaking of radar did you know—" and then I'm stuck for forty-five minutes learning about how radar systems work against my will.

But here's the thing: it worked. Some kids learned to fish from their dads. I learned how to explain complex systems by being trapped in the house with a man who treats every red light as an opportunity to lecture about F12 jets.

And among the many things I absorbed through involuntary osmosis was this: radar systems are just asking questions and listening for echoes.

Military radars? Same thing, just with more expensive hardware and cooler acronyms. They send out high-energy pulses, those pulses travel, hit something (enemy aircraft, weather balloon, probably aliens), and bounce back. The time between "hello?" and "HELLO BACK" tells you everything—distance, speed, direction, whether you should be scared.

Simple concept.

Now here's the part where I trick you into learning about CPUs.

THE ILLUSION OF THE PERFECT MACHINE

Your computer is lying to you.

Actually, that's not fair. Your computer isn't lying, you're just choosing not to look behind the curtain, and the computer is totally fine with that arrangement. It's like a magician who would rather you be amazed than explained his tricks.

You open thirty Chrome tabs. You fire up a VM. You've got Spotify streaming, Slack notifying, Discord screaming, and somewhere in the background, your antivirus is having a full-blown existential crisis about a cookie it just found, yet, everything works. Smooth. Seamless. Like magic.

But under the hood? Wahala! (a nigerian exclamation that signifies Chaos) .

Because here's the truth that sounds fake but isn't: your CPU, even that fancy one with sixteen cores and RGB lighting, can only execute one instruction at a time per core. Not two. Not three. ONE.

So how does everything run at once?

It doesn't.

It just switches between things so fast that your slow human brain perceives it as simultaneous. Like a film projector showing Jujutsu Kaisen's twenty-four still frames per second to create the illusion of motion. Like a radar sweeping across the sky, painting a complete picture one Jet at a time.

The CPU is a pathological liar, and we love it for that.

VIRTUALIZATION

When tech people say "virtualization," we usually mean Docker containers or VMware or that time you tried to run Linux on your Windows and it went just -

But the original virtualization? The one that started it all?

Your CPU was gaslighting programs before gaslighting was a word.

Every process running on your computer lives in a beautiful simulation where:

• They own all the memory (they don't—they're in a sandbox with walls they can't see)

• They have uninterrupted CPU access (they get kicked out thousands of times per second)

• They're the only program that matters (just like your girlfriend)

This is the illusion of continuity. Without it, every program would have an existential crisis the moment it realized it's being interrupted 1,000 times per second to make room for Slack's annoying notification about a GIF Sade from Product posted.

PROCESSES: The Beautiful Lies We Tell Programs

A process is just a running program. But more importantly? It's a protected delusion.

When you double-click that icon, the operating system doesn't just pat it on the head and say "go compute, baby." It creates a Process Control Block (PCB) —think of it as a government file on your program, tracking everything:

• Process ID (its legal name)

• Program Counter (where it left off reading instructions, like a bookmark)

• CPU Registers (its scratch paper—numbers it was juggling)

• Memory Limits (the cage it's allowed to play in)

• Open Files (what it's touching)

• Process State (its current mood, which changes constantly)

And moods? Oh, processes have moods.

THE EMOTIONAL ROLLERCOASTER OF EXISTENCE

Every process cycles through emotional states like a teenager:

    BORN -----> READY -----> RUNNING -----> GONE
                  |             |
                  |             |
                  +---> WAITING +

• BORN (NEW) : Just created. OS is doing paperwork. Not doing anything yet.

• READY: Alive. Awake. Sitting on the bench, waiting for the coach (scheduler) to put it in the game.

• RUNNING: Actually executing instructions. Living its best life. THIS is what it was made for.

• WAITING: Blocked on I/O. Waiting for the hard drive. Waiting for the network. Waiting for YOU to type something. Patience is not its virtue.

• GONE (TERMINATED) : Dead but not cleaned up yet. In computing, we call this "zombie state." Yes, really. Yes, it's as creepy as it sounds.

THE SCHEDULER: Air Traffic Controller of Your CPU

Remember the radar?

A radar doesn't stare at one spot forever. It sweeps. It scans. It builds a picture of the sky by looking everywhere, just not all at once.

The CPU scheduler is exactly the same thing, except instead of tracking planes, it's tracking which processes get to run.

It asks three questions, constantly, forever, until the heat death of the universe or you close your laptop:

1. Who runs next? (Selection)

2. How long do they run? (Duration)

3. What happens when time's up? (Preemption—fancy word for "your turn is over, get out")

And just like radar systems evolved from spinning dishes to phased arrays, schedulers evolved from simple algorithms to the beautiful, complicated beasts running your machine right now.

SCHEDULING ALGORITHMS: A History of Trying to Be Fair

First Come First Served (FCFS) — The Resturant Approach

Processes line up. First one in gets the CPU until it's done.

Fair? Sure. Efficient? Absolutely not.

Shortest Job First (SJF) — The Idealist's Dream

Run the quickest tasks first. Maximize throughput. Make everyone happy.

Problem? You have to know how long a task will take before it runs.

Round Robin (RR) — The Time-Share

Give everyone a fixed time slice. 10 milliseconds for you. 10 milliseconds for you. 10 milliseconds for EVERYONE.

This is what creates the illusion. Everyone gets a tiny turn, in a circle, forever. Your video player gets 10ms, then Chrome gets 10ms, then Spotify gets 10ms, then back to your video player before you even notice it left.

The time slice (called a quantum, because computer scientists love making simple things sound fancy) is critical:

• Too big? It's just First Come First Serve with extra steps. Programs run forever, others wait.

• Too small? You spend all your time switching between processes instead of actually doing anything. It's like a party where guests arrive, say hello, and immediately leave—no actual party happens.

Priority Scheduling — The Class System

Some processes are more equal than others. I really thought that only applied to man and animals but -

System processes or lets call them your applications. Your video game > your antivirus scan. The thing handling your keystrokes > the thing rendering a PDF you opened three hours ago and forgot about.

This makes sense—humans are impatient, so interactive stuff gets priority. But there's a con to it : starvation. Low-priority processes can wait forever, watching everyone else get CPU time while they sit in the corner, quietly weeping.

THE REAL WORLD: Schedulers Are Hybrid Nightmares

Real schedulers—Linux's Completely Fair Scheduler, Windows' NT kernel—don't pick one algorithm. They use multi-level queues:

[TOUCHING THE SCREEN RIGHT NOW] << HIGHEST PRIORITY
         [VISIBLE APPLICATIONS] << HIGH
               [BACKGROUND TASKS] << MEDIUM
                [BATCH PROCESSING] << LOW
                   [IDLE STUFF] << "whenever, man"

Your keystrokes jump the line because waiting for a human is bad for business. Background compilation? It can wait 200 milliseconds. You won't notice. The render farm running overnight? It runs when NOTHING else wants the CPU.

This is tiered priority, and it's how your laptop stays responsive while also doing seventeen other things you forgot about.

CONTEXT SWITCHING: The Actual Magic Trick

This is where the illusion happens. This is the thing that makes it all work.

When the scheduler decides it's time for Process A to stop and Process B to run:

1. FREEZE — Process A is mid-instruction. Stop. Right there. Don't move.

2. SAVE — Take everything Process A was doing (registers, program counter, scratch paper) and stuff it into its PCB. Photograph the moment.

3. LOAD — Find Process B's PCB. Pull out its photograph. See what it was doing last time it ran.

4. RESUME — Process B wakes up exactly where it left off, none the wiser that it's been asleep for 50 milliseconds.

This happens in microseconds. A 10ms time slice means 100 context switches per second. Your computer does this thousands of times while you blink once.

Process B has no idea it was frozen. It thinks it's been running continuously. The illusion holds.

---

WHAT THIS MEANS FOR YOU, CODER PERSON

When you write:

while True:
    data = network.recv()  # This blocks
    process(data)

That network.recv() call puts your process into the WAITING state. Your process is literally asleep, consuming zero CPU, waiting for bytes to arrive.

The scheduler sees this and thinks, "Oh, you're sleeping? Cool, I'm running something else." Then, when data arrives, your process wakes up and gets back in line.

This is efficiency. This is why your server can handle thousands of connections—most of them are just WAITING, not RUNNING.

When you write CPU-bound loops without yielding? You're that person at the buffet who won't stop talking. Everyone else is waiting. The scheduler can't help you if you refuse to share.

BACK TO RADAR: Closing the Loop

Remember the radar?

A radar system:

• Sends a pulse

• Listens for returns

• Processes what it hears

• Moves to the next azimuth

• Repeats forever

A CPU scheduler:

• Gives a process CPU time

• Listens for interrupts (I/O, timer)

• Processes the next decision

• Switches to the next process

• Repeats forever

Both are resource managers managing limited attention. The radar can't stare at one spot forever—it needs to sweep the sky. The CPU can't run one process forever—it needs to sweep the run queue.

Both create complete pictures from discrete samples. The radar builds a picture of the sky. The CPU builds the illusion of simultaneous execution.

Neither one actually does what we perceive. Both are magnificent liars.

THE REAL ILLUSION

Here's the thing that keeps me up at night:

The deepest magic isn't that CPUs switch between processes. It's not even that they do it fast enough to fool us.

The deepest magic is that entire generations of programmers have written millions of lines of code without thinking about this, and it mostly works.

When your .NET event loop handles ten thousand connections? It's not magic—it's processes (or threads) taking turns, sleeping when they wait, waking when data arrives.

When your laptop stays responsive while compiling a massive project? It's not luck—it's the scheduler prioritizing your keystrokes over the compiler, because waiting for a human is the one thing computers refuse to do.

The illusion of a perfect machine isn't really a lie anymore.

It's a collaborative hallucination. We all agree to believe in it so we can get work done. The OS maintains the simulation. The CPU runs the numbers. The processes live in blissful ignorance.

And somewhere, my dad is happy I finally found a way to connect fighter jets to computer science.