3 ms·

Much of that is documented in the page called "Getting Started": http://appfs.rkeene.org/web/home/Getting%20Started http://appfs.rkeene.org/web/home/Getting%20S

Much of that is documented in the page called "Getting Started": http://appfs.rkeene.org/web/home/Getting%20Started http://appfs.rkeene.org/web/home/Getting%20Started I'll summarize it here: 1. To use it to run application: a. Get AppFSd running; then b. Run the application you actually wanted to run 2. To package an application: a. Create a package manifest b. Run the build script to create a CPIO archive c. Upload that CPIO archive to a webserver d. Run the script to publish the archive 3. The package manifest format is described in the README ( http://appfs.rkeene.org/web/doc/trunk/README.md http://appfs.rkeene.org/web/doc/trunk/README.md ) -- it's CSV with the format "type,time,extraData,name" where the extraData is depends on the value of "type" for type==file, it's "size,perms,sha1" If you're looking for something Docker-like then it's different since this is a filesystem based approach which doesn't require any of the containerization techniques used by Docker... which is how this conversation got started. It would also not be available on every platform since not every platform supports the same containerization mechanisms, and for platforms that do they often require escalated privileges.

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 ago
  Which is why AppFS doesn't rely on that and instead relies on the ability to present a single unified filesystem.

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 ago
Which is why AppFS doesn't rely on that and instead relies on the ability to present a single unified filesystem.