Is there a downside to Flatpak?

There is some drawback. The main one : app can't communicate with each other.

Example firefox and his extension keepass. As keepass can't communicate with firefox, you have to open both apps and switch their windows.

You can use flatseal to manage communication between apps but that's not an easy process and may prove a security issue if you don't understand the technical jargon.

1- It takes a lot of space. jUsT bUy a bIgGeR dRiVe --stfu I'm not going to spend money for you to waste it

1- a) Everyone assumes you're an American with 20Gbps symmetrical fiber optic. My internet can't handle 2+ Gb downloads for a fucking 50 Mb app bro

2- Duplicate graphics drivers. Particularly painful with Nvidia

3- It puts a lot of security work with distro library trees straight into the shitter

4- Horrendously designed system for CLI apps (flatpak run org.whocares.shit.app)

5- Filesystem isolation has many upsides for security but also it can cause some pain (definitely nitpicking)

Yes, I love it and don't get me wrong but there are many downsides and they all result from poor planning and/or bad decisions around how flatpak was built. Here are a few:

• Poor integration with the system: sometimes works against you and completely bypasses your system instead of integrating with it / using its features better. To me it seems more like the higher levels are missing pieces to facilitate communication between applications (be it protocols, code or documentation) and sometimes it is as simple as configuration;
• Overhead, you'll obviously end up with a bunch of copies of the same libraries and whatnot for different applications;
• No reasonable way to use it / install applications offline. This can become a serious pain point if you're required to work in air gapped systems or you simply want to level of conservation for the future - it doesn't seem reasonable at all to have to depend on some repository system that might gone at some point. Note that they don't provide effective ways to mirror the entire repository / host it locally nor to download some kind of installable package for what you're looking for;
• A community that is usually more interested in beating around the bush than actually fixing what's wrong. Eg. a password manager (KeePassXC) and a browser (Firefox/Ungoogled) both installed via flatpak can’t communicate with each other because developers seem to be more interested in pointing fingers on GitHub than fixing the issue.

Flatpak acts as a restrictive sandbox experience that is mostly about "let's block things and we don't care about anything else". I don't think it's reasonable to have situations like applications that aren't picking the system theme / font without the user doing a bunch of links or installing more copies of whatever you already have. Flatpak in general was a good ideia, but the system integration execution is a shame.

For me it's lacking in user friendliness. Go easy on the downvotes if I'm doing it the hard way.

• Flatpaks aren't really single-executables. You have to use to the flatpak command to run them.
• I can't just say flatpak run firefox, I have to use the full app-id which could be quite long.

Yes, I could make this simpler with scripts or aliases but how hard would it have been for Flatpak to automatically do this for me?

It's HUGE. That's the biggest downside for me. I'm always use a deb/native package first because they are way smaller.

• overly verbose way to launch them in terminal
• can sometimess not even respect your gtk/qt theming
• sandboxing/permission system can lead to you trying to figure out which directory you need to give access to when you want to save file if it wasn't preconfigured
• uses its own libraries and not system libraries, want to play the hit new AAA game with steam flatpak? get fucked it requires a mesa commit that was merged 8 hours a go and you're stuck on 23.0.4 and can't use the git release.

Flatpak probably has it's specific uses like trying to use one piece of proprietary software that you don't trust and don't want to give it too much access to your system, or most GUI software clients having an easy way to install Discord on your Steam Deck (no terminal usage, Linux is easy yay), but native packages 99% of the time work better.

The worst part of flatpaks is that they don't get to see the actual path of files that they open. Instead, they get a /var/run/1000/blah proxy. The proxy is forgotten after you reboot, so any flatpak that memorized that path is holding a bunch of dead links.

Startup time and disk space.

It's great for user apps, gui apps, and sandboxing. It's terrible for cli apps, libraries, development, and integration.

Some people don't like it because it uses a bit more storage and can start a bit slower, (I think) they can't be used for system packages, and I've also had some issues with theming

I think its biggest weakness is also its biggest strength: isolation. Sometimes desktop integration doesn't work quite right. For instance, the 1password browser extension can't integrate with the desktop app when you use flatpak firefox.

No proper estimate of download size.

For me, the question is why I should add an extra layer of complexity. If the things I use already work well using apt, and if most things are bundled in the default distro install, then my life is already good.

This all depends on your software needs, if course. Some people are using a lot of new stuff, so the above setup leads to annoying situations.

It ruins single source of truth for apps and their installed state. It hides installed state from standard enterprise tools.

I’ve had my first downside with flatpak.

VSCode’s flatpak version won’t let you use certain packages because they’re installed on the system and flatpak is a sandbox with no access. You need to enable some stuff but I’m far too lazy to troubleshoot that shit.

I got the Snap version so I’m ready for the hate.

• no OS level components
• duplicate libraries as some core apps (editor, filemanager, Desktop) cannot be flatpaks (yet?)
• old runtimes etc. dont force developers to keep them updated. Often thats because or 3rd party packagers though
• complicated packaging, I heard that the Flatpak builder is better for certain languages.
• theming issues I heard (on Fedora Kinoite Wayland it just works, and I can also force themes per app)
• bad permissions by default (best we have though)
• bad run commands (this could easily be fixed, and I have a script for it)

For OS components / packaging every part, Snaps may work, but for GUI apps they seem subpar and nobody really cares.

Nix may be way better for installing just anything compartimentalized, but there is no permission system (thats why packaging is easier).

But Flatpaks are really great overall, Bubblewrap, KDE Settings / Flatseal, Portals, official app support. Its really really important.

IMO yes but it might not be an issue for you, flatpaks work like windows standalone executables where each app brings all their dependencies with them, the advantage is the insane stability that method provides, the downside is the huge size the app will ultimately take, flatpaks are compressed and they don't really bring all their dependencies with them (because they can share runtimes) but the gist of it is a flatpak is usually much heavier than a system (.deb .rpm .PKG) package.

If you are ok with tweaking I recommend nix pkgs as they work on any distro and only take slightly more space than system packages. I have a terrible connection and low disk space, flatpaks aren't something I can use on the long run.

Oh and if you're wondering flatpak >>>> snap > appimages (IMO)

Why isn’t this just the default?

One may notice that for every new method, the old ways stay around, possibly forever. It is not the default because there were things that worked prior to flatpak. The distros that from before flatpak have likely added the capability, but won't likely change their default for another decade, or more.

the main drawbacks I see are related to the sandboxing of apps, e.g. that several firefox addons that I just, such as the KeePassXC connector don't work in flatpak packaged firefox, because they require native messaging support which is unavailable in flatpak. There is a three year old bug report on this at github, and an even older bug report in the Firefox bugzilla. Unfortunately, there seems to be no capacity to solve this or this is not a priority, although this problem affects quite a few users. I have similar issues with the Flatpak packages Nextcloud client: Do to the poor system integration, neither autostart works not integration with Nautilus or other file managers, unless you do some manual tinkering (which isn't particularly difficult, but with native packages it will just work™ out of the box.) These issues have been known for many years, yet there seems to be no activity to solve them.

Yes. It is not pacman

They dont integrate well into your system like they should, (theming, bookmarks, storage, etc), and to fix that you gotta do some work arounds that should be done automatically

There's still a few edge cases that Flatpak is not great for. The Flatpak version of Kdenlive video editor can't see Whisper, which it uses to generate subtitles. The Appimage and native builds work flawlessly.

I'm assuming these problems will be addressed eventually but it takes time.

It is the default on atomic distros. And many people who got to know flatpaks use it as a default on traditional installs as well.

But there are still bugs and quirks with some apps. Not all apps have all the functionality as a traditional install. E.g. dolphin or terminals.

It is up and coming and gradually replacing traditional installs. You rarely find an app that you can't install via flathub.

There are theming issues with older flatpaks.

Edit:

I have no idea how to view logs in the terminal with flatpaks.

You can't easily run flatpaks by their common known names. You have to use the reverse flatpak name which is annoying and difficult.

Bloated and unnecessary if freeSW or openSW. That's what system shared libraries are for. If sandboxing is a thing, then firejail is availble, which can be combined with apparmor if looking for extra MAC security.

Endlessly reading on social media that is not a good from Linux "gurus". LOL

It's been great for me, but I wish it had a official gui for permissions management.

All that was said here, plus sometimes they don't work. I've reported a bug where the kdenlive flatpak version doesn't render titles or fades - and that's on Debian Testing, Arch, and Asahi Fedora. Native version works perfectly, but forces me to download an untidy amount of KDE stuff on my gnome installs ; flatpak would've been a cool solution to that.

I am yet to report another where Ardour nukes pipewire, at least on Asahi, but on Arch it was misbehaving also. Native, distro-provided version works perfectly.

I don't trust flatpak because no one single publisher can test every possible config, and I'm afraid distros become "lazy" and stop packaging native versions of stuff since it's a lot of work.

I believe it's the packaging process. It favors the standatd procedure of builds, and does not take account of various build systems (Seems C-centered). Seems this is why many apps end up providing AppImages instead.

Flat pack install OBS? works awesome! Try to install plug in afterward not so much.

I've used flatpak for a while because it's the default ob Fedoras GUI Software Center, but I've recently switched back to dnf and native packages where I can.

The thing is, that I have a shitty 500GB SSD with a shitty 50Mbit Internet connection (which is closer to 30Mbit because my house still has lead cables instead of copper). So downloading 300+ MB of libraries for a 2MB Program is just not feasible for me.

I'm a little put off by the inconvenient command line and the mandatory bells and whistles (flathub is nice and all, but must it be baked into the main executable rather than having the package manager as an optional thing on top?).

So far, AppImage just looks superior to me. Works without installing a runtime into my system, no need to become root and integrate an app into a system-wide managed package repository, I can just run it.

Others have mentioned disk usage and desktop integration. There is some truth to them, but shared runtimes keeps disk uasge down (although worse than native apps). Desktop launchers now search /var/lib/flatpak/exports/share/applications by default, but I'm still having issues with themes in one or two niche apps.

Trust is the big one. The benefit of your distro's packages is that they are maintained by a limited number of maintainers. Flatpaks have a much, much larger number of maintainers, which is where sandboxing comes in. Flathub now marks apps with lax permissions as "potentially unsafe", which is a huge step in communicating this to the average user.

Most desktop apps can get away with having next to no access, as long as they support the appropriate XDG desktop portals.

Ultimately, your mileage will vary, as there are many classes of application which are ill-suited to being sandboxed. Program launchers, programming languages, IDEs, file managers are a few.

As everything in life, yes, there is downside. Major downside is that it can occupy more space in your hd or ssd.

However I think the downsides are not that bad to justify all the hatred some guys have.

Flatpak positive sides are way more relevant then the downsides

One of the use cases I would like to have used Flatpak for is Visual Studio Code. Unfortunately, I found the isolation to be too onerous for developer needs. Take the Rust compiler toolchain. There's no way to access that from VSCode. There are ways to add on tools to the VSCode environment, but that feels like a kludge when I already have everything installed and set up. And if the toolchain isn't available for Flatpak, tough luck. Other features just simply don't work. I eventually switched to using the Ubuntu builds from the VSCode developers.

Edit: The Rust compiler toolchain can be added onto Flatpak because there is a packaged version of the toolchain, but it's not the host environment's version. Other tools like the fish shell might be entirely unavailable.

Take a look at this site that goes into the details of the shortcomings of Flatpak, its from 2020 but I'm sure some of this is relevant still

What could be wrong with random foreign executables in your system?

The biggest downside is that it's only for distributing applications with a graphical user interface. Command line utilities still need another method of distribution.

As a basic end-user I have not been too happy with my experience with flatpaks. I do appreciate that I can easily setup and start using it regardless of what distro I'm using. But based on standard usage using whatever default gui "app store" frontends that usually come with distros, it tends to be significantly slower than apt, for instance, and there seems to be connection problems to the repos pretty often as well.

I don't use Flatpak much, but I rarely see issues. Sometimes I see minor things like themes not quite being right, but its never been bad enough for me to spend the time to fix it.

I suppose another downside is the need to have the base runtime packages, so it could take more disk space if each app uses a different one. In practice apps will share runtimes though.

GPU drivers. It uses the Ubuntu 22.04 (LTS) userspace side of drivers. Could be incompatible with your kernel. Had all sorts of graphical weirdness with my AMD GPU with flatpak Steam.

If you have an unusual setup, it can be annoying trying to give programs permissions and sometimes it just outright doesn't work. For example, I mainly game on a laptop which has a pretty small hard drive, so I tend to put most of my games on an external hard drive. Flatpak really doesn't play well with that.

The main reason I don't use them is because when I move my nixos config to a new machine as far as I know you cant get them to auto install. I have to remember which ones I had installed and redo them manually.

Which is why if for some odd reason I don't want to just install from the nix pkgs repo. I use app images. I can keep them in a directory which I can just copy over to the new machine with my nixos config files.

I feel like this should be required reading for a lot of Linux users. That article is a couple years old now, but I think is even more true now than it was when it was written. Having a middleman (package maintainer) between the user and the software developer is a tremendous benefit. Maintainers enforce quality, and if you bypass them, you're going to end up with Linux as the Google Play Store (doubly so if you try and fool yourself into thinking it won't happen because "Linux is different")

Yes, the confusion that results when things don't work because of isolation.

What I find most annoying is the extra drive space required. It makes backing up and restoring my computer so much more annoying. The upside of this is that I've ended up learning how to install from source so I can avoid them when a deb package is not available!

I personally don't really like it, since it sidesteps what is supposed to be the all-in-one package manager for the system, and integration can be poor.

It's an alright idea, but I like the native package managers better. We're not Windows, we don't need so many different places to download our stuff.

Discuss it with https://lemmy.world/post/12126335

Flatpak usually ships very outdated drivers.

I've been in the support channel for yuzu linux, and you would not believe all the issues people have with games freezing, etc that are instantly fixed by using the appimage instead of the flatpak.

Also flatpaks are non-xdg compliant, since it creates the useless ~/.var directory. And they have said over and over that they won't fix that. So fuck them.

Not to mention all the issues people have with their theming and integration into the system.

Appimages are just simpler and better, the other day I was thinking how many issues would be fixed if Steam shipped as an appimage.

• It would allow for shipping a patch glibc with EAC
• It would allow for moving all the nonsense that steam puts in the home user dir, since appimages support a portable home.
• It would allow for shipping the 32bit libraries instead of having to install them system wide.

And depending on how you go about, appimages will even take less disk space than flatpaks or native packages even though you don't get shared libraries with those, because they are compressed which reduces their size significantly.

Like for example the LibreWolf appimage is 110MiB while a the native package for librewolf 300MiB. Same with LibreOffice, the appimage is 300MiB while the native package is 600 MiB.

It also makes it easier to downgrade if you run into an issue, like I had to had an older appimage of ferdium because the latest version is affected by an electron bug that broke its zoom functionality.

I use flatpak for all GUI apps I use.

Yes, security

I like Flatpak, especially now that it has upstream providing packages. It does not have auto updates yet as far as I know. Not a big deal, if there are important security updates in the news, it is time to check for updates.

Problem I have with Flatpak is their way of naming packages which makes them very akward to run in a WM. That's basically the only reason why I haven't used Flatpak since I switched to WMs, pacman and AUR also work really well so there isn't even a reason to use something else.

Unless you are using like a 64GB drive, not really. Ig flatpaks are as bit more annoying to start from the terminal

No downside, only flatpak