Lesson 1.1: What Is an Operating System?

01 Introduction

Every computer you have ever used runs an operating system, but the operating system itself is almost invisible. You interact with a window manager, a shell, or a mobile app; the layers beneath are rarely noticed until something goes wrong. Yet without an operating system, a modern processor would be almost unusable — a collection of registers and memory cells with no convenient way to run more than one program, no file to save your work in, and no protection between different tasks.

This lesson establishes the two complementary ways of thinking about an operating system that will recur throughout the course:

As a resource manager — the software that arbitrates access to the CPU, memory, storage, and devices among many competing programs.
As an extended machine — the software that hides the messy details of the hardware and presents a clean, convenient interface for programmers.

Both views are correct. Neither is complete on its own. Understanding how they fit together is the foundation for everything that follows.

02 Learning objectives

By the end of this lesson you will be able to

Define an operating system.
Describe the operating system as a resource manager.
Describe the operating system as an extended machine.
Explain key operating-system functions.
Explain why operating systems are essential.

This lesson contributes to U1.1 and course learning outcome CLO1.

03 Required reading

OSTEP — Chapter 1, A Dialogue on the Book. The two characters in the dialogue introduce the three "easy pieces" — virtualization, concurrency, and persistence — that organise the entire text.

How to read OSTEP Chapter 1

The dialogue is not decoration. The professor in the dialogue is modelling a habit you should adopt: whenever a program runs, ask what is the OS doing underneath this? Keep that question in mind for the rest of the course.

04 Core content

4.1 A working definition

There is no single universally agreed definition, but the following is precise enough to be useful:

An operating system is the software that manages a computer's hardware resources and provides a set of abstractions and services on which application programs can be built and executed.

Two things in that definition deserve emphasis. First, the operating system manages hardware — it is the layer that decides which program gets the CPU, which memory address maps to which physical frame, and which process may open which file. Second, it provides abstractions — it offers concepts like "process", "file", and "socket" that do not exist in hardware but make programs vastly easier to write.

4.2 The operating system as resource manager

A computer has a finite set of resources: one or more CPUs, a fixed amount of physical memory, some number of storage devices, network interfaces, and peripherals. Many programs want to use those resources at the same time, and their demands conflict. The operating system resolves those conflicts.

Consider a small example. Three programs are running on a laptop:

a web browser rendering a page,
a music player decoding audio,
a background backup copying files to an external disk.

All three want CPU time, all three want memory, and two of them want to read from storage. The operating system must:

Multiplex the CPU — switch rapidly between programs so each makes progress and the user perceives them as running simultaneously.
Allocate memory — give each program a private region and prevent one from reading or corrupting another's data.
Schedule I/O — order competing disk and network requests so that the backup does not starve the music player.
Enforce policy — decide who gets priority, how much, and for how long.

Resource management is an optimisation problem

There is rarely a single "correct" answer. Two schedulers can both be fair and both be efficient in different senses. Part of what you will learn in this course is how to compare competing policies and reason about the trade-offs between them.

4.3 The operating system as extended machine

Hardware is hostile to programmers. To read one sector from a disk, a driver must program a device controller, wait for an interrupt, handle error codes, and translate between the device's view of the world and the CPU's. Doing this correctly is difficult, and doing it once per program would be absurd.

The operating system hides this complexity behind abstractions. A program that wants to read a file calls read(); the operating system translates that into device operations. A program that wants to create a new execution context calls fork(); the operating system creates a process. From the program's point of view, the hardware looks like a small, tidy set of operations rather than a collection of devices.

Figure 1.1 — Two views of the same software. As resource manager (left) the OS arbitrates between competing programs. As extended machine (right) it hides device detail behind clean abstractions.

4.4 Key functions of an operating system

The two roles expand into a set of concrete responsibilities. Every general-purpose operating system performs all of the following, regardless of whether it runs on a phone, a server, or a supercomputer:

Process management: Create, schedule, suspend, resume, and terminate processes and threads; provide mechanisms for interprocess communication and synchronization.
Memory management: Allocate and reclaim memory; give each process an isolated address space; implement virtual memory so that programs can use more memory than is physically present.
File-system management: Provide a naming and storage abstraction for persistent data; organise files into directories; manage free space, metadata, access permissions, and reliability.
I/O and device management: Hide device-specific behaviour behind a uniform interface; schedule I/O requests; handle interrupts and errors.
Protection and security: Prevent one process from interfering with another; authenticate users; enforce access-control policy; resist external attack.
Networking: Provide protocols and interfaces for communication between processes on the same machine or across a network.
User interface: Offer a way for humans to interact with the machine — a command shell, a graphical desktop, or a touch-based mobile interface.

4.5 Why operating systems are essential

It is worth asking why an operating system is needed at all. In principle, a programmer could write code that drives the hardware directly. In practice, several forces make this unworkable.

Multiplexing

Hardware can only do one thing at a time per core. Sharing it safely between programs is a non-trivial problem that no individual application should have to solve.

Isolation

Without protection, a bug in one program can corrupt another or crash the machine. The OS enforces the boundaries that make multi-programming safe.

Portability

Device interfaces differ enormously. The OS presents a uniform view so that a program written for one machine can run on another with the same OS.

Productivity

Writing against a rich abstraction layer is orders of magnitude faster than writing against raw hardware.

Security

Modern systems handle sensitive data. Authentication, authorization, and audit are OS-level concerns that cannot be safely delegated to individual applications.

05 Worked example

To make the abstractions concrete, trace what happens when you type a single command in a shell:

ls /home

Every step involves the operating system

The shell reads your keystrokes. The terminal driver (part of the OS) translates physical key events into characters delivered to the shell process.
The shell parses the command. It recognises ls as a program name and /home as an argument. To run ls, the shell asks the OS to create a new process — via a system call such as fork() — and then to replace that process image with the ls binary via execve().
The OS loads the binary. The kernel opens the ls executable, reads its header, maps its text and data segments into the new process's virtual address space, sets up a stack, and transfers control to its entry point.
ls opens the directory. It calls open("/home", O_RDONLY). The kernel resolves the path, checks permissions, finds the inode, and returns a file descriptor. Each directory entry is then read via getdents().
ls writes its output. It calls write() to descriptor 1 (standard output), which is connected by the shell to your terminal. The kernel buffers, schedules, and finally hands the bytes to the terminal driver.
ls exits. It calls exit(). The kernel tears down the address space, closes open descriptors, and notifies the parent (the shell).
The shell resumes. It prints the next prompt. Meanwhile the OS has been quietly scheduling other processes on the same CPU throughout.

The point of the example

A single one-line command touched process management, memory management, the file system, I/O, and scheduling. Every concept introduced in the rest of this course is present in this tiny sequence.

06 Interactive activity

Activity · observe the operating system at work

In your Linux VM, open a terminal and run the following. Record what you observe for each step.

See processes. Run ps aux | head -20. Every line is a process. How many belong to your user? Which process has PID 1?
See scheduling in real time. Run top and watch the CPU percentage column. Press q to quit. Which process is consuming the most CPU?
See memory usage. Run free -h and cat /proc/meminfo | head. Note the difference between "free" and "available".
Trace the system calls of a command. Run strace -c ls /home. The -c flag summarises calls by count. How many system calls did ls make? Which was the most frequent?
Watch a system call in detail. Run strace -e openat ls /home 2>&1 | head -10. Each line is the kernel opening a file on behalf of ls.

Reflect: which of the two roles from this lesson — resource manager or extended machine — was most visible in each observation?

07 Knowledge check

Check your understanding

Question 1

A program calls read() to retrieve 4 KiB from a file. In which role is the operating system acting when it translates that call into device commands — resource manager or extended machine? Justify your answer.

Show answer

Both roles are present, but the extended-machine role is more prominent here. The program does not know or care whether the bytes come from an NVMe SSD, a SATA disk, or a network file system. The OS presents a uniform read() abstraction — that is the extended machine. At the same time, the OS must schedule the underlying device operation against competing requests, which is the resource-manager role.

Question 2

Explain why hardware multiplexing is a necessary function of a modern operating system, even on a single-user laptop.

Show answer

Even a "single user" laptop runs dozens of processes concurrently: the window manager, background services, the browser, media playback, and system daemons. There is only one or a small number of CPU cores, so the OS must rapidly switch between them to give the illusion of simultaneity. Multiplexing is required regardless of how many human users are present.

Question 3

Which of the following is not typically considered a core function of an operating system, and why?
(a) process scheduling (b) virtual-memory management (c) rendering a web page (d) access control

Show answer

(c) Rendering a web page. Page rendering is an application-level task. The operating system provides the abstractions the renderer uses — memory, files, network sockets, a display device — but the rendering logic itself lives in the browser. The other three are core OS responsibilities.

08 Unit discussion

Discussion prompt

The lesson presents two views of an operating system — resource manager and extended machine. Choose a device you use daily (laptop, phone, smart TV, car, router). Identify one design decision in its operating system that clearly favours one view over the other, and explain the trade-off that decision implies.

Post your response to the Unit 1 discussion forum and reply to at least two classmates. This activity contributes to your participation grade and supports CLO1.

09 Practice exercise

This ungraded exercise consolidates the lesson. Aim to spend about 30–45 minutes on it.

Classify a command. Run wc -l /etc/passwd in your VM. Then run strace -c wc -l /etc/passwd. Which system calls appear? Group them into categories: process management, file management, memory management, I/O.
Count the processes. Run ps -e --no-headers | wc -l. How many processes are running on your VM right now? Pick two and describe what each is likely responsible for.
Trace a fork. Write a short C program that calls fork() and has both parent and child print their own PID. Compile it with gcc -Wall -g -o fork_demo fork_demo.c and run it. What does the output tell you about how the OS created the child?
Write a one-paragraph reflection. In your own words, describe one task the operating system performed on your behalf during each of the three exercises above. Identify the role — resource manager or extended machine — each task best illustrates.

10 Summary

An operating system is the software that manages hardware resources and provides abstractions for application programs.
It is best understood through two complementary views: as a resource manager that arbitrates access to CPU, memory, storage, and devices, and as an extended machine that hides hardware complexity behind a clean interface.
Its core functions are process management, memory management, file-system management, I/O management, protection and security, networking, and the user interface.
Operating systems are essential because they multiplex shared hardware, isolate programs from one another, provide portability, boost programmer productivity, and enforce security.
Even a single one-line shell command touches process creation, memory mapping, file access, I/O scheduling, and process termination — all coordinated by the OS.

Looking ahead

Lesson 1.2 traces how the modern operating system came to be — from the earliest batch monitors through time-sharing, personal computing, and distributed and cloud systems.

11 References

Arpaci-Dusseau, R. H., & Arpaci-Dusseau, A. C. Operating Systems: Three Easy Pieces, Chapter 1. Available online at ostep.org.
Silberschatz, A., Galvin, P. B., & Gagne, G. Operating System Concepts, 10th ed., Chapter 1.
Tanenbaum, A. S., & Bos, H. Modern Operating Systems, 4th ed., Chapter 1.