Every piece of hardware on a computer is a piece of global mutable state. There are many good reasons to hide that fact behind an abstraction, but I can't help but think hiding global mutability is better handled at the application level than the OS level, because there are too many cases where the abstraction becomes extremely limiting.<p>As an example, most people would want to be able to import an image into a word processor regardless of where that image is located (local drive, network drive, floppy disk, etc.). To support that, most end user programs would want to be offered access to the entire filesystem. The moment two applications do this at once, you have all the shared mutable state problems we do now.
This was first explained by the capability security community. Plan 9's private nameapaces is an approach to capability secure file systems, with the default being the empty namespace. I'm surprised the article didn't mention Plan 9 actually since it discusses capabilities.
I've thought for years that 'file systems' are an abomination. We use a cobbled-together schema of parent-directory, filename, some random date/time stamps and maybe a three-letter extension. Why? Because we inheirited that from some DOS days.<p>Why not a collection of immutable UUID-labelled resources with an arbitrary schema of attributes? Like a relational database or some such.<p>Overkill? Doesn't every major app have to do this itself, in some container (document/mail folder/image definition/contact list and on and on)?<p>Designers of operating systems have made no effort to capture this kind of service and provide it as a fundamental OS feature. And OSs are exactly where this belongs - where you can carefully get it right and everybody writing apps can depend on it.
Interesting, and should definitely be read with the companion <a href="https://www.devever.net/~hl/objectworld" rel="nofollow">https://www.devever.net/~hl/objectworld</a><p>Given the same title, I would write a rather different article. So many of our traditional filesystem problems center around concurrency: what kind of read-after-write or durability semantics are guaranteed. A lot of effort goes into this, which is necessary for databases to work on top of a general-purpose filesystem on top of a disintermediated storage system that may be a disk or SSD with a variety of block sizes. But for most operations it's unnecessary overhead.<p>Many games ship with a "packfile", which is a pseudo-filesystem that appears as a giant blob to the OS. Usually it's faster to seek individual small items out of the blob than if they were separate files.<p>Further to that is the security problem; we've moved from "apps are all trusted, but you need to watch the files closely between multiple users" to "there's only one user, but you can't trust the apps".<p>Note how the cloud has avoided both of these by moving storage to three different areas with different semantics. Apps can speak to "blob storage" (S3) which has a transactionality/security granularity of one blob. Or they can speak to a database (which has intelligence of its own), or separate raw block storage if neither of those suits.<p>What if we moved from "everything is a file" to "everything is a URL"? Possibly adding a system-default packfile mechanism. So an app would be allowed access to everything that it ships with, but nothing outside except what it could request as URLs with various sorts of security mechanism.
As anyone who has put together a chroot knows, it isn't as simple as just preventing a process from accessing the filesystem. Most programs <i>need</i> to access <i>a</i> filesystem, just so they can load libc and the various other libraries it might need.
One thing missing from this rethinking, as far as I can tell, is names.<p>You can't move pointers between different processes in general, because each process has its own "memory address namespace". But an absolute path generated by one program does make sense to another program.
This is a fascinating idea, and totally obvious in retrospect :-)<p>I've noticed features that work towards cutting off access from global file system. Containers are mentioned in the article, but there are other things like systemd giving easy access to per-service private temp files, blocking access to /home, whitelisting paths that are allowed at all etc.<p>The problem really is that this global mutable state has existed for 50+ years, so lots and lots of things now rely on it: dynamic loading of libraries (could be separate objects from files), configuration (doesn't need to be stored in files), UNIX sockets that are accessed by file name etc.<p>And not only have many programs started to rely on files, but many have relied on them being mutable. Webservers can be told to re-read their config from a running process, things like that.<p>So, is there any way forward for UNIX-based systems that don't break the world?<p>Edit: another interesting observation is that iOS has already done away with the global file system, at least from the perspective of the apps.
Web assembly is a good step in the elimination of the globally shared FS. Dynamically linked libraries are explicitly provided with an index only that links to the library location. <a href="https://webassembly.org/docs/dynamic-linking/" rel="nofollow">https://webassembly.org/docs/dynamic-linking/</a><p>WASI <a href="https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webassembly-system-interface/" rel="nofollow">https://hacks.mozilla.org/2019/03/standardizing-wasi-a-webas...</a> will provide access to files given to the function by the runtime, not vice versa as in operating systems where a syscall is sent to ask permission for a file.
This reminded me of this [1] talk from 32c3, which talks about the same issues and presents and overview of some approaches ppl have come up with. Somewhat BSD centric, but I found it interesting back then.<p>[1]: <a href="https://media.ccc.de/v/32c3-7231-cloudabi" rel="nofollow">https://media.ccc.de/v/32c3-7231-cloudabi</a>
One thing that has always astounded me is the fact that the following script can be executed without any special permission (apart from execution, read and write):<p><pre><code> rm -rf ~
</code></pre>
A key to a more modern file system would be a much more granular permission systems apart from "rwx" for a certain group of users.