An operating system (OS) is the software layer between hardware and applications. It is a resource manager and a referee, providing three great abstractions so that programs need not touch raw hardware: the process (a running program), virtual memory (each process sees its own private address space), and the file (a named, persistent stream of bytes).

Because there are more processes than CPU cores, the OS scheduler rapidly switches the CPU between processes — a context switch saves one process's state and restores another's — creating the illusion of simultaneous execution (concurrency). Virtual memory, via paging, gives every process a clean, contiguous-looking address space that the hardware's MMU maps to scattered physical RAM (and to disk when RAM is full).

The OS runs privileged code in kernel mode and applications in restricted user mode; a program requests OS services through a system call, the controlled gateway across that boundary. This protection is what stops one buggy app from crashing the whole machine or reading another's memory.

The unifying job of an OS is sharing scarce resources safely and fairly among untrusting programs. Time-sharing the CPU gives responsiveness; space-sharing memory with isolation gives security; mediating I/O gives a uniform interface to wildly different devices. Every OS feature is a variation on "many want this resource; grant access without letting them corrupt each other."

Concurrency is powerful but perilous. When multiple threads touch shared data, their operations can interleave badly — a race condition — producing wrong results that appear only sometimes. The fix is synchronisation (locks, mutexes, semaphores) to enforce mutual exclusion over a critical section. But locks introduce their own hazard, deadlock: two threads each holding a lock the other needs, both waiting forever. Managing this tension is among the hardest parts of systems programming.

We simulate a scheduler running two well-known policies — FCFS (first-come-first-served) and Round Robin (time-sliced) — and compare the average wait, illustrating why time-slicing improves responsiveness.

# Each process: (name, burst) = CPU time it needs.
jobs = [("A", 6), ("B", 2), ("C", 4)]

def fcfs(jobs):
    """Run each job to completion in arrival order. Simple but poor for short jobs."""
    time, waits = 0, {}
    for name, burst in jobs:
        waits[name] = time          # this job waited for all prior jobs
        time += burst
    return waits

def round_robin(jobs, quantum=2):
    """Give each job a fixed time slice, cycling until all finish -> fair, responsive."""
    from collections import deque
    remaining = deque((name, burst) for name, burst in jobs)
    time, finish = 0, {}
    while remaining:
        name, burst = remaining.popleft()
        run = min(quantum, burst)   # run for at most one quantum
        time += run
        burst -= run
        if burst == 0:
            finish[name] = time     # completed
        else:
            remaining.append((name, burst))   # not done -> back of the queue
    return finish

print("FCFS waits:      ", fcfs(jobs))
# {'A': 0, 'B': 6, 'C': 8}  -> short job B waits 6 behind the long job A

print("Round Robin done:", round_robin(jobs))
# {'B': 4, 'C': 10, 'A': 12} -> B finishes early; no job monopolises the CPU

Under FCFS the short job B is stuck behind the long job A (the "convoy effect"). Round Robin slices time so B finishes quickly and no process hogs the CPU — the essence of an interactive, responsive system. The cost is extra context switches, the eternal scheduling trade-off.