1. 3

Use FUSE and loop mounting to deliver an app and its dependencies as a bundle in one single file runnable by an unprivileged user.

  1.  

  2. 9

    See also:

    1. 4

      This is like a more complicated way of creating a statically linked binary?

      1. 1

        Could someone explain the difference? (Am assuming there is one.)

        1. 2

          Things that are not in the binary. Most software isn’t written for including pictures etc in the binary. It also allows for software that is written as several executables, or an interpreter and a hundred source files, to be deployed as one file.

      2. 2

        One practical problem with AppImage for me personally is that an unmodified guix[0] wouldn’t be able to produce an AppImage, as the image needs to use relative paths.

        But with bubblewrap[1] plus AppImage it looks like it should be possible to use absolute paths. Will look into this in my Copious Spare Time.

        [0] https://www.gnu.org/software/guix/

        [1] https://github.com/projectatomic/bubblewrap/blob/master/README.md

        1. 2

          Why would I want to go back to the dark ages of managing my own dependencies and updates and updates to my dependencies? Sounds like a nightmare.

          1. 2

            first, there was the dark ages of managing your own dependencies. Then came the new age, where people began relying on package managers and upstreams to handle dependencies for them. This was revealed as a false dawn. Package managers and upstreams are no better, and frequently far worse, at managing your dependencies than you are. Now we are tentatively exploring other alternatives, in which it is possible to lock down dependencies. This is probably not working either. Simple solutions may not be forthcoming.

            1. 4

              Nix gets this right by allowing multiple versions of a package to coexist. In retrospect, it’s kind of unfortunate that the nix community put their energy into making a Linux based on it rather than trying to get it adopted as a base-package manager for more use cases.

              1. 1

                What sort of use cases are you imagining?

                1. 5

                  Every language has its own package manager and, IMO, they all mostly suck. If I can’t get my one big universal package manager based on nix, I wish at least pip, opam, maven, etc etc were based on nix.

                  1. 1

                    Yeah. I try as much as I can to stick to packages in my OS unless I really want to play with bleeding-edge libraries for something :)

                  2. 2

                    To be clear, I’m saying I wish nix was the base technology these language specific package mangers were implemented on, even if they have their own repositories and UIs and all that.

                  3. 1

                    The way nix solves this is great, but most good OS systems also allow multiple major versions to coexist when necessary, it’s just less considered the major, core feature that Nix has made it.

                    1. 1

                      This is based on the assumption the different minor and patch versions are compatible, or at least backwards-compatible.

                      Nix is built on the observation that they can’t be guaranteed to be.

                  4. 2

                    At least when an OS handles the dependencies you get a single set installed that works for all apps instead of whatever I as the developer thought worked on my machine.

                    But I agree, nothing is simple and someone always has to do the work.

                    1. 1

                      you, the developer, are more right than everyone else is about what version of dependencies are appropriate for your software. This is further true for each and every developer of each and every software. The best an OS can do is try to make things safe for everyone generically, which constantly causes dependency-version-fighting between bundles, forced upgrades, and the decoupling of the dependency from its original use.

                      1. 0

                        you, the developer, are more right than everyone else is about what version of dependencies are appropriate for your software.

                        Except when you’re not. Lots of developers publish dozens of packages and can’t really be bothered to keep track of all dependencies and any security updates.

                  5. 1

                    There is a AppImage daemon that is supposed to update appimages if they embed a special manifest.

                    What I personally like about AppImage is that it’s much simpler than using the package manager; download a file and run it.

                    On the other hand, yes it’s true, with appimage you don’t get all those nice updates of dependencies being shoved into everything you run on your computer. But docker has stopped that trend nicely anyway, atleast on the server and when heavily relied on.