Introduction to Operating Systems

Learning Objectives

By the end of this page, you should be able to:

• Define what an operating system is and explain its role as an intermediary between hardware and applications.
• List and describe the six core functions of an OS: process, memory, file system, and device management, security, and the user interface.
• Distinguish between a kernel, an operating system, and firmware.
• Explain the difference between user mode and kernel mode, and why that boundary exists.
• Compare monolithic, microkernel, and hybrid kernel architectures with real examples (Linux, Minix, Windows NT/macOS).
• Identify which OS category (batch, time-sharing, real-time, distributed, embedded, mobile) fits a given scenario.

Quick Answer

An operating system (OS) is the system software that sits between your hardware and every application you run, managing the CPU, memory, storage, and I/O devices so programs don't have to talk to hardware directly. It multiplexes a computer's limited physical resources — one CPU, a fixed amount of RAM, one disk — across many competing processes, while enforcing isolation so one buggy or malicious program can't crash another or read its memory. Examples include Linux, Windows, macOS, Android, and iOS. It matters because almost nothing else in computing works without it: every scheduling decision, every file you save, every device driver, and every security boundary on a modern computer is implemented or coordinated by the OS. Understanding the OS is the foundation for the rest of this module — process scheduling, memory management, file systems, and synchronization all build directly on the concepts introduced here.

Overview

Think about what actually happens when you double-click a web browser icon. The disk has to be read, machine code has to be loaded into RAM, the CPU has to be told to start executing that code, the network card has to be initialized so the browser can make requests, and the screen has to be told what pixels to draw. If every application had to write its own code to do all of that — talk directly to the disk controller, manage its own chunk of RAM, arbitrate with other running programs over who gets the CPU next — software would be enormous, fragile, and completely unable to run alongside other software safely.

The operating system exists to remove that burden. It is the layer of software that owns the hardware and offers every other program a simpler, safer, more abstract way to get things done: open() a file instead of talking to a disk controller, malloc() memory instead of managing physical RAM addresses, read() from a socket instead of programming a network chip's registers. This is usually drawn as a layered architecture:

Applications never touch hardware directly — they go through the system call interface, a well-defined set of entry points (like open, fork, read, write, mmap on Linux, or the Win32 API on Windows) that ask the kernel to do privileged work on their behalf. This boundary is enforced by the CPU itself, not just by convention: modern processors have at least two privilege levels, commonly called user mode and kernel mode (on x86, these correspond to protection rings 3 and 0). Application code runs in user mode and simply cannot execute instructions that touch hardware directly — it must trap into kernel mode via a system call, and the CPU checks a mode bit in hardware before allowing privileged instructions to run. This is why a crashing Chrome tab doesn't take down your whole machine: the OS, not politeness, is what keeps it in its lane.

Key Functions of an OS

An OS earns its place in the system by doing six jobs well:

1. Process management — creating, scheduling, and terminating processes so multiple programs can appear to run at once on a limited number of CPU cores.
2. Memory management — allocating RAM to processes, protecting one process's memory from another, and using virtual memory to let programs use more address space than physically exists.
3. File system management — organizing raw disk blocks into files and directories, and controlling who can read or write them.
4. Device management — talking to printers, disks, network cards, and GPUs through device drivers so applications don't need device-specific code.
5. Security and access control — authenticating users, enforcing permissions, and isolating processes from each other.
6. User interface — giving humans a way to interact with the machine, whether through a shell (bash, PowerShell) or a graphical desktop (GNOME, Windows Explorer, macOS Finder).

Each of these becomes its own dedicated topic later in this module — this page's job is to give you the vocabulary and mental model that the rest of the module assumes you already have.

1. Process Management

A process is a program in execution — code, plus its own memory, open files, and CPU register state. A thread is a unit of execution inside a process; multiple threads in one process share memory but have their own stack and instruction pointer. The scheduler decides which of the many runnable processes/threads gets the CPU next, and for how long.

Example: Open Firefox on Linux and run ps aux | grep firefox — you'll see one process with a PID, and if you look at /proc/<pid>/task/, you'll see multiple threads inside it (one for rendering, one for networking, etc.), all sharing the same address space but scheduled independently by the kernel's Completely Fair Scheduler (CFS).

Why it matters: Without process management, running a background music player while compiling code would either be impossible or would require the music player and compiler to cooperate manually on CPU time — which never scales past a handful of trusted programs.

Deep coverage of scheduling algorithms (FCFS, SJF, Round Robin, priority, multilevel queues) is in the next page of this module: Process Management and Scheduling.

2. Memory Management

The OS gives every process the illusion that it owns the entire address space, even though physical RAM is shared among dozens of processes. It does this through virtual memory: each process gets its own virtual address space, and the OS (with help from the CPU's Memory Management Unit) translates virtual addresses to physical RAM addresses via paging. If physical RAM is full, rarely-used pages can be swapped out to disk.

Example: On a Linux system with 8 GB of RAM, you can still run Chrome, an IDE, and a database that together claim to need 12 GB of virtual memory, because not all of it is resident in physical RAM at once — the OS pages in what's actively used and pages out what isn't.

Why it matters: Virtual memory is also a security feature — it's what stops Process A from reading or corrupting Process B's memory just by guessing an address, because Process A's virtual addresses don't map to Process B's physical pages at all.

Full treatment of paging, segmentation, and page-replacement algorithms is deferred to the Memory Management page of this module.

3. File System Management

Disks store raw blocks of bytes; the file system is the OS-level abstraction that turns those blocks into a hierarchy of files and directories, along with metadata (owner, permissions, timestamps, size). Linux commonly uses ext4 or btrfs, Windows uses NTFS, and macOS uses APFS. All of them expose the same basic model to applications: a tree of directories containing files, even though the on-disk layout differs completely.

Example: When you run echo "hello" > note.txt on Linux, the OS finds free blocks on disk, writes the data, updates the ext4 inode table, and updates the containing directory's entry — all invisible to you as a single "save."

Why it matters: Because the file system abstraction is standardized (POSIX open/read/write/close on Unix-likes), the same application code can run on ext4, NTFS-via-WSL, or a network file system like NFS without modification.

4. Device Management

Every physical device — printer, disk, network card, USB drive — has its own quirks and command set. A device driver is kernel (or, on some systems, user-space) code that translates the OS's generic I/O requests into device-specific commands.

Example: When you plug in a USB drive on Windows, the kernel loads a driver for that specific storage controller, and from then on your applications just see it as another drive letter — they never issue device-specific commands themselves.

Why it matters: Device management is what lets one OS support thousands of different pieces of hardware from different vendors without every application needing to know about every device.

5. Security and Access Control

The OS is the trust boundary of the entire machine. It authenticates who is allowed to log in, authorizes what each authenticated user or process can do (via file permissions, user IDs, and increasingly fine-grained mechanisms like SELinux or Windows ACLs), and isolates processes from each other via memory protection.

Example: On Linux, chmod 600 secrets.txt restricts a file to be readable/writable only by its owner — the kernel enforces this on every open() call, not the application.

Why it matters: Application-level security means nothing if the OS underneath doesn't enforce isolation — a browser sandbox is only as strong as the kernel features (like Linux namespaces and seccomp) it's built on.

6. User Interface

The OS provides at least one way for a human (or another program) to issue commands: a command-line interface (bash, zsh, PowerShell, cmd.exe) or a graphical user interface (Windows Explorer, GNOME, macOS Finder). Modern systems ship both, and power users often prefer the CLI precisely because it's scriptable.

Example: ls -la and double-clicking a folder icon in Finder both ultimately call the same underlying system calls (readdir, stat) — the UI is just a different presentation layer on top of the same kernel services.

Kernel vs. Operating System vs. Firmware — A Common Point of Confusion

People use "operating system" and "kernel" interchangeably, but they aren't the same thing. The kernel is the core program that runs in privileged mode and directly manages the CPU, memory, and hardware. The operating system is a much larger bundle that includes the kernel plus system libraries, utilities, background services (daemons), and often a UI — "Linux" strictly refers to the kernel, while "Ubuntu" or "Fedora" is the OS built around that kernel. Firmware (like BIOS/UEFI) is even lower-level: it's the first code that runs when the machine powers on, and its main job is to initialize hardware and load the OS's bootloader — it hands off control to the OS and then mostly gets out of the way.

Kernel Architectures

Not all kernels are built the same way:

• Monolithic kernel — the entire OS (scheduler, file system, drivers, memory manager) runs in a single address space in kernel mode. Linux is the classic modern example; it's fast because components call each other directly, but a bug in any driver can crash the whole kernel.
• Microkernel — only the bare minimum (IPC, basic scheduling, basic memory management) runs in kernel mode; file systems and drivers run as user-space servers that communicate via message passing. Minix and QNX are examples; more robust to driver crashes, but slower due to message-passing overhead.
• Hybrid kernel — a pragmatic middle ground that runs most services in kernel space for performance but keeps some modularity. Windows NT's kernel and the XNU kernel underlying macOS/iOS are commonly described this way.

Types of Operating Systems

OSes are also categorized by how they schedule and serve work:

• Batch OS — jobs are queued and run without user interaction (historically, punch-card mainframes).
• Time-sharing / multitasking OS — the CPU is rapidly switched between multiple interactive users/processes so each appears to have continuous access (Linux, Windows, macOS on a desktop).
• Real-time OS (RTOS) — guarantees a task completes within a strict deadline; used in pacemakers, anti-lock braking systems, and industrial controllers (FreeRTOS, VxWorks).
• Distributed OS — makes a cluster of machines present themselves as a single coherent system to users and applications.
• Embedded OS — a stripped-down OS built into a single-purpose device, like a router or a smart thermostat.
• Mobile OS — optimized for battery life, touch input, and sandboxed apps (Android, iOS).

Key Terms

Term	Definition	Context/Related
Kernel	The core OS component that runs in privileged (kernel) mode and directly manages CPU, memory, and devices	Smaller than "the OS"; Linux kernel vs. Ubuntu (the OS)
Process	An instance of a program in execution, with its own memory space, open files, and execution state	Created via fork()/exec() on Unix, CreateProcess() on Windows
Thread	The smallest schedulable unit of execution within a process; threads in a process share memory	Multithreading, pthread_create()
System call	A controlled entry point that lets user-mode code request a privileged operation from the kernel	open, read, write, fork on Linux; traps CPU into kernel mode
User mode / Kernel mode	Two CPU privilege levels; user mode restricts direct hardware access, kernel mode allows it	x86 protection rings 3 and 0
Virtual memory	An abstraction giving each process its own address space, decoupled from physical RAM layout	Implemented via paging; covered in depth in Memory Management page
Device driver	Kernel or user-space code that translates generic I/O requests into device-specific commands	Enables one OS to support many vendors' hardware
Firmware	Low-level code (e.g., BIOS/UEFI) that initializes hardware and loads the OS bootloader	Runs before the OS; distinct from the OS itself
Monolithic kernel	A kernel design where all core services run in one privileged address space	Linux
Microkernel	A kernel design where only minimal services run in kernel mode; the rest run as user-space servers	Minix, QNX
Multitasking	The OS's ability to run multiple processes by rapidly switching the CPU between them	Underlies time-sharing systems

Common Mistakes

Misconception 1: "The kernel and the operating system are the same thing." Why it's wrong: This confuses one component (the kernel) with the entire software bundle (the OS) that ships around it. Correct explanation: The kernel is the privileged core that manages hardware directly. The OS is the kernel plus libraries, utilities, daemons, and often a UI. This is precisely why "Linux" (a kernel) can be combined with different surrounding software to produce distinct operating systems like Ubuntu, Fedora, or Android — same kernel, very different OS.

Misconception 2: "Multitasking means the CPU literally runs multiple programs at the exact same instant on a single core." Why it's wrong: On a single CPU core, only one instruction stream can execute at any given nanosecond — true simultaneity on one core is physically impossible. Correct explanation: The OS creates the illusion of simultaneity by rapidly context-switching the CPU between processes (often every few milliseconds), so from a human's perceptual timescale it looks parallel. True simultaneous execution only happens across multiple physical cores; even then, the number of runnable processes almost always exceeds the number of cores, so scheduling and context-switching are still essential.

Misconception 3: "User mode and kernel mode are just a software convention, not something enforced by hardware." Why it's wrong: If it were purely a software convention, any user program could simply ignore it and access hardware directly, defeating the entire point of process isolation. Correct explanation: The privilege distinction is enforced by the CPU itself. Processors implement hardware privilege levels (rings on x86), and instructions that touch hardware or change privileged state will fault if executed in user mode. A user process must issue a system call, which triggers a trap instruction to transition the CPU into kernel mode under the kernel's control — the hardware, not application good behavior, is what makes isolation real.

Comparison and Connections

Concept	What it is	Runs in kernel mode?	Example	Common confusion
Kernel	Core OS component managing CPU/memory/devices	Yes	Linux kernel, XNU, Windows NT kernel	Confused with "the OS" as a whole
Operating system	Kernel + libraries + utilities + services + UI	Partially (kernel yes, most utilities no)	Ubuntu, Windows 11, macOS Sonoma	Used interchangeably with "kernel"
Firmware	Hardware-initialization code that runs before the OS	N/A (runs before OS privilege model exists)	BIOS, UEFI	Confused with the bootloader or OS itself
Monolithic kernel	All core services in one privileged address space	Yes, entirely	Linux	Assumed to be less "modern" than microkernels
Microkernel	Only minimal services in kernel mode; rest in user-space servers	Only a small core	Minix, QNX	Assumed to always be slower — modern hybrids close the gap
Hybrid kernel	Mixes monolithic performance with some modular structure	Mostly	Windows NT kernel, macOS/iOS XNU	Assumed to be "just monolithic" or "just microkernel"
Batch OS	Runs queued jobs without interactive input	Yes	Historic mainframe job queues	Assumed to be obsolete/irrelevant (still used for large offline compute jobs)
Time-sharing OS	Rapidly switches CPU among interactive users/processes	Yes	Linux, Windows, macOS desktop	Confused with "multiprocessing" (multiple CPUs)
Real-time OS (RTOS)	Guarantees deadline-bound task completion	Yes	FreeRTOS, VxWorks	Assumed to mean "fast" rather than "deterministic"

Practice Questions

Recall

1. What are the six core functions of an operating system listed in this guide? Answer guidance: Process management, memory management, file system management, device management, security/access control, and the user interface.
2. What is the difference between user mode and kernel mode? Answer guidance: User mode is a restricted CPU privilege level where applications run and cannot directly execute privileged instructions or touch hardware; kernel mode is the privileged level where the OS runs and can access hardware and privileged CPU state directly. The transition between them happens via a system call/trap.

Understanding

3. Explain why "Linux" and "Ubuntu" are not the same thing, using the kernel vs. OS distinction. Answer guidance: Linux is the kernel — the core component that manages the CPU, memory, and devices in privileged mode. Ubuntu is a full operating system built around that kernel, adding system libraries (glibc), package management (apt), a desktop environment (GNOME), and utilities. Other OSes (Fedora, Android) can use the same Linux kernel with an entirely different surrounding OS.
4. Why does virtual memory improve both usability and security compared to giving processes direct access to physical RAM addresses? Answer guidance: Usability: it lets each process behave as if it has its own large, contiguous address space regardless of what else is running, and lets total virtual memory usage exceed physical RAM via paging. Security: because virtual addresses are translated to physical ones by the OS/MMU per-process, one process cannot address another process's physical memory just by guessing a pointer value — the mapping simply doesn't exist.

Application

5. A washing machine's control board runs a stripped-down OS that must respond to a "door open" sensor within 5 milliseconds every time, with no exceptions. Which category of OS is this, and why wouldn't a general-purpose time-sharing OS like desktop Linux be a good fit? Answer guidance: This is a real-time OS (RTOS) use case, because it requires a guaranteed deadline, not just fast average performance. A time-sharing OS optimizes for overall throughput and fairness across many processes and can't guarantee a specific task always gets the CPU within a hard deadline, since scheduling decisions are influenced by other runnable processes.
6. You run ps aux on a Linux machine and see 40 processes but the CPU only has 4 cores. Explain, in terms of scheduling and privilege levels, how all 40 processes appear to make progress simultaneously. Answer guidance: The kernel's scheduler rapidly context-switches each core among the runnable processes (time-slicing), saving and restoring each process's register state on every switch, so each of the 40 processes gets frequent, short turns on one of the 4 cores. Because switches happen every few milliseconds, this appears simultaneous to a human observer even though true parallel execution is capped at 4 at any instant. The scheduler itself and the context-switch mechanism run in kernel mode.

Analysis

7. Compare a monolithic kernel and a microkernel in terms of what happens when a buggy device driver crashes. Which architecture better contains the damage, and what's the performance cost of that safety? Answer guidance: In a monolithic kernel (e.g., Linux), a driver runs inside the kernel's single privileged address space, so a serious driver bug can corrupt kernel memory and crash the entire system. In a microkernel (e.g., Minix), the same driver runs as an isolated user-space server, so a crash can often be caught and the driver restarted without taking down the whole OS. The cost is that every driver operation now requires message-passing IPC between the driver's process and the minimal kernel, which is slower than a direct in-kernel function call — this is the classic performance-vs-isolation trade-off in kernel design.
8. A new hire says: "We don't need an operating system for our microcontroller-based smart thermostat — we'll just write everything in one big loop that polls the sensors and updates the display." Under what conditions is that actually a reasonable choice, and when would it break down as the product grows? Answer guidance: It's reasonable for very simple, single-purpose devices with few concurrent responsibilities and no need for memory protection, multitasking, or a file system — a "superloop" avoids OS overhead entirely and is easy to reason about. It breaks down once the device needs to do several time-sensitive things concurrently (network connectivity, a touchscreen UI, firmware updates, sensor sampling with strict timing), because manually interleaving all of that in one loop becomes error-prone and hard to extend — at that point, an embedded OS or RTOS earns its overhead by providing scheduling, isolation, and drivers instead of hand-rolled polling logic.

FAQ

Q: Is the Linux kernel itself an operating system, or do I need something else on top of it? A: Strictly speaking, the Linux kernel alone isn't usable as a complete OS — you also need a C library (glibc or musl), a set of core utilities (coreutils), an init system (systemd), and typically a shell and package manager. That's why distributions like Ubuntu, Debian, and Fedora exist: each bundles the Linux kernel with a different set of surrounding software to form a complete operating system.

Q: Why can't a regular application just write directly to the disk instead of going through the OS? A: It technically could try, but the CPU's hardware privilege levels prevent it — direct disk I/O typically requires kernel-mode instructions, and a user-mode process attempting them will fault. Even if that restriction didn't exist, letting every application manage disk I/O independently would cause data corruption the moment two programs tried to write to the same physical blocks at once. The file system's job is precisely to serialize and coordinate that access safely.

Q: Is Android's kernel the same as desktop Linux's kernel? A: Android runs a modified Linux kernel (with additions like Binder IPC and wakelocks for battery management), but its surrounding OS is completely different — no glibc, no X11/Wayland, a different init system, and an application model built on the Android Runtime instead of a traditional desktop environment. It's a good real-world example of "same kernel lineage, very different OS."

Q: Do I need to memorize every OS category (batch, time-sharing, real-time, distributed, embedded, mobile) for exams? A: You should be able to recognize which category a described scenario fits and explain why — that's the testable skill, not rote memorization of the list. Exam questions typically give you a scenario ("a pacemaker must respond within X ms") and ask you to identify and justify the category (real-time), not ask you to recite the full taxonomy from memory.

Q: What's the practical difference between a driver crash on Windows (Blue Screen) and a driver issue on Linux? A: Both Windows and Linux use largely monolithic-style kernels where most drivers run in kernel space, so a sufficiently serious driver bug can crash the whole system on either OS — that's why a bad graphics driver can cause a Windows BSOD or a Linux kernel panic. The difference is mostly in driver ecosystem maturity and signing/certification requirements, not a fundamental architectural gap; true isolation of drivers is really the microkernel's selling point, not something either mainstream OS fully provides.

Quick Revision

• An OS is the software layer between hardware and applications; it manages CPU, memory, storage, and devices.
• Six core OS functions: process management, memory management, file system management, device management, security, user interface.
• Applications interact with the OS through system calls (open, read, fork, etc.), never touching hardware directly.
• CPUs enforce two privilege levels: user mode (restricted) and kernel mode (privileged) — this is a hardware guarantee, not just convention.
• Kernel ≠ operating system: the kernel is the privileged core; the OS is the kernel plus libraries, utilities, and UI (e.g., Linux kernel vs. Ubuntu OS).
• Firmware (BIOS/UEFI) runs before the OS and hands off control to the bootloader; it is not the OS itself.
• Monolithic kernels (Linux) run everything in kernel space — fast but a driver bug can crash the system.
• Microkernels (Minix, QNX) isolate most services in user space — safer against crashes, but slower due to message passing.
• Hybrid kernels (Windows NT, macOS's XNU) blend both approaches for a pragmatic performance/safety balance.
• OS types by workload: batch, time-sharing/multitasking, real-time (RTOS), distributed, embedded, mobile — each optimized for a different constraint (throughput, interactivity, deadlines, scale, footprint, battery).
• Multitasking on one core is an illusion created by fast context-switching, not true simultaneity; true parallelism requires multiple cores.
• Virtual memory gives each process an isolated, larger-than-physical address space and is a security boundary, not just a convenience.

Related Topics

Prerequisites

• Basic computer architecture (CPU, RAM, storage, buses)
• Programming fundamentals (what a running program/process conceptually is)

Related Topics

• Computer Organization and Architecture (privilege rings, MMU hardware)
• Systems Programming (system calls, POSIX APIs)

Next Topics

• Process Management and Scheduling (page 2 of this module) — covers process states, context switching, and scheduling algorithms (FCFS, SJF, Round Robin, priority, multilevel queue) in depth
• Memory Management (page 3) — paging, segmentation, and virtual memory implementation details
• File Systems (page 4) — on-disk structures, inodes, journaling, and file system comparisons