Filesystem organization is the Achille's heel of Unix. Many of the OS's weaknesses can be traced back to the (lack of) design of (and later patches to) the filesystem hierarchy.
In the old days, these things used to be just minor inconveniences—the idiosyncrasies of Unix that you learned to live with. But the world has changed. Thanks to the GNU and Linux projects, Unix is now ubiquitous. And thanks to the Xen project, it is a commodity. Unfortunately, these developments have also brought the inherent problems in the filesystem layout to the forefront, and amplified them in unexpected ways.
In fact, like a pebble in the shoe preventing one from moving about freely, I believe the disorganized state of the filesystem is now blocking the evolution of Unix. Maybe even of operating systems in general.
It is difficult to fix these things gradually. The incremental benefits are not enough to offset sacrificing backward compatibility. Nor can you pull the rug from under the feet of existing systems.
But what you can do is to introduce a parallel track of the OS with a newly rethought filesystem hierarchy. Objectroot is my humble proposal for that hierarchy. What follows are notes on how it addresses some of the most pressing problems in the current system.
Problem: Unix continues to be an insecure computing environment. It is not easy to set up, say, a GNU/Linux system for Internet workstation use, and be absolutely certain that your personal files will never end up in the wrong hands. Furthermore, some Unix platforms, such as Mac OS X, seem to be a complete Wild West, with binary-only software “phoning home” on every invocation. The user has no control over—or even any idea of—what's going on in their computer. This is utterly unacceptable.
Solution: Objectroot compartmentalizes not just users but also software publishers, OS instances and services within an OS instance, to their own containers. These containers can be individually protected, chrooted, sandboxed, snapshotted, diffed and tripwired.
Problem: Currently, when invoking a command by name, a shell programmer can never be sure which of the many known implementations of the command gets executed. This makes writing portable scripts very difficult.
Solution: In objectroot, every command by every software publisher has a globally unique canonical pathname that can be referenced when the implementation of the command matters.
Problem: Currently, files related to a particular subsystem are scattered all over the place based on irrelevant criteria such as the type or variability of a file, or just for plain “historical reasons.”
Solution: In objectroot, files are organized by containment.
This means, for example, that a simple
rm -r gets rid of any
subsystem in its entirety, and you will not later find cruft about it
/var or some other obscure place (that probably
needn't even exist).
Problem: Currently, because everything in the filesystem is mixed and mashed with everything else, software package management has become a war of its own. In fact, the problem is so complex that whole new operating system distributions seem to have been started just to introduce a new package management scheme. If this is not a sign that the hierarchy needs rethinking, I don't know what is.
Solution: In objectroot, all software is organized into publisher specific trees. This makes package management trivially easy to implement.
Problem: The current filesystem organization dates back to the time of mainframe computers and teletype terminals. In those days, performing a Unix installation was a major event. Unfortunately, the permanency of the installation left its mark on the filesystem organization. As a result, it is a poor fit for today's data centers where agile installations, Unix-as-a-commodity marketplace and loosely connected clusters are the norm.
Solution: Objectroot objectifies not just the user environment
but the operating system itself. This not only makes the system
completely reflective, but there can be many variants, versions,
configurations and instances of the OS
installed on the system disk at any one time. Switching between
them and migrating them from one computer to another takes just a