| Subject: [GTALUG] Flatpak: Anyone with Experience or Opinions on It? | It looks like it may have been | developed by people associated with Fedora and may be a replacement for | RPM, APT, and the like (https://en.wikipedia.org/wiki/Flatpak). | | In any case, has anyone on this list looked at this or used it? Is it | any good? Is it a good replacement for RPM or APT? Am I off-track here | asking that question? I have not (knowingly) used this technology. But Here's my take anyway (based on guess-work!): Packaging like dpkg and rpm is fine but the result is tied to a release of a distro. The main reason is that the shared libraries are partially bound into the binary package. But there are other subtle and annoying difference between distros that are visible to programs. Packaging little virtual machines is way more portable but somewhat expensive and awkward. This is reasonable for a service but not most programs. Various folks have tried to find a middle ground. The barriers are market buy-in, not technology. There are two that I'm aware of: - Canonical's "snap" - "flatpak" sponsored by Red Hat As usual, Canonical appears to me to be more of a control freak than Red Hat. Naturally, my preference is for the more open one, flatpak. But I'm not 100% on-board. I like old-fashioned packages (mostly). The idea behind both, as I understand it, is to create a sandbox for each application. I think that each application carries around its own libraries etc. I hate the duplication implied. There is also a non-technical idea. Since flatpaks are universal among Linux distros, the distro would no longer be in the business of distributing the package. And no longer standing behind it for bug fixes and security vetting. Win: you no longer are tied to the (possibly old) version that your distro includes. Example: python and perl projects seem to want to run repos for users that are orthogonal to distros, something this model would better support. Win: projects no longer have to package their stuff for the various distros. They no longer have to match the downstream release cadence. Lose: you have to be a connoisseur of each project from which you take flatpaks. Each one has a different development and QA process with possibly unknowable risks and rewards. Lose: when a bug is found and fixed in a shared library, each distro can fix it with one update. But each flatpak and snap that uses that library needs to be re-issued and updated on each installation. Lose: I obsessively do updates. On each of my Fedora systems, that amounts to "sudo dnf update". On Windows, it is annoyingly more intricate: check for updates note: this must be repeated until no change happens for x in firefox chrome Adobe Reader etc. perform x's check-for-updates procedure Microsoft Applications Store check for downloads With flatpaks, Linux becomes more like Windows. Win or lose? python 2 must die. But with flatpaks or snaps, each program has its own universe so we don't need a flag day when everyone switches. But everyone should switch. Yesterday. Right now I'm fairly comfortable with Fedora and Red Hat's QA. I don't really want to take that on myself. Except for a few packages about which I have special knowledge or concerns. As an example of the role of distros, consider the Linux Kernel. It used to be common for folks to take the Linus kernel and build it on their own machine and use it in place of their distro's kernel. It wasn't too hard. Linus went to some trouble to make sure a release was clean. I infer that things have changed. All distros take a raw release and fix it up before shipping it. And you want those fixes. It's not impossible to build a Linus kernel and use it but it is probably not worthwhile.