Before discussing schedulers, memory, filesystems, or containers, we need to understand how Linux actually executes code.

At the core of Linux lies a strict execution model built around two separate worlds:

• User Space

• Kernel Space

This separation is not an implementation detail.

It is one of the most important design decisions in modern operating systems.

Understanding this boundary explains why Linux behaves the way it does — especially when things go wrong.

User space is where applications live:

• shells

• browsers

• databases

• system services

• scripts

• containers

Code running in user space is unprivileged.

It cannot:

• access hardware directly

• touch kernel memory

• control the CPU

• bypass security checks

If a user-space process crashes, the system survives.

This is intentional.

Kernel space is where the Linux kernel executes.

Code here has:

• full access to hardware

• unrestricted memory access

• control over CPU scheduling

• authority to allow or deny operations

A bug in kernel space can crash the entire system.

That’s why kernel code is:

• tightly controlled

• heavily audited

• isolated from user applications

The kernel is powerful — and dangerous.

Early operating systems often ran everything in a single execution space.

The result:

• unstable systems

• crashes that took down the whole machine

• security nightmares

Linux enforces separation to guarantee:

• stability — application failures stay isolated

• security — users can’t bypass permissions

• control — the kernel arbitrates all access to resources

This is why Linux can safely run thousands of processes simultaneously.

User-space programs cannot jump into kernel space freely.

There is only one legal gateway:

System calls are controlled entry points into the kernel.

Examples:

• read()

• write()

• open()

• fork()

• execve()

• mmap()

Whenever a program needs:

• disk access

• memory allocation

• network I/O

• process creation

it asks the kernel via a system call.

The kernel then decides:

• Is this operation allowed?

• Are the resources available?

• Does this violate isolation or security rules?

When you run:

cat file.txt

What actually happens:

1. cat runs in user space

2. It issues an open() system call

3. The kernel checks permissions

4. The filesystem driver reads data

5. Data is copied into user-space memory

6. cat prints the result

At no point does cat touch the disk directly.

The kernel is always in control.

Modern CPUs support multiple execution modes.

Linux primarily uses:

• user mode

• kernel mode

When a system call occurs:

• the CPU switches from user mode to kernel mode

• executes kernel code

• then safely returns to user mode

This transition is fast — but not free.

That’s why excessive system calls can impact performance.

Once you understand the execution model, many Linux behaviors become obvious:

• why aliases don’t work in scripts

• why containers can’t access arbitrary devices

• why permissions behave strictly

• why performance bottlenecks appear in I/O-heavy workloads

• why kernel bugs are catastrophic

Linux isn’t being “difficult”.

It’s enforcing boundaries.

Keep this model in mind throughout the book:

User space requests — Kernel space decides — Hardware executes

If something behaves unexpectedly, the explanation is almost always found at the boundary.

In the next sections, we’ll build on this model to explore:

• process creation and scheduling

• virtual memory and isolation

• filesystems and I/O paths

• kernel interfaces like /proc and /sys

Everything relies on this execution split.

The Linux kernel is not magic.

It is discipline, separation, and control — enforced thousands of times per second.

Once you understand the execution model, Linux stops feeling unpredictable

and starts behaving exactly as designed.