"Flatpak Is Not the Future"

[mediclaser]

Is Flatpak the devs' alternative to WINE...to create a binary that works everywhere? Is this the devs' new way of saying Linux will be the future of desktop computing, or is this an indication of throwing in the towel?

Well, Wine doesn't create any binaries, it's just a hacky compatibility layer, and it definitely doesn't work everywhere. It usually doesn't work.

Did you misunderstand my post due to my poor wording, or did I misunderstand how Flatpak works? I know there is no need for separate copies of WINE for each Windows app I want to run in Linux....Does Flatpak require separate copies of the same (or similar) bloatware for each app?

[rene]

Flatpak conceptually bundles applications each with their own "runtime", i.e., with a basically mini-distribution to run it under. Theoretically and even though conceptually bundled, said runtimes are in fact shared over multiple applications using the same runtime. Practically and even though theoretically shared, unsynchronized updates of flatpak applications has them quickly depend if not on different runtimes than on different versions of the same runtime (which tend to share little among themselves in again practice) so that in the end it's fairly fair to say that each individual flatpak comes close to needing its own individual runtime, i.e., distribution to run under.

Note that that's not just theory; I used to be fairly positive about flatpak but found myself I believe a year or so after starting with them with I believe 5 flatpak applications depending on 5 different runtimes which all in all used up 5G+ of diskspace, while being slow to load, slow to run, ...

[mediclaser]

Ouch! So Flatpak is worse than what I thought it was?
Somebody please assure me Linux Mint devs will not be making this mandatory in the future releases.

[Petermint]

Flatpak and the others could be compared to Java. You install the big Java runtime first then individual Java applications are small because they share the one runtime. Similar to Flatpak applications sharing the one set of updated packages. The Java runtime compatibility is so bad that many Java applications are compiled with a specific runtime. Appimage is similar to a Java application compiled with the runtime.

Appimage runs the application a bit like Firejail. This could be good if it was better understood and was an exact equivalent. Appimage can package new packages to let an application run on older versions of Linux and less developed distributions. There are lots of good points but an Appimage can also include an outdated package missing security updates.

Flatpak is a messier alternative to Appimage because Flatpak tries to manage all the versions of packages for all the flatpaks. One mistake flattens every pak.

[rene]

Somebody please assure me Linux Mint devs will not be making this mandatory in the future releases.

While I am not a Linux Mint developer nor have had any who are tell me so, I can myself still sort of guarantee they will not.

Mint has since I believe version 17 positioned itself on top of Ubuntu LTS, i.e., on an only every two year changing base. I came in at that time and remember from around the 17.3 time-frame many complaints about old software versions. PPAs to an extent alleviated and alleviate it also and/but I believe you should view Flatpak support on Mint in that way: as a method of providing updated software to those that want/need it on a still "stable" base. In fact also believe that now at 20.3 the old base makes itself known mostly in e.g. kernel and other lower-level components; that flatpak might just be doing its job there.

Personally I consider the technology interesting by and large only for large, closed-source and/or commercial software. I.e., felt until the flatpak version for some or other reason started bugging out more often than the .deb that the Steam flatpak was a great example of how/why/when to use it. It's Red Hat that seems en route to flatpak-up any and all. Although admittedly "any and all" sort of automatically lessens my above runtime version objection that's technical lunacy; externally and independently developed, "discrete" applications of the kind that would now go into /opt -- flatpak great; my standard webbrowser -- flatpak mad as a cow.

Snap is already a definitive failure (for desktop) only waiting to be classified such; Flatpak will see some support from the senseless secuwity-blabber crowd for some time still but will hopefully/supposedly in the end settle in in that "external software" role. And I'm in any case pretty sure that specifically Mint will not in foreseeable future have its role be other than either that or the mentioned one of allowing for e.g. newest shiny LibreOffice on a stable/old base.

[MurphCID]

Ouch! So Flatpak is worse than what I thought it was?
Somebody please assure me Linux Mint devs will not be making this mandatory in the future releases.

Doubtful, I use them because they seem to have more up to date software especially for LibreOffice, otherwise I stick with what has come with Mint for the most part.

[Portreve]

Committed open-source developers don't use a development model which, let's say, "necessitates" containerization. Moreover, I'm not particularly interested in supporting software titles whose existence and improvements are dictated by the edicts of a business cycle or by those of Corporate America. I'm just not. That's along side having a fairly healthy distrust of the closed-source software development model, which I think is counterproductive for we the open-source community to further encourage, aid, and abet.

[dave0808]

The Java runtime compatibility is so bad that many Java applications are compiled with a specific runtime.

Actually the runtime compatibility is very good. Nearly every Java application (certainly, everything I've come across) can be run by newer runtimes.

The only way it doesn't work is when an application is compiled with a newer major version of the compiler (e.g. 11.x) and someone attempts to run it with an older major version (e.g. 8.x). This is because new features and functionality just don't exist in the older versions.

[acerimusdux]

Did you misunderstand my post due to my poor wording, or did I misunderstand how Flatpak works? I know there is no need for separate copies of WINE for each Windows app I want to run in Linux....Does Flatpak require separate copies of the same (or similar) bloatware for each app?

There are a handful of runtimes which are used by many apps. Flatpak is strictly for desktop apps. There is no duplication of the underlying system at all. But different apps may use different runtime platforms for the desktop. I've found the most frequent are either the Gnome platform, or the Freedesktop platform. If you use KDE apps, you would likely have a KDE runtime, as well. And, you may have one app which uses the latest Gnome, and one the previous version, so maybe you have two Gnome runtimes. But most things are kept enough up to date that you shouldn't have much duplication beyond that.

So it may take 2G to install your first flatpak app, but might only use another 4G to install another 10 apps. I currently have 8 applications (Bitwarden, Discord, Flatseal, Skype, Spotify, Celluloid, Firefox, and Gnome Network Display) using about 5.3G of space. That includes 3.7G in /var/lib/flatpak (1.4G in ./app and 1.7G in ./runtime) and another 1.6G in my user data ~/.var/app.

[half-word]

In my view it depends on what are you comparing flatpaks to.

For example, flatpaks are great compared to snaps as they are not so isolated. I refuse to use any snaps because they can read only your user directory. As most of the files I need to open are outside, they are nearly useless to me. While my system disk is an SSD, I keep most of my data on a large secondary mechanical HDD. Snaps refuse to open files on it. My other need is to open files received by mail for quickviewing; as snaps can't see system-wide /tmp they are also useless for that. Flatpaks do all that just as normal apps do.

Flatpaks are also by necessity often a better solution than using the prepackaged apt versions as they offer the newest versions of apps, while the distro-packaged stuff usually lags far behind. While the most "correct" solution would be to find the official upstream apt repository for the important software, it gets quite hard to manage if you need to follow dozens of programs that way. Flatpak simplifies the issue by always offering newest versions.

Therefore, I've already decided to install desktop apps I need as fresh as possible as flatpaks. Only certain software for development or server use I still install from upstream apt repos, but in the future at least for some of them that might not be the case anymore, at least for the desktop apps (say my favorite IDE).

Concerning security, contrary to the rigid snaps, flatpaks are configurable. You can for example install Flatseal and increase isolation for an app if you feel you need that. While devs can configure some of the security features in advance for snaps, user has no say in that when they install them.

[Coffeeee]

I'd rather a more Linux solution like https://mpr.makedeb.org

Flatpak feels more like an android style solution. Sandbox(partial) is an excuse to allow more security problems. It's like windows defender for windows. An almost worthless band-aid machine.

A linux like solution would need users to review what they are installing from already in place repositories.

Windows vs Android vs Linux mindset is very different.

The only thing keeping me on ubuntu based distro is ppa.

If LMDE came with makedeb I'd use LMDE.

I'm even considering manjaro becauase of AUR but I much prefer Debian base for long term stability.

[Hoser Rob]

makedeb is a cool idea but the whole point of flatpak/appimage/snap is to enable installation of software that uses depemdency libraries that can break the existing OS if installed normally. This is needed partly because in Linux all such libraries are globally shared. makedeb doesn't solve this problem at all.

[half-word]

I like the idea of makedeb. In fact, I'm pretty sure it would be possible to build debs for any (at least currently supported) apt-based distro for any piece of software. I think there should be a site like that, similar to snapcraft and flathub.

Problems with dependency libraries, someone says? Well the good news is, it can be done! Just take a look a bit further than Linux and you can see FreeBSD and its Ports and its further development by NetBSD called "pkgsrc" which is BTW available for other OS-es too. When I worked with those I simply couldn't believe how elegantly they solved dependencies. The same apps are available both for very old OS versions and newest ones alike. Also all the different programs require wildly different libraries and it's all handled by using clever tricks.

To cut the story short, it can be done.

There are already upstream apt repos that offer software debs for any conceivable version of Debian, Ubuntu and friends. So I guess an universal APT repo for everything could be done. Some techniques already used for that are compiling against different compatible library versions available on target systems or including those libraries for systems lacking them.

[151tom]

I like the idea of makedeb. In fact, I'm pretty sure it would be possible to build debs for any (at least currently supported) apt-based distro for any piece of software. I think there should be a site like that, similar to snapcraft and flathub.

Problems with dependency libraries, someone says? Well the good news is, it can be done! Just take a look a bit further than Linux and you can see FreeBSD and its Ports and its further development by NetBSD called "pkgsrc" which is BTW available for other OS-es too. When I worked with those I simply couldn't believe how elegantly they solved dependencies. The same apps are available both for very old OS versions and newest ones alike. Also all the different programs require wildly different libraries and it's all handled by using clever tricks.

To cut the story short, it can be done.

There are already upstream apt repos that offer software debs for any conceivable version of Debian, Ubuntu and friends. So I guess an universal APT repo for everything could be done. Some techniques already used for that are compiling against different compatible library versions available on target systems or including those libraries for systems lacking them.

Some of us want download and install and use OOTB.

Your idea might be good for those who like to compile and build apts.

Appimages / Flatpak ain't a bad choice if the oem repos ain't got what ya want.

[icewind]

I like the idea of makedeb. In fact, I'm pretty sure it would be possible to build debs for any (at least currently supported) apt-based distro for any piece of software. I think there should be a site like that, similar to snapcraft and flathub.

Problems with dependency libraries, someone says? Well the good news is, it can be done! Just take a look a bit further than Linux and you can see FreeBSD and its Ports and its further development by NetBSD called "pkgsrc" which is BTW available for other OS-es too. When I worked with those I simply couldn't believe how elegantly they solved dependencies. The same apps are available both for very old OS versions and newest ones alike. Also all the different programs require wildly different libraries and it's all handled by using clever tricks.

To cut the story short, it can be done.

There are already upstream apt repos that offer software debs for any conceivable version of Debian, Ubuntu and friends. So I guess an universal APT repo for everything could be done. Some techniques already used for that are compiling against different compatible library versions available on target systems or including those libraries for systems lacking them.

Some of us want download and install and use OOTB.

Your idea might be good for those who like to compile and build apts.

Appimages / Flatpak ain't a bad choice if the oem repos ain't got what ya want.

I agree, sometimes Appimage/Flatpak has a newer version of the software than the repos. So if i want a newer version i just look in Flatpak and install that.