Here is a fact that surprises people outside the field: on the TOP500 list — the twice-yearly ranking of the world's most powerful supercomputers — the "Operating System Family" column reads Linux, 500 out of 500. Every machine. This has been true for every list since November 2017, an unbroken run that stood at eight consecutive years as of the November 2025 list. No Windows, no proprietary Unix, no bespoke vendor OS holding the top spot. For a field that prides itself on custom everything, the operating system is the one place everyone converged on the same answer.
It didn't used to be this way
In the 1990s the machine room was a zoo of proprietary Unix: Cray's UNICOS, IBM's AIX, SGI's IRIX, Sun's Solaris — each welded to one vendor's hardware. Linux showed up on the list as a single system in the late 1990s and climbed from there. The tipping point was economic and practical: a research group could take a free, open kernel, run it on commodity x86 servers, and build a cluster at a fraction of the cost of a proprietary big iron. The "Beowulf" cluster movement turned that into a template, and once the national labs adopted it, proprietary Unix on the list withered. By 2017 it was gone.
Why Linux specifically, and not just "some Unix"
Three reasons, and they're the same reasons HPC is a distinct discipline:
- You can strip it. A compute node's job is to run your program and nothing else — every background daemon, every timer interrupt, every stray kernel thread steals cycles and, worse, arrives at a slightly different time on each node. That jitter (OS noise) desynchronizes a job at every barrier and murders performance at scale. With an open kernel you rip out everything the node doesn't need. Cray's compute-node OS and lightweight-kernel research (Catamount, Kitten, IBM's CNK on Blue Gene) all chase the same goal: a near-silent node. You cannot do that to an OS whose source you can't touch.
- You can patch it at the source. Supercomputers do things no laptop does — 200 Gb/s RDMA network cards, exotic parallel filesystems, custom schedulers. The vendor writes kernel modules and often patches the kernel itself, then ships the modified source. That's legal and normal with the GPL; it's impossible with a closed OS.
- Drivers come first. When NVIDIA, AMD, or a network vendor ships new silicon, the Linux driver lands first — because that's what the datacenter runs. The entire HPC and AI hardware ecosystem is developed on Linux. Picking anything else means waiting for a port that may never come.
What actually runs on the nodes
In practice a big machine runs a Linux distribution hardened for the job — El Capitan, the current #1, runs Red Hat Enterprise Linux; many centers use SUSE (SLES) or the community TOSS/Rocky rebuilds. On top sit the vendor's kernel patches, the network and GPU drivers, the parallel filesystem client, and the scheduler's node daemon. From a login node it feels like an ordinary Linux box:
$ uname -sr
Linux 5.14.0-427.el9.x86_64
$ ldd ./my_solver | grep -E 'mpi|cuda'
libmpi.so.40 => /opt/cray/pe/lib/libmpi.so.40
libcudart.so => /usr/local/cuda/lib64/libcudart.so
Why it matters: the GPU cluster your model trains on is the same story. CUDA is Linux-first. The RDMA stack, the NCCL collective library, the container runtime, the Slurm or Kubernetes scheduler — all assume Linux, because that's the OS the whole HPC lineage standardized on. When you SSH into a training cluster and find yourself in bash looking at NVIDIA drivers and an InfiniBand fabric, you've inherited thirty years of supercomputing settling on one answer. Knowing why makes the environment legible instead of arbitrary.