A Computer of One’s Own

As you read this, the device in front of you is running hundreds of programs. The browser, the clock, the network service, the code that watches the battery: each behaves as though it had a processor and a block of memory entirely to itself. None of them does. One small set of processors is switching among all of them many times a second, and a single physical memory is divided, rearranged and partly stored on disk without any of the programs noticing.

That arrangement is the main product of an operating system. It is easy to think of an operating system as the thing that shows icons and windows, but the deeper work is invisible: taking one scarce machine and making it appear to be many private machines, each safe from the others. Every major operating system in history can be read as a particular version of that illusion and a particular answer to the question that comes with it. If many people and programs share one computer, who must be protected from whom?

The operator and the batch

The earliest computers had no operating system at all. A programmer, or a professional operator, loaded a program by hand, ran it, collected the output, and loaded the next. While a person changed tapes and decks of cards, the expensive machine sat idle.

The first operating systems were written to remove that idleness. In the mid-1950s, customers of the IBM 704, including General Motors and North American Aviation, built monitor programs that read a stack of jobs and ran them one after another without human intervention. This was batch processing, and it changed the economics of computing centres: the machine stayed busy.

It also defined whose time mattered. A history of MIT’s computing centre puts it precisely: “Batch processing maximized utilization of the computer rather than optimizing throughput of getting programs written.”¹ A researcher submitted a deck of cards and returned hours later, sometimes the next day, to find a list of errors. Fixing a small mistake could take several such cycles. The computer was treated as the scarce resource, and people waited for it.

Time-sharing: the first illusion

At MIT in the late 1950s, a group of researchers who had used interactive machines such as the Whirlwind and the TX-0 wanted that responsiveness back. John McCarthy wrote a memo dated 1 January 1959 proposing interactive, time-shared debugging, and he became, by Fernando Corbató’s account, the person who best articulated why interactive computing was needed.¹

Corbató, working with Marjorie Merwin Daggett and Robert Daley, decided that a modest demonstration would persuade people faster than a grand design. In 1961 they modified the operating system of MIT’s IBM 709, reserving a small part of memory for a supervisor program that switched rapidly among four typewriter terminals. The demonstration was working by November 1961. It ran alongside the existing batch work, which is why it was called the Compatible Time-Sharing System, CTSS.¹

Time-sharing created the founding illusion of the modern operating system. Each person at a terminal could type, run and correct a program as if the computer were theirs, while in fact it was rotating among everyone. To make the illusion safe, the system had to protect users from each other: one person’s program could not be allowed to overwrite another’s memory or read another’s files. Accounts, passwords and private storage followed. The scarce resource being optimised was no longer only the machine’s time. It was also the person’s.

The ambition of the general-purpose system

The 1960s produced operating systems of enormous ambition. In 1964 IBM announced System/360, a family of computers spanning a wide range of prices and speeds that would all run the same software. Its operating system, OS/360, was among the largest software projects ever attempted at the time. Fred Brooks, who managed much of it, drew from the experience the lessons of The Mythical Man-Month (1975), including the observation that adding people to a late software project makes it later.

The decision to make a whole product line compatible had consequences that outlasted almost everything else about it. Customers could move to bigger machines without rewriting their programs, and the compatibility promise became so valuable that IBM’s mainframes still run descendants of that software today. The lesson is one that recurs in operating system history: compatibility, once established, becomes a gravitational force that shapes everything that comes later.

At MIT, the successor to CTSS was Multics, a joint project with General Electric and Bell Labs begun in 1965. It aimed to be a computing utility, as dependable as electricity, with a hierarchical file system, rings of protection and an implementation written in a high-level language. Multics introduced ideas, particularly about security, that influenced systems for decades, and it ran in production for many years. But it was large and slow to reach the state its developers hoped for, and in 1969 Bell Labs withdrew from the project.

Unix: the fellowship and the file

Dennis Ritchie later explained what the Bell Labs researchers who left Multics wanted to keep. “What we wanted to preserve was not just a good environment in which to do programming, but a system around which a fellowship could form. We knew from experience that the essence of communal computing, as supplied by remote-access, time-shared machines, is not just to type programs into a terminal instead of a keypunch, but to encourage close communication.”²

Unable to get a large machine, Ken Thompson began writing a small system on a little-used PDP-7 in 1969. It grew into Unix. When Ritchie and Thompson described it in Communications of the ACM in July 1974, their summary of its achievement was about economy: “Perhaps the most important achievement of UNIX is to demonstrate that a powerful operating system for interactive use need not be expensive either in equipment or in human effort: UNIX can run on hardware costing as little as $40,000, and less than two man years were spent on the main system software.” They hoped users would find its most important characteristics to be “its simplicity, elegance, and ease of use.”³

Unix made several design decisions that became permanent features of computing. Its hierarchical file system organised everything into directories. Its most unusual feature, the paper said, was that devices themselves appeared as files: “Special files are read and written just like ordinary disk files, but requests to read or write result in activation of the associated device.” To punch paper tape, “one may write on the file /dev/ppt.”⁴ A single abstraction, the file, now covered storage, terminals and hardware alike. Pipes, added in 1973, let the output of one program flow directly into the input of another.

In 1978 Doug McIlroy and his co-authors summarised the style that had grown up around these mechanisms in a set of maxims that are still quoted: “Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new ‘features.’ Expect the output of every program to become the input to another, as yet unknown, program.”⁵

Unix spread for reasons beyond its design. Rewritten in C in 1973, it could be moved to new machines with relatively little effort. AT&T, restricted from entering the computer business, licensed it to universities at low cost, and generations of students learned computing on it, producing variants such as Berkeley’s BSD. The fellowship Ritchie described grew far beyond Bell Labs.

The theory of the operating system in Unix was that of a toolkit for capable users: a small kernel, a uniform abstraction, and many small programs combined by the people using them. Its view of the user was generous. It assumed people who wanted to build things.

The personal computer: a machine with one owner

When microcomputers appeared in the 1970s, the problem changed. A personal computer had one user, who owned it. The elaborate protection of time-sharing systems seemed unnecessary, and the machines had little memory to spare for it.

Gary Kildall’s CP/M, written in 1974, gave early microcomputers a simple operating system for loading programs and managing disks. MS-DOS, which Microsoft supplied for the IBM PC in 1981, followed a similar approach. These systems ran one program at a time and let it touch any part of the machine. In a world where the owner was the only user, that was a reasonable choice. It made the systems small and fast and let programmers use the hardware directly.

The graphical interface changed what people thought an operating system was. Ideas developed at Xerox PARC on the Alto in the 1970s, windows, icons, a mouse, reached a mass market with Apple’s Macintosh in 1984 and later with Microsoft Windows, especially Windows 3.0 in 1990 and Windows 95. For most people, the operating system became the desktop they saw: a visual illusion of folders and documents laid over the underlying files.

The decision to drop protection carried a delayed cost. When personal computers were connected to networks and the internet in the 1990s, software from anywhere could reach them, and a system that let any program touch anything had no defence against programs that meant harm. The industry spent the following decade importing the protections that time-sharing had developed thirty years earlier. Windows NT, released in 1993 and designed by a team led by Dave Cutler, brought protected memory and multi-user security to mainstream PCs; its design became the basis of all later versions of Windows. Apple rebuilt the Macintosh on a Unix foundation with Mac OS X in 2001. By the early 2000s, the consumer operating system had absorbed the time-sharing era’s settlement: programs must be protected from each other, and the system from both.

The operating system as a commons

Running alongside the commercial systems was a different idea of who an operating system belongs to. On 27 September 1983 Richard Stallman posted an announcement that began: “Free Unix! Starting this Thanksgiving I am going to write a complete Unix-compatible software system called GNU (for Gnu’s Not Unix), and give it away free to everyone who can use it.”⁶ Over the following years the GNU project produced compilers, editors, shells and libraries, along with a licence, the GPL, that required modified versions to remain free.

The missing piece was a kernel. On 25 August 1991 Linus Torvalds, a student at the University of Helsinki, posted to a newsgroup: “I’m doing a (free) operating system (just a hobby, won’t be big and professional like gnu) for 386(486) AT clones.”⁷ Combined with the GNU tools, his kernel became the core of complete free operating systems. Early in 1992, the computer scientist Andrew Tanenbaum argued in a public exchange with Torvalds that a monolithic kernel design was outdated compared with microkernels; the debate is still remembered as a clash of two coherent design philosophies, and both approaches remain in use today.

The modesty of Torvalds’s announcement is one of the great understatements in computing. Linux became the dominant operating system for servers and for the infrastructure of the internet; every system on the TOP500 list of the world’s fastest supercomputers has run Linux since November 2017. It is also the kernel underneath Android. The theory here was that an operating system could be a commons: built by a distributed community, owned by no one, available to everyone.

Protecting the user from their own software

Phones produced the next settlement. iOS and Android, both descendants of Unix-family systems, run each app in its own sandbox: a restricted environment with its own storage, unable to see other apps’ data, and allowed to use the camera, location or contacts only with the user’s permission. Apps are mostly installed from curated stores.

This turned protection around once more. Time-sharing protected users from each other. Desktop systems protected the operating system from programs. Mobile systems protect the user from the software they choose to install. The illusion changed too. Most phone users never see a file system at all; they see apps, each a sealed world.

The result shows in today’s figures. StatCounter’s measurements of web traffic for September 2026 put Android at 42.5 percent of use across all devices worldwide, Windows at 29.0 percent, iOS at 19.5 percent, Apple’s desktop systems at about 6.4 percent combined, and desktop Linux at 1.7 percent.⁸ By this measure, the most used operating system in the world is a phone system built on the free kernel that began as a hobby.

Machines inside machines

The last great change made the illusion recursive. As early as 1972, IBM’s VM/370 gave each user a complete virtual machine, a software imitation of the hardware on which an entire operating system could run. Gerald Popek and Robert Goldberg formalised the requirements for such virtualisation in 1974. The idea returned to commodity computers with VMware in the late 1990s and became the foundation of cloud computing, in which a provider rents out virtual machines running on shared physical servers.

Containers went one step further. Rather than imitating a whole machine, the operating system gives a group of processes its own isolated view of files, network and process numbers, so that applications can be packaged with everything they need and run anywhere. Docker made the technique popular in 2013, and orchestration systems soon managed thousands of containers across data centres. Today, a single program on a cloud server may run inside a container inside a virtual machine on a physical computer shared with strangers: three layers of illusion, each giving its occupant a machine of its own.

For most people, the operating systems that matter most now run where they will never see them. The data centre has, in a real sense, become a single computer, and the operating systems coordinating it are infrastructure as invisible as plumbing.

Understanding the philosophy

An operating system is often described as the software that manages hardware. That description is accurate and hides almost everything interesting. Operating systems create convenient fictions and make them reliable; they exercise authority over programs that cannot escape it; they divide scarce resources and so must decide what fairness means; they embody judgements about simplicity and ambition; they are, in the case of Linux, one of the largest commons ever governed; they encode decisions about whom to trust; and they have become infrastructure so invisible that most people never think of it. This section takes these ideas one at a time. Each is explained in plain terms, connected to the philosophical tradition that has thought about it most carefully, traced in the history above, tested against its strongest objection, and related to computing today. The links to named philosophers are interpretations offered to make the ideas understandable; operating system designers did not, by and large, cite them.

1. Useful fictions

The idea in plain terms

Every program on your computer behaves as if it had the processor and memory to itself. It does not. Every file looks like a continuous sequence of bytes; on disk it may be scattered in pieces. The operating system tells convincing stories, and the whole of computing depends on everyone acting as if they were true.

The tradition

In The Philosophy of “As If” (1911), the German philosopher Hans Vaihinger argued that much of human thought relies on fictions: ideas known to be false or unprovable that are nonetheless indispensable because acting as if they were true produces good results. His examples ranged from mathematical idealisations to legal fictions, such as treating a company as a person. A later and more favourable reading came from the philosopher Daniel Dennett, who argued in “Real Patterns” (1991) that higher-level descriptions, such as beliefs or centres of gravity, can be entirely real in the sense that they capture genuine, predictive patterns, even though they are not physical objects.

Where it shows up

Time-sharing gave each user the fiction of a private machine; CTSS’s supervisor switched among four terminals so quickly that each user could act as if alone.¹ Virtual memory gives each program the fiction of a large, continuous memory. Unix gave devices the fiction of being files: “Special files are read and written just like ordinary disk files.”⁴ Virtual machines and containers extend the fiction recursively, so that a program can act as if it owns a computer that is itself a fiction running on another.

The strongest objection

Calling these abstractions fictions makes them sound like deceptions, and they are not. In Dennett’s sense they are real patterns: a process really does have its own address space, enforced by hardware, and a program that relies on it will behave correctly. The more precise statement is that operating systems construct new levels of reality on top of the physical machine and make them trustworthy.

What it means today

Most of what people think of as “the computer”, files, apps, windows, accounts, exists at the level of these constructed realities. Understanding that they are constructed explains both their power and their failures: when an abstraction breaks, the physical reality beneath it suddenly matters.

2. The sovereign in the machine

The idea in plain terms

On a modern system, ordinary programs cannot touch hardware directly. They must ask the kernel, which decides whether to grant the request. Programs give up direct power, and in exchange they are protected from each other.

The tradition

In Leviathan (1651), Thomas Hobbes argued that without a common power to keep them in check, people would live in a state of nature that is a “war of every man against every man,” in which life is “solitary, poor, nasty, brutish, and short.” To escape it, they agree to give up some of their liberty to a sovereign, who in return keeps the peace. John Locke later argued for a more limited government, one whose powers are constrained and accountable.

Where it shows up

Early personal computer systems such as MS-DOS were close to Hobbes’s state of nature: any program could write anywhere in memory or talk directly to hardware. That was workable when one person owned the machine and ran trusted software. When computers joined networks, it became a war of all against all, in which malicious code could do anything. Windows NT and Mac OS X restored the sovereign: a protected kernel that alone can touch the hardware, with programs reduced to petitioning it through system calls. The 1992 debate between Andrew Tanenbaum and Linus Torvalds over microkernels versus monolithic kernels can be read as a Hobbes-versus-Locke argument about how much power the sovereign itself should hold: a microkernel keeps the sovereign small, with services outside it, while a monolithic kernel concentrates more power in one place for efficiency.

The strongest objection

Programs are not citizens, and the analogy can be pushed too far. But the people who use and write programs are affected by these choices, and the analogy captures something real: protection always involves surrendering some freedom to an authority one must trust.

What it means today

Every security architecture, from sandboxed phone apps to cloud hypervisors, is a constitution of this kind. The questions Hobbes and Locke asked, how much power the authority should have, how it is limited, and what happens if it is corrupted, are exactly the questions security engineers ask about kernels.

3. Dividing a scarce machine fairly

The idea in plain terms

When many programs want the processor at once, the operating system must decide who goes first and for how long. Every answer favours someone.

The tradition

Philosophers have long debated distributive justice: how scarce goods should be shared. Aristotle argued in the Nicomachean Ethics that justice in distribution is proportional: equals should receive equal shares, and unequals unequal shares, according to some measure of merit. Utilitarian thinkers asked instead which distribution produces the greatest total good. Rawls argued that inequalities are justified only if they benefit the least advantaged.

Where it shows up

Operating system schedulers implement theories of distributive justice whether their designers think of it that way or not. Round-robin scheduling gives each process an equal turn, a strict equality. Priority scheduling gives more to processes judged more important, a form of proportional justice. Maximising throughput, the total work done, is a utilitarian goal. Giving interactive programs fast response at the cost of background work protects the people at the keyboard, the users who would suffer most from delay. Batch systems of the 1950s optimised for the machine’s total utilisation; time-sharing, as the CTSS history puts it, shifted priority toward “getting programs written,” toward the people.¹

The strongest objection

Processes have no interests of their own, so calling scheduling a matter of justice may seem a category error. The reply is that every process stands for someone’s work, and on shared machines, from time-sharing systems to cloud servers, the scheduler decides whose work waits.

What it means today

In cloud computing, scheduling decides how resources are divided among paying customers; in phones, it decides whether a background task can drain a battery. Every such decision embodies a view of fairness that can be examined and argued about.

4. Simplicity and ambition

The idea in plain terms

Some systems try to do everything correctly and completely. Others do less, more simply, and let users combine the pieces. The second kind has often spread further, even when the first was better designed in principle.

The tradition

Ockham’s razor, the medieval principle that one should not multiply entities beyond necessity, is the classic statement of parsimony. In computing, Richard Gabriel’s essay “The Rise of Worse is Better” (written in 1989) described two design philosophies: the “MIT approach,” which values correctness and completeness of the interface even at the cost of implementation complexity, and the “New Jersey approach,” associated with Unix and C, which values simplicity of implementation above all. Gabriel argued, uncomfortably, that the simpler approach tends to win because it is easier to port, adopt and improve.

Where it shows up

Multics aimed to be a complete computing utility; Unix aimed, in the words of its creators, to show “that a powerful operating system for interactive use need not be expensive either in equipment or in human effort.”³ McIlroy’s maxims, “Make each program do one thing well,” are a philosophy of parsimony.⁵ Ritchie’s description of C as “quirky, flawed, and an enormous success” is the essence of worse-is-better.

The strongest objection

Simplicity can be a debt. The simplicity of early Unix and personal computer systems left out protections that later had to be added at great cost, and some of the security problems of C-based systems are the long-term price of New Jersey simplicity. Ambitious systems such as Multics also contributed ideas, especially about security, that others later adopted.

What it means today

Parsimony is a strategy for spreading, not a guarantee of being right. The Unix lesson is that small, composable designs travel; the Multics lesson is that some things left out at the beginning must eventually be put back.

5. The operating system as a commons

The idea in plain terms

Linux is owned by no one, built by thousands of people and companies, and used by billions of devices. That should, by some theories, be impossible to sustain.

The tradition

In a famous 1968 essay, the ecologist Garrett Hardin described the tragedy of the commons: when a resource is shared freely, each user has an incentive to overuse it, and the resource is ruined. The political economist Elinor Ostrom, whose work earned her the Nobel Prize in economics in 2009, showed in Governing the Commons (1990) that communities around the world have successfully managed shared resources for centuries, through rules they set themselves: clear boundaries, collective decision-making, monitoring, graduated sanctions and mechanisms for resolving conflicts.⁹

Where it shows up

Stallman’s GNU announcement promised software given “away free to everyone who can use it,” protected by a licence that keeps it free.⁶ Linux, begun as “just a hobby,” grew into a commons governed by a structure Ostrom would recognise: maintainers responsible for subsystems, public review of contributions, a final authority for merges, and norms about what is accepted.⁷ Software is not depleted by use, which removes Hardin’s central problem, but the commons still faces the challenge of maintenance: someone must do the work.

The strongest objection

Much of modern Linux development is funded by large companies, which makes it less a community commons than a shared industrial resource. And critical open-source components are sometimes maintained by very few people, a fragility that has led to serious security incidents in the wider ecosystem.

What it means today

The foundations of the internet are, to a remarkable extent, governed commons. Their sustainability depends on whether those who benefit contribute to their maintenance, a question Ostrom’s principles address directly.

6. Trust, and who is protected from whom

The idea in plain terms

Every operating system decides whom to trust: other users, the programs one installs, the software that built those programs. Each era drew those lines differently.

The tradition

The philosopher Annette Baier argued in “Trust and Antitrust” (1986) that trust is accepted vulnerability to another’s goodwill: to trust someone is to let them be in a position to harm you, relying on them not to. In computing, the classic statement of the limits of trust came from Ken Thompson, co-creator of Unix, in his 1984 Turing Award lecture, “Reflections on Trusting Trust.” He showed how a compiler could be altered to insert a hidden back door into programs, including future versions of itself, in a way no inspection of the source code would reveal, and concluded that “you can’t trust code that you did not totally create yourself.”¹⁰

Where it shows up

Time-sharing systems distrusted other users and protected their files. Personal computers trusted everything. Networked systems learned to distrust code from outside. Mobile operating systems sandbox every app, protecting users from software they themselves chose to install. Cloud platforms isolate tenants who share the same hardware. Thompson’s lecture explains why none of these arrangements can be absolute: every system ultimately rests on some layer that must simply be trusted.

The strongest objection

Total distrust is impossible and paralysing. Society, and computing, run on reasonable trust in institutions, processes and reputations. The question is not whether to trust but how to make trust well placed: through transparency, verification where possible, and accountability.

What it means today

Supply-chain attacks on software, in which trusted tools or updates are compromised, are Thompson’s lecture made real. The industry’s response, reproducible builds, signed software, auditable components, is an attempt to give Baier’s accepted vulnerability better grounds.

7. Infrastructure that disappears

The idea in plain terms

Most people never think about the operating systems that run the services they use every day. That invisibility is a sign of success, and it also hides where power and fragility lie.

The tradition

The sociologist Susan Leigh Star observed in “The Ethnography of Infrastructure” (1999) that infrastructure is by definition largely invisible, and that it “becomes visible upon breakdown.”¹¹ Heidegger’s distinction between tools that are ready-to-hand and those that become conspicuous when broken, discussed in the mobile essay, describes the same experience at the scale of a single object.

Where it shows up

The history of operating systems is a history of disappearance. Users once dealt directly with job control languages and command lines; then with desktops; then with apps that hide files entirely; now with cloud services whose operating systems run in data centres no user will see. The OS has become, as the essay’s history notes, infrastructure as invisible as plumbing. When a major cloud provider or a widely used system component fails, the invisible layer suddenly becomes visible to millions at once.

The strongest objection

Invisibility is what people want from infrastructure. No one wishes to think about plumbing, and there is no virtue in making people manage what can be managed for them.

What it means today

Invisible infrastructure concentrates both expertise and power in those who run it. Understanding, at least roughly, the layers beneath the services one depends on, who operates them, and what happens when they fail, is part of being an informed user in an age when the computer of one’s own is increasingly a rented fiction in someone else’s building.

Bringing the threads together

Philosophically, an operating system is a small society. It constructs useful fictions and makes them real. It establishes a sovereign and limits it. It distributes scarce resources according to some theory of fairness. It chooses between simplicity and completeness. In the case of free software, it is a commons that must be governed. It decides whom to trust and rests, finally, on trust it cannot verify. And when it works well, it disappears. The history traced above, from batch monitors to containers, is the history of how those arrangements were renegotiated as the people sharing machines, and the dangers they faced, changed.

Sharing that feels like ownership

Return to the question at the start. Operating systems spend their lives creating illusions because the problem they solve is sharing: a machine is always scarcer than the demands on it, whether those demands come from many people at terminals, many programs on a phone or many customers in a data centre. The operating system’s task is to divide that machine fairly and safely while letting each user and each program behave as though it owned the whole thing.

Every era settled that problem differently, and each settlement was a kind of political arrangement: how resources are allocated, who is trusted, who is protected from whom. Corbató’s four terminals, Ritchie’s fellowship, the single owner of a personal computer, the sandboxed app and the rented virtual machine are all answers to the same question. What has changed is who the occupants are and what they fear. What has not changed is the promise. However many others share it, the operating system’s job is to give each of us, convincingly and safely, a computer of our own.

Selected bibliography

• Walden, David, and Tom Van Vleck, eds. The Compatible Time Sharing System (1961–1973): Fiftieth Anniversary Commemorative Overview. IEEE Computer Society, 2011. PDF
• Corbató, F. J., M. Merwin-Daggett, and R. C. Daley. “An Experimental Time-Sharing System.” AFIPS Spring Joint Computer Conference (1962).
• Ritchie, Dennis M., and Ken Thompson. “The UNIX Time-Sharing System.” Communications of the ACM 17, no. 7 (July 1974): 365–375. PDF
• Ritchie, Dennis M. “The Evolution of the Unix Time-sharing System.” 1979; AT&T Bell Laboratories Technical Journal 63, no. 8 (1984). Text
• McIlroy, M. D., E. N. Pinson, and B. A. Tague. “UNIX Time-Sharing System: Foreword.” Bell System Technical Journal 57, no. 6 (1978): 1899–1904.
• Brooks, Frederick P. The Mythical Man-Month. Addison-Wesley, 1975.
• Stallman, Richard. “Initial Announcement” of the GNU Project, 27 September 1983. gnu.org
• Torvalds, Linus. “What would you like to see most in minix?” Post to comp.os.minix, 25 August 1991.
• Popek, Gerald J., and Robert P. Goldberg. “Formal Requirements for Virtualizable Third Generation Architectures.” Communications of the ACM 17, no. 7 (1974): 412–421.
• StatCounter Global Stats. “Operating System Market Share Worldwide.” gs.statcounter.com
• Vaihinger, Hans. The Philosophy of “As If”. 1911; trans. C. K. Ogden, 1924.
• Dennett, Daniel C. “Real Patterns.” Journal of Philosophy 88, no. 1 (1991).
• Hobbes, Thomas. Leviathan. 1651.
• Locke, John. Two Treatises of Government. 1689.
• Gabriel, Richard P. “The Rise of Worse is Better.” From “Lisp: Good News, Bad News, How to Win Big,” 1989–1991.
• Hardin, Garrett. “The Tragedy of the Commons.” Science 162 (1968).
• Ostrom, Elinor. Governing the Commons. Cambridge University Press, 1990.
• Baier, Annette. “Trust and Antitrust.” Ethics 96, no. 2 (1986).
• Thompson, Ken. “Reflections on Trusting Trust.” Communications of the ACM 27, no. 8 (1984).
• Star, Susan Leigh. “The Ethnography of Infrastructure.” American Behavioral Scientist 43, no. 3 (1999).

Research limitations

The 1962 CTSS paper was not consulted directly; early time-sharing at MIT is described from the IEEE Computer Society’s 2011 commemorative history, which draws on participants’ accounts. Ritchie’s explanation of why Bell Labs left Multics is his own recollection and should be read as one participant’s view of a system that was influential in its own right. Descriptions of OS/360, early personal computer systems, Windows NT and virtualisation draw on standard histories rather than primary documents. StatCounter measures share of web traffic, not installed devices, and its figures vary with methodology. The reading of operating system history as a sequence of settlements about illusion and protection is the author’s interpretation. The philosophical section relates operating systems to Vaihinger, Dennett, Hobbes, Locke, Aristotle, Rawls, Ockham, Gabriel, Hardin, Ostrom, Baier, Thompson and Star; apart from Gabriel’s and Thompson’s writings about software, these connections are the author’s interpretation, offered to make the ideas understandable.

Footnotes

1. David Walden and Tom Van Vleck, eds., The Compatible Time Sharing System (1961–1973): Fiftieth Anniversary Commemorative Overview (IEEE Computer Society, 2011), section 2, “Early history of CTSS.” ↩ ↩² ↩³ ↩⁴ ↩⁵

2. Dennis M. Ritchie, “The Evolution of the Unix Time-sharing System,” section “Origins.” ↩

3. Dennis M. Ritchie and Ken Thompson, “The UNIX Time-Sharing System,” Communications of the ACM 17, no. 7 (July 1974), p. 365. ↩ ↩²

4. Ritchie and Thompson (1974), §3.3 “Special Files,” p. 367. ↩ ↩²

5. M. D. McIlroy, E. N. Pinson and B. A. Tague, “UNIX Time-Sharing System: Foreword,” Bell System Technical Journal 57, no. 6 (July–August 1978), p. 1902. ↩ ↩²

6. Richard Stallman, “Initial Announcement,” posted to net.unix-wizards and net.usoft, 27 September 1983, gnu.org/gnu/initial-announcement.html. ↩ ↩²

7. Linus Torvalds, post to comp.os.minix, 25 August 1991, reproduced at cs.cmu.edu. ↩ ↩²

8. StatCounter Global Stats, “Operating System Market Share Worldwide,” September 2026, all platforms; OS X and macOS are listed separately (4.05 and 2.32 percent). ↩

9. Elinor Ostrom, Governing the Commons: The Evolution of Institutions for Collective Action (Cambridge University Press, 1990). ↩

10. Ken Thompson, “Reflections on Trusting Trust,” 1983 ACM Turing Award lecture, Communications of the ACM 27, no. 8 (August 1984): 761–763. ↩

11. Susan Leigh Star, “The Ethnography of Infrastructure,” American Behavioral Scientist 43, no. 3 (1999): 377–391. ↩