I love Flatpaks, the programs are nicely separated so they don’t interfere with each other. They also don’t have flaws like Snap’s low performance or Nix’s complexity.

But being limited to only graphical apps seems like a real drawback. If one wants to use Flatpaks as their primary package manager there have to be some awkward workarounds for cli programs.

E.g., the prime Flatpak experiene is supposed to be on immutable distros like Silverblue. But to install regular cli programs you are expected to spin up a distrobox (or toolbox) and install those programs there.

Having one arch distrobox where I get my cli programs from will not work, as the package entropy over time will get me the very dependency issues that Flatpak wants to solve.

So what is the solution here? Have multiple distroboxes and install packages in those in alternation and hope the boxes don’t break? Use Nix alongside Flatpak? Use Snaps?

  • @ExtremeDullard
    -23•5 months ago

    Flatpaks are disk and memory hogs, and they start slowly. That’s because they’re like little selt-contained full-fledged operating systems.

    Flatpaks, like snaps, applimages, dockers, Electron apps, React apps or Flutter apps are the lazy 21st century developer’s way of achieving cross-compatibility without any effort.

    • Montagge
      16•5 months ago

      I always like comments like this that don’t offer the “real” solution

    • Vojtěch Fošnár
      9•5 months ago

      That’s not true and misleading. Docker and flatpak base images mostly contain shared libraries and even these get automatically deduplicated. Your flatpak calculator doesn’t ship systemd or any other init system nor does it ship system drivers lol

      And yeah if you are working in a restrained env and care about those few mbs taken by shared libraries then containarization is not for you.

      Containerization is not perfect and it will never be, but that was never the goal. Making apps and services independent of the base system and easily restrictable like mounting volumes, restricting network, etc… was.

      • @ExtremeDullard
        0•5 months ago

        I didn’t say they were the same thing. I said they’re what people do today to avoid having to port their code to different platforms and manage shared library versions, performances be damned.