I’ve been involved with Linux for a long time, and Flatpak almost seems too good to be true:
Just install any app on any distro, isolated from the base system and with granular rights management. I’ve just set up my first flatpak-centric system and didn’t notice any issues with it at all, apart from a 1-second waiting time before an app is launched.
What’s your long-term experience?
Notice any annoying bugs or instabilities? Do apps crash a lot? Disappear from Flathub or are unmaintained? Do you often have issues with apps that don’t integrate well with your native system? Are important apps missing?
Flatpaks are great. I do wish flatseal was part of the flatpak standard. I want an android style permissions menu
Well, Flatseal is using flatpak’s standard way of managing permissions. Everything it does you can also do from the command line with flatpak. It’s just a frontend.
I think KDE wants to add these options to it’s settings as well. That will be great, when it’s better integrated into the whole system.
KDE already does have the same thing in its settings
I’d like to see permission pop ups so I know it wanted permission to do something and didn’t have them, having to ask me. Sometimes it is explained that certain stuff the app does are blocked by the sandbox by default for security, but you can enable it, which is alright. Sometimes you’ll just have to find that out for yourself.
I wish it would be possible now but it probably won’t happen until windows and mac will have similar features. The problem is that processes cannot just read a file, because in the container it doesn’t exist. It’s maybe due to permission. Maybe not. You cannot tell. Android apps are written in a way that they request access, while pc apps are just reading the files directly without requesting permission.
So the app has to be written for flatpak. However, afaik, this is the maintainers goal too. Btw, the file open dialog is a currently working example of the dynamic permission handling. It’s just that the app should use these features which is not guaranteed.
That makes sense. Unfortunate that we won’t have it anytime soon
I want an android style permissions menu
Same. In addition to the prompt-based permissions that @Kusimulkku@lemm.ee brings up, I’d like to see more granular control of permissions. For example, a flatpak app’s access to webcams, controllers, etc. are all controlled through just one permission:
--device=all(aka “Device Access” in KDE’s Flatpak Permission Settings).
Really awesome. They’re all contained within my home directory too, so when I swap distros I can just copy my home dir and all my installed apps are carried over that way. Super useful feature that never gets mentioned! The downside to flatpaks is having to use them for cli in any way is a huge pain.
Why not use a seperate /home partition if that’s something you value?
I do, that doesn’t keep packages installed between distro reinstalls or swapping between entirely different distros. I’m talking about the actual packages and app data themselves that are contained in home.
For automatic installation I recommend ansible, its real easy
There’s literally no need. It’s auto installed because everything is portable and most applications that launch .desktop files know to look for it’s directory.
that doesn’t keep packages installed between distro reinstalls or swapping between entirely different distros. I’m talking about the actual packages and app data themselves that are contained in home.
It’s auto installed because everything is portable
Then you didn’t explain it very well. Your former comment clearly states that copying the files keeps the packages (so you don’t have to redownload?) and the data, but “doesn’t keep packages installed” (hinting that .desktop files don’t get found)
I always use Flatpaks when available, I have been using it for about 1~2 years and honestly, I haven’t found any issues that are deal breakers, mostly some missing storage permissions, but KDE makes this easy to deal with. I know some apps have some issues, but the biggest one that I had is that Steam Flatpak still requires Steam-Devices to be installed as a package, but that’s more to do with the way Steam Input works.
The only issue that I have is that uninstalling Flatpaks should present an option to delete the app data.
So how do you delete app data after uninstalling?
And does uninstalling a flatpak app also uninstall flatpak dependencies that came with it?flatpak uninstall --delete-data example-packageAnd does uninstalling a flatpak app also uninstall flatpak dependencies that came with it?
from what I have seen, NO it does not do so automatically. there is a flatpak command option to clean out unused runtimes, and another to remove user data.
delete app data after uninstalling?
you either manually delete the data, or there’s some
flatpakcommand option, or you can use a tool such aswarehousewhich is available as a flatpak.other posts list the specific commands.
you can use
flatpak remove --unused --delete-datato remove all unused dependencies and delete their data.from what I have seen, NO it does not. there is a flatpak command option to clean out unused runtimes.
It does. The unused command is mostly for after updates, then what’s used may have changed.
Check out Warehouse for deleting app data
If you install your flatpaks through the discover store it gives you an option to delete data whenever you uninstall
Same on Gnome software
But I guess I agree that it should prompt you when doing it through a TUI
Don’t like them, they are annoying to deal with - CLI naming is odd, files are stored unintuitively and if your whole system is not on flatpak, chances are the sizes are going to be absurd. One of the main reasons I wen’t with Arch is Pacman + AUR, never have to install a flatpak, because the package management is so good.
I don’t think the size thing is much of an issue these days outside of say IoT or very old computers. Absurd for say a single calculator app to be weighing like a gig or however much Gnome runtime is, but even in that situation it’s not much of an actual problem imo. And once you install anything else using that same runtime, you in a way halved the size of that app.
Never used them, maybe I’m old, but I only use app from the mx/debian repo. Everything is here and up-to-date. I prefer raw native.
I’m using official flatpak Firefox because I didn’t want to wait any longer for Fedora releasing their rpm version of it. This way I get new releases right away and they are official as intended by Mozilla.
Not really a flatpak advantage, but a Firefox advantage.
Perfection. Debian + GNOME Software + Flatpak = Rock solid and clean OS with the latest software.
There are a few things that still need to be ironed out tho. For eg. communication between desktop apps and browser extensions such as this.
Another thing I would like to see is a decent and supported way to mirror flathub and/or have offline installations.
I managed to get the workaround working, but it’s nowhere near optimal to have to do that. I hope they’ll fix it
What workaround specifically?
KeepAssXC and Firefox both being flatpaks but still talking to each other
Lololol KeepAss
I don’t like it. Updating dependencies in case of security problems is impossible, I have to wait for the developer to release an update. Also, it wastes a lot of space. Pollutes
dfoutput. App startup is slooow.Just use the native packaging system! There is no reason software can’t be released using that.
Wdym by
dfpollution? That’s the case with snap, not flatpakI see that fragmentation of runtimes is a problem. If all apps would simply use the same runtime, and a modern one, and there was a package manager that installs the missing dependencies, that would be nice.
The diskspace is a true problem too, just because of the fragmented runtimes.
But Distros are fragmented too. If simply everyone could unify, at least a bit, instead of at least 5 different big Distros competing, every app could just work. But thats not the case, so Flatpaks often work best, and maany packages are either only .deb, .rpm or even only on Arch
idk what type of drive you’re using, but flatpak startup times are indistinguishable to me, when compared to native packages. And I’ve used flatpaks on A LOT of computers…
There’s a pretty simple reason. It’s that developers don’t have to spend the time to package for every single distro. I know I wouldn’t, I’d just focus on packaging for the distro that I use and flatpak. Having flatpak also means that some less known distros start with a big amount of apps available from the get go with flatpak.
Just to provide counter examples, in arch I can’t use the native steam package and play games with proton. It just doesn’t work. I think proton expects some ubuntu libraries or something (found something like that while spending 5 hours debugging nfs heat). And even if I manage to fix it, next time I update the system it’ll be broken again.
I use flatpak, and everything just works.
However, in arch if something is in the official repo or the AUR i prefer those.
In ubuntu I installed krita and gmic, but it doesn’t work. For some reason krita doesn’t find the gmic executable. Instead of debugging krita and gmic for hours I just installed the flatpak version, and it just works.
And yeah, app startup went from 5 to 7-10 seconds in krita, and from 1 to 2-3 seconds in firefox. It’s not snap, it’s 2023, we have SSDs.
Really? I use Arch native Steam and Proton no problem. You either use steam-runtime (uses built in Ubuntu runtime) or steam-native (expects Arch packages) but there is a meta package for pulling the runtime deps. Both have worked for me.
That said, Flatpak has come in clutch for me as well on the Steam Deck, and for things like Prism Launcher (modded Minecraft launcher) where you want to juggle multiple Java versions without needing to run archlinux-java between switching packs.
I prefer them. There’s trade-offs (like disk usage and occasional theme issues) but it’s worth it to me for the sandboxing and ability to easily run a newer version of an application than your distro has packaged up in their repos. It’s better for developers since they don’t have to support deb, rpm, etc. etc. And long term, it’ll allow immutable systems to become the default and that’ll be good for security and stability.
Between Snap, Flatpak, and AppImage, I default to Flatpak. It seems like the best supported even if they all have their strengths and weaknesses. AppImage is great for old versions of software you don’t want updated/integrated into menus. Snaps are basically the same and I happily use them if there’s no Flatpak but it’s so tied to Ubuntu/Canonical that some people have opinions about using it. I don’t know of any developer stubbornly refusing to support Flatpak on ideological grounds.
What’s your long-term experience?
Excellent. After uninstalling it never comes back.
My experience with flatpak has been stellar from a technical perspective has been stellar.
Where it currently falls short for me personally is trust. With my distro I am putting my trust into the maintainers, but with flatpak its… random people for most apps?
It is tough when it is not a primary channel of distribution for most devs, but I am optimistic that will change in the future.
It’s sandboxed though. Running an app from a developer already implies trust on your part. So if it’s sandboxed away from your other stuff, what’s the issue?
Sandboxed just means an app can’t reach out to the rest of the OS. What about the information I am entrusting to it to process?
If my browser is a flatpak, it likely has access to most of the information I care about. If I am using a chat app that is a flatpak, it can read my most personal communications. Why do I care if it can read what is in /etc?
Relevant: https://xkcd.com/1200/
Running an app from a developer already implies trust on your part.
You totally missed my point. My point was that a lot of flatpaks are packaged by unknown third parties. I would love it if the devs would package things as flatpaks directly, but that is mostly not the case.
Looking at flathub right now. 1567 applications are from unverified publishers vs 789 verified. Unverified apps include chrome, edge, chromium, brave, BITWARDEN and signal. All of those applications process highly sensitive information.
Seems like every flatpaks update has to redownload Nvidia drivers for each package which is like 500mb, and my download speed is 3mb/s on a good day. So flatpaks limit me to updating once a month
You can pin the Nvidia driver with
flatpak mask appnameand update the rest of your apps.
Flatpak is good for chat apps and proprietary apps which you don’t want to have full access to your system
ive had supprisingly little issues with flatpaks.
i have been running silverblue for about half a year now, and rely heavily on them.
i can remember 3 distinct issues:
vs code commandlines start in the sandbox, which needs a workarround (rather understandable)
either the fedora, or the flathub build of firefox didnt come with some video codec, OpenH264 i think. switching to the other build fixed it (imo more a licensing issue with the codec than a flatpak problem)
on rare occasions (about once every 3 month)
steam behaves weirdly, and refuses to start until i update the flatpak.other than that, it has been a smoth ride.
either the fedora, or the flathub build of firefox didnt come with some video codec, OpenH264 i think. switching to the other build fixed it (imo more a licensing issue with the codec than a flatpak problem)
Just in case anyone in this thread also has problems with video playback on flathub Firefox, I just solved that by installing the ffmpeg-full flatpak.
No idea why a dependency that is needed to play video without jitter isn’t installed automatically.
I am not terribly impressed. The ability to build and run apps in a well defined and portable sandbox environment is nice. But everything else is kind of terrible. Seemingly simple things like having a package that contains multiple binaries aren’t properly supported. There are no LTS runtimes, so you’ll have to update your packages every couple of months anyway or users will get scary errors due to obsolete runtimes. No way to run a flatpak without installing. Terrible DNS based naming scheme. Dependency resolving requires too much manual intervention. Too much magic behind the scene that makes it hard to tell what is going on (e.g. ostree). No support for dependency other than the three available runtimes and thus terrible granularity (e.g. can’t have a Qt app without pulling in all KDE stuff).
Basically it feels like one step forward (portable packages) and three steps back (losing everything else you learned to love about package managers). It feels like it was build to solve the problems of packaging proprietary apps while contributing little to the Free Software world.
I am sticking with Nix, which feels way closer to what I expect from a Free Software package manager (e.g. it can do
nix run github:user/project?ref=v0.1.0).
