Disclaimer (8/28/2019): I was talking out of my head when I wrote this. Graph-based file systems don’t need a new kernel, and the whole “binary DOM” essentially proposes the use of atoms and enums to reduce memory usage.
As I was watching Druaga compare the Windows system folder with the Mac system folder (which is probably just a fake frontend to a really ugly backend), I suddenly began to pace around, thinking about that graph-based file system again. I also thought about the “organization” defined by POSIX: is /usr/, /var/, /etc/, /opt/, /lib/, etc. really understandable? There’s clearly a conflict here: we want an organization that caters to both readability by the user, the core system, its components, and applications.
I speculate the creation of a new operating system in the next generation. Currently, I believe that it is nearly impossible for a new kernel to be created due to the excess complexity of driver-writing, rendering operating system support for PCs effectively exclusive to Linux and Windows since those are the only two systems that can really be tested.
Why do we need a new operating system? In truth, we really do not. The conservatives will say, “Then why go into so much effort making an operating system that nobody will use, when there already exists one that works?” I’d ask the same thing about GNU Hurd, ReactOS, and so on.
It’s for the future. You see, I believe there is a fatal flaw in the current operating systems’ basic persistence mechanism: it’s a limited directed graph that surmounts to a tree. It works under the premises that system data can be organized as papers and files inside folders. But the truth is that such data can be organized in various ways, but still not necessarily in a hierarchical or tag-based structure.
An undirected graph-based file system would work like the brain, and using more fundamental pieces of data that could allow the cluster size to go down to perhaps 2K. It would be incredibly difficult to visualize, but what you could still do is place sections of this data system in different physical locations, such as a server.
Let’s walk through what this system could look like.
On boot, the bootloader finds the data system and binds to it. The first node is always the header node, which may or may not link to a boot node, a data node containing the binary data to start the kernel. The kernel booter then looks through a kernel list linked by the boot node and selects the most recent one, or the one selected by the “selected-kernel” node (this is, of course, the human-readable name of the node; the actual reference is by UID or by a standardized, system-assigned tag whose meaning can be translated into a human-readable form by an enumeration somewhere in the data system). The kernel, of course, has a first-class link to drivers and modules needed to start the system, as well as a user-mode initializer (like init, but more agnostic).
The loading process continues, but the nice thing is that every section of the system always has a one- or two-step reach to its necessary resources.
There’s an even greater advantage: it obsoletes most functions of a package manager. How? A package need only be extracted to a special “packages” node, and plop, its resources are neatly connected to each other, and any necessary system modules are connected (or, if the package is a system module, then a connection is made from the system modules node to that package). Uninstallation is just as simple: the package node is removed, as well as all references to it (the “package manager” checks to see if any of these connections are actually dependencies, but usually packages will just link directly to one another to indicate dependency).
The user also gets a bite of that simplicity: documents can be organized as “thoughts,” “business,” “travel,” or multiple categories. Finding recent documents is instant, and not just some nifty MRU hack from the file manager you’re using. Users are no longer pressured to organize their data in either one way or the other: they can simply connect related things to each other and tag them, or let the computer auto-tag from the data.
Integration with cloud storage is not easy, but this data system would still make it practical, since most storage providers use an object-based structure rather than a hierarchical file-folder structure.
Viewing the applications or packages list on your computer is no longer some arcane command, whose application by regular users is often combated with the approach, “Why do you need to know?” Instead, the file manager can use a preset organization that can provide a nice application list by category, size, and so on, only needing to expose the name of the application and its icon in the initial enumeration without first having to check it into the desktop environment on the application’s install. Yet power users can right click that application icon, command the file manager to go to that package, and view its dependencies, resources, executables, and whatever the power user wants to know. In contrast, on *nix-based machines, it’s impossible to do this simply because every program is strewn all over multiple directories, shared by many programs via a hackton of symbolic links.
For the security-minded, one can create realms, which use a sort of mandatory access control to control who can view a specific area of nodes, regardless of how a user arrived to a node within that area. For instance, a business user can say, “I want to keep all of my business data in one place, and make sure nobody except me can see it.” He would then gather all of his business documents together and designate them as a part of a realm. If he wanted to, he could also place a realm inside a realm to designate extra-secure data. He could then create a job to back up or move all contents of the realm to another storage service.
How is this different from a tag-based file system? A tag-based file system only works under the assumption that it is the user, rather than the system, that deserves the complexity. You can have the shiniest UI, but the absolute ugliest stuff under the hood. Like a Mac, the user only sees the “applications are just folders” gimmick, but in the backend, it’s a big spaghetti of POSIX-compliant directories.
But simplicity should be everywhere. And if this offends you, I believe that flat files for configuration (where only keys and values are needed) are an anti-pattern in this data system design. You want as many things to be linked to each other. Your configuration “file” would become a node, which each key connected to that node containing a data node as a value. No more waste of time parsing dumb .properties and .ini files, except if you have a legitimate database.
I don’t know. It’s an idea for the future, and I haven’t seen much headway made into the concept of a data system that works like a brain rather than like a tree.
My second idea is a slim layout engine which I like to call “Layman,” or perhaps “Layton” if anyone cries foul of gender bias or whatever people protest these days. After seeing the sluggish loading speed of a simple webpage on the Mozilla Navigator in PS2 Linux – granted, the PS2 does not work great as a general computing device, given it only has about 32 MB of usable RAM – it’s probably time to start figuring out how we can place web browsers in embedded devices without slaughtering them with 150-250 MB per web page open, while preserving as many HTML/CSS features as possible (including animations and WOFF2!), keeping total download sizes less than 1 MB, and making layout speeds snap fast.
But I don’t think the world needs another layout engine at this moment. Arrogance and debate are abound.