Unix and Internet Fundamentals: how Linux and the Net work

Updated November 2026

A Linux computer is a stack of simple parts: firmware starts a boot loader, the boot loader starts the kernel, the kernel starts systemd, and systemd starts everything else. The Internet works the same way: names become addresses, addresses carry packets, and protocols on top of them carry web pages. This page explains each part in plain words and gives a command to look at it on your own machine.

You do not need to be an expert. Open a terminal and try the commands as you read. None of them change anything.

What happens when you switch on

  1. Firmware. The UEFI firmware (or the older BIOS) on the motherboard does basic hardware setup. Then it finds a boot loader on a disk, usually in the EFI system partition.
  2. Boot loader. GRUB or systemd-boot shows a menu (often hidden) and loads two files into memory: the kernel, and an initramfs. The initramfs is a small compressed file system that holds the drivers needed to reach your real disk.
  3. Kernel. The kernel is the core program that controls the hardware. It unpacks the initramfs, uses it to find and mount the root file system, then hands control to the first program.
  4. systemd. This first program, process number 1, starts services in the right order: networking, logging, the login screen. It works toward a goal called default.target, which means either a graphical desktop or a text console.
systemd-analyze               # how long firmware, loader, kernel and userspace took
systemd-analyze blame         # which services took longest to start
journalctl -b                 # every log message since this boot

Older systems used LILO instead of GRUB and SysV init scripts instead of systemd. The idea is the same.

The kernel and processes

A running program is a process. Each process has a number (PID), an owner, and its own private memory. The kernel switches between processes many times a second. That is why dozens of programs seem to run at once even on a few CPU cores.

New processes are made by copying an existing one (the fork system call) and then loading a new program into the copy (exec). When you type ls in a shell, the shell forks, the child runs ls, and the shell waits for it to finish. Every program returns an exit code: 0 means success, anything else means a kind of failure.

Programs cannot touch hardware directly. They ask the kernel through system calls: "open this file", "send these bytes", "give me more memory". The kernel checks permissions and does the work. Processes can also receive signals, short messages such as "stop" (SIGTERM) or "stop now" (SIGKILL).

ps -ef | head                 # list processes with their PIDs and parents
top                           # live view of CPU and memory use (q to quit)
ls; echo $?                   # $? holds the exit code of the last command

Files and directories

Everything lives in one tree that starts at /. There are no drive letters. Other disks and USB sticks are mounted into the tree, for example at /media/you/USB. The main directories:

DirectoryWhat it holds
/etcSystem-wide configuration files
/usrInstalled programs and libraries (read-only in normal use)
/varData that changes: logs, caches, databases, mail queues
/homeUsers' personal files
/bootThe kernel, initramfs and boot loader files
/devDevice files, such as /dev/nvme0n1 for a disk
/proc, /sysVirtual files the kernel creates to show its state
/run, /tmpTemporary data that is cleared at boot

A file name is only a label. The file's real record is an inode, which stores its size, owner, permissions, timestamps and where its data sits on disk. Several names (hard links) can point to the same inode.

Every file has an owner, a group and three sets of permissions: read (r), write (w) and execute (x) for the owner, the group, and everyone else. -rw-r--r-- means the owner can read and write, and everyone else can only read. The user root can bypass these checks, which is why you use sudo only when needed.

ls -l /etc/hostname           # permissions, owner, group, size, date
stat /etc/hostname            # the inode details
df -h                         # mounted file systems and free space
cat /proc/cpuinfo | head      # the kernel reports what CPU it found

Unix also treats many things that are not files as files: disks, terminals, even random numbers (/dev/urandom). The same read and write calls work on all of them.

Memory

Each process sees its own virtual memory, as if it had the whole machine. The kernel maps those virtual addresses onto real RAM in small pages (usually 4 KiB). This keeps processes from reading each other's memory. It also lets the kernel load parts of a program only when they are used.

Spare RAM is not wasted. The kernel uses it as a page cache for recently read files and gives it back when programs need it. When RAM really runs out, the kernel can move little-used pages to swap (a disk area, or compressed RAM with zram). If even that is not enough, the out-of-memory killer ends a process.

free -h

Look at the available column, not free. "Available" estimates how much memory new programs can get without swapping, including cache the kernel can drop. A machine showing 200 MB free but 6 GB available is fine.

How the Internet carries data

Data travels in packets, small chunks with a sender and receiver address on each. Routers pass each packet one step closer to its destination. Protocols are stacked in layers, and each layer does one job:

ip addr                       # your addresses (replaces the old ifconfig)
ip route                      # where packets go; "default via" is your router
ss -tln                       # TCP ports that programs on this machine listen on
sudo ss -tlnp                 # the same, with the name of each listening program
ping -c 3 kernel.org          # can packets reach it and come back?

DNS: names to addresses

People use names like www.kernel.org, but packets need IP addresses. The Domain Name System is a worldwide distributed database that turns one into the other. Your computer asks a resolver (often your router or your provider's server). The resolver asks the root servers who handles .org, asks those servers who handles kernel.org, and finally asks that domain's own servers. Answers are cached for a time the domain owner sets (the TTL), so most lookups are answered from cache in milliseconds.

On Ubuntu and Fedora, systemd-resolved runs as a local resolver, and /etc/resolv.conf points programs at it. Debian and Arch do not enable it by default; there /etc/resolv.conf usually lists your router or provider's servers directly.

getent hosts www.kernel.org       # what normal programs will get
resolvectl query www.kernel.org   # ask systemd-resolved (where it runs)
dig www.kernel.org                # raw DNS answer (package dnsutils or bind-utils)

HTTP and TLS: the web

1. DNS name → address 2. TCP connect to port 443 3. TLS check cert, encrypt 4. HTTP GET / → 200 OK
The four steps behind every https:// address. Each one can be tested on its own.

HTTP is a simple request and reply. The browser sends a method and a path, such as GET /index.html, plus headers. The server answers with a status code (200 OK, 301 moved, 404 not found, 500 server error), headers and the page itself.

TLS wraps the connection so nobody in between can read or change it. During the handshake, the server sends a certificate that proves it owns the name. A certificate authority your system trusts has signed it. Then both sides agree on keys and encrypt everything that follows. TLS 1.3 is the current version (as of November 2026). The padlock in a browser means this check passed. It does not mean the site is honest.

curl -sv https://www.kernel.org/ -o /dev/null   # shows DNS, TCP, TLS and HTTP steps
openssl s_client -connect www.kernel.org:443 -servername www.kernel.org </dev/null
                                                 # shows the certificate chain

In the curl output, lines starting with * are connection and TLS steps, > lines are what you sent, and < lines are the server's reply.

When something breaks

Because each layer depends on the one below it, test from the bottom up:

  1. ip addr: do you have an address?
  2. ip route and ping your router: is the local network up?
  3. ping 9.9.9.9 (Quad9, a public DNS service): can you reach the Internet by number?
  4. getent hosts example.org: does DNS work? If numbers work but names fail, the problem is DNS.
  5. curl -v: does the server answer, and is the certificate accepted?

The classic version of this HOWTO is kept by the Linux Documentation Project at tldp.org. It describes machines of around 2000, so some details are out of date.

Sources