What if a collection of networked computers could appear as a single, coherent system? Users wouldn't know—or need to know—which machine runs their process, which disk stores their file, or which CPU performs their computation. The illusion would be seamless: one unified, powerful virtual computer built from many physical machines.

This is the vision of Distributed Operating Systems—systems designed from the ground up to manage multiple computers as a unified resource, providing transparency, fault tolerance, and scalability impossible with single-machine systems.

Distributed systems introduce challenges absent in conventional OS: network latency, partial failures, clock synchronization, and the fundamental impossibility of achieving certain consistency guarantees simultaneously. Understanding these systems requires grappling with trade-offs that have no clean solutions—only engineering choices appropriate to specific contexts.

Not all systems spanning multiple computers are 'distributed operating systems.' Understanding the spectrum clarifies what truly distinguishes distributed OS design.

The Single System Image (SSI):

The defining characteristic of a true distributed OS is the single system image—the appearance that multiple machines constitute one unified computer. This manifests as:

1. Unified Namespace — All resources (files, devices, processes) have globally unique names, regardless of physical location.

2. Location Transparency — Access to a resource doesn't require knowing its location. The system routes requests automatically.

3. Seamless Process Execution — Users launch processes without specifying where they run. The system places and potentially migrates them.

4. Coherent State — Changes to shared resources are visible consistently across all nodes.

5. Fault Masking — Individual node failures don't manifest as system failures (to the extent possible).

Distributed systems aim to hide complexity through various forms of transparency—making the distributed nature invisible to users and applications. The ISO Reference Model for Open Distributed Processing identifies eight types:

Case Study: Plan 9 from Bell Labs

Plan 9 (successor to UNIX, also from Bell Labs) achieved extraordinary transparency through a simple idea: everything is a file, accessed through a unified namespace, composable across machines.

# On Plan 9, import another machine's screen:
import graphicsbox /dev

# Now /dev/draw shows the remote display
# Local programs draw there transparently

# Import another machine's CPU:
import cpuserver /mnt/cpu

# Process execution can transparently use remote CPU

Each machine exports resources as files. Any machine can mount any other machine's resources, creating a unified namespace tailored to each user. The system achieved remarkable transparency with minimal complexity—though it never achieved widespread adoption outside research.

Distributed systems face challenges that are not merely difficult but provably impossible to solve completely. Understanding these impossibility results is crucial for making informed design trade-offs.

Distributed systems require mechanisms to coordinate actions across nodes: mutual exclusion (ensuring only one node accesses a resource), leader election, and atomic commit (ensuring all-or-nothing transactions).

Distributed Mutual Exclusion:

When multiple nodes may access a shared resource, how do we ensure only one accesses it at a time?

Centralized Approach:

1. Designate one node as coordinator
2. Nodes request lock from coordinator
3. Coordinator grants if free, queues otherwise
4. On release, grant to next in queue

Advantages: Simple, fair
Disadvantages: Single point of failure, coordinator bottleneck

Token Ring Approach:

1. Arrange nodes in logical ring
2. A token circulates around the ring
3. Node can enter critical section only when holding token
4. After use, pass token to next node

Advantages: No central coordinator, fair
Disadvantages: Token loss requires recovery, high latency if ring is large

Ricart-Agrawala Algorithm:

1. To enter critical section, broadcast REQUEST to all nodes
2. Each receiving node replies REPLY if:
   - Not interested in entering, OR
   - Has lower timestamp (other request has priority)
3. Wait for REPLY from all nodes
4. Enter critical section
5. On exit, send deferred REPLYs

Advantages: Fully distributed, no single point of failure
Disadvantages: High message overhead (2(n-1) messages)

Leader Election:

Many distributed algorithms require a designated leader (coordinator). Leader election algorithms ensure exactly one leader emerges, even after failures.

File systems are the most visible manifestation of distributed OS—enabling access to files stored across many machines as if they were local. Each distributed file system makes different trade-offs in consistency, availability, and performance.

Design Dimensions:

Case Study: Google File System (GFS)

GFS revolutionized distributed storage by accepting trade-offs appropriate for Google's workloads:

Assumptions:

• Files are huge (multi-GB common)
• Workloads are append-heavy, random writes rare
• High throughput more important than low latency
• Component failures are routine, not exceptional

Architecture:

┌──────────────────────────────────────────────────────────────┐
│                           GFS Master                          │
│  • File/chunk namespace                                       │
│  • Chunk location mapping                                     │
│  • Lease management                                           │
│  (Single master, replicated for recovery)                     │
└─────────────────────────┬────────────────────────────────────┘
                          │ Metadata operations
┌─────────────────────────┼────────────────────────────────────┐
│  Client                 │                                     │
│  ┌──────────┐          ▼                                     │
│  │App       │    ┌────────────┐                              │
│  │Code      │───▶│GFS Client  │                              │
│  └──────────┘    └─────┬──────┘                              │
│                        │ Data operations (direct)             │
└────────────────────────┼─────────────────────────────────────┘
                         ▼
┌──────────────────────────────────────────────────────────────┐
│             Chunk Servers (thousands)                         │
│  ┌─────────┐  ┌─────────┐  ┌─────────┐  ┌─────────┐         │
│  │64MB     │  │64MB     │  │64MB     │  │64MB     │  ...    │
│  │Chunks   │  │Chunks   │  │Chunks   │  │Chunks   │         │
│  │(3x rep) │  │(3x rep) │  │(3x rep) │  │(3x rep) │         │
│  └─────────┘  └─────────┘  └─────────┘  └─────────┘         │
└──────────────────────────────────────────────────────────────┘

Relaxed Consistency: GFS doesn't provide POSIX semantics. Concurrent appends may result in record duplication or interleaving. Applications must handle this—an acceptable trade-off for massive scale.

Several research systems pioneered distributed OS concepts, proving the vision achievable even if they never achieved mass adoption.

While true distributed operating systems never achieved mass adoption, their principles live on in modern cloud platforms and container orchestration systems.

Kubernetes as a Distributed OS

Kubernetes, though called a 'container orchestration system,' embodies many distributed OS concepts:

Modern Coordination Services:

Distributed systems require coordination primitives that the distributed OS concepts formalized. Modern systems use specialized coordination services:

We've explored the ambitious vision of distributed operating systems—making many computers appear as one unified system—and the fundamental challenges that make this goal always partially elusive.

What's Next:

We've explored systems that scale to many machines. Next, we'll examine Embedded Operating Systems—the OS domain where the challenge isn't scale or distribution, but extreme resource constraints: tiny memory, limited CPU, power budgets, and physical constraints that desktop computing never faces.