Operating System

7 min read

Operating System

The software layer between your programs and the hardware — the building manager that allocates resources, prevents conflicts, and ensures every program gets what it needs without directly touching the physical machine.

What is it?

Your computer runs dozens of programs simultaneously — a browser, a text editor, a music player, background services. Each one needs the CPU, memory, disk, and network. Without coordination, they would overwrite each other’s data, fight for the processor, and crash.

The operating system (OS) is the coordinator. It sits between your programs and the hardware, managing who gets what, when, and for how long. Programs never talk to hardware directly — they make requests to the OS, which translates those requests into the specific signals each piece of hardware needs.1

Windows, macOS, Linux, Android, and iOS are all operating systems. They differ in user interface, philosophy, and design decisions, but they all perform the same fundamental job: managing hardware resources on behalf of programs.2

The concept dates to the 1960s. Before operating systems, only one program could run at a time, and programmers had to manage hardware directly. The OS was invented to share resources between multiple programs and multiple users — what is now called multiprogramming.3

In plain terms

An operating system is the building manager in an office tower. Tenants (programs) do not deal with plumbing, electricity, or elevators directly. They submit requests to the building manager, who coordinates with the actual infrastructure. No tenant needs to know how the boiler works.

At a glance

How does it work?

Process management

The CPU can only execute one instruction at a time (per core). Yet your computer runs dozens of programs “simultaneously.” The OS achieves this through time-sharing — rapidly switching the CPU between processes, giving each one a tiny slice of time.4

The switch happens so fast (thousands of times per second) that every program appears to run continuously. Each process thinks it has the CPU to itself.

Think of it like...

A chef in a kitchen working on five dishes at once. They chop for dish A, stir dish B, check the oven for dish C, then return to dish A. Each dish “thinks” it has the chef’s full attention. In reality, the chef is switching rapidly between them.

Memory management

The OS assigns each program its own region of memory and enforces boundaries. Program A cannot read or write Program B’s memory. This isolation prevents one buggy program from corrupting another’s data.5

The OS also manages virtual memory — using disk storage as an extension of RAM. When physical memory is full, less-used data is moved to disk (swapped out) and brought back when needed.

Concept to explore

See memory-management for the full picture of how programs use stack and heap memory within the space the OS allocates.

Device abstraction

Every piece of hardware — disk, network card, display, keyboard — speaks its own protocol. The OS provides a uniform interface through device drivers — specialised software that translates generic operations (“write this data to disk”) into the specific signals each device understands.6

This is why your Python program can say open("file.txt") and it works regardless of whether the file is on an SSD, a mechanical hard drive, or a network share. The OS handles the translation.

The file system

Raw storage is just a sequence of bytes with no structure. The file system is the OS’s organisational layer — it provides folders, filenames, permissions, and metadata. It is the reason you can find your documents instead of navigating raw disk addresses.7

Why do we use it?

Key reasons

1. Resource sharing. Multiple programs run simultaneously without conflicting. The OS arbitrates access to CPU, memory, disk, and network.

2. Abstraction. Programs interact with a simple, uniform interface instead of hardware-specific protocols. This makes software portable across different machines.

3. Protection. Programs cannot access each other’s memory or interfere with the OS itself. This isolation makes the system stable and secure.

4. Convenience. File systems, window managers, networking stacks, and input handling are all provided. Without the OS, every program would need to implement these from scratch.

When do we use it?

  • Every time you use a computer, phone, or tablet — the OS is always running
  • When you write code that reads files, opens network connections, or creates processes — you are making requests to the OS
  • When debugging performance issues — CPU scheduling, memory limits, and I/O bottlenecks are OS-level concerns
  • When choosing deployment infrastructure — the OS determines what software can run and how resources are allocated

Rule of thumb

You interact with the OS constantly without knowing it. Every time your code opens a file, creates a thread, or allocates memory, it is asking the OS for permission and resources. Understanding this layer helps you understand why programs behave the way they do.

How can I think about it?

The building manager

An operating system is like the manager of an office building.

  • Tenants = programs. Each has a lease (memory allocation) and office space (process). They submit work orders (system calls) to the manager.
  • Utilities = hardware resources (CPU, memory, disk). The manager distributes water (memory), electricity (CPU time), and post (I/O) to each tenant.
  • Security = process isolation. The manager ensures no tenant enters another’s office or tampers with the building’s electrical panel (kernel space).
  • Maintenance staff = device drivers. The manager hires specialists for plumbing (disk driver), electrical (network driver), and HVAC (display driver). Tenants never deal with maintenance directly.

The air traffic controller

The OS is like an air traffic controller. Many planes (programs) want to use the same runways (CPU, memory, I/O channels). The controller sequences them, prevents collisions, and ensures each plane lands and takes off safely.

Without the controller, planes would collide on the runway (data corruption), circle indefinitely (deadlock), or run out of fuel waiting (resource starvation). The controller’s job is to make shared resources usable by coordinating access.

Concepts to explore next

ConceptWhat it coversStatus
memory-managementHow stack and heap work within the OS’s memory allocationcomplete
runtimeThe layer between the OS and your codecomplete
abstraction-layersThe OS as one layer in the full abstraction laddercomplete

Check your understanding

Where this concept fits

Position in the knowledge graph 

graph TD
    SD[Software Development] --> OS[Operating System]
    SD --> AL[Abstraction Layers]
    OS --> MM[Memory Management]
    OS -.->|provides layer for| RT[Runtime]
    AL -.->|OS is a layer| OS

    style OS fill:#4a9ede,color:#fff

Related concepts:

  • memory-management — how programs use memory within the space the OS allocates
  • runtime — the execution environment that sits between the OS and your code
  • abstraction-layers — the OS is a key abstraction layer between software and hardware

Sources

Further reading

Resources

Footnotes

  1. GeeksforGeeks. (2024). Introduction to Operating System. GeeksforGeeks. ↩

  2. Tanenbaum, A. & Bos, H. (2014). Modern Operating Systems. 4th ed. Pearson. The standard university textbook on OS design. ↩

  3. The concept of multiprogramming was pioneered in the Atlas Supervisor (1962) and the IBM OS/360 (1966). Brinch Hansen, P. (2000). Classic Operating Systems. Springer. ↩

  4. OpenStax. (2024). Fundamental OS Concepts. OpenStax. ↩

  5. Silberschatz, A. et al. (2018). Operating System Concepts. 10th ed. Wiley. ↩

  6. TechTarget. (2024). What is an Operating System?. TechTarget. ↩

  7. Carrier, B. (2005). File System Forensic Analysis. Addison-Wesley. ↩

Graph View

Backlinks