2 ms·
I should have looked up the actual functionality to avoid confusion, my bad. This is what I'm talking about: https://docs.docker.com/storage/storagedriver/#how-
by peterwwillis 8y ago
I should have looked up the actual functionality to avoid confusion, my bad. This is what I'm talking about: https://docs.docker.com/storage/storagedriver/#how-the-overlay2-driver-works https://docs.docker.com/storage/storagedriver/#how-the-overl...
The Overlay2 filesystem driver is Linux-native, but you could implement it as a FUSE module. It would provide basically all the functionality I'm looking for, minus the network code. The idea would be to unpack software packages on the filesystem (e.g. chroot environment) and then overlay the directories of the packages needed before running a particular version of an app.
In order to make custom paths transparent to the application, you need some custom system calls that Linux provides, such as mount namespaces, which is essentially a containerization technology - but you don't need to use "containers" per se, just a particular system call. If you don't use mount namespaces, you have to use complicated hacks to make an application's view of the filesystem unique, such as chroot with bind mounts, or an LD_PRELOAD filter, but all that's too hacky for a general solution.
Plan9 had mount namespaces (among other things) decades ago, but good luck getting modern OSes to implement useful features in a standard way
- rkeene2 8y agoWhich is why AppFS doesn't rely on that and instead relies on the ability to present a single unified filesystem.