Before the questions, make sure you can: explain what an operating system does from the user's view and from the system's view; describe the OS as a resource manager and name the resources it manages; trace the evolution of operating systems from serial processing and batch systems to multiprogramming, time-sharing, personal, mobile, cloud and edge systems, and say which problem each step solved; distinguish batch, multiprogramming, time-sharing, multiprocessor, distributed, network, real-time, embedded and mobile operating systems; compute CPU utilization under multiprogramming with the model 1 − pⁿ; state the goals of an OS and the trade-offs between them; list the generic components of an OS; use Amdahl's law to compute the speedup of a program on several cores; and explain why the same resource-management questions appear on a phone, a server, a cloud and an edge network.
Every computer — a phone, a laptop, a server in a data centre, a small edge server in a campus building — has more demands than resources: more programs than CPUs, more data than fast memory, more requests than network bandwidth. The operating system is the software that decides who gets what, when, and for how long, while hiding the messy hardware behind clean abstractions. This course studies those decisions — first inside one machine, then across many machines, up to the edge–cloud systems where today's most interesting resource-management problems (and a lot of current research) are found.
What is an operating system?
An operating system (OS) is the layer of software between the hardware and the applications. It can be seen from two sides:
- User view — the OS as an extended machine. It hides the hardware details and offers convenient abstractions: files instead of disk sectors, processes instead of raw CPU registers, sockets instead of network-card buffers, windows instead of pixels. A programmer writes
open("notes.txt")and never thinks about disk heads. - System view — the OS as a resource manager. It allocates the CPU, memory, storage, devices and network among competing programs and users, fairly, efficiently and securely.
Think of a busy restaurant. Customers (applications) see a simple menu and a waiter (the user view). Behind the kitchen door, a manager decides which order the cooks prepare first, which table gets the next free seat, and who may enter the storeroom (the system view). The OS is both the waiter and the kitchen manager.
| Resource | What the OS decides | Chapter |
|---|---|---|
| CPU (cores, GPUs) | Which process or task runs, on which core, for how long | 4–6 |
| Memory | Who gets which part of RAM; what stays on disk | 9–10 |
| Storage | Where files live; in which order disk requests are served | 11 |
| Devices and network | Who may use them, and how requests are queued | 2, 11 |
| Machines (servers, VMs, edge nodes) | Where a job or container runs; when to rent more | 6, 12, 13 |
How we got here: a short history
Each generation of operating systems solved a problem the previous one could not:
| Period | Step | Problem solved |
|---|---|---|
| 1940s–50s | Serial processing — one user at a time, with a sign-up sheet | — (the expensive machine sat idle between users) |
| Mid 1950s | Batch systems — jobs collected and run one after another by a resident monitor | Idle time between jobs |
| 1960s | Multiprogramming — several jobs in memory; when one waits for I/O, another uses the CPU | CPU idle during slow I/O |
| 1960s–70s | Time-sharing (CTSS 1961, MULTICS, UNIX 1969–71) — many interactive users, each gets short time slices | Long waits for interactive users |
| 1980s–90s | Personal computers and networked OSs (MS-DOS 1981, Windows, Linux 1991) | Computing for everyone |
| 2000s | Mobile OSs (iOS 2007, Android 2008): battery, touch, sensors, app sandboxes | Computing in the pocket |
| 2006 → | Cloud (e.g., Amazon EC2, 2006): virtual machines rented by the hour; later containers (Docker 2013) and orchestration (Kubernetes 2014) | Buying capacity on demand |
| 2015 → | Edge computing: small data centres close to users (a campus, a base station) | Latency that the distant cloud cannot offer |
The key idea behind every step is the same: keep expensive resources busy while keeping users waiting as little as possible.
Multiprogramming and CPU utilization
Most programs spend much of their time waiting for I/O (disk, network, the user). If one program runs alone, the CPU is idle during those waits. Multiprogramming keeps several programs in memory so another one can run.
A simple probabilistic model: if each process waits for I/O a fraction p of its time, and there are n independent processes in memory, the CPU is idle only when all of them wait at once, which has probability pⁿ. So:
CPU utilization ≈ 1 − pⁿ
Worked example (p = 0.8, i.e., processes wait for I/O 80% of the time):
| Processes in memory (n) | Utilization 1 − 0.8ⁿ |
|---|---|
| 1 | 20.00% |
| 2 | 36.00% |
| 4 | 59.04% |
| 10 | 89.26% |
To reach at least 90% with p = 0.8, you need n = 11 processes; with p = 0.5 only n = 4. The model is simple (real processes are not independent), but it explains why operating systems want many processes in memory — and why memory size limited multiprogramming for decades (Chapter 9).
Types of operating systems
| Type | Key idea | Example |
|---|---|---|
| Batch | Jobs run one after another without interaction | Payroll runs, today: overnight data-processing jobs |
| Multiprogramming | Several jobs in memory, CPU switches when one waits | The basis of every modern OS |
| Time-sharing / multitasking | Short time slices give each user the illusion of a private machine | Linux, Windows, macOS |
| Multiprocessor | Several CPUs/cores share memory; the OS schedules across them | Every laptop and server today |
| Network OS | Separate machines that share files and printers; users know which machine they use | Windows Server file sharing |
| Distributed OS | Many machines appear as one system (transparency) | Research systems; ideas live on in cluster managers |
| Real-time | Correctness depends on meeting deadlines (hard: never miss; soft: rarely miss) | Car brakes (hard), video streaming (soft); VxWorks, QNX |
| Embedded | Small, specialized, often real-time | Routers, washing machines, IoT sensors |
| Mobile | Energy, touch, sensors, app isolation | Android, iOS |
| Cloud / edge platforms | Resources of many machines managed as a pool, rented on demand | Hypervisors, Kubernetes |
- Multiprogramming: several programs in memory so the CPU is kept busy (switch when one waits).
- Multitasking / time-sharing: switching often (time slices) so each interactive user or task gets a quick response.
- Multiprocessing: several CPUs or cores really run things at the same moment. A modern laptop does all three.
Goals of an operating system — and their conflicts
- Convenience — easy to use and to program.
- Efficiency — high utilization of CPU, memory and devices; high throughput.
- Responsiveness — short response times for interactive users.
- Fairness — no process starves.
- Reliability and protection — one faulty or malicious program cannot crash or spy on others.
- Scalability — works from one core to thousands.
- Energy efficiency — essential on phones and in data centres.
Goals conflict: running each job to completion maximizes throughput but hurts responsiveness; checking every memory access protects programs but costs time; aggressive power saving slows programs. Much of this course is about trade-offs.
Generic components of an OS
- Process and thread management — creation, scheduling, synchronization, termination.
- Memory management — allocation, protection, virtual memory.
- File and storage management — files, directories, disks.
- I/O and device management — drivers, buffering, interrupts.
- Networking — protocols and sockets.
- Protection and security — authentication, access control, isolation.
- User interface — command line (shell) and graphical.
The kernel is the core part that runs with full hardware privileges (Chapter 2).
Parallelism and Amdahl's law
Adding cores (or servers, or GPUs) only helps the part of a program that can run in parallel. If a fraction P of the work can be parallelized over N processors, Amdahl's law gives the speedup:
Speedup(N) = 1 / ((1 − P) + P / N)
For P = 0.9:
| N cores | Speedup | Efficiency (speedup / N) |
|---|---|---|
| 2 | 1.818 | 90.9% |
| 4 | 3.077 | 76.9% |
| 8 | 4.706 | 58.8% |
| 16 | 6.400 | 40.0% |
| ∞ | 10.000 | → 0% |
Even with unlimited cores, the 10% serial part limits the speedup to 10×. This is why schedulers care about the structure of the work (Chapter 6), not only the number of machines.
The modern picture: the device–edge–cloud continuum
Today's applications run across three layers, each with its own OS and its own resource manager:
| Layer | Resources | Typical latency from the user | Main constraints |
|---|---|---|---|
| Device (phone, sensor) | Weak CPU, small battery | 0 ms (local) | Energy, heat, limited computing |
| Edge (server in the building or at the base station) | A few servers, maybe GPUs | ~1–10 ms | Limited capacity, shared by many users |
| Cloud (large data centre) | "Unlimited" servers, rented | ~30–150 ms | Distance (latency), cost, privacy |
EdgeCampus, our running case, is a smart-campus platform at WKU: students' phones run CampusAR (augmented-reality navigation and lecture capture), each building has a small edge cluster with GPUs, and a public cloud region handles heavy, non-urgent work. One AR frame raises every question of this course: Should the phone process it itself or offload it (Chapter 13)? Which edge server and which GPU should run it (Chapters 5–6)? How much memory does it get (Chapters 9–10)? What if the edge is full — rent cloud capacity (Chapter 12)? Who may see the camera images (Chapter 14)?
Deciding where and when to run tasks on heterogeneous resources — CPUs, GPUs, edge servers, cloud VMs — under deadlines, budgets and energy limits is an active research field. Classic ideas you will learn (priority queues, list scheduling, bin packing) are the building blocks of research algorithms for workflow scheduling, cloud provisioning and edge offloading, including machine-learning approaches. Chapters 6, 12 and 13 take you to the research frontier.
The skills in this course are daily work in industry: site-reliability engineers tune Linux schedulers and memory limits, cloud engineers size clusters and autoscalers, mobile developers fight for battery and memory, and platform teams run Kubernetes clusters that are, in effect, operating systems for whole data centres.
Key takeaways
- An OS is both an extended machine (abstractions) and a resource manager (allocation, fairness, protection).
- Each generation — batch, multiprogramming, time-sharing, PC, mobile, cloud, edge — solved a resource or responsiveness problem of the previous one.
- Multiprogramming: utilization ≈ 1 − pⁿ; more processes in memory keep the CPU busy.
- Know the OS types (batch, time-sharing, multiprocessor, network, distributed, real-time, embedded, mobile, cloud/edge) and the difference between multiprogramming, multitasking and multiprocessing.
- OS goals (convenience, efficiency, responsiveness, fairness, protection, scalability, energy) conflict; design is about trade-offs.
- Amdahl's law: speedup = 1 / ((1 − P) + P/N) — the serial part limits scaling.
- The same resource-management questions repeat on the device, edge and cloud — the thread of this course.
Ready? Close the notes and practise.
30 questions. Predict the output before you check — that is the skill the exam measures.