The operating system: the manager

Who is in charge

Your laptop right now is running dozens of programs: a browser, a music player, a chat app, and background services you never see. There is one CPU, and inside it only a handful of cores.

A core is one independent instruction-runner inside the CPU chip, each able to execute exactly one stream of instructions, meaning one fetch-decode-execute loop from lesson 1-2, at a time. A typical laptop has 4 to 10 cores and one shared pool of RAM.

Dozens of programs and a handful of cores means somebody has to decide who gets what. That somebody is the operating system, whether Windows, macOS, or Linux.

The OS is itself a program, but a special one that is in charge of all the others, and its always-resident core is called the kernel. Every operations command you will ever type, including kill, top, and docker, is a conversation with this manager, which is why understanding it pays off weekly rather than someday.

The OS has three big jobs:

1. Share the hardware, giving each program turns on the CPU cores and its own slice of RAM.
2. Protect programs from each other, so your browser cannot read your password manager's memory.
3. Provide services such as files, networking, the screen, and the keyboard, so programs ask the OS instead of touching hardware directly.

The rest of this course is those three jobs in detail.

The three rules in practice

Each job shows up in commands and behavior you can observe on your own machine:

The third job is worth pausing on. Programs do not contain code for talking to an SSD, a network card, or a keyboard, and if they did, every program would need updating whenever hardware changed.

Instead a program makes a system call, a request into the kernel, and the kernel's driver deals with the specific device. That boundary is why the same Python script reads a file on a laptop SSD and on a data-center storage array without a line of difference.

A toy model of memory protection

The OS records which addresses each process owns, and every access is checked against that record.

owner = {
    "browser": (0, 99),
    "editor": (100, 199),
}

def check_access(process, address):
    low, high = owner[process]
    if low <= address <= high:
        return "allowed"
    return "BLOCKED: address not owned by " + process

print("browser reads 42:", check_access("browser", 42))
print("browser reads 150:", check_access("browser", 150))
print("editor reads 150:", check_access("editor", 150))

Output

browser reads 42: allowed
browser reads 150: BLOCKED: address not owned by browser
editor reads 150: allowed

Address 150 belongs to the editor's range of 100 to 199, so the browser is blocked and the editor is allowed. The same address is legal or illegal depending only on who is asking.

Real machines run this check in hardware on every single memory access, which is the only way it can be free enough to do billions of times per second. Unit 4 shows what happens to a real program that gets blocked, which is that the OS kills it with a segmentation fault.

The job the OS does not have

Managing memory, scheduling processes, and talking to devices are all operating system jobs. Judging whether your code's logic is correct is not.

The OS manages hardware and protects programs from each other, and it has no idea what your code means. A logic bug that computes the wrong answer is perfectly legal as far as the OS is concerned, and the program keeps its CPU time and its memory.

The OS steps in only when a program breaks a rule about the hardware. Everything about meaning is your problem, which is the division of responsibility this whole course describes.

What happens when a script reads a file

A Python script that reads a file asks the operating system to do it, and the OS talks to the disk.

Programs never touch hardware directly. open() and read() turn into system calls, requests into the kernel, and the kernel's disk driver performs the actual hardware work before handing the bytes back.

The chain looks like this:

your code  ->  open()/read()  ->  system call  ->  kernel driver  ->  SSD

This boundary is the central idea of the whole course. It is why a program needs no knowledge of what kind of disk it is running on, why the OS can enforce file permissions that no program can bypass, and why every measurement of "slow I/O" is really a measurement of time spent inside the kernel.

The name for the core of the OS

The always-loaded core of the operating system, the part that owns the hardware and handles requests from programs, is the kernel.

It stays in memory the whole time the machine is on, owns the hardware, and serves system calls from every other program. The word is the same one used for the core of a seed or a nut.

Linux is technically just this part. Everything else in a distribution, meaning the shell, the package manager, and the desktop, consists of ordinary programs arranged around it, which is why the same kernel powers an Android phone, a web server, and a router.