Where Does the Linux Kernel Actually End?

"Linux is not an operating system. It is a kernel."

You've probably seen that phrase everywhere—in forum arguments, documentation, pedantic blog comments. It's technically correct, which as we all know is the best kind of correct. But George from Core Dumped asks the obvious follow-up that almost nobody bothers answering: okay, so where exactly does the kernel end and everything else begin?

The answer involves tracing the entire process tree back to a single point of origin, and it reveals something most Linux users don't realize about what they're actually running.

The Process Tree Goes All the Way Down (Until It Doesn't)

Every process on a Unix-like system is created by another process. On Linux, this happens through a clone-then-replace dance: a process clones itself, then the clone replaces its program. Windows does it differently—a process just asks the OS to create a new one—but the result is the same. User processes spawn user processes.

Which means every process has a parent. And that parent has a parent. And if you follow that chain backward far enough, you hit a wall: one process that has no parent. Process ID 1. The init process.

Run the process tree command on any Linux system and you'll see it—the root of everything, the ancestor of every shell, every desktop environment component, every background service. But init itself wasn't created by another user process. It can't have been, or it wouldn't be the root.

"Believe it or not, this is where our answer can be found," George explains, "because in some way everything that happens before this process is considered part of the kernel."

Kernel Space vs. User Space: The Boundary That Matters

The kernel sits directly on top of hardware. It's the layer that actually manipulates GPUs, network cards, storage devices—all the tedious, risky stuff that would break constantly if random applications could touch it directly. So CPUs enforce two execution modes: privileged mode, where you can do basically anything, and restricted mode, where you're limited to safe operations that don't touch hardware.

Kernel code runs in privileged mode. Everything else runs in restricted mode, which we call user space. When your application needs hardware access—to write to disk, display something on screen, send a network packet—it makes a system call asking the kernel to do it.

This boundary is clean and well-defined. But here's where it gets interesting: a huge portion of what people think of as "the operating system" actually runs in user space.

Your desktop environment? User space. The display server rendering your windows? User space. The network manager? User space. The package manager? User space. As George puts it: "A huge portion of what we casually call the operating system is actually a collection of user space processes."

The kernel doesn't know what a window is. It doesn't understand buttons, widgets, dark mode, or any of the desktop abstractions we interact with daily. "What you see on the screen exists because user space software renders pixels into buffers and then requests that the kernel instruct the GPU to display them. To the kernel, it's just memory and hardware access."

Init: The Kernel's One Gift to User Space

During boot, after the kernel loads its subsystems and prepares to hand off control, it does exactly one thing for user space: it hard-codes a routine to find and execute a file called init. The kernel looks in a specific priority order through several paths. If you check the Linux kernel source in init/main.c, you'll find a function called kernel_init that eventually calls kernel_execve—not the system call version, since this code already runs in kernel mode, but a direct routine that loads the new process.

If the kernel can't find init in any of the expected paths, it panics. The boot process fails completely.

But here's the thing: "This is as far as kernel developers care about user space software," George notes. "They hard-code the routine that launches the very first user process, but they do not care what that process actually does afterward. In fact, this init program is nowhere to be found in the Linux kernel source code. It is not part of the kernel."

From that single process, everything else emerges. Init spawns the network manager, logging services, the display server, the desktop environment—all the processes that make Ubuntu feel like Ubuntu or Fedora feel like Fedora. The kernel provides the foundation, but init builds the house.

This explains why there's no "default" Linux. The kernel itself is useless without user space programs. Linux developers ship a kernel. Distribution maintainers decide what runs on top of it.

The Symbolic Link That Explains Everything

Modern systems don't usually place the actual init executable where the kernel expects it. Instead, they put a symbolic link there—a shortcut pointing to the real program, which might be systemd, or OpenRC, or runit, or any other init implementation.

On Ubuntu, the kernel thinks it's launching init, but it's actually launching systemd. The kernel doesn't care. It just needs something to start running in user space.

Init gets two special privileges. First, it always receives process ID 1, making it easy to identify. Second, and more importantly, it can never terminate. The kernel refuses to deliver kill signals to it, because the kernel needs init to adopt orphaned processes—those whose parents have terminated while they're still running.

"If for some reason init itself crashes due to a bug or even if it exits without errors, the kernel will panic," George explains, "even though nothing inside the kernel itself failed."

The Second Boundary: Where Does User Space OS End?

That first boundary—privileged mode versus restricted mode—is straightforward. But George raises a harder question: if all these OS components are just regular user space processes, where do we draw the line between the operating system and user applications?

Is Firefox part of the OS because it ships with most distributions? Probably not—a web browser isn't essential to system operation. But what about the file explorer? The terminal emulator? The desktop environment itself?

You could argue that anything you can do through the GUI, you can also do through the shell, so GUI tools aren't really part of the OS. But consider Mac OS 9 in the '90s, which had no shell and no terminal emulator. Everything had to be done through the GUI. In that environment, the file explorer and settings panels weren't optional luxuries—they were the only way to interact with the system.

"To me, that line is a bit blurry," George admits. "How do we even define the user space part of an operating system? Is it every program that ships with the OS? Every program that has no lower level alternative?"

The closest definition might be: programs that init starts automatically, plus essential services. But that breaks down quickly. The terminal isn't started by init—you invoke it when needed. Core utilities like ls, grep, and cat aren't launched at boot, but try using Linux without them.

This ambiguity isn't a bug. It's a feature of Unix philosophy: small, composable tools that can be mixed and matched. The kernel provides the foundation. Init builds the first layer of infrastructure. After that, it's turtles all the way up—and where "operating system" ends and "user applications" begin is more about philosophy than technical boundaries.

Which means the real answer to "where does the kernel end?" is simpler than you'd expect: it ends where privileged mode ends. Everything after that is negotiable.

—Dev Kapoor