4 ms·

I did. http://appfs.rkeene.org/ http://appfs.rkeene.org/ You're welcome.

by rkeene2 8y ago

peterwwillis 8y ago
Errr... that's not really what I'm looking for, my last paragraph was a bit inaccurate. But seems cool nonetheless.
- rkeene2 8y ago
  It's literally what you described in the third paragraph: > All you need to distribute a software package is files, and a subsystem that maps files into the user's environment, and links together the files needed to run the software. We can accomplish this with a copy-on-write, overlay filesystem, and some software to download dependent files and lay them out in the right way. It should be incredibly simple, and it should work on any operating system that supports those filesystems. And those filesystems should be simple enough to implement on any operating system! It's literally, and exactly that. I'm not sure how it can be not what you're looking for.
  - peterwwillis 8y ago
    Well, first of all, there's almost no documentation. I can see how to install it and run it, but I have no idea how to use it. How am I supposed to package software for it, or with it? How does it work internally? How is it supposed to provide an overlay for an individual application, much less multiple? How does it link dependencies? What's even the package manifest format? I skimmed through the C code and the Tcl code and none of it was readily apparent to me, and I could find no more documentation than a Getting Started guide. The manual is literally just the arguments to the app. I'm not sure how anyone other than the author could figure out how to do what I'm looking to do with it. Also, you may be missing that I'm looking for Docker-like functionality. That is to say, have, say, 3 trees of files, one built on top of the other. When launching the application, lay the first tree down on an overlay, then the second, then the third, then run the application. By having the third tree link to the first two, I just pick the tree I want to run (the third tree, the one with the app), and it creates the correct overlays with the correct dependencies and runs it. No special paths needed by the application. What I'm asking for could be done with existing packaged software, with no need to change existing packages - the same way Docker does it now.
    - rkeene2 8y ago
      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

I did. http://appfs.rkeene.org/ http://appfs.rkeene.org/ You're welcome.

peterwwillis 8y ago

Errr... that's not really what I'm looking for, my last paragraph was a bit inaccurate. But seems cool nonetheless.

rkeene2 8y ago
It's literally what you described in the third paragraph: > All you need to distribute a software package is files, and a subsystem that maps files into the user's environment, and links together the files needed to run the software. We can accomplish this with a copy-on-write, overlay filesystem, and some software to download dependent files and lay them out in the right way. It should be incredibly simple, and it should work on any operating system that supports those filesystems. And those filesystems should be simple enough to implement on any operating system! It's literally, and exactly that. I'm not sure how it can be not what you're looking for.
- peterwwillis 8y ago
  Well, first of all, there's almost no documentation. I can see how to install it and run it, but I have no idea how to use it. How am I supposed to package software for it, or with it? How does it work internally? How is it supposed to provide an overlay for an individual application, much less multiple? How does it link dependencies? What's even the package manifest format? I skimmed through the C code and the Tcl code and none of it was readily apparent to me, and I could find no more documentation than a Getting Started guide. The manual is literally just the arguments to the app. I'm not sure how anyone other than the author could figure out how to do what I'm looking to do with it. Also, you may be missing that I'm looking for Docker-like functionality. That is to say, have, say, 3 trees of files, one built on top of the other. When launching the application, lay the first tree down on an overlay, then the second, then the third, then run the application. By having the third tree link to the first two, I just pick the tree I want to run (the third tree, the one with the app), and it creates the correct overlays with the correct dependencies and runs it. No special paths needed by the application. What I'm asking for could be done with existing packaged software, with no need to change existing packages - the same way Docker does it now.
  - rkeene2 8y ago
    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