Who does flatpak/snap benefit? - eviltoast

As a user, the best way to handle applications is a central repository where interoperability is guaranteed. Something like what Debian does with the base repos. I just run an install and it’s all taken care of for me. What’s more, I don’t deal with unnecessary bloat from dozens of different versions of the same library according to the needs of each separate dev/team.

So the self-contained packages must be primarily of benefit to the devs, right? Except I was just reading through how flatpak handles dependencies: runtimes, base apps, and bundling. Runtimes and base apps supply dependencies to the whole system, so they only ever get installed once… but the documentation explicitly mentions that there are only few of both meaning that most devs will either have to do what repo devs do—ensure their app works with the standard libraries—or opt for bundling.

Devs being human—and humans being animals—this means the overall average tendency will be to bundle, because that’s easier for them. Which means that I, the end user, now have more bloat, which incentivizes me to retreat to the disk-saving havens of repos, which incentivizes the devs to release on a repo anyway…

So again… who does this benefit? Or am I just completely misunderstanding the costs and benefits?

  • lloram239@feddit.de
    link
    fedilink
    arrow-up
    8
    arrow-down
    2
    ·
    edit-2
    1 year ago

    Snap is just up Canonical trying to build an AppStore that they control so they get a bit of every software sale on Linux. It’s straight up evil. They neither support third party repositories nor is their AppStore server Open Source. It’s build such that they retain all the control and only employs the minimum amount of Open Source to get away with it.

    Flatpak is more tricky, I am not sure there is any company behind it actually controlling it directly. But it is very much build for KDE and Gnome apps. As a general Linux package manager it’s completely useless, as it has no dependency management, the only thing you can depend of are the KDE and Gnome runtimes, there is no separation of individual libraries and such. Support for more than one binary per package didn’t exist last time I checked, the support for command line in general is terrible and the whole thing is geared towards an Android’ish experience with simple monolithic apps you can click on. The fact that it runs on multiple distributions is great, but everything else about it is awful.

    There is also Nix, this is by far the best package manager we currently have. Runs on all distros, completely reproducible builds, git repositories can themselves be treated as actual packages, everything is easily overridable and changable by the user and best of all it is all build on regular Unix tooling, i.e. just some symlinks and environment variables, very transparent and easy to understand, no weird container magic that hides what is going on.

      • zwekihoyy@lemmy.ml
        link
        fedilink
        arrow-up
        2
        ·
        1 year ago

        however much I love NixOS, I would argue that in it’s current form (steep learning curve and horrendous documentation), the better option is using Nix package manager on a proven distro like Arch (or Debian but I’ve had some issues there). you get the benefits of nixpkgs while also having other pacman repos if you must.