your comment on flatpak, snap and appimage?

I know the snap server software is non free. I would prefer had the server software been free software. But it is not a free software matter, because free software is about the license of the software running on your computer.

The problem is: the Snap Store does not only serve free software and there is no way to setup an alternative server that would have a "only free software" policy. Flatpak does not have that problem: https://docs.flatpak.org/en/latest/hosting-a-repository.html

I have been leaning towards snap, because I would expect cannonical having more resources for providing a secure solution.

Canonical does not have more resources than Red Hat, which now belongs to IBM. Red Hat pushes Flatpak.

https://ostechnix.com/linux-package-managers-compared-appimage-vs-snap-vs-flatpak/ criticizes Snappy, including when it comes to security. I quote:

"On the flip side of things, snaps are widely criticized for being centered around Canonical’s modus operandi. Most of the commits to the project are by Canonical employees or contractors and other contributors are required to sign a release form (CLA). The sandboxing feature, a very important one indeed from a security standpoint, is flawed in that the sandboxing actually requires certain other core services to run (such as Mir) while applications running the X11 desktop won’t support the said isolation, hence making the said security feature irrelevant. Questionable press releases and other marketing efforts from Canonical and the “central” and closed app repository are also widely criticized aspects of Snappy. Furthermore, the file sizes of the different snaps are also comparatively very large compared to the app sizes of the packages made using AppImage."

The same link criticizes Flatpak's security too:

"Flatpak has resulted in widespread criticism of the team’s tall claim of providing a secure framework. The blog (named flatkill) linked at the end of this guide in fact mentions a couple of exploits that were not addressed by the Flatpak team as soon as they should’ve been.[15]"

That said, one should check whether such exploits still work. I would not be surprised if flatkill was motivated by primary anti-Red-Hat-ism (as many anti-systemd sites).

About flatpak, I have noticed when you install the first couple of flatpaks, then some big software packets gets added.

They are called runtimes. They provides basic dependencies many programs need.

I expect about appimages you do not get that sharing gain?

Indeed. A package that uses a runtime is easier to maintain by its developers. As far as I understand, that is the main advantage. Also, with AppImage, I believe that a same library may be loaded several times to RAM, for different programs.

In terms of decentralization and program makers not having to rely on someone else's system appimage is the better option.

That is my understanding too, but relying on runtimes eases their work. Snappy is certainly the worse when it comes to centralization.

I prefer Appimages. With Flatpaks and Snaps you have to download a bunch of extra stuff to get them set up and running, then they pollute your software center with a ton of proprietary garbage - at least that's been my experience on Debian / Fedora based systems.

Appimages remind me of "Portable Apps" on Losedows. Download the app you want, make sure it's executable, and then you're done. Individual programs can push updates through their own servers and if you want to decline an update you can stay on which ever version you have downloaded. Works great for emulators like Duckstation and RPCS3.

I installed a few flatpaks because I wanted to try some advanced features. Especially the newest version of Okular, KDE's PDF document viewer and editor. The latest versions have some special editing features I would like to use. Unfortunately, flatpak had to download a truly massive amount of stuff to install Okular, and once it did, I found that the flatpak version was crippled, especially with no ability to print. Since printing the edited PDFs is one of the primary functions, the package was basically useless.

My other experiences with flatpaks were similar. Very large downloads, and the packages themselves were either slightly or highly crippled making them not worth the trouble.

On AppImages, I use the LibreWolf one, and it is truly a good web browser experience. Uses less resources than any other major browser that I've tried. I'm now learning to extract the AppImage file and alter its contents in order to enhance the privacy of the LibreWolf browser even further. And the LibreWolf AppImage file is actually smaller than the installation files for some distros, such as for Arch. I think the AppImage packaging method shows a lot of promise.

I still believe GNU Guix is the best option for a distro-independent package manager (although I prefer using it as a distro itself). Guix:

* respects the GNU free system distribution guidelines
* builds all packages from source
* can be instructed to build from a specific git checkout or with a specific patch
* does not do any containerization/sandboxing natively - some might see this as a negative but I'd rather that be something I can opt into rather than controlled by the package manager.

I'm using one 'appimage', and it is quite slow to load on an i7. 32 bit Sempron kind of slowness. Too slow, IMO. Once loaded, it works very well, I haven't seen any problems when I run it. It is a huge file for what it does.

I left Canonical's distros because of Snaps. No, thanks, not interested, and despite my removing snapd from 'buntu, the Canonical plan to further the spread of Snaps is not a goal I wish to spread.

So far, that is my 2 cents.