Kernel
The kernel is the core program of an operating system: the one piece of software that is always resident in memory, runs with complete authority over the hardware, and decides which programs get the processor, which memory they may touch, and how they reach disks, networks and other devices. Everything else a person thinks of as "the computer" — browsers, editors, shells, even the desktop itself — runs on top of the kernel and asks it for services, and when the kernel itself fails the entire machine fails with it, which is why a kernel crash looks like a Linux "kernel panic" or a Windows blue screen rather than a single misbehaving window.
The kernel's authority rests on a hardware-enforced split between kernel mode and user mode. Modern processors provide at least two privilege levels (x86 calls them rings, with ring 0 for the kernel and ring 3 for ordinary programs). Code in kernel mode can execute privileged instructions, program the memory-management unit and talk directly to devices; code in user mode cannot, and an attempt to do so triggers a fault that the kernel handles, usually by terminating the offending process. Combined with virtual memory, which gives every process its own private address space, this split is what lets one buggy or malicious program fail without corrupting its neighbors or the system.
A system call is the only sanctioned doorway from user mode into the kernel. A program that wants to read a file, allocate memory, start a process or open a network connection cannot do so itself; it places arguments in registers, executes a special instruction (syscall on modern x86-64, or an older software interrupt), and the processor switches into kernel mode at an address the kernel chose. The kernel validates the request, performs it and returns a result. Classic Unix calls such as open, read, write, fork, execve and mmap are the vocabulary of this interface, and language libraries such as the C standard library, Python's os module or a Go runtime are largely friendly wrappers around it. Each crossing costs time, which is why high-performance software batches work and why interfaces such as io_uring in Linux exist to reduce the number of crossings.
Kernel designs differ mainly in how much code is allowed to run in kernel mode. A monolithic kernel, as in Linux and the traditional BSD systems, keeps the scheduler, memory manager, file systems, network stack and device drivers all in one privileged address space, so components call each other directly and quickly, at the price that a bug in any driver can take down everything. A microkernel, as in MINIX, QNX and the formally verified seL4, keeps only the bare minimum (address spaces, scheduling, message passing between processes) in kernel mode and runs file systems and drivers as separate user-mode servers, trading some speed for isolation and a far smaller trusted core. Windows NT and Apple's XNU, which combines the Mach microkernel with BSD code, are usually described as hybrids. The debate was famously aired in 1992, when Andrew Tanenbaum argued that Linux was obsolete because it was monolithic and Linus Torvalds defended his pragmatic design.
Linux, the most widely deployed kernel today, began as a student project. On 25 August 1991 Linus Torvalds, a Finnish student at the University of Helsinki, announced on a Usenet group that he was writing a free operating system "just a hobby", and version 0.01 appeared in September 1991. Combined with the GNU userland tools begun by Richard Stallman in 1983, it formed a complete free Unix-like system, and the Linux kernel now runs most web servers, nearly all supercomputers, Android phones and the majority of cloud infrastructure. It is developed in the open by thousands of contributors, with Torvalds still releasing the mainline versions, and the largest share of its source code is device drivers rather than the core scheduler or memory manager.
The kernel is also where the machine's resource sharing, security and observability are decided, and that matters directly for modern workloads. Its scheduler time-slices processors among thousands of threads, its memory manager pages data in and out and enforces limits, and features such as Linux namespaces and cgroups provide the isolation behind containers like Docker and Kubernetes pods. Machine-learning clusters depend on kernel behaviour in ways that are easy to overlook: GPU access goes through a kernel driver, huge pages and NUMA placement affect training throughput, and the out-of-memory killer may quietly terminate a job that exceeds its limits. The Meltdown and Spectre disclosures of 2018 showed the stakes, since defending the kernel's memory from user-mode speculation required changes such as kernel page-table isolation that measurably slowed some system-call-heavy workloads.
Two misconceptions recur. The kernel is not the same thing as the operating system, which also includes shells, libraries, utilities and often a graphical environment; this is why "Linux" can mean the kernel alone while distributions such as Debian, Fedora and Ubuntu are complete systems built around it. And the kernel is not a process that sits beside the programs waiting its turn: it mostly runs on behalf of them, entered by system calls, interrupts and faults, so its work is interleaved with theirs rather than being a separate program the processor visits.
Read the kernel as the single trusted referee of a computer: hardware privilege levels keep every other program in user mode, system calls are the only door through which they may ask for anything real, and the choice between monolithic and microkernel designs is simply a decision about how much code is trusted to stand inside that door.