What Linux Is: Kernel, Userland and Distributions

Part I · Module 1 · Chapter 1.1 · What Linux Is: Kernel, Userland and Distributions

1. One Word, Three Things

Read these three sentences. All three are things engineers say, and all three use the word Linux to mean something different.

• "This server runs Linux."
• "That bug was fixed in Linux 5.15."
• "Which Linux is installed — Ubuntu or Rocky?"

The first means a system built around the Linux kernel. The second means the kernel itself, which has version numbers of its own. The third means a distribution — a particular company's or project's assembly of the kernel plus thousands of other programs.

This is not pedantry looking for somewhere to happen. Consider a failure you will certainly meet:

./analyze: /lib64/libc.so.6: version `GLIBC_2.28' not found

Nothing in that message is the kernel's fault, and upgrading "Linux" in the sense of the kernel would not help. The missing piece is a library — an ordinary file that lives in the userland layer, installed and versioned by the distribution. Knowing which of the three layers is complaining is the difference between fixing this in ten minutes and losing an afternoon.

So: three words, from the bottom up.

2. The Kernel: What Actually Owns the Machine

The Linux kernel is a single program, and it is the only program on the machine with direct authority over the hardware. It is loaded when the machine boots and it keeps running until the machine stops.

Its responsibilities are specific:

• Processes. It decides which running program gets the CPU and for how long, and it starts and stops processes on request.
• Memory. It hands out memory to programs and keeps each program's memory separate from every other program's.
• Files. It presents disks, partitions and network storage as one tree of files and directories, and performs every read and write.
• Devices. It talks to disks, network cards, keyboards and graphics hardware through drivers.
• Permissions. It enforces who may read, write or run what. A permission check is the kernel's decision, not a program's politeness.

Everything else on the machine — every single program you will type the name of in this course — has to ask the kernel for all of those things. A program cannot read a file by itself. It asks.

You can see the kernel's version directly:

uname -r

5.15.0-105-generic

uname prints information about the running system; -r asks specifically for the kernel release. That number has nothing to do with the version of your distribution. A machine can run Ubuntu 22.04 with kernel 5.15 and another machine can run Ubuntu 22.04 with a different kernel entirely.

3. Userland: Everything You Actually Type

Userland is every program on the machine that is not the kernel. The name is literal — these programs run in user space, with no direct access to hardware, and must go through the kernel for anything real.

Userland is what you interact with all day:

• the shell that reads your command lines — Bash, in this course;
• ordinary commands such as ls, cat, grep, cp;
• the editors, compilers, interpreters and simulators you run;
• the system libraries those programs share, such as the C library that the error message in §1 was complaining about;
• long-running background services.

Two things about this list are worth noticing now.

The shell is just a userland program. It is not part of the kernel and it is not special to the operating system. It has a name, a version and a file on disk like any other program. That fact is the entire subject of the next chapter.

The commands are ordinary files. When you type ls, you are running a program that exists as a file on disk. You can see those files:

ls /bin | head -5

bash
cat
chgrp
chmod
chown

That listing is the first concrete proof of something that will matter repeatedly: most commands are not features of Linux. They are programs, installed as files, that the shell locates and runs. Which programs exist on a given machine is a decision somebody made — and the body that usually made it is the distribution.

The arrangement in Figure 1 is a chain of dependence, not a stack of boxes that happen to be drawn above each other. A program in the top band calls a library in the second; the library asks the kernel; the kernel drives the hardware. Reading the figure from the top down also reads a failure from the top down, which is exactly how §6 will use it.

4. The Distribution: Packaging, Not a Layer

A kernel on its own is unusable. You cannot log in to it, there is no shell, no ls, no compiler, no way to install anything. Somebody has to choose, build, configure and package a complete working system.

That is what a distribution is: a curated assembly of the Linux kernel plus a userland, shipped as something installable, with a policy for keeping it updated. Ubuntu, Debian, Red Hat Enterprise Linux, Rocky Linux, SUSE, Fedora, Arch and Alpine are distributions.

A distribution decides:

• which kernel version ships, and which fixes are backported into it;
• which userland programs are included, and which versions of them;
• which library versions are available — the decision behind the GLIBC message in §1;
• how software is installed — the package manager, apt or dnf or zypper or another;
• where things live and how they are configured — service management, default file locations, security policy;
• how long all of that is supported before you are expected to upgrade.

Most modern distributions record their own identity in a file you can read:

cat /etc/os-release

NAME="Ubuntu"
VERSION="22.04.4 LTS (Jammy Jellyfish)"
ID=ubuntu
VERSION_ID="22.04"

Compare that with uname -r from §2. They are independent facts about the same machine: one names the distribution, the other names the kernel.

5. The Misconceptions Worth Naming

Three wrong models, each of which causes a specific kind of wasted time.

"Linux is the operating system, like Windows." The comparison is close enough to be useful in a sentence and misleading beyond it. What ships as a single product from one vendor on Windows is, here, a kernel from one project plus thousands of independently developed userland programs, assembled by a distribution. That is precisely why you can be running "the same Linux" as a colleague and still be missing a program they have.

"Different distributions are different operating systems." They share the same kernel project and overwhelmingly the same userland programs. What differs is version choices, packaging, default configuration and file layout. Skills transfer almost completely; package-manager commands and some paths do not.

"The commands are part of Linux." ls, grep and cat are programs in userland, installed as files, most of them from the GNU project rather than the kernel. This is not trivia: it explains why the same command can accept slightly different options on a different system, which Module 21 treats under portability, and why reading the local manual beats reading a web page. A command's behaviour is its own program's decision.

6. Why Engineers Care: Reading a Failure by Layer

Here is the practical payoff, and it is the reason this chapter is first.

When something does not work, ask which layer is refusing. Figure 1 gives you the order to ask in — top down, because the top is where your command actually is.

Semiconductor work makes this concrete, and you do not need any chip-design knowledge to follow why. Commercial EDA tools — simulators, synthesis tools — are large userland programs that are qualified against specific distributions and specific library versions. A vendor will tell you a release is supported on a named distribution, because the library versions it needs are a distribution decision. When such a tool refuses to launch on a compute server, the overwhelmingly likely cause sits in the userland band: a missing library, a wrong library version, or a program the machine does not have. Part II returns to this in detail once you have the shell skills to investigate it.

7. Check Your Understanding

Question 1. A colleague says their script works on their laptop and fails on the compute server with grep: unrecognized option --fixed-strings. Which layer differs between the two machines, and which of the three words from this chapter explains it?

Question 2. Two machines both report VERSION_ID="22.04" from /etc/os-release but different output from uname -r. Is that possible, and what exactly differs?

Question 3. You are told "the kernel enforces permissions". A program on the machine refuses to open a file and prints Permission denied. Which component actually made the refusal — the program, the shell, or the kernel?

Question 4. Explain in one sentence why "the commands are part of Linux" is a model that will eventually cost you time.

8. Remember

• Linux is the name of the kernel — one program, loaded at boot, with sole direct authority over the hardware. It owns processes, memory, files, devices and permission checks.
• Userland is everything else that runs — your shell, ordinary commands, libraries, services. None of it touches hardware directly; all of it asks the kernel.
• A distribution is packaging and policy, not a layer at run time. It decides which kernel, which programs, which library versions, which package manager, and how long they are supported.
• The shell is an ordinary userland program, and most commands are ordinary files on disk. Neither is a feature of the kernel.
• A failure belongs to a layer. command not found is the shell; a library version mismatch is the distribution's userland; Permission denied and No space left on device are the kernel reporting what it enforces.
• Ask which layer is refusing, and who owns it. That single question decides whether a problem is yours to fix, your administrator's, or neither.

The next chapter takes the one userland program you will spend the rest of this course talking to — the shell — and establishes exactly what it does with the line you type.