There is a rising trend amongst entrepreneurs to call their products the “Operating System of X” where X could be creator economy, large language models, so on and so forth. This nomenclature is correct in that the Operating System is a tool to manage resources and “bring everything together”, but incorrect largely because an Operating System has a specific meaning. An operating system, in its true sense, is a specialized software that manages hardware resources, provides common services for computer programs, and acts as an intermediary between users and the computer hardware. If we ignore the great OS wars between the big three right now (“Linux”, MacOS and Windows), Operating Systems generally behave the same way and aim to provide the same set of features. A bunch of softwares including text editors, photo viewers, browsers, file managers and a terminal - along with some shared commands, usually POSIX compliant, in one way or another.
In the phrase, "“…acts as an intermediary between users and the computer hardware.”, the word “user” is an operational keyword. However, the user doesn’t just mean the flesh and bones using the computer, it refers to an abstract group of processes that have less privileged access to the hardware.
Asianometry, a YouTuber who covers politics and technology of Asia, says in their video, “You might think that your "file" is sorted away somewhere as a discrete entity on computer memory - like a book in a bookcase. But this is a fraud! In reality, the file data scattered in pieces like Cheetos across wherever the computer happened to have storage.” - and that is correct.
In Linux, for example, files are managed by the filesystem, which provides an abstraction layer over the raw storage device. Common filesystems include ext4, XFS, and Btrfs (You can view what filetypes are mounted ). These filesystems use various structures to manage and locate file data. The actual contents of a file are stored in data blocks on the storage device. These blocks are usually a fixed size (e.g., 4 KB). When a file is created or modified, its data is written to one or more of these blocks. However, these blocks are not necessarily contiguous.
Due to fragmentation and the way filesystems allocate space, the blocks for a single file can be scattered across different physical locations on the disk. Each file in a Linux filesystem is represented by an inode. An inode contains metadata about the file, such as its size, permissions, timestamps, and pointers to the data blocks where the actual file contents are stored. The inode itself does not contain the file name or the data; instead, it provides a reference to the data blocks. Often, Inodes also contain pointers to the data blocks.
For small files, these pointers might be direct, meaning the inode points directly to the data blocks (since they’re non-fragmented at smaller sizes). For larger files, the inode may use indirect pointers, which point to blocks that contain further pointers to the actual data blocks. This multi-level pointer system allows the filesystem to manage large files efficiently (This isn’t a text on how these things work, so I will spare you how these indirect pointers work, but I will reference to some resources towards the end).
This level of complexity, to create a simple “hello.txt” isn’t acceptable to the user. So instead, we use the kernel to handle these resources. But didn’t we just say that we use the operating system? Well, the operating system is a “wrapper” around the kernel, and uses other user friendly software like system libraries and (eventually) user interfaces.
There are a million things inside of a kernel that are abstracted away from a user for their ease of use. These things could be processes, interrupts, file descriptors, pipes, and even how the OS loads itself.
If you’ve read “In the Beginning... Was the Command Line” or “The Mythical Man-Month”, you might be expecting some historical documentation of a white-bearded Engineer reminiscing about “Ye Olde Days” - unfortunately for both of us, I was born the same year the first MacOS to be officially called MacOS was released (I’ll leave that for you to figure out). With all that said, I’ll be as thorough as I can be, I’ll leave nothing to chance.
This is the start of my work on collecting and documenting the history of operating systems as told by the first engineers and users to work on them.
The structure is, I’ll pick 3 big releases that happened every year since 1951, and give a little preamble about how it all came to be. I’ll try to judge and estimate reasons for why OSes are how they are best as I can.
I’ll try to send you a new chapter every week, some chapters take longer, some shorter, and for most I’ll have to comb books, emails, letters, videos and more. But you can trust me.
See you around soon.
logout now
(Note: I will most likely not actually do this. I wrote this in 2025, I have not written one chapter after that.)