A Short History & the OS Zoo
How the cost of a computer shaped every OS idea we still use
Operating systems did not arrive fully formed. Almost every idea we now take for granted — running many programs at once, protecting one program from another, giving each user a fair slice of the machine — was invented to solve a very concrete problem of its day. And the biggest problem, for decades, was money: computers were staggeringly expensive, so the whole job of the OS was to make sure that precious hardware was never sitting idle.
That single pressure explains a surprising amount. As hardware went from a million-dollar machine shared by a whole university, to a chip cheap enough to put in every home, to a battery-powered phone in your pocket, to a rented sliver of a server in a data centre, the priorities shifted — but the core techniques kept getting reused. The container you deploy to the cloud today is, at heart, the great-grandchild of a 1960s time-sharing system.
This chapter is a guided tour of that story. We are not memorising dates for a quiz; we are watching each OS technique get born from the constraints of its era, so that when we study it in depth later, you already know why it exists and what it was trying to fix.
Why the history is worth your time
Every design decision in an operating system was an answer to the constraints of its time. When a computer cost more than a building, the overriding goal was to keep its one CPU busy every possible second, because idle hardware was money burning. When chips became cheap enough for every desk, the goal shifted to being friendly and responsive for a single human. On a phone, battery life and touch responsiveness dominate; in the cloud, packing many tenants safely onto one server is what pays the bills.
This is why history is useful rather than trivia: the features you use every day are fossil records of old problems. Understanding the problem an idea solved makes the idea itself far easier to remember and to reason about when it breaks.
- Expensive hardware era: never let the costly CPU idle — share it across jobs.
- Cheap-hardware era: make one machine pleasant and safe for one person.
- Mobile era: stretch a battery and respond instantly to a human finger.
- Cloud era: run many untrusting tenants on shared iron, isolated and metered.
Why it matters: Whenever an OS feature seems arbitrary, ask what was expensive when it was invented. The answer is almost always the real explanation.
The batch era & the birth of the OS
The earliest computers ran exactly one job at a time, and there was no operating system at all. A programmer would sign up for a block of machine time, load their program by hand — often as a deck of punched cards — run it, and read the results. Between jobs the multi-million-dollar machine sat idle while a human shuffled paper, which was an enormous waste.
The first step toward an OS was the batch monitor: a small permanent program that stayed in memory and automatically loaded the next job when the previous one finished. Operators would collect many decks into a batch and hand them off; the monitor sequenced them without a human in the loop between jobs. This was the seed of the OS — software whose job is to run other software.
- Batch job
- A program plus its input, submitted as a unit to run without any interaction while it executes.
- Monitor
- The first resident control program; it loaded, ran, and cleaned up after each job in sequence.
- Job Control Language (JCL)
- Early control cards that told the monitor how to run a job — a distant ancestor of the shell script.
The pain that drove everything next: A batch job that pauses to read a card or write to tape leaves the CPU doing nothing during that I/O. On the most expensive machine in the building, that idle time was intolerable — and fixing it is the whole story of the next section.
Multiprogramming & time-sharing
The fix for the idle CPU was multiprogramming: keep several jobs in memory at the same time, so that when the running job stops to wait on slow I/O, the OS immediately switches the CPU to another job that is ready. The expensive processor now stays busy, and total throughput climbs dramatically. But this demands real OS machinery — memory protection so jobs cannot corrupt each other, and a scheduler to decide who runs next.
Time-sharing was the next leap, and arguably the one that defines the modern OS. Instead of running batch jobs to completion, the OS gives each of many interactive users a rapid slice of CPU time, cycling through them so fast that everyone feels they have the machine to themselves. CTSS pioneered it, the ambitious MULTICS project pushed the ideas further, and UNIX distilled them into something small and elegant that the whole industry ended up building on.
- Multiprogramming
- Keeping multiple jobs in memory so the CPU can switch to a ready one whenever the current job blocks on I/O.
- Time-sharing
- Rapidly rotating the CPU among many interactive users so each gets a fair, responsive slice.
- Time slice (quantum)
- The short interval a program is allowed to run before the OS forcibly switches to the next one.
- CTSS / MULTICS / UNIX
- The lineage of time-sharing systems; UNIX became the simple, portable design the modern world inherited.
The modern echo: Time-sharing is why your laptop runs a browser, an editor, and a music app at once without any of them knowing about the others. The cloud takes the same idea one level up: many isolated tenants sharing one physical server.
The personal-computer era
When the microprocessor made a whole CPU cheap, the computer moved from the shared machine room onto a single person’s desk. The economics inverted overnight: the hardware was no longer the scarce resource, the user’s time and comfort was. Early PC operating systems like DOS were tiny and simple — they ran one program at a time and offered almost no protection, because a machine with one user and one program did not obviously need it.
As PCs grew more capable, their operating systems had to re-learn everything mainframes already knew. Windows and the Mac line added multitasking, then memory protection, then proper user accounts. Meanwhile UNIX’s ideas flowed into the open-source world: Linux, written from that lineage, became the free UNIX-like kernel that now runs most servers on earth. It is a striking pattern — the PC era rediscovered protection and multitasking from scratch, arriving at the same answers the time-sharing pioneers had found decades earlier.
- DOS
- An early single-user, single-tasking PC OS with no memory protection — small because the problem was small.
- Windows / macOS
- The mainstream desktop lines that gradually added multitasking, protection, and multi-user support.
- Linux
- An open-source, UNIX-like kernel started in 1991; now the backbone of servers, cloud, and Android.
- Open source
- Software whose source code is freely shared and modifiable — the model that let Linux spread everywhere.
Remember: Cheaper hardware did not make OS problems disappear; it just delayed them. The moment PCs ran more than one program and touched a network, they needed the very protections the mainframes had pioneered.
Mobile, embedded & real-time
Phones brought new constraints — battery life, a touch screen, and constant sleeping and waking — but not new fundamentals. Android is built on the Linux kernel, and iOS descends from the same BSD-UNIX family as macOS. They aggressively manage power and suspend background apps, yet underneath they are still scheduling processes, protecting memory, and managing devices exactly like their desktop ancestors.
Embedded and real-time systems flip the priorities entirely. In a pacemaker, an engine controller, or an industrial robot, the machine does not need to run many programs — it needs to react within a guaranteed time. A real-time OS (RTOS) is judged not on throughput but on predictability: can it always respond before the deadline? The distinction between hard and soft real-time is exactly how strict that deadline is.
- Android
- A mobile OS built on the Linux kernel, tuned for touch, apps, and battery.
- iOS
- Apple’s mobile OS, descended from the same BSD/UNIX lineage as macOS.
- Embedded OS
- A small OS baked into a device (router, TV, sensor) to do one dedicated job reliably.
- Hard real-time
- A missed deadline is a system failure — an airbag or brake controller cannot be "a little late".
- Soft real-time
- Deadlines matter but an occasional miss only degrades quality — a video stream may drop a frame.
Same core, different scorecard: A general-purpose OS optimises for average performance across many programs. An RTOS sacrifices average speed to guarantee the worst case — because in real-time work, being usually fast is not good enough.
The OS zoo today
Put it all together and today’s operating systems fall into a handful of families, each shaped by the constraint it lives under. Desktop and server OSes chase general-purpose performance; mobile OSes chase battery and responsiveness; embedded and real-time systems chase predictability; and distributed and cloud systems chase safe, dense sharing of pooled hardware across many tenants.
- Desktop / server
- General-purpose systems (Windows, macOS, Linux) balancing many programs and users.
- Mobile
- Battery- and touch-optimised systems (Android, iOS) built on desktop-class kernels.
- Embedded / RTOS
- Dedicated, often deadline-driven systems inside appliances, vehicles, and sensors.
- Distributed / cloud
- Many machines presented as one pool, sliced into virtual machines and containers for isolated tenants.
- Hypervisor
- Software that runs many virtual machines on one physical host — time-sharing applied to whole operating systems.
That last family is where the story comes full circle. A hypervisor slices one server into virtual machines, and containers slice one OS kernel into isolated, metered environments — the very same instinct as 1960s time-sharing, now applied to entire operating systems and services. We will unpack VMs and containers properly in a later part; for now, just notice the family resemblance.
The through-line: Whatever the zoo animal — phone, laptop, pacemaker, or cloud server — every operating system exists to do the same three jobs: manage the CPU, manage memory, and manage devices. Everything ahead in this course is those three jobs, done well.