Linux's 'everything is a file' idea is 50 years old, and it still explains why the OS feels so different

If you ask a Windows user to check their laptop's battery level from a command line, they'll probably use a PowerShell cmdlet or battery report. If you ask a Linux user to do the same thing, there's a good chance they'll just read it directly from a file. Basically everything on Linux is a file, and it comes from a design decision made at Bell Labs over 50 years ago. Linux inherited it from Unix, and it's one of the defining characteristics that sets it apart from Windows.

Everything is a file on Linux

What exactly does that mean?

Unix took shape at Bell Labs starting in 1969, and its file system was at the heart of the design from the beginning. Dennis Ritchie later credited himself with the idea of device files, and even the earliest version of Unix had special files representing hardware, which is similar to what Linux uses today. When Ritchie and Ken Thompson described the system in their 1974 paper, they listed three kinds of files: ordinary files, directories, and special files for I/O devices.

This gave them a single, small interface to work with, which simplified things significantly over other stuff available at the time. A program can open something, read from it, write to it, and close it, and doesn't care if it's a document, terminal, disk, or even another program. Unix also didn't impose structure onto file contents. A file is considered a sequence of bytes, and it's up to whatever program reading those bytes to decide what it is.

In contrast to Windows, this is a pretty different way to treat a file system. Windows NT is built around kernel objects tracked by the Object Manager, which keeps its own hierarchical namespace with paths like \Device\HarddiskVolume1. Programs reach those objects through handles, much as Unix programs use file descriptors, but the difference is visibility. That namespace sits outside of the file system, while in Unix it sits right in the directory tree.

Linux hardware lives in /dev

Hardware is treated like a file, and it's clever

/dev is the most concrete example of hardware being treated as a file in modern day Linux. A SATA drive shows up as something like /dev/sda, an NVMe drive as /dev/nvme0n1, and partitions get their own entries alongside them. Some entries have no hardware behind them at all: /dev/null discards anything written to it, /dev/zero produces endless zeros, and /dev/urandom produces random bytes, all of which can be useful in various scenarios.

And because a disk is treated like an ordinary file, ordinary tools work on it all the same. dd is a great example of this, as it's a general purpose copy tool. If you give it an ISO as input and /dev/sdX as the output, you've made a bootable USB drive. If you were to type in the wrong drive, congratulations, you just overwrote that disk with the contents of the ISO. That's the downside of an interface that's this uniform, and it's why dedicated tools exist. On Windows you'd just use something like Rufus.

The kernel talks back through /proc and /sys

Kernel state is exposed as files on Linux

One of the more interesting aspects of treating everything as a file comes from the kernel, which exposes certain aspects of itself as files in Linux. It does so through virtual file systems that don't exist on the disk itself, and they're only generated when you read them.

/proc is the first example of this: Tom Killian built it for Unix and presented it in a 1984 paper called “Processes as Files.” Linux then added its own /proc in 1992 and soon expanded it beyond processes, and that’s why cat /proc/cpuinfo and cat /proc/meminfo are such common ways to check hardware and memory details.

/sys arrived a bit later in Linux 2.6, and it exposed the kernel's device model as a tree of small files. For example, a laptop battery’s charge level sits in a file like /sys/class/power_supply/BAT0/capacity as a plain percentage. You can also check thermal sensors through files like /sys/class/thermal/thermal_zone0/temp in millidegrees Celsius, so 45000 would mean 45 degrees. Many of these files are writable and can change the way the kernel behaves, too.

This makes Linux so unique

Nothing really compares today

Once hardware and kernel state are byte streams, the tools built on top can work completely differently, and that's for the better. Every program on Linux starts with three standard file descriptors: input, output, and error, and they're pretty crucial in knowing how to use the command line. In early 1973, pipes were finally added to Third Edition Unix, and this was huge.

Pipes let one program’s output flow straight into another’s input, which is how Linux users can chain small tools like grep, sort, and awk instead of opening one large application, and it opens up so many different command line workflows. Being able to grep an error readout from a program and pipe it to a log file in one line is something I and many other Linux users use almost every time something needs troubleshooting.

PowerShell on Windows deliberately took a different route, passing structured .NET objects between commands rather than text. Neither approach is wrong, but they build very different habits. As someone whose command line habits are well-seasoned in Linux, trying to understand PowerShell is really difficult.

An idea that changed everything

The “everything is a file” concept is older than most of the people who rely on it, and it's even older than Linux itself. Much of what makes an operating system like Linux so unique comes from those early Unix days, and while there are certainly interfaces in Linux that aren't files like D-bus and netlink, the file layer still remains underneath everything. If you're coming from Windows and something doesn't quite make sense in Linux, more often than not that 'something' is controlled by a file.