17 ms·

To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution

To be fair, as a daily user and (to some extent) app developer, in my experience Flatpaks have solved the problem of library fragmentation and app distribution on Linux. While my experience on Snaps was mostly negative (due to bugs, virtual "loop disks" per every app affecting the system performance, etc.), I found that Flatpak finally lets me install essentially any app on any distro. For example, the Elementary OS "AppCenter" apps are now available in any other distribution, thanks to the Flatpak remote. Testing daily GNOME apps has become as easy as installing their Flatpak reference, and letting them update automatically. Regarding memory, storage and power consumption: - The base runtimes (which are the heaviest bit) are downloaded only once per system, e.g., one for the KDE Plasma ecosystem, one for Elementary, and so on. The first app you install will pull them, so I do not see it as much more bloaty than having an enormous bundle of system-wide dependencies (e.g. if you install a KDE app in a primarily GNOME environment) as would happen otherwise. - Memory and CPU-wise, Flatpaks are very light containers (which do not require loop disks, or anything else) which should have almost no overhead. I never witnessed any loss of performance, at least. - Bug and crash-wise, I experienced a tremendously stable and "flat" experience on Flatpaks. That is, if there is a bug in one app on one distribution, the bug will exist on all, or vice versa. This is not as common as it should be in containerized app install tools, and makes debugging overall much easier. The only drawback are updates taking longer than on other platforms, probably because compressed deltas are not yet available unlike in other major package managers. With this, I don't want to describe Flatpak as a panacea in everything, but at least for GUI apps, it solved a lot of distribution fragmentation issues in my case.

user0123895264 5y ago
I might be imagining it, and there might be another cause, but I stopped using Elementary after the latest release after many things moved to Flatpaks because I kept running out of memory. (On Endeavour/Arch, installing everything natively, I no longer have the problem.)
- kirbyfan64sos 5y ago
  If I had to guess, the update might have just introduced a memory leak somewhere else in the system?
0x0nyandesu 5y ago
Nah they take up too much disk space. Rather use Gentoo
- capableweb 5y ago
  Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.
  - 0x0nyandesu 5y ago
    A typical system will end up with 10 versions of some .so library on disk. Sometimes more. Disk usage waste everywhere. You're better off having a package manager that can link multiple versions at the same time to the programs that need it instead of bundling.
    - capableweb 5y ago
      But you're confusing what sides of the developer/user aisle you're on. Yes, there are probably a better distribution for the user to use if they want to save disk space. But Flatpak is not a distribution, it's a delivery mechanism. Are you really gonna tell people "Hey, don't use $YOUR-CURRENT-DIST, use Gentoo instead if you want to use my application" if your goal is to provide value for as many users as possible? It's simply not possible to ask people to change their distribution because you as a developer prefers a different one. Flatpak is for all distributions, and doesn't require someone to change from what they know and use already, it'll work for everyone equally.
    - nextaccountic 5y ago
      Just use a deduplicating filesystem. Both btrfs and xfs can deduplicate identical files.
      - sho_hn 5y ago
        This is misleading. While btrfs and xfs have some dedup functionality, it must be invoked explicitly (e.g. by using `cp` with the `--reflink` argument). For application installation to benefit from this, business logic would have to pre-identify identical files and make such references. There have been some experiments in btrfs to enable inband dedup on arbitrary writes, but nothing that made it in there as yet. Note however that the discussion misses on the fact that Flatpak itself does perform dedup by using ostree for on-disk storage. ostree implements data structures and ideas very similar to git sans the version control.
sebow 5y ago
My experience was exactly the opposite: snaps usually feel more polished and take less space than "flatpaks", at least when you compare the first time you install a flatpak.It's true that over time flatpaks take less space because they use what's already there. However the conclusion still holds imo, both are bad.Not necessarily because they haven't partially solved what they tried to achieve, but because they are being pushed instead of provided as alternatives to good-old package managers or binaries. Though technically older than both, AppImage is more recent in adoption compared to both Flatpak & Snap, and yet 95% of the time i had absolutely no problem using AppImage(with the small caveat that desktop integration is less polished, and i use a neat tool called AppImageLauncher to 'install' them). I know it's an apples to oranges comparison and AppImage is not a package manager, but the point still stands.
gens 5y ago
I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.
- kaba0 5y ago
  Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.
  - alvarlagerlof 5y ago
    And AppImage integrates poorly with desktops.
    - southerntofu 5y ago
      How so? Double-clicking an AppImage from a specific folder is not user-hostile (that's a common pattern across desktop systems), and the blogpost specifically points to appimaged and AppImageLauncher as solutions for full desktop integration.
    - gens 5y ago
      Desktops integrate poorly with desktops.
      - ahartmetz 5y ago
        What do you mean? When I think of "...integrate poorly with desktops", I think of Electron apps. These also have a Flatpak-like distribution (but not security) model. And a "best effort" integration model. Basically, whatever is possible without lifting too much of a finger.
        gens 5y ago
        When i think of "desktop integration", i think about drag and drop not working between `ark` (a QT program) and `thunar` (a GTK program), and i think of folk writing blog posts about window theming. (there's also notifications, icons, etc, blablabla, that keeps getting worse (freedesktop is, that is)) To be honest, i don't care much about how programs look. But i do know many people do care.
goodpoint 5y ago
There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. - Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk. - Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks.
- fsflover 5y ago
  So basically all the same drawbacks as in Windows, when you install third-party software?
  - ahartmetz 5y ago
    Of course, it's basically the same distribution model. Everything but the kernel and a very basic set of runtime libraries are shipped with the application. Except, I guess, that the basic Windows runtime libraries cover more security-relevant functionality than the same with Flatpak. I'm thinking of SSL, for example.
  - raffraffraff 5y ago
    When I had to install my first AppImage I got a horrible déjà vu from my Windows XP days. The Linux repo experience is just better. Trust the repo via gpg and https instead of trusting every download url and scanning every blob for malware. Upgrade the whole system at once, instead of hunting down every new blob (and remembering where you got it).
  - monopoledance 5y ago
    Haven't used Windows in a decade, but third party apps on Windows don't even have the framework for some sort of package management, do they? At least with snap/flatpak/AUR/PPA you got an aggregated updating interface and optionally sandboxing for snaps and flatpaks. I think, something like Appimages are the better fitting equivalent to Window's normalized madness, no?
dylan-m 5y ago
> Memory and CPU-wise, Flatpaks are very light containers Adding to that: it's really worth noting, on "Memory Usage, Startup Time," the author of this article went straight into Snap ("the slowest of all") and doesn't mention Flatpak once. Could it be … it isn't a big deal? Nah, let's move on, Flatpak bad. They also conveniently use an old version of GNOME Software which predates the recent rework of how it displays permissions, age ratings, and other details. In Fedora 35, GIMP most definitely has a worrisome "Unsafe" message. It's very shiny and new so it would be excusable to miss that if you weren't pretending to be a well-researched hatchet job.
- Barrin92 5y ago
  I also can't replicate that snap apps take the same long amount of boot time every single time. Snaps generally take a few seconds on the first startup but then for me start more or less as fast as any other app.
  - dylan-m 5y ago
    Yep, as I understand it the Snap thing is also obsolete information. Older snaps are still slow, but new snaps are more efficient to start, and that has been the case for a while now.
raffraffraff 5y ago
This validates an assumption that I had made: easier developers, harder for everyone else. It's a pain in the ass packaging apps for each distro, but the value of a single command to update libraries and applications on millions of Linux systems is worth it, no?
ho_schi 5y ago
My experience with Flatpak is okay, the payload by runtimes is okay and it works. What worries me is the actual amount of files within /var/lib/flatpak, for 23 packages (apps and all depdencies) it is about a half million files. This a problem, moving /usr now takes a lot time. I think Flatpak applies well for checking out new applications and closed-source binary applications. You don't want many closed-source applications within the official package-mangement and the core system, it also prevent their publisher to create distribution specific packages. Good things require always hard work, there is no magic solution. I appreciate API and ABI stability and slick package management of Linux distributions. The work of developers and package maintainers make this possible. This is the reason why Linux is efficient and comfortable. This is not a magic solution but work. And it makes efficient distributions possible. The grass is green on the other side? On Windows you have to install all automatic updates or new applications will not run. If you don't do this you will face errors about missing C#-Runtimes or a C++ Redistributable. And application developers need to ship dependencies within the application. This is the reason why Windows is so fat, why applications are fat and the usage of a permission system is not possible. The article doesn't states this. MacOS on the other hand? The break compatibility every few years. MacOS Classic to MacOS X, Quartz, PPC, Intel and finally M1. Android and iOS had the luck to be new. Permissions work, if they aren't requested all. But still, iOS fails to provide file-system access, file handling is burden for users and backups are impossible. Apps haven grown quickly into being fat. Garmin Connect, an app which cannot do anything without cloud, 340 MB. Do yourself a favor an check what your banking app requires, you won't get away with less than 200 MB and only the good ones can show you our balance locally - which requires how many kilobytes to store? Messengers like Signal are also growing an growing, Signal is right about 170 MB. Back to Linux: I can only appreciate the path to system wide ABI/API stability on Linux, with Systemd, GLIBC, LIBSTDC++ valuing stability and the recent changes around Gtk3 and Gtk4 the situation may become even better. I think Flatpak can be improved, it should be improved. But we don't need another competing standard, before we didn't tried hard to improve the existing solution. I hope that at one day Canonical will start collaborating with the community and especially Red Hat, they always implement a less favorable solution (Mir, Unity, Snap, Upstart...) lose and harm Linux. Collaborate with Flatpak, add a payment solution and share the revenue with Red Hat and others?

user0123895264 5y ago

I might be imagining it, and there might be another cause, but I stopped using Elementary after the latest release after many things moved to Flatpaks because I kept running out of memory. (On Endeavour/Arch, installing everything natively, I no longer have the problem.)

kirbyfan64sos 5y ago
If I had to guess, the update might have just introduced a memory leak somewhere else in the system?

0x0nyandesu 5y ago

Nah they take up too much disk space. Rather use Gentoo

capableweb 5y ago
Not sure if you misunderstand what Flatpak is or if you are really suggesting to ship a entire distribution for your users to install if they want to use the application you're delivering to them.
- 0x0nyandesu 5y ago
  A typical system will end up with 10 versions of some .so library on disk. Sometimes more. Disk usage waste everywhere. You're better off having a package manager that can link multiple versions at the same time to the programs that need it instead of bundling.
  - capableweb 5y ago
    But you're confusing what sides of the developer/user aisle you're on. Yes, there are probably a better distribution for the user to use if they want to save disk space. But Flatpak is not a distribution, it's a delivery mechanism. Are you really gonna tell people "Hey, don't use $YOUR-CURRENT-DIST, use Gentoo instead if you want to use my application" if your goal is to provide value for as many users as possible? It's simply not possible to ask people to change their distribution because you as a developer prefers a different one. Flatpak is for all distributions, and doesn't require someone to change from what they know and use already, it'll work for everyone equally.
  - nextaccountic 5y ago
    Just use a deduplicating filesystem. Both btrfs and xfs can deduplicate identical files.
    - sho_hn 5y ago
      This is misleading. While btrfs and xfs have some dedup functionality, it must be invoked explicitly (e.g. by using `cp` with the `--reflink` argument). For application installation to benefit from this, business logic would have to pre-identify identical files and make such references. There have been some experiments in btrfs to enable inband dedup on arbitrary writes, but nothing that made it in there as yet. Note however that the discussion misses on the fact that Flatpak itself does perform dedup by using ostree for on-disk storage. ostree implements data structures and ideas very similar to git sans the version control.

sebow 5y ago

My experience was exactly the opposite: snaps usually feel more polished and take less space than "flatpaks", at least when you compare the first time you install a flatpak.It's true that over time flatpaks take less space because they use what's already there. However the conclusion still holds imo, both are bad.Not necessarily because they haven't partially solved what they tried to achieve, but because they are being pushed instead of provided as alternatives to good-old package managers or binaries. Though technically older than both, AppImage is more recent in adoption compared to both Flatpak & Snap, and yet 95% of the time i had absolutely no problem using AppImage(with the small caveat that desktop integration is less polished, and i use a neat tool called AppImageLauncher to 'install' them). I know it's an apples to oranges comparison and AppImage is not a package manager, but the point still stands.

gens 5y ago

I recommend just shipping everything you need with your app, either manually or using AppImage. Flatpack is, more or less, just a bad package management.. technology.

kaba0 5y ago
Nah, AppImage still won’t run on all distros. The only thing I think actually solves packaging is nix.
- alvarlagerlof 5y ago
  And AppImage integrates poorly with desktops.
  - southerntofu 5y ago
    How so? Double-clicking an AppImage from a specific folder is not user-hostile (that's a common pattern across desktop systems), and the blogpost specifically points to appimaged and AppImageLauncher as solutions for full desktop integration.
  - gens 5y ago
    Desktops integrate poorly with desktops.
    - ahartmetz 5y ago
      What do you mean? When I think of "...integrate poorly with desktops", I think of Electron apps. These also have a Flatpak-like distribution (but not security) model. And a "best effort" integration model. Basically, whatever is possible without lifting too much of a finger.
      - gens 5y ago
        When i think of "desktop integration", i think about drag and drop not working between `ark` (a QT program) and `thunar` (a GTK program), and i think of folk writing blog posts about window theming. (there's also notifications, icons, etc, blablabla, that keeps getting worse (freedesktop is, that is)) To be honest, i don't care much about how programs look. But i do know many people do care.

goodpoint 5y ago

There are plenty of drawbacks: - Security: you are trusting random developers on the Internet to handle security of all the dependencies in a flatpack, forever. Most do not provide security updates at all. - Privacy: distros like Debian spot and patch out trackers, telemetries and similar things. - Long term maintenability: your desktop becomes a random mashup of applications with increasing complexity that you have to maintain yourself. - Licensing issues: distros review licenses (and find plenty of copyright violations while doing so). A flatpak puts you or your company at risk. - Impact on the ecosystem: the more users switch to opaque blobs the less testing and review is done for proper packages. The whole ecosystem become more vulnerable to supply chain attacks.

fsflover 5y ago
So basically all the same drawbacks as in Windows, when you install third-party software?
- ahartmetz 5y ago
  Of course, it's basically the same distribution model. Everything but the kernel and a very basic set of runtime libraries are shipped with the application. Except, I guess, that the basic Windows runtime libraries cover more security-relevant functionality than the same with Flatpak. I'm thinking of SSL, for example.
- raffraffraff 5y ago
  When I had to install my first AppImage I got a horrible déjà vu from my Windows XP days. The Linux repo experience is just better. Trust the repo via gpg and https instead of trusting every download url and scanning every blob for malware. Upgrade the whole system at once, instead of hunting down every new blob (and remembering where you got it).
- monopoledance 5y ago
  Haven't used Windows in a decade, but third party apps on Windows don't even have the framework for some sort of package management, do they? At least with snap/flatpak/AUR/PPA you got an aggregated updating interface and optionally sandboxing for snaps and flatpaks. I think, something like Appimages are the better fitting equivalent to Window's normalized madness, no?

dylan-m 5y ago

> Memory and CPU-wise, Flatpaks are very light containers Adding to that: it's really worth noting, on "Memory Usage, Startup Time," the author of this article went straight into Snap ("the slowest of all") and doesn't mention Flatpak once. Could it be … it isn't a big deal? Nah, let's move on, Flatpak bad. They also conveniently use an old version of GNOME Software which predates the recent rework of how it displays permissions, age ratings, and other details. In Fedora 35, GIMP most definitely has a worrisome "Unsafe" message. It's very shiny and new so it would be excusable to miss that if you weren't pretending to be a well-researched hatchet job.

Barrin92 5y ago
I also can't replicate that snap apps take the same long amount of boot time every single time. Snaps generally take a few seconds on the first startup but then for me start more or less as fast as any other app.
- dylan-m 5y ago
  Yep, as I understand it the Snap thing is also obsolete information. Older snaps are still slow, but new snaps are more efficient to start, and that has been the case for a while now.

raffraffraff 5y ago

This validates an assumption that I had made: easier developers, harder for everyone else. It's a pain in the ass packaging apps for each distro, but the value of a single command to update libraries and applications on millions of Linux systems is worth it, no?

ho_schi 5y ago

My experience with Flatpak is okay, the payload by runtimes is okay and it works. What worries me is the actual amount of files within /var/lib/flatpak, for 23 packages (apps and all depdencies) it is about a half million files. This a problem, moving /usr now takes a lot time. I think Flatpak applies well for checking out new applications and closed-source binary applications. You don't want many closed-source applications within the official package-mangement and the core system, it also prevent their publisher to create distribution specific packages. Good things require always hard work, there is no magic solution. I appreciate API and ABI stability and slick package management of Linux distributions. The work of developers and package maintainers make this possible. This is the reason why Linux is efficient and comfortable. This is not a magic solution but work. And it makes efficient distributions possible. The grass is green on the other side? On Windows you have to install all automatic updates or new applications will not run. If you don't do this you will face errors about missing C#-Runtimes or a C++ Redistributable. And application developers need to ship dependencies within the application. This is the reason why Windows is so fat, why applications are fat and the usage of a permission system is not possible. The article doesn't states this. MacOS on the other hand? The break compatibility every few years. MacOS Classic to MacOS X, Quartz, PPC, Intel and finally M1. Android and iOS had the luck to be new. Permissions work, if they aren't requested all. But still, iOS fails to provide file-system access, file handling is burden for users and backups are impossible. Apps haven grown quickly into being fat. Garmin Connect, an app which cannot do anything without cloud, 340 MB. Do yourself a favor an check what your banking app requires, you won't get away with less than 200 MB and only the good ones can show you our balance locally - which requires how many kilobytes to store? Messengers like Signal are also growing an growing, Signal is right about 170 MB. Back to Linux: I can only appreciate the path to system wide ABI/API stability on Linux, with Systemd, GLIBC, LIBSTDC++ valuing stability and the recent changes around Gtk3 and Gtk4 the situation may become even better. I think Flatpak can be improved, it should be improved. But we don't need another competing standard, before we didn't tried hard to improve the existing solution. I hope that at one day Canonical will start collaborating with the community and especially Red Hat, they always implement a less favorable solution (Mir, Unity, Snap, Upstart...) lose and harm Linux. Collaborate with Flatpak, add a payment solution and share the revenue with Red Hat and others?