People use “Linux” to mean two different things. Sometimes they mean the kernel. Sometimes they mean the whole operating system. The words get swapped so often that the distinction feels pedantic until the moment it matters, and then it matters a lot.

Here is a clean explanation of what the kernel actually is, what the operating system is, and why the difference is worth knowing.

What a kernel does

The kernel is the lowest layer of software on a running system. It sits between your hardware and everything else, and it does three things at its core.

Resource management. Every program that runs needs CPU time, memory, and access to storage. The kernel decides who gets what and when. When you open a browser and a text editor at the same time, the kernel is the reason both of them run without stepping on each other.

Hardware abstraction. Your application does not know or care whether your disk is an NVMe drive, a SATA SSD, or a spinning hard drive. The kernel presents a uniform interface so that software can read and write files without caring about the underlying hardware. The same binary can run on different hardware because the kernel abstracts those differences away.

Security and isolation. The kernel enforces boundaries between processes. Your music player cannot read memory belonging to your password manager. The kernel runs in a privileged mode (ring 0 on x86) that no application can access directly. When an application needs to do something that requires hardware access, it makes a system call and the kernel handles it.

You can see the kernel version on any Linux system with:

uname -r
# example output: 6.8.0-51-generic

That number is the Linux kernel version. Everything else you interact with is built on top of it.

What an operating system is

An operating system is the kernel plus everything required to make a usable computing environment. At minimum that means:

A shell. The interface between a user and the kernel. On Linux this is typically bash, zsh, or fish. The shell is what you type commands into. It is not part of the kernel.

A filesystem. The kernel supports filesystem types (ext4, btrfs, xfs), but the tools you use to create, format, and manage filesystems are separate software.

System utilities. Commands like ls, cp, grep, ps, and chmod are not part of the kernel. They are programs, most of them from the GNU project, that use the kernel’s system calls to do their work.

An init system. After the kernel boots, it hands off to an init system that starts services and brings the rest of the system up. On most modern Linux distributions this is systemd.

Package management. apt, dnf, pacman and their libraries are not kernel code. They are userspace software layered on top of the OS.

A desktop environment (optional). GNOME, KDE Plasma, and Xfce are entirely userspace. The kernel has no concept of a window or a mouse cursor. Those are handled by display servers (X11 or Wayland) and desktop environments built on top.

Why this matters in practice

The distinction stops being abstract the moment you look at what “Linux” actually runs on.

Android is Linux. The kernel inside every Android phone is the Linux kernel. But Android does not run bash, or apt, or systemd, or GNOME. It has its own userspace, its own init system, and its own runtime. You would not call it a Linux distribution in the usual sense, but it runs Linux the kernel.

Ubuntu and Arch Linux use the same kernel. If you install Ubuntu 26.04 and Arch Linux on the same hardware, both will run a Linux kernel. The kernel versions will differ, and they will be configured differently, but the kernel is the same software project. What makes them feel completely different is everything else: the package manager, the default desktop, the release model, the default services, the configuration tools.

“Linux broke my hardware” is usually not about the kernel. When someone says a driver does not work, they mean the kernel does not include working kernel module code for that piece of hardware. When someone says their Wi-Fi stopped working after an update, the kernel is involved but the fix is usually a kernel update or a firmware package, not a change to userspace.

Kernel updates and OS updates are separate things. On Debian stable, the userspace packages are deliberately old. The kernel can be updated independently via backports without changing any of the userspace software. On Arch Linux, both the kernel and userspace packages roll forward together.

The GNU/Linux naming debate

Richard Stallman and the GNU Project have argued for decades that the correct name for what people call “Linux” is “GNU/Linux,” because most of the userspace on a typical Linux distribution (the shell, the compilers, the core utilities) comes from the GNU project, not from Linus Torvalds.

The argument is technically accurate. Torvalds wrote the kernel. The GNU project wrote most of the tools that make a usable operating system around it. Calling the whole thing “Linux” does omit a large body of work.

In practice, the name “Linux” stuck, and almost no one uses “GNU/Linux” outside of the Debian project and FSF materials. But understanding the debate clarifies the kernel/OS distinction better than most explanations do.

A concrete look at the layers

Here is what is running on a typical Ubuntu desktop, from bottom to top:

# See kernel version
uname -r

# See init system (almost certainly systemd)
ps -p 1 -o comm=

# See your shell
echo $SHELL

# See core userspace tools (these are GNU coreutils)
ls --version | head -1

# See desktop environment
echo $XDG_CURRENT_DESKTOP

Each of those layers is independent software. The kernel does not care which shell you use. The shell does not care which desktop environment you run. The desktop environment does not care which init system started it. They communicate through well-defined interfaces (system calls, environment variables, D-Bus, sockets), not through tight coupling.

That modularity is why Linux powers both a 200 MB embedded router firmware and a fully equipped desktop workstation. Strip out the desktop environment, the package manager, and most of the userspace tools, and the kernel is still there doing its job.

Kernel space vs user space

One more distinction worth knowing: kernel space and user space.

Kernel space is where the kernel runs. Code executing in kernel space has direct access to hardware and memory. A bug in kernel space can crash the entire system or corrupt data. Kernel modules (drivers, filesystem code, network code) run in kernel space.

User space is where applications run. A bug in user space crashes that process and leaves the rest of the system intact. Everything you think of as an application runs in user space: your browser, your editor, your terminal emulator, systemd, bash.

When a user space program needs something only the kernel can do (open a file, send a network packet, allocate memory), it makes a system call. You can watch system calls in real time with strace:

# See every system call a command makes
strace ls /tmp

# Count system calls by type
strace -c ls /tmp

The output is verbose but reveals exactly how a program talks to the kernel. Every openat, read, write, and close call is the application asking the kernel to do something on its behalf.

The short version

The Linux kernel is the software Linus Torvalds started in 1991. It manages hardware, schedules processes, and enforces security boundaries. You never interact with it directly.

A Linux operating system is the kernel plus the shell, system utilities, init system, package manager, and optionally a desktop environment. Ubuntu, Fedora, Debian, and Arch are all operating systems built around the Linux kernel. They share the kernel but differ in everything else.

When someone says they “run Linux,” they mean they run an operating system whose kernel is Linux. When someone says “Linux supports this hardware,” they mean the kernel has a driver for it. The context usually makes the meaning clear once you know both definitions exist.