4 ms·

Docker is a nice idea. It's one tool, one system, for easily packaging software and running it, in an isolated environment. But Docker includes a lot of crap mo

Docker is a nice idea. It's one tool, one system, for easily packaging software and running it, in an isolated environment. But Docker includes a lot of crap most people don't need. Do we need an isolated network for our apps? Do we need an isolated cgroup? Do we need to install a complete base image of an OS? Do we need root to run those apps? The answer, for most cases, is no. Then there's things like Flatpak. They also want to make it easy to package and distribute software. And they see all the features of Docker and go, "Hey, a sandbox! That sounds cool! Let's make it mandatory!" In order to simply distribute software in a compatible way, they include a lot of restrictions they don't need to just distribute and run software. 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! So what the hell is the deal here? Why has nobody come along and just provided the bare minimum needed to just distribute software (edit: in a way that also allows it to be run with all its dependencies in one overlay filesystem view)? Why is it always some ass-backwards incompatible crap that is "controversial" ? Why can't we just make something that works for any software?

rkeene2 8y ago
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.

rkeene2 8y ago

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.