Plan 9 had such a powerful model for networked systems using these virtual file systems, it sounds like a fairytale!
Oh, want to use that other machine as a gateway? Just mount its /net.
Oh, want to route audio through another machine? Just mount their soundcard into your /dev.
Oh, your machine is too puny to do the task at hand? Just run “cpu thebigmachine” which transplanted your entire environment over there (all the virtual file systems) so that you can continue doing what you were doing, but using that machine’s CPU and memory.
This solved the problem of having to transplant your setup to the remote machine, which you have with modern SSH. If you wanted a different environment you instead created it locally. Each process har its own virtual file tree with mounts.
There were cool things at the local level too: All the programs would expose virtual file systems to interact with. Text editor? Each window had a directory with files containing window content, current selection, even the UI “tagline” with commands. This meant you could write scripts for your programs in any language, because you just had to interact with files.
A modern take on plan 9 is definitely on my Christmas wishlist!
Have a look at Objective-Smalltalk[1][2], with polymorphic identifiers[3] (all identifiers are URIs), storage combinators[4] (virtual filesystems on steroids), and polymorphic write streams[5] (streams everywhere).
Objective-Smalltalk basically provides the sorts of things you write about locally at the language level. You could also move specific instances behind an operating system boundary.
Could you explain the connection you see a bit more?
Part of the appeal of the Plan 9 approach was that you could use any program in your distributed environment, written in any language, because the abstraction layer was the file system – the lingua Franca of IO.
Let's start with an example, the Objective-Smalltalk equivalent of Python's simple web-server for a directory.
Python:
python3 -m http.server 8000
This serves the current directory on port 8000. The invocation for the Objective-Smalltalk script doing the equivalent job looks as follow:
./simplefileserver.st ./ 8000
Here is the Objective-Smalltalk 'simplefileserver.st' script:
#!env st
#-server: <ref>dir port: <int>port
framework:ObjectiveHttpd load.
dir asScheme waitOnPort: port.
If you look carefully, you'll notice that this doesn't actually say anything about the filesystem. It just expects an argument 'dir' that is a 'ref' and then goes from there.
Here are some other example of what a "ref" can be:
The first will make this server act like an http proxy, the second will serve a remote directory, the third will serve our environment variables, the fourth will serve the contents of our process's defaults database (a macOS/iOS thing), the fifth our classes and the sixth the contents of the scheme registry where all the other schemes listed so far are registered.
"Ref" is anything referencable by a polymorphic identifier, a slightly adapted version of a URI. And any ref can be turned into a store (aka "scheme-handler"). And a store can be literally anything that can store and retrieve data by key/index/name/path, from local variables via filesystems, databases all the way to the World Wide Web.
So you can see that you can get the same location transparency that Plan 9 gives you without requiring operating system support. Which comes in handy when you can't switch to a new operating system. What's more, the support extends to a lot of things even Plan 9 probably wouldn't consider a filesystem (local variables?). Last not least, this does not require accessing everything via POSIX API and a byte-serialized representation. Definitely not "least"!
You can access via a byte-serialized representation (as via the http server above) if you want, and you can even access via POSIX API (there is a generic fileserver that serves any of these stores / scheme handlers) if you really, really want. I am not at all sure why you would want that.
And you can, of course, also access this via any language that can talk to C as the libraries that implement the functionality are written in portable Objective-C. Objective-Smalltalk just provides the proper linguistic support.
Git is incredibly mediocre. But it's all most people know. It's a version control tool that can't handle binary files; and no GitLFS does not count. The end result is a version control tool that is unable to actually version control all the things you need for a project.
This results in a Meta VCS layer where a ton of critical assets are stored in Docker files and other misery. If you want to re-compile a project for 2015 then good luck and god speed.
Personally I think full toolchains belong in source control. And that you should be able to clone / materialize a repro, yank your network cable, and build. This is how big tech monorepos work. It is TheWay imho.
IMO screw that. It's maybe a good way to build software in exactly one environment for exactly one environment, deployment to a corporate server fleet.
Consider a Linux desktop distro: if every little binary (out of order of magnitude 1000) acted like the center of the universe with gigabytes of build environment and "opinions" galore instead of portability, builds would take much more resources than they already do and parts wouldn't necessarily work together.
The .git directory does not contain plain files, so the same files may look different in different .git directories. But yeah, you could make it work if you designed for it.
Visual Studio and Xcode take up tens of gigabytes, are updated often, and include system components. Storing them in VCS is impossible, and would be a waste of disk space.
Disagree. They’re stored _somewhwre_ anyway, and they may as well be versioned.
Putting toolchains in perforce is how it works for lots of C++ shops, the setup instructions are “sync and hit build”, whether there’s a toolchain upgrade required or not
I wonder if we're doing virtual filesystems wrong.
There is a good reason why traditionally filesystem access was mediated by the OS layer, but there are many use cases where you just want to give processes a different view of what they already can access and it could be done as a library in the same userspace process.
However, for that to work across all the processes in a session we'd need a standard way to install such a hook in all peocesses and that's achievable to some extent using LD preload but falls apart quite rapidly with statically built binaries or different libcs
Sending -asScheme to a reference is just a shorthand that actually constructs a composition[2] of a "path relative" store with the underlying store of the original reference. So the following two are identical:
This composition mechanism can be carried further with post-processing, so for example an img-scheme can be constructed by composing an image-decoder store with the previous store
Comments
Dreaming of "virtual filesystems everywhere". Hmm, sorta sounds like Plan 9.
Great to have an inside view of wrangling technologies for these behemoth data sets.
Plan 9 had such a powerful model for networked systems using these virtual file systems, it sounds like a fairytale!
Oh, want to use that other machine as a gateway? Just mount its /net.
Oh, want to route audio through another machine? Just mount their soundcard into your /dev.
Oh, your machine is too puny to do the task at hand? Just run “cpu thebigmachine” which transplanted your entire environment over there (all the virtual file systems) so that you can continue doing what you were doing, but using that machine’s CPU and memory.
This solved the problem of having to transplant your setup to the remote machine, which you have with modern SSH. If you wanted a different environment you instead created it locally. Each process har its own virtual file tree with mounts.
There were cool things at the local level too: All the programs would expose virtual file systems to interact with. Text editor? Each window had a directory with files containing window content, current selection, even the UI “tagline” with commands. This meant you could write scripts for your programs in any language, because you just had to interact with files.
A modern take on plan 9 is definitely on my Christmas wishlist!
Have a look at Objective-Smalltalk[1][2], with polymorphic identifiers[3] (all identifiers are URIs), storage combinators[4] (virtual filesystems on steroids), and polymorphic write streams[5] (streams everywhere).
Objective-Smalltalk basically provides the sorts of things you write about locally at the language level. You could also move specific instances behind an operating system boundary.
[1] https://objective.st
[2] https://dl.acm.org/doi/10.1145/3689492.3690052
[3] https://dl.acm.org/doi/10.1145/2508168.2508169
[4] https://2019.splashcon.org/details/splash-2019-Onward-papers...
[5] https://dl.acm.org/doi/10.1145/3359619.3359748
Could you explain the connection you see a bit more?
Part of the appeal of the Plan 9 approach was that you could use any program in your distributed environment, written in any language, because the abstraction layer was the file system – the lingua Franca of IO.
Sure!
To start:
An operating system is a collection of things that don’t fit into a language. There shouldn’t be one.
— Dan Ingalls, https://www.cs.virginia.edu/~evans/cs655/readings/smalltalk....
Let's start with an example, the Objective-Smalltalk equivalent of Python's simple web-server for a directory.
Python:
This serves the current directory on port 8000. The invocation for the Objective-Smalltalk script doing the equivalent job looks as follow: Here is the Objective-Smalltalk 'simplefileserver.st' script: If you look carefully, you'll notice that this doesn't actually say anything about the filesystem. It just expects an argument 'dir' that is a 'ref' and then goes from there.Here are some other example of what a "ref" can be:
The first will make this server act like an http proxy, the second will serve a remote directory, the third will serve our environment variables, the fourth will serve the contents of our process's defaults database (a macOS/iOS thing), the fifth our classes and the sixth the contents of the scheme registry where all the other schemes listed so far are registered."Ref" is anything referencable by a polymorphic identifier, a slightly adapted version of a URI. And any ref can be turned into a store (aka "scheme-handler"). And a store can be literally anything that can store and retrieve data by key/index/name/path, from local variables via filesystems, databases all the way to the World Wide Web.
So you can see that you can get the same location transparency that Plan 9 gives you without requiring operating system support. Which comes in handy when you can't switch to a new operating system. What's more, the support extends to a lot of things even Plan 9 probably wouldn't consider a filesystem (local variables?). Last not least, this does not require accessing everything via POSIX API and a byte-serialized representation. Definitely not "least"!
You can access via a byte-serialized representation (as via the http server above) if you want, and you can even access via POSIX API (there is a generic fileserver that serves any of these stores / scheme handlers) if you really, really want. I am not at all sure why you would want that.
And you can, of course, also access this via any language that can talk to C as the libraries that implement the functionality are written in portable Objective-C. Objective-Smalltalk just provides the proper linguistic support.
Oh wow, I didn't know it had things like that.
Especially the CPU functionality is really interesting. I'm pondering similar problems and the current solutions just aren't good enough.
Redox seems to take inspiration from it and has all things exposed as schemes so /home/user is actually /scheme/file/home/user, etc.
I'd love a Plan9 with a keyboard driven UI.
Please universe I beg you.
Git is incredibly mediocre. But it's all most people know. It's a version control tool that can't handle binary files; and no GitLFS does not count. The end result is a version control tool that is unable to actually version control all the things you need for a project.
This results in a Meta VCS layer where a ton of critical assets are stored in Docker files and other misery. If you want to re-compile a project for 2015 then good luck and god speed.
Personally I think full toolchains belong in source control. And that you should be able to clone / materialize a repro, yank your network cable, and build. This is how big tech monorepos work. It is TheWay imho.
IMO screw that. It's maybe a good way to build software in exactly one environment for exactly one environment, deployment to a corporate server fleet.
Consider a Linux desktop distro: if every little binary (out of order of magnitude 1000) acted like the center of the universe with gigabytes of build environment and "opinions" galore instead of portability, builds would take much more resources than they already do and parts wouldn't necessarily work together.
Deduping files is easy.
It's also useless if every tool lives in its own copy of the universe - there'd be little to no identical files.
It also won't work for version control databases, assuming use of a distributed VCS.
Yes it would require a global blob store across reps. That seems like a good design choice.
I don’t know what you mean by “ won't work for version control databases, assuming use of a distributed VCS.”
The .git directory does not contain plain files, so the same files may look different in different .git directories. But yeah, you could make it work if you designed for it.
Yeah Git is super mediocre. But the hypothesis is that you could build something that doesn’t suck!
Visual Studio and Xcode take up tens of gigabytes, are updated often, and include system components. Storing them in VCS is impossible, and would be a waste of disk space.
You could consider ZFS a VCS, and it can easily store multiple versions (snapshots) of Visual Studio.
It's not impossible, there just isn't that much demand for it.
Literally not impossible. And also not tens of gigabytes.
Disagree. They’re stored _somewhwre_ anyway, and they may as well be versioned.
Putting toolchains in perforce is how it works for lots of C++ shops, the setup instructions are “sync and hit build”, whether there’s a toolchain upgrade required or not
I wonder if we're doing virtual filesystems wrong.
There is a good reason why traditionally filesystem access was mediated by the OS layer, but there are many use cases where you just want to give processes a different view of what they already can access and it could be done as a library in the same userspace process.
However, for that to work across all the processes in a session we'd need a standard way to install such a hook in all peocesses and that's achievable to some extent using LD preload but falls apart quite rapidly with statically built binaries or different libcs
I think there is a good case to be made for these things not to be mediated by the operating system by default.
In Objective-Smalltalk[1], I can access a file as follows:
This is structurally the same way I would access a local variable, environment variable, database, remote http server etc. etc.And you can also introduce shortcuts
Or Sending -asScheme to a reference is just a shorthand that actually constructs a composition[2] of a "path relative" store with the underlying store of the original reference. So the following two are identical: This composition mechanism can be carried further with post-processing, so for example an img-scheme can be constructed by composing an image-decoder store with the previous store And so on and so forth, caching is also a nice example.[1] https://objective.st
[2] https://dl.acm.org/doi/10.1145/3359591.3359729