"Flatpak Is Not the Future"

[astra]

An interesting text, getting into details of app distribution/packaging, well worth reading:
https://ludocode.com/blog/flatpak-is-not-the-future
Lengthy read, but highly recommended.
A.

[Michael_Hathaway]

So how big are these runtimes? On a fresh machine, install KCalc from Flathub. You’re looking at a nearly 900 MB download to get your first runtime. For a calculator. - Nicholas Fraser

It was a good read, are you Nicholas?
I am not sure what he is referring to a fresh machine? He may have been over exaggerating his example for dramatic effect? Flatpak is not as heavy as Snaps. Snaps on the other hand, yes, those are crazy heavy.

[rene]

I am not sure what he is referring to a fresh machine?

KCalc depends on the KDE runtime, i.e., needs that pulled down if it hasn't been yet on a fresh install.

I used to and to some degree still do take issue with counting size of a runtime as part of size of an application that depends on it (since runtimes are shared) but have also since basically the start of this application containerisation debacle seen individual versions of runtimes undermine that point in a most serious way: flatpak apps 1, 2 and 3 may all depend on "the GNOME runtime" or on "the KDE runtime" or ... but if application 1 depends on version 1 of said runtime, application 2 on version 2 and application 3 on version 3 you still have fully application-private runtimes in practice --- and yes, as the article says, only very little is shared between those runtimes even if only as a matter of trivial recompile differences.

Yes, was a good read. I've personally little to no confidence that "the stable platform issue" will ever resolve itself in Linux without something like flatpak/snap/appimage but have no longer any confidence as to such with those systems either. It's just alternative N+1, N+2 and N+3 for third-party developers.

[Pierre]

it's an number of points are quite interesting, too.

the idea of Size is relevant, as well .. in that Kde calculator example ..
& in more recent times .. disk size has actually shrunk, whereas it was getting bigger, with each year.

especially as most Laptop manufacturers are switching to smaller flash drives to improve performance,
and those spinning hdds are on the way out.

plus, I'm not that surprised either .. these bigger programs, are too heavy for an spinning hdd,
- - I've spent Two Days in trying to update win-10 from 19H2 - 21H2 .. it's painfully slow on an 1Tb hdd

these Linux software alternatives are in the same scenario, too .. too big for what they should be doing.

[MikeNovember]

Hi,

The example of Kcalc is an oriented one: since flatpaks need runtimes, installing just a simple calculator as flatpak is not really a good idea. However, if you have several applications from KDE world, they will share the same runtime.

And the author has not understood the meaning of the size "<" for a runtime to install; it is a maximum, not the prediction of the size of the installed runtime.

Moreover, the author says that kcalc works out of flatpak on its computer "since all libraries are already installed". This may be true in computers with KDE desktops, but it is not generally true. I run Linux Mint 20.2 Mate, and I try to avoid to install anything beginning by K or with a K inside since it will require tons of kde libraries that are not installed by default by the distro.

Finally, yes, disks are cheap. 1TB SSD is worth less than 100$... and this will continue to decrease.

But there is something missing in this paper: the author compares flatpak, a sandboxing system that improves security, to an installation without sandbox.

Is flatpak the future? I don't know; I know it is my present: I have 14 applications installed as flatpaks. With their runtimes, they use 5.4 GB of my SSD, 0.5% of its capacity.

This has two advantages:
- all my applications connecting to internet are run in sandboxes: internet security is improved;
- my applications are fresh, automatically updated ones; this allows me to really use a "Long Term Support" distro, within a stable environment, without having to reinstall periodically a new LTS distro simply because apps have become obsolete.

I will probably use Mint 20.x up to April 2025 (provided there is no crash... ), with only one PPA (flatpak stable) and fresh apps till 2025.

Regards,

MN

PS: some distros, such as Fedora Silverblue are based on ostree file system (for the "environment") and flatpak for the applications. Each package is run in its own container, without interference with others. Silverblue is called an "immutable" distro, since it is installed the same way for all users; this might be the future.

[rene]

Hi

You missed basically every point he made; have seemingly not in fact read the article.

Sharing issue: as also mentioned above by me and as mentioned by author by ways of e.g. his Ubuntu /usr tree remark, undermined by different versions of same runtime --- in which he is right, again even if only as a matter of trivial recompile differences.

Storage is cheap issue; his point is that standard storage space has in fact been shrinking; budget laptops, RP4, ...

Sandbox. Article mentions that e.g. Flatpak only says it's sandboxed but is not actually so in a meaningful manner since a flatpak app can basically just ask for any permission it wants. As to Snap in that same context,

The Snap Store app, to its credit, displays a warning: “This application is unconfined. It can access all personal files and system resources.” Which apps display this warning, you ask? All of them. KCalc has it. All of the Editor’s Picks have it. In my testing for this blog post I could not find an app that does not display the warning.

So, is the topic "missing" from this article? Yeah, no, it isn't; it's a rather large section of the article in fact. It's secuwity, so you comment but seemingly without even having read it because, as I've said before and will undoubtedly say again, secuwity is not about security or technology but about image.

[MikeNovember]

Storage is cheap issue; his point is that standard storage space has in fact been shrinking; budget laptops, RP4, ...

Any justification? you can still buy laptops or desktops with the storage size you want...

Sandbox. Article mentions that e.g. Flatpak only says it's sandboxed but is not actually so in a meaningful manner since a flatpak app can basically just ask for any permission it wants. As to Snap in that same context,

Flatpak apps have a list of permissions defined by their authors; you can override these permissions with the command line, using flatpak reference language, or more simply, in a graphical way, with flatseal. It is indeed very easy to see what permissions are allowed and to change them (enlarge / restrict). My Thunderbird flatpak is not able to launch the opening of an attachment: I have to save it (to downloads) before to open it (this allows, for example, the use of an antivirus, for example Virus Total, in case of doubt). Flatpak apps DO NOT ask for any permission they want: they just use the allowed permissions...

The Snap Store app, to its credit, displays a warning: “This application is unconfined. It can access all personal files and system resources.” Which apps display this warning, you ask? All of them. KCalc has it. All of the Editor’s Picks have it. In my testing for this blog post I could not find an app that does not display the warning.

You can very easily restrict the access; I don't see any reason to allow a calculator to access user files; if it is the case, the flatpak developer allowed wrong permissions. Just remove home access with flatseal.
More generally, user should not use a sandboxed application, using flatpak or firejail, without having checked the permissions.
As an example, Chromium flatpak has, by default, lots of permissions, while Firefox flatpak has much more restricted ones; once checked, it is easy to give Chromium the same permissions as Firefox using flatseal.

So, is the topic "missing" from this article? Yeah, no, it isn't; it's a rather large section of the article in fact. It's secuwity, so you comment but seemingly without even having read it because, as I've said before and will undoubtedly say again, secuwity is not about security or technology but about image.

All the content of this article is oriented, including security discussion, to a single direction: discourage users to use flatpaks; some parts show the author did not understand flatpak, or show he is not de bona fide.
It is a polemic paper, like our respective answers.

Regards,

MN

[rene]

you can still buy laptops or desktops with the storage size you want...

Of course you can. But the point of course is that a current basic system and systems such as the Pi have not.

Flatpak apps have a list of permissions defined by their authors; you can override these permissions with the command line, using flatpak reference language [ .. ]

Of course you can. But the point of course is that unless you actively intervene this marvelled "sandbox" means absolutely nothing in current practice --- and as I would personally add: do also be sure to check e.g. your /etc/apparmor.d/usr.bin.firefox for a long deployed version of that wheel.

It is a polemic paper, like our respective answers.

Your answer to the article wasn't polemic but not an answer. Simply ignored and ignores for example the point about the "sharing" being far less relevant in practice than theory, nor had or has anything to say about the effect of such not just on disk space but on loading time and memory use. Was moreover saying it "missed" something which it in fact spent considerable time discussing, indicating that you glanced at the actual article at best before you decided to go ride your hobby horse in reply.

You don't agree with said discussion --- but that is as I've noticed merely to say chances of something being right increase. I'll stick with the number of good points the article makes.

[RollyShed]

Storage is cheap issue; his point is that standard storage space has in fact been shrinking; budget laptops, RP4, ...

Any justification? you can still buy laptops or desktops with the storage size you want...

You missed rene's use of the word BUDGET.

I use, at times, a laptop with 30GB of storage and 2GB of RAM.

[MikeNovember]

Storage is cheap issue; his point is that standard storage space has in fact been shrinking; budget laptops, RP4, ...

Any justification? you can still buy laptops or desktops with the storage size you want...

You missed rene's use of the word BUDGET.

I use, at times, a laptop with 30GB of storage and 2GB of RAM.

Hi,

Yes, "budget" is not very precise... And the definition of cheap / expensive is always a personal one.

The use of a 30GB storage and 2GB RAM computer is probably very limited, even when using Linux. Any "entry level" computer sold today has more RAM and more storage capacity, and probably a more powerful CPU. Entry level laptops can be bought from 280 USD, with 128 GB SSD and 4GB RAM, allowing the use of Windows or Linux, including flatpaks.

I use an old computer, 9 years old; it was when I bought it a powerful laptop. I could give it a second life with a 1TB SSD I paid some 110 EUR; prices begin now at ~ 80 EUR or 90 USD for such an SSD. And a 256 GB SSD can be purchased from 30 EUR, or 34 USD.

Storage cost has constantly decreased, and storage size has constantly increased. My 1st desktop PC had an HDD of 500 MB, less than a CD-ROM. But it run Windows 95, and all the computer (storage, RAM, graphics card, CPU...) was adapted to the OS.

Modern OSes and modern computer use require more processing power and more storage size: my Linux Mint 20.2 Mate has some 530,000 files (system and apps, including flatpaks) and uses 13.5 GiB; my Windows 10 virtual machine has still more files and uses 19 GiB when fully compacted; my personal files use 260 GiB. I don't use a computer in 2021 the same way I used it in 1995, or in 1980 when I bought my 1st one, and Apple II with 8 bits CPU, 64 kB RAM and 1.4 MB 5"25 floppy disks...

Coming back to flatpaks, the main reason to use them is, for the developers, to avoid to compile a program for different distros, each one having its own libraries with different revisions. It is a trend that will come stronger and stronger, induced by man hour costs. This trend has produced flatpaks, snaps, AppImages, Gnu Guix, Zero Install and still others. I don't know which will be the most used in the future.

A parallel trend is towards increased security, particularly for internet connecting applications. Flatpaks and snaps apps are, by default, run in sandboxes; Zero Install apps, though not by default, can be run in sandboxes.

It is so very probable that the future will use flatpaks and snaps, or any way to deliver "standard" containerized apps, running in sandboxes, working on the largest possible number of distros.

Fedora Silverblue is already fully oriented this way: all the "distro environment" is made with containers based on ostree file system, and all the apps are flatpaks. Maybe representative of "a" future of Linux distros...

Regards,

MN

[RollyShed]

RollyShed - I use, at times, a laptop with 30GB of storage and 2GB of RAM.
Yes, "budget" is not very precise... And the definition of cheap / expensive is always a personal one.

The use of a 30GB storage and 2GB RAM computer is probably very limited, even when using Linux.

The laptop in question is an ASUS T200 which originally had Win10 on it. Now that is ridiculous as how does it do updates if you have a few files saved and it wants about 15GB to run an update? As it is with Mint Cinnamon, not the fastest to boot up but it is a travelling computer, my "screwdriver". Use it to fix other people's problems, to carry files to an off internet holiday home, pre-write emails in front of the TV, etc. Perfect for what it is used for.

Cost? Free.... "See if you can find someone to make use of it." said the owner.

[meToo]

I know this conversation is about flatpak but where do Appimages fit in? They seem to be a good idea to me in as much that if I had to reinstall Mint, a collection of archived Appimages would quickly get me back to square one. Comparison with Flatpak sizes, appimages seem to be much smaller. For example, Openshot appimage is 132MiB and Gimp is 160MiB and they can be archived to a SDHC. To me with my limited Knowledge, it seems that appimages could be the future but I realise that the source must be most trustworthy.

[rene]

I know this conversation is about flatpak but where do Appimages fit in?

Well, actually, title of this thread notwithstanding it's also about AppImage (and Snap, and Steam, and Docker). The reason that as compared to Flatpak and Snap AppImage can appear to make for smaller images is the in it missing concept of runtimes. A runtime in the flatpak/snap sense is basically a complete Linux distribution running on top of your native kernel but with largely everything else replaced. AppImage "just" bundles explicit dependencies rather than a complete-ish distribution such as that.

In the sense of containerised applications still "sharing" something, runtimes are at least in theory a better idea; flatpak app 1 and 2 which are both linked against the same runtime share said same runtime, and not even only on disc but also in memory. As mentioned above, in practice the sharing is far less relevant than the theory promises: although I don't use flatpak any more, when I did and checked things approximately 1 year after starting to do so I had I believe 5 flatpak apps with 5 different versions of their runtimes installed as a matter of their unsynchronized updates. Still, AppImage doesn't even attempt to share (AFAAI I guess I should say; never much looked at AppImage).

What is in any case so is that for some given number N, N AppImage applications that bundle the same libraries are larger than N flatpaks/snaps + 1 runtime. That that initial impression of AppImage as providing for smaller bundled applications can in fact quickly be precisely wrong --- again, if that flatpak/snap-sides sharing had actually meant in practice that which a naive user such as myself originally once expected in theory, but still (and note; diskspace all fine and well maybe but startup time and even run-time as to cacheing and memory-size hence memory-bandwidth are far more important as far as I'm concerned).

The security aspects are largely irrelevant in the first place on current desktop Linux and even though I'd agree that any such system should as a matter of principle concern itself with the potential issue, we do in fact already have infrastructure in place in the form of AppArmor (and SELinux, although not on Ubuntu/Mint) for sandboxing native, non-containerised applications and have had for a long time. Working on making that easier accessible / friendlier would seem a better idea even for those that like to play h@ckz0r than doing what amounts to running each individual application in its own private Linux distribution.

Article says that native backwards compatibility has been improving in Linux even inter-distribution. I'd need more data to believe that since it's basically the thing us users have been promised for 20+ years now and which has never even come anywhere near to being true. I used to feel that e.g. Flatpak was the only thing that could even potentially make things happen but I'm not seeing that either any more.

As in, <shrug>, Linux: at least it's not Windows...

[Hoser Rob]

... I've personally little to no confidence that "the stable platform issue" will ever resolve itself in Linux without something like flatpak/snap/appimage but have no longer any confidence as to such with those systems either. It's just alternative N+1, N+2 and N+3 for third-party developers.

+1. Until the issues of no consistent packaging systems, no stable APIs/ABIs etc get resolved then flatpaks et al ARE the way of the future.

These program devs are not being paid to do what they do. Most of the people I see here ranting about flatpak etc just have no idea whatsoever of how much drudgery maintaining software is. And to do it unpaid?

[Portreve]

An interesting text, getting into details of app distribution/packaging, well worth reading:
https://ludocode.com/blog/flatpak-is-not-the-future
Lengthy read, but highly recommended.
A.

It's funny... through other means and for other reasons, I ran across this very article yesterday, and read it with not inconsiderable interest.

Theoretically — and I emphasize the term theoretically — LSB should have allowed the community to deal with this problem a long time ago. In fact, I do sometimes wonder why the ████ we're still having this stupid issue. It makes me think the userland software (meaning: the programs we as human beings are using, like a web browser, or word processor, or whatever) as well as the lower level APIs and libraries aren't really being constructed properly. As I'm not a developer but really just a user of software, maybe this might come off a bit high-handed on my part, but let me try and delve into this a bit deeper.

We live in an era where security concerns are almost more important than stability. That means we are constantly having to be on the lookout for stuff which can be exploited, in addition to all the other traditional kinds of bugs which can be and often are present in the code, and then release a never-ending stream of updates to patch 𝑋, 𝑌, or 𝑍 thing. This therefore forces the condition that the exact versions of APIs and other libraries upon which any given program (which they themselves are also constantly being updated) depend are constantly changing. However, I truly fail to see why a good program would care what version of an API or library is present on a system, so long as it's at least part of the same, let's say, major version release of that library. For example, let's say there's a library called "portreve" (well... how humble of me) and it's gone from a 1.0 initial release to now 7.15.237.3. I could understand that for instance LO Writer 7.0 was written and released when portreve was at version 6.69.107.9, and so maybe it really wouldn't be able to function correctly on portreve 5.x, but at least any of the 6.x series should be interchangeable. LO Writer should not be written in so specific a way that the tiniest little bump knocks it off its horse. At the same time, how the hell are APIs written that they work in radically incompatible ways just because we've even jumped major versions, like 6.x to 7.x?

Of course, nobody really wants to own this sort of problem.

To my mind, this is a helluva good argument for having highly mainstream distros which all get together and say they're going to commonly use certain version levels of the totality of the APIs and libraries out there, go the LTS route, and then use both the carrot and the stick approach with the overall software developer community to get its collective ████ together, thereby making Linux a much more homogenic platform for everybody. Which, I might add, would also include commercial software developers. Why in the world should they write their stuff for a platform which, no matter how big of a target and a market it is collectively, acts like a bunch of Ayn Randian "it's all about me and what itches I want to scratch, and the ████ with anyone for trying to get me to recognize there's a much larger interdependent society out there which benefits from cooperation and collaboration" little fiefdoms which basically subdivides this larger Linux platform into what might just as well be a bunch of separate walled gardens? Y'know? That's what's gotten us app contanerization in the first place.

[cliffcoggin]

These program devs are not being paid to do what they do. Most of the people I see here ranting about flatpak etc just have no idea whatsoever of how much drudgery maintaining software is. And to do it unpaid?

The logical answer then is for Linux Mint to charge for its use so that developers can be paid to do the drudgery as well as the fun stuff. Personally I have no objection to that as I do not expect anything life to be free, but no doubt a cost would lead to problems with piracy and enforcement. I see no solution to the quandary.

[Portreve]

These program devs are not being paid to do what they do. Most of the people I see here ranting about flatpak etc just have no idea whatsoever of how much drudgery maintaining software is. And to do it unpaid?

The logical answer then is for Linux Mint to charge for its use so that developers can be paid to do the drudgery as well as the fun stuff. Personally I have no objection to that as I do not expect anything life to be free, but no doubt a cost would lead to problems with piracy and enforcement. I see no solution to the quandary.

Just because the LM Project would suddenly charge for LM would not cause there to be piracy. This would actually lead to a different sort of problem: getting any money out of a revenue model in an environment where people would just legally give out copies for free of what LMP was attempting to charge.

That's why RedHat, SUSE Linux Enterprise, et al, kind of don't / can't really charge for the software (except possibly for any proprietary bits which in theory they might chuck into the mix), but rather charge for support. You want to get your hands on a copy of RHEL? Go for it. Install it on your own box? Knock yourself out. But if you think you're getting support for an unregistered, unpaid-for copy, you're wrong.

I'll go back to what I posted up-thread: provide as fine-tuned a distro-level experience as you want, but just build everything out of the same versions of stuff, and also make sure software isn't written in a way which brings things crashing down just because of slight iterative differences in the at-that-moment-on-the-box installed components.

[MikeNovember]

I know this conversation is about flatpak but where do Appimages fit in?

Hi,

Like flatpaks, AppImages are a way to deliver applications that are not dependent of a given distro libraries, since they (normally) include all their required dependencies.

Regards,

MN

[MikeNovember]

Hi,

This discussion about "the future" and flatpaks, snaps AppImages etc. is simply the consequence of a problem Linux distros could not treat well: compatibility.

A program compiled for bionic will not run in most of cases under fossa, because it expects exact versions of libraries, or because more recent version of libraries are not compatible with former ones.

At the opposite, proprietary systems such as MacOs or Windows have solved this problem:
- any 32 bits app for MacOS could be run from Snow Leopard to Mojave,
- any 64 bits app for MacOS can be run up to Monterey,
- a 32 bits version of Windows can run any 16 bits or any 32 bits app released for a former version (I do use on a Windows 7 32 bits virtual machine some apps written for Windows 3.1),
- a 64 bits version of Windows can run any 32 bits app or any 64 bits app released for a former version (I do use on Windows 10 64 bits virtual machine some apps written for Windows 95).

With GNU Linux systems, this lack of compatibility obliges distro packagers to compile the same program for the different supported versions; same thing for developers directly publishing their software (in PPAs, as an example, there are so many versions of a package that there are supported versions of Ubuntu).

Since this is no longer wanted, lots of solutions have appeared in the past years:
- flatpaks or snaps not attached to a given version of a given distro,
- AppImages, supposed to contain all their required dependencies,
- extra package managers, such as GNU Guix, able to be added to any distro,
- Zero Install, independent from any distro,
- all kinds of containerized apps,
- developers offering on their web sites distro independent software (LibreOffice Community Edition, Firefox, Thunderbird, FreeFileSync, XnView MP, Calibre...),
- or, at the opposite, web sites offering sources only and letting distros packagers or users compile the sources.

When you add this to the initial differences between distros (rolling / stable; different way to deliver packages, such as rpm or deb; different desktop environments such as Gnome, Mate, Cinnamon, XFCE, KDE and others; different file systems; different development tools and environments...) the final result is a great mess: GNU Linux is not an operating system, but tens of incompatible ones.

This will not last for ever: this uses a lot of man hours and, even for volunteers, time is money. From this mess will emerge a reduced set of solutions, pushed by some big companies such as Redhat or Canonical. Wait and see.

Regards,

MN

[astra]

As a minor issue - but one related to the thread: - I would suggest that LM Software Manager should tag Flatpaks right at the software selection list, so that a user does not have to bring up the particular package to the install panel and remeber to check the "Details:" (or the Size!) to find out that the application is distributed as a flatpak. This id doubly annoying, as some applications are labelled "flatpak" on the selection list table, so users that assume all applications will be so labelled can easily end up installing flatpaks when they have decided to avoid them.