kernel: The Linux kernel
The kernel is the piece of software that sits between your hardware and your programs. No kernel, no working system: no processes, no file system, no network stack. Everything you run on a Linux server — containers, databases, web servers — depends on what this layer does well. And it's open source, so you can see what's happening.
That insight is more important than it seems. On a server that runs 24/7, you want to know who is responsible for which piece of code. With closed operating systems, that's someone else. With Linux, you can look at the source code yourself, and that's not a theoretical possibility. It's the reason the kernel has lasted for decades without its foundations collapsing.
The kernel is monolithic in design. That means the core — process management, memory management, the network stack — runs in one space, directly on the hardware. No translation layer between components, no overhead of processes that need to communicate with each other. That delivers speed, but it also means a fault in one component can affect the entire system.
That's why the kernel has modules. Pieces of code that you can load and remove dynamically, without restarting the system. Adding a device driver while the server is running, disabling a network feature you don't use. The extension is `.ko`, and you manage them with `modprobe` and `rmmod`. This way, you combine the speed of a monolithic kernel with the flexibility of something modular. You can also choose what you compile: a kernel for a web server doesn't need Bluetooth support.
The version numbering is `major.minor.patch`, but the meaning is different from much other software. Odd minor numbers are development releases, even numbers are stable. Additionally, there are LTS versions, which are maintained for at least two years with security patches and bug fixes. For production systems, that's often the sensible choice: you get updates without having to run a new major version every few months.
The kernel runs on more than you think. Smartphones via Android, servers, routers, smart TVs, supercomputers. The same kernel that started in 1991 as a student project now runs on devices that the developers of that time had no idea about. That's no coincidence, but the result of a design that can adapt to new hardware without the core changing.
What the kernel is not: the entire operating system. What people call "Linux" is usually the combination of the kernel and the GNU software — the compiler, the shell, the basic commands. The kernel is the engine, but without the rest of the car, you won't move an inch. That nuance is relevant when you choose a distribution: the kernel is largely the same everywhere, the difference is in what surrounds it.
The development of the kernel is a global collaboration. Thousands of developers contribute, many employed by companies that run Linux in production. Management is centralized with one person who has final responsibility for what ends up in the mainline. That sounds fragile, but it's the reason the kernel has remained consistent for years. There's no democratic committee that decides on the network stack; there's someone who says: this is good enough.
The version control system Git was developed for this process. Not because someone wanted to build a nice new tool, but because the existing systems couldn't handle the amount of patches that came in daily. Git is now everywhere, but it was made for this one purpose: letting thousands of developers collaborate on one codebase without getting in each other's way.
For anyone managing a server, the kernel is not an abstraction. It's the layer that determines how your system handles memory, network traffic, disk I/O. A kernel that isn't well configured for your workload you feel directly: slow network response, high latency, unexplained crashes. That's why choosing the right version is not a detail. It's part of your responsibility as an administrator.
The kernel is not software you install and forget. It's the layer you need to understand if you want to know why your system behaves the way it does. Not because you deal with the kernel every day, but because when something goes wrong, you need to know where to look. And that's almost always closer to the kernel than you'd like.
The kernel is the foundation. What you build on it — containers, databases, hosting platforms — stands or falls with what's underneath. As long as that foundation is solid, you can rely on it. And if it isn't, you know where to start looking.