Introduction to Linux OS

Ask three people what “Linux” means and you’ll probably get three different answers. One will tell you it’s an operating system. Another will start listing distributions — Ubuntu, Debian, Fedora — like they’re brands of the same product. A third might just say “it’s what runs servers” and leave it at that.

None of them* are w*rong. They’re just each describing a different layer of the same stack. Before you type a single command, it’s worth untangling those layers — because almost every point of confusion you’ll hit later (“why does this work on my machine but not the server,” “why do these instructions not match what I’m seeing”) traces back to not knowing which layer you’re actually looking at.

The Problem With The Word “Linux”

Here’s the core issue: “Linux” is used to refer to at least three different things, and people rarely specify which one they mean.

1. The Linux kernel — a specific piece of software
2. A Linux distribution — a complete, installable operating system built around that kernel
3. The shell — the program you actually type commands into

These aren’t three competing definitions to pick from. They’re three layers stacked on top of each other, and you interact with all three every time you use a Linux system.

Layer 1: The Kernel — The Actual “Linux”

Strictly speaking, Linux refers only to the kernel: a program that sits between your hardware and everything else. It’s the thing that:

• Talks to your CPU, memory, and storage devices
• Decides which running program gets access to the processor and when
• Manages memory so one program can’t read another’s data by accident
• Provides a consistent way for software to talk to wildly different hardware

You never interact with the kernel directly. No one types commands “into” the kernel. It works silently underneath everything else, and if it’s doing its job well, you never think about it at all.

Layer 2: Distributions — Linux Wearing Different Clothes

A kernel by itself isn’t something you can install and use. It has no text editor, no way to install software, no user accounts, no graphical interface — nothing you’d recognize as an operating system.

A distribution (or “distro”) takes the Linux kernel and bundles it with everything needed to make it usable:

• A package manager (for installing and updating software)
• A set of core utilities (for copying files, managing users, etc.)
• Default configuration and startup behavior
• Often, a curated selection of pre-installed software

This is why Ubuntu and Fedora can both be “Linux” while looking and behaving quite differently — they’re the same kernel, dressed in different tooling, defaults, and philosophies. Ubuntu and Debian (Ubuntu is actually built on top of Debian) favor apt for package management and lean toward broad hardware compatibility out of the box. Red Hat–family distributions like Fedora or RHEL use dnf/yum instead and often favor a more conservative, enterprise-oriented release cycle.

Throughout this course, examples are written for Debian-based systems (Ubuntu, Debian itself, and their derivatives), since that’s the most common environment you’ll encounter in cloud servers, CI systems, and containers. Where another major distribution family does something meaningfully different, we’ll call it out with a note like this one:

Layer 3: The Shell — Your Interface To All Of This

If the kernel is the engine and the distribution is the car built around it, the shell is the steering wheel. It’s the program that reads the commands you type, interprets them, and asks the underlying system to carry them out.

A few things worth knowing about the shell before you ever open one:

• The shell is just a program — not a special, built-in part of Linux. It’s swappable.
• The most common shell on Linux systems is bash. When people talk about “the terminal” or “the command line,” they usually mean bash specifically, even if they don’t say so.
• The shell doesn’t do the work itself — it hands your command off to the kernel or to other programs, then shows you the result.

You’ll get hands-on with the shell in the next chapter. For now, the important thing is just knowing that “typing a command” involves this chain: you → shell → kernel → hardware/other software, and back again with the result.

Putting The Three Layers Together

    flowchart TB
    A["You"] --> B["Shell (e.g. bash)<br/>reads and interprets commands"]
    B --> C["Distribution tooling<br/>(package manager, utilities, config)"]
    C --> D["Linux Kernel<br/>talks to hardware, manages processes & memory"]
    D --> E["Hardware<br/>CPU, memory, disk, network"]
  

Each layer depends on the one below it, but each layer is also replaceable independently. You can swap bash for a different shell without touching the kernel. You can run the same kernel under wildly different distributions. This separation is a big part of why Linux ended up running everything from smartphones to supercomputers — the pieces aren’t welded together.

Checking What You’re Actually Running

Two commands are worth knowing about even before you’re comfortable with a terminal, because you’ll see their output referenced constantly in documentation, forums, and bug reports:

• uname -r shows the kernel version currently running.
• cat /etc/os-release shows details about the distribution — its name, version, and family.

You don’t need to run these yourself yet — that’s what the next chapter is for. Just recognize them when you see them: the first tells you about the kernel, the second tells you about the distribution built on top of it. Now you know why those are two separate questions.

What’s Next

With the kernel/distribution/shell picture in place, the next chapter gets you into an actual terminal — what a shell prompt is telling you, how to read a command’s structure, and how to get help without leaving the terminal.