Operating Systems

There are three operating systems most IT professionals will spend their careers with: Windows, macOS, and Linux. One of them dominates the desktops you support. A different one dominates the servers you'll administer. Knowing which is which — and why — is the start of this chapter.

They have different origins, different strengths, and different dominant contexts. Chapter 7 already covered what an operating system is in the abstract — the layer between hardware and applications. This chapter is about the three real ones you'll actually encounter, how their core pieces work, and how IT professionals interact with them every day.

The Big Three

Windows dominates the personal computer market. The vast majority of laptops and desktops shipped to businesses and homes run Windows, which makes it the default platform for end-user support, enterprise software, and productivity tools. Windows Server extends this to the server room, handling Active Directory, file sharing, and many enterprise applications.

macOS runs exclusively on Apple hardware. It has carved out a strong position among creative professionals, developers, and in education. Under the hood, macOS is built on a Unix foundation (Darwin/BSD) — meaning its terminal behaves very similarly to Linux. A skill you learn at a macOS terminal almost always transfers directly.

Linux is an open-source kernel first released by Linus Torvalds in 1991. Hundreds of distributions — Ubuntu, Debian, Red Hat Enterprise Linux, Fedora, Rocky Linux, and many others — package the Linux kernel with different default software, configuration tools, and support models. Linux is free, modifiable, and runs on nearly anything. It is also the dominant OS for servers, cloud infrastructure, and embedded systems.

Open Source vs. Closed Source

In practice, most organizations use both. The interesting question isn't which model is "better" — it's which one fits which job.

The distinction itself is about who owns the code. Windows and macOS are closed source (proprietary): the source code is private, owned by the vendor, and users receive only the compiled software. Linux is open source: the source code is publicly available, and anyone is free to read it, modify it, and distribute their own version under the terms of its license.

Open source does not mean free of charge. Red Hat Enterprise Linux, for example, is open source but sold with paid support contracts worth thousands of dollars per server per year. The important freedoms are access to the code and the right to modify it — not the price tag. The phrase often used is "free as in freedom, not necessarily free as in beer."

Open source tends to win when cost or flexibility is the driver. Deploying 500 Linux servers carries no per-seat license cost; the same deployment on Windows Server can run into hundreds of thousands of dollars. If the software doesn't do exactly what the business needs, an open source codebase can be forked and modified — a proprietary vendor's answer is "wait for the next release," or "pay for a custom feature." Avoiding vendor lock-in is its own kind of insurance: if a proprietary vendor raises prices, discontinues a product, or goes out of business, migration is painful. With open source, there is always an escape route, and in regulated industries the code can be audited line by line.

Closed source tends to win when accountability and integration are the driver. Open source software typically comes with no warranty and no SLA; when something breaks at 2 a.m., a paid vendor contract means someone is contractually obligated to help fix it. A shop already running Microsoft 365, Azure Active Directory, and Teams will usually find that Windows Server fits in with less friction than a Linux alternative. Some compliance frameworks in healthcare, finance, and government effectively require vendor-supported software, and smaller organizations without a dedicated Linux administrator often find that a managed product is cheaper in total even when the license isn't.

This is why most real-world environments are mixed. A typical company runs Linux on its web servers, Windows on employee desktops, an open source database like PostgreSQL underneath the apps, and a proprietary ERP system on top of all of it. The decision gets made service by service — not once for the whole organization.

Why Linux?

For IT professionals, Linux is not optional knowledge. The desktop market share numbers above might make it look like a niche curiosity — 4% of laptops is hardly intimidating. That picture inverts completely the moment you look anywhere other than a personal computer.

Over 96% of the top one million web servers run Linux. 100% of the TOP500 supercomputers run Linux. Android — the OS on roughly 72% of smartphones — is built on the Linux kernel. Every major cloud platform (AWS, Azure, GCP) defaults to Linux for virtual machines, and most network equipment, routers, and embedded devices run Linux-based firmware under the hood.

It is, in short, the environment where most infrastructure actually lives. You may spend your workday supporting Windows desktops and still need Linux fluency the moment you have to SSH into a web server, manage a cloud instance, or troubleshoot a firewall appliance. This chapter gives you the foundation.

The Kernel

Underneath every operating system, no matter how user-friendly its desktop, is a kernel — the piece of software that actually talks to the hardware. Everything else negotiates with the kernel.

The kernel runs in a privileged execution mode called kernel space, with direct access to hardware. All other software — your browser, your shell, your scripts — runs in user space, with restricted hardware access. The boundary between them is enforced by the CPU itself. This is the abstraction hierarchy from Chapter 7 in practice: each layer knows only what the layer below it presents.

When a user-space application needs hardware access — reading a file, sending data over the network, drawing to the screen — it makes a system call: a controlled handoff from user space to kernel space. The kernel executes the request with full hardware access, then returns the result to the application. The application never directly touches hardware; it always goes through the kernel.

The kernel has three primary responsibilities, and once you see them, you see what an OS really is. Process scheduling decides which program runs on the CPU at any moment, and for how long, so that multiple applications appear to run simultaneously on a CPU that can really only do one thing at a time. Memory management allocates RAM to each process and enforces that processes cannot read or write each other's memory — the isolation that keeps one crashed program from taking down the entire system. Hardware access provides a uniform interface to hardware through device drivers, so that an application doesn't need to know the specific details of every device installed in the machine. The CPU itself enforces the privilege boundary in hardware: code in kernel space can execute privileged instructions; code in user space cannot.

The Shell

The shell is a program that takes text commands, interprets them, and runs other programs in response. It is the interface between you and the operating system's kernel. The most common shell on Linux systems is Bash (Bourne Again SHell), though others like Zsh and Fish are also used.

When you open a terminal on a Linux desktop, you are running a shell. When you connect to a remote server over SSH (Secure Shell), the shell is often the only interface available — there is no desktop, no windows, no mouse. Just a prompt.

Most production Linux servers run without a graphical desktop at all. There are three reasons for this, and they reinforce each other. A full desktop environment like GNOME or KDE consumes 300–800 MB of RAM and meaningful CPU cycles doing nothing useful for server workloads — on a machine whose job is to serve web requests or process data, that's just wasted capacity. SSH already gives you a fast, encrypted text terminal over any network connection, even a slow one, where a remote desktop would demand far more bandwidth and specialized software. And shell commands can be scripted: an operation you run on one server can be run across a thousand simultaneously, with no human clicking through menus. That's how large-scale infrastructure is actually managed.

Learning to navigate confidently in a shell is one of the most transferable technical skills in IT. The commands you learn here work on any Linux server, any macOS machine, and — through Windows Subsystem for Linux — on Windows as well.

Basic Shell Commands

Every shell session starts with a prompt — a line like student@linux:~$ — indicating who you are, what machine you're on, and where in the filesystem you currently are. The ~ symbol is shorthand for your home directory (/home/student in this case). The $ means you are a regular user (as opposed to #, which indicates root).

A few things to know before you start typing:

• Linux filenames are case-sensitive. Notes.txt and notes.txt are different files.
• rm is permanent. There is no undo, no recycle bin. Double-check before pressing Enter.
• Use the up arrow to recall previous commands. This alone saves significant time.
• A path starting with / is absolute (from the root of the filesystem). A path without a leading / is relative (from your current location). .. means "one directory up."

The simulator below has a pre-built home directory to explore. Try navigating into documents/, reading files with cat, creating new directories, and copying files. Use help to see all available commands.

Users and Permissions

Linux is a multi-user operating system. Every file and directory has an owner, and access to it is controlled by a set of permission rules that apply separately to three groups: the file's owner, the owner's group, and everyone else.

root and sudo

Every Linux system has a superuser account called root — the one account with unrestricted access to everything. On modern systems, the root account is typically kept locked, and administrators use the sudo command ("superuser do") to run individual commands with root-level privileges. This means mistakes with elevated access are narrowly scoped: you only have superuser power for that one command, not for the entire session.

The convention is to work as a regular user at all times and invoke sudo only when necessary — installing packages, editing system configuration files, or managing users. A common saying in Linux administration: never run as root unless you need to.

The rwx Permission Model

Every file and directory has three permission bits for each of the three groups:

• r (read) — view the file's contents, or list a directory's contents
• w (write) — modify the file, or create/delete files inside a directory
• x (execute) — run the file as a program, or enter a directory with cd

When you run ls -l, the first column shows permissions in symbolic notation:

-rw-r--r--  1 student student  89  May  8 09:14  report.txt
drwxr-xr-x  2 student student  4096  May  8 09:14  documents/

Read left to right: the first character is the file type (- for a regular file, d for a directory). The next nine characters are three groups of three — owner permissions, group permissions, and other permissions. -rw-r--r-- means the owner can read and write; the group can only read; everyone else can only read.

The same permissions can be expressed as a three-digit octal number. Each bit has a value: r = 4, w = 2, x = 1. Add the values for each group to get its digit. rw- = 4 + 2 = 6. r-- = 4 = 4. So rw-r--r-- = 644. Octal notation is compact and widely used — you will see it constantly in documentation and commands like chmod 755 script.sh.

Package Management

Installing software on Linux works differently than on Windows. Instead of navigating to a vendor's website, downloading a .exe, and clicking through an installation wizard, Linux uses a package manager — a command-line tool that fetches, installs, updates, and removes software from curated, cryptographically signed repositories.

The two most common package managers are apt (used on Debian and Ubuntu-family distributions) and dnf (used on Red Hat, Fedora, and Rocky Linux). The syntax differs slightly, but the concept is the same.

Installing the Nginx web server on Ubuntu:

sudo apt install nginx

That single command downloads Nginx, verifies its cryptographic signature, installs it, and configures it to start on boot. Updating all installed software on the system:

sudo apt update && sudo apt upgrade

Chapter 9 zooms in on one specific part of the OS's job: how the file tree actually gets stored on disk, who owns what, and how the same model scales to manage a whole organization's worth of accounts and machines.