I still don’t even know what problem snap and flatpak were intended to solve. Just apt or dnf installing from the command line, or even using the distro provided store app, has always been sufficient for me.
The idea is that the application may want libraries asynchronously of the distribution cadence. Worse, multiple applications may have different cadence and you want to use both (some app breaks with gnome 45 and so it needs gnome 44, and another app requires gnome 46).
Or some pick forks of projects that neglected to change the shared object name or version, so you have two multimedia applications depending on the same exact library name and version, but expecting totally different symbols, or different ‘configure’ options to have been specified when they built the shared library.
So we have this nifty mount namespace to make believe the ‘filesystem’ is whatever a specific application needs, and for that to be scoped to just one.
There’s also an argument about security isolation, but I find that one to be unfulfilled as the applications basically are on the honor system with regards to how much access it requests of the system compared to a ‘normal’ application. So an application can opt into some protection so it can’t accidentally be abused, but if the application wants to deliberately misbehave it’s perfectly allowed to do so.
Modern Linux distros tend to have configuration and dependency issues where certain packages if installed the “Linux Way” doesn’t completely work as desired at times depending on the distro or even a desktop spin (which might have different default libraries installed than the “main” one). Flatpak is a single configuration meant to work one single way across all distributions and has become more of a standard, usable way for Linux applications to just work.
Use Flatpak. Easy to install and easy to tweak from flatseal or similar GUI Flatpak permission tweakers if you want more flexibility at the possible cost of security.
I still don’t even know what problem snap and flatpak were intended to solve. Just apt or dnf installing from the command line, or even using the distro provided store app, has always been sufficient for me.
The idea is that the application may want libraries asynchronously of the distribution cadence. Worse, multiple applications may have different cadence and you want to use both (some app breaks with gnome 45 and so it needs gnome 44, and another app requires gnome 46).
Or some pick forks of projects that neglected to change the shared object name or version, so you have two multimedia applications depending on the same exact library name and version, but expecting totally different symbols, or different ‘configure’ options to have been specified when they built the shared library.
So we have this nifty mount namespace to make believe the ‘filesystem’ is whatever a specific application needs, and for that to be scoped to just one.
There’s also an argument about security isolation, but I find that one to be unfulfilled as the applications basically are on the honor system with regards to how much access it requests of the system compared to a ‘normal’ application. So an application can opt into some protection so it can’t accidentally be abused, but if the application wants to deliberately misbehave it’s perfectly allowed to do so.
Modern Linux distros tend to have configuration and dependency issues where certain packages if installed the “Linux Way” doesn’t completely work as desired at times depending on the distro or even a desktop spin (which might have different default libraries installed than the “main” one). Flatpak is a single configuration meant to work one single way across all distributions and has become more of a standard, usable way for Linux applications to just work.
Use Flatpak. Easy to install and easy to tweak from flatseal or similar GUI Flatpak permission tweakers if you want more flexibility at the possible cost of security.