There are no drive letters. Every storage device, every network share, and several things that are not storage at all appear somewhere in a single tree beginning at the root.
That arrangement is not cosmetic. It means a directory can be moved to a different disk without any program noticing, because programs address paths rather than devices.
Mounting is what assembles the tree
A filesystem becomes visible by being attached to a directory, and from that point the directory's contents are the filesystem's contents. Anything previously in that directory is hidden rather than deleted, and reappears when the filesystem is detached.
This is why a machine can have separate devices for the root, for user data, and for logs, while every path continues to work unchanged. It is also why a full disk sometimes affects only part of the system.
The directories that matter
| Path | Holds | Survives reboot |
|---|---|---|
| /etc | System configuration, text files | Yes |
| /var | Data that changes, logs, spools, caches | Yes |
| /usr | Installed programs and libraries | Yes |
| /home | User files | Yes |
| /opt | Self contained third party software | Yes |
| /tmp | Scratch space, often cleared or in memory | No |
| /proc | Kernel and process state, generated on read | No |
| /sys | Device and driver state, generated on read | No |
| /dev | Device nodes, populated at boot | No |
The dividing line worth remembering is the last three rows. Those directories contain no files on any disk, and their contents are produced by the kernel at the moment they are read.
Directories that are not storage
Reading a file under the process directory returns information the kernel assembles on demand, which is why the reported size is frequently zero while the content is substantial.
This is the mechanism behind a great many ordinary tools. Listing processes, reading memory usage, and inspecting network connections are all reads of these synthetic files rather than system calls with dedicated interfaces.
Where installed software lands
Software installed by the distribution's package manager goes under the system directories, and anything placed there is expected to be managed by that package manager.
Software installed by hand belongs elsewhere, conventionally under a local hierarchy that mirrors the system one, or in a self contained directory per application. Mixing the two causes upgrades to overwrite manual changes, which is the most common cause of a machine that breaks during routine patching.
Everything addressable is a path
The tree holds more than files. Devices, running processes, kernel settings, and network sockets all appear as paths, which means the same tools that read a text file can read a disk, query a driver, or inspect a process.
This is why so much of the system can be operated without dedicated interfaces. Changing a kernel parameter is writing to a file, and checking a network counter is reading one.
Configuration and state are deliberately separated
Configuration lives in one place and changing state lives in another, and the separation is what makes a system reproducible.
Configuration is text, belongs in version control, and should be identical across identical machines. State is logs, databases, caches, and queues, is machine specific, and is what actually needs backing up. Treating them as one directory makes both tasks harder.
Why the layout has operational value
Giving state its own filesystem prevents runaway logs from filling the root and stopping the machine. Mounting the program directories read only limits what a compromise can alter. Backing up configuration and user data while excluding caches reduces backup size substantially with no loss.
None of these are possible if everything lives in one undifferentiated tree, which is the practical argument for the convention.
Note: the useful question when looking at an unfamiliar path is not what it contains but who owns it. Package manager, administrator, application, or kernel, and the answer determines whether editing it is safe.