What is a kernel?

Someone once asked me, holding a refurbished machine I had just handed over, "so what exactly is this Linux you put on it?" I started with the honest answer — the kernel — and watched their eyes glaze over in about four seconds. That was my fault, not theirs. If you cannot explain something without jargon, there is a decent chance you do not understand it as well as you think.

So I went away and found a better answer. It comes from my first profession — I trained as an electronics engineer, and electronics has exactly the same problem to solve. You have components that all want to use the same wires at the same time, and something has to decide who speaks and when. That something is a controller. The kernel is that, for a computer.

The kernel is not a program. It is a traffic controller

Here is the mental model that works for most people I have explained this to.

Your computer has hardware — a processor, memory, a drive, a network card, a screen. It also has programs — a browser, a spreadsheet, a music player. Programs are not allowed to talk to hardware directly. If they were, the first badly written program would grab all the memory, or write over another program's data, or seize the drive and never let go. Instead every request goes through one layer in the middle, and that layer is the kernel.

You open a file. The program does not reach into the drive; it asks the kernel, and the kernel decides whether that program is allowed to read that file, then goes and fetches it. You start an application. The kernel assigns it a slice of memory and a share of processor time. You close it. The kernel takes the memory back and cleans up after it. Two programs both want the processor at once — the kernel decides who goes first and for how long, thousands of times a second, so smoothly that you experience it as "both running at the same time", which is a comfortable illusion.

Everything you think of as "the system" — the desktop, the windows, the start menu, the settings — sits on top of that layer and is not the kernel at all. This is why the same kernel runs under a machine on your desk, a phone in your pocket, a router in the hallway and a server in a data centre. The kernel is the part that talks to hardware. What gets built on top of it is a separate decision.

Why anyone outside the trade should care

Because the kernel is where every security question ultimately lands. It is the component that answers "is this program allowed to do that?" — and if it answers wrongly, nothing above it can save you. Your antivirus, your password manager, your careful habits all sit on top of that one decision-making layer.

The Windows kernel does the same job, and does it competently — this is not a comparison of engineering quality, and I have no interest in pretending otherwise. The difference is narrower and, to me, decisive: I can read one of them.

The Linux kernel source is public. Anyone can download it, read it, and see the full history of who changed which line and why. Every change carries a name and a justification, and the arguments about those changes happen on a public mailing list that anybody can read. Nothing about that arrangement is polite — kernel development has a reputation for bluntness — but it is visible.

Let me be precise about what that does and does not buy you, because overselling it would be dishonest. I do not read the kernel source every morning; nobody does. It runs to tens of millions of lines and no single person understands all of it. What openness buys is not my personal vigilance. It is that thousands of people with competing interests — rival corporations, universities, security researchers, governments who distrust each other — are all looking at the same code. None of them has to trust the others. They only have to keep watching.

What this changes in practice

Two things, and both are mundane rather than dramatic.

The first is longevity. Because the kernel is separable from everything built on top of it, support for old hardware tends to stay in place long after a commercial vendor would have dropped it. Someone somewhere still uses that network card, so the code that drives it stays. This is the technical reason a machine declared obsolete by one vendor keeps receiving security updates under another system. It is not charity. It is a consequence of nobody having a commercial motive to remove working code.

The second is diagnosability, which sounds abstract until the day you need it. When a server misbehaves at three in the morning, the useful question is not "who do I call?" but "what is it doing?" On an open system I can follow that thread all the way down — from the application, through the system calls it is making, into the kernel's own reporting. I have spent nights doing exactly that. The answer is sometimes embarrassing and it is mine to find. On a closed system the thread stops at a support ticket.

One honest caveat, because the open model has a real cost and pretending otherwise is how people end up disappointed. Openness does not mean simplicity. When something goes wrong on Linux you are handed the entire truth, and the entire truth is frequently overwhelming. A closed system that says "an error occurred" is, for many people on many days, genuinely the kinder option. The value of transparency shows up when you need it, not when you are trying to print.

Where the updates come from

One practical consequence of this structure is worth spelling out, because it is the mechanism behind a claim I make when I hand over a machine: that an eight-year-old computer will keep receiving security updates.

The kernel is developed continuously, and some versions are designated for long-term maintenance. Those versions stop receiving new features and receive only fixes, for years. A distribution such as the one I install picks a long-term kernel and a long-term set of surrounding software, and commits to patching that combination for a defined period. When the period ends you move to the next long-term release — on the same hardware, because the hardware was never the thing that expired.

Notice what is absent from that description: any decision about your processor's generation. The kernel supports hardware for as long as somebody maintains the code that drives it, and old hardware is maintained because old hardware is still in use, frequently in places that cannot be replaced on a marketing schedule — industrial equipment, medical devices, infrastructure. Your desk benefits from a decision made for a factory.

The short version, for the person at my counter

The kernel is the layer between your programs and your hardware. It decides who gets memory, who gets the processor, and who is allowed to read which file. It is the single most security-critical component in the machine, and it is the part you never see.

I choose to run the one whose source I can open. Not because I read it daily, and not because it is flawless — it is not, kernel security patches come out regularly like everyone else's. But because when I need to know what a machine is doing, the answer exists somewhere I can reach it. That is the whole argument, and it is a smaller one than people usually expect.

If you trust the heart of a machine because someone told you to, that is faith. If you trust it because it can be inspected, that is engineering. I prefer the second one, and I build what I sell on that preference.