Why Write an OS?

Few hobby operating system projects reach a state of practical, general-purpose use. This is characteristic of the activity rather than a deterrent: the value of the exercise lies less in the finished result than in the understanding required to produce it.

An operating system touches nearly every layer of a computer: how the CPU boots and switches privilege levels, how physical memory becomes the virtual address spaces a program sees, how a keyboard interrupt becomes a character on screen, how a scheduler decides what runs next, and how a filesystem turns bytes on a disk into files and directories. These subjects can be studied individually, but implementing a kernel is what connects them: a memory management defect that later corrupts interrupt handling is a common example of the interdependence between subsystems that isolated study does not convey.

Kernel development also provides few of the conveniences typical of application programming. No C standard library, memory allocator, or process abstraction exists until it is written. This absence of provided infrastructure is part of what makes the exercise instructive: functionality normally taken for granted is revealed as a series of specific design decisions, each of which must be made explicitly.

Linux began as a project of this kind, described by Linus Torvalds in 1991 as “just a hobby, won’t be big and professional.” Most hobby kernels do not reach comparable scope, which does not diminish the value of the exercise. Reaching a shell prompt, running a second process, or mounting a filesystem for the first time are commonly cited milestones in projects of this scale.