Basically title.
I’m wondering if a package manager like flatpak comes with any drawback or negatives. Since it just works on basically any distro. Why isn’t this just the default? It seems very convenient.
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.
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.
You only need flatseal on GNOME. KDE has it baked into the settings
Thank for the information. i didn’t know since i use vanilla os :)
Kde has many things baked into the settings that gnome hasn’t. GNOME is just more beautiful (and has PaperWM which is why I have to use GNOME)
Where in KDE are those settings? I see Flatpak permissions listed in Discover (bottom of right panel,) but you can’t change them there. Not sure where else to look. I’ve been using Flatseal but if it isn’t needed …
You can’t change them? https://github.com/KDE/flatpak-kcm
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)
Where in America is there 20Gbps symmetrical fiber? Everywhere I know tops out at 1gbps if you are lucky that your ISP isn’t shit, and lots of areas are still on slow cable.
In my area my options are 200mbps cable or 100mbps ADSL (which inexplicably costs more than the cable Internet)
Lived in 8 different states in the US - never had anything above 1 Gbps. Typically been 300-500 mbps, with only the past and current state state where I’ve gotten 1gbps. Poster is just assuming because we’re a first world country that we have good internet. We don’t. I hear Europe has better speeds than us.
Best I’ve ever had was like 60mbps down. Might be a budget thing though, I refuse to pay more than £30/month for internet
Maybe is an hyperbole I have optic fiber straight to my door here and is 10gbps tops but usually it works around 80% of that with some conditions. And it’s not symmetrical I don’t recall the up speed tho.
All of this. Plus often it just doesn’t work.
And no. I do not want to blind fiddle with the permissions to fix it.
Yes. It is not pacman
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.
The double-edged sword of isolation.
On the one hand, poor communication between apps and waste of storage.
On the other, relative safety from malicious applications, or from otherwise-safe applications built on top of a thousand libraries none of which have been audited by the dev.
I don’t know how it’s going to go down, but I suspect something will come along to address these issues and snatch the market away from Flatpak.
but I suspect something will come along to address these issues and snatch the market away from Flatpak.
I believe it could only be fixed by a team from GNOME or KDE, they’re the one in a position to develop something like Flatpak but deeply integrated with the system instead of trying to get around it.
For what’s worth Apple did a very good job when it came to the isolation and containerization of desktop applications, but again only possible because they control both sides.
Apple enforces a LOT of isolaton, they call it sandboxed apps and it is all based on capabilities, you may enjoy reading this. Applications get their isolated space at
~/Library/Containersand are not allowed to just write to any file system path they want.A sandboxed app may even think it is writing into a system folder for preference storage for example - but the system rewrites the path so that it ends up in the Container folder instead. For example under macOS apps typically write their data to
~/Library/Application Support. A sandboxed app cannot do that - and the data is instead written beneath the~/Library/Containers/app-idpath for that app.And here’s how good Apple is, any application, including 3rd party tools running inside Terminal will be restricted:
I bet most people weren’t expecting that a simple
lswould trigger the sandbox restrictions applied to the Terminal application. The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.I believe this was the best way to go about things but it would require to get a DE team to make it in a cohesive and deeply integrated with the system. Canonical could do it… but we all know how Canonical is.
The best part is that instead of doing what Flatpak does (just blocking things and leaving the user unable to to anything) the system will prompt you for a decision.
No, Flatpak isn’t the problem here, portals for these things exist. The problem is that apps would have to use them, and unlike Apple, there’s noone restricting the old / unrestricted ways of doing things… So apps usually don’t port over to the portals.
Even where the unrestricted APIs stop working, like with screen capture and Wayland, apps are excruciatingly slow to port over, because they don’t get kicked from app stores for it, and because many users can still fall back to using the old system.
While what you say is true, the “portals” were an afterthought, an imposition to developers and a cumbersome and poorly documented solution. Just like the theming and most other things.
Instead of bluntly blocking things why can’t Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path? A GUI capable of automatically enumerating those resources and a bunch of checkboxes like "app X and Y both have access to socket at
/var/run/socketYwould also solve most of the issues.Instead of bluntly blocking things why can’t Flatpak just simulate a full environment and just prompt the user whenever some application wants to read/write to file / unix socket at some path?
Because the user getting a hundred popups on app start for various files the app needs isn’t exactly a usable experience. Also, blocking the app’s main thread (which is the only way you could do this) is likely to break it and cause tons of user complaints too.
Aside from apps using the APIs meant for the purpose of permission systems, there’s no good way to make it work.
To the duplicate libraries
Do you know if flatpak leverages the memory side of this? With shared libs, you only keep one copy in memory, regardless of how many applications use it. Makes application launch faster, and memory usage lower.
For flatpak, it of course will load whatever it needs to load, but does it manage to avoid loading stuff across other flatpaks?
It’s HUGE. That’s the biggest downside for me. I’m always use a deb/native package first because they are way smaller.
Of course they are. they share dependencies with other software. flatpaks bundle all dependencies,which is great for sandboxing,even though some sort of break the rule and share some,they are still sandboxed.
Unless you “firejail” or “bubblewrap” your software, security is much better OOB for flatpaks.
That’s a myth. Security of flatpaks depends entirely on the given permissions, and since most flatpaks just set their own permissions on installation, or require filesystem access to work, there is no meaningful difference in security OOB.
Flatpak apps cannot set their own permissions “on installation”. If flatpak tells you some weather app uses only the network permission then that is all the app is going to get.
For an app to be able to change its own permissions, it first needs permission to the flatpak overrides directory. Any app that does this gets an “Unsafe” designation in gnome-software.
Also about most apps requiring filesystem access to work: I have 41 flatpak apps on my system (Silverblue so everything is flatpak). Only 6 have access to my home or Documents directory. (11 apps requested full filesystem or homedir permission, but 5 of these work perfectly fine after I turned off their permissions in Flatseal).
Notably, “large attack surface” apps like Thunderbird or Firefox don’t have access to my Documents. File uploads and email attachments go through the file picker portals.
Those dependencies adenoid and no kept Upton date, unlike deb/rpm installed stuff. Best sandbox to not compromise your system. Also hope that sandboxing is done right…
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
flatpakcommand 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?
I’m using KDE and when I download a flatpak it automatically creates a .desktop file. I think gnome does this too if I’m not mistaken. I do have to restart or relogin for it to put the file there but that’s not that bad IMO.
I agree, tho trivially solvable with aliases and Desktop app definitions, but still an extra step.
- Flatpaks aren’t really single-executables. You have to use to the
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.
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.
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.
That definitely used to be the case, but I haven’t had any connection issues in the last year or more.
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.
Some developers don’t want to deal with building an app for multiple versions. Sure some DEBs can work without needing to deal with that, but some don’t.
some devs don’t want to debug last arch/ubuntu broken setup.
Flatpak is a distro on its own, but with original dev support. Its like a Linux Distro replacing others.
So it adds complexity but with the potential to remove it from the OS. For example Libreoffice, Browsers, Thunderbird etc are huge and its a good approach to use official versions here.
Then what’s the point in having different distros lol we don’t have duplication for the sake of duplication there are reasons why there are different distros, philosophies and packaging method. I see this mistake from many usually newer Linux users, there are different distros because there is a point in packaging the OS differently.
Flatpak for example completely abandons makig apps use patched system libraries. Or having different packages for different init systems. Or , god forbid, supporting BSDs
Yes, security
How? Security is one of its selling points.
libxyz has security vulnerability:
Your distro updates libxyz. Fixed and every piece of software gets the fix for free.
Every single flatpak that uses libxyz has to update to include the fix. Let’s hope all those package maintainers are on the their game.
That’s not how Flatpak works.
Flatpak has runtimes, which is where most shared libraries are. There’s a common base one called Freedesktop, a GNOME runtime, a KDE runtime , an Elementary runtime, and more. (The GNOME and KDE ones are built on top and inherit from the Freedesktop base runtime.)
https://docs.flatpak.org/en/latest/available-runtimes.html
Additionally, at least for Flathub, they have shared modules for commonly used libraries that aren’t in runtimes. (Many are related to games or legacy support like GTK2.)
https://github.com/flathub/shared-modules
Lastly, some distributions are building their own runtimes and apps on top, so the packages they build are available as flatpaks as well. This is the case for Fedora, Elementary, Endless, and others.
That’s not how Flatpak works.
That’s exactly how flatpaks work if the library you need is not in the runtime. Which is very often the case.
I know because I made one for my personal use and the package was not available elsewhere.
Additionally, at least for Flathub, they have shared modules for commonly used libraries that aren’t in runtimes. (Many are related to games or legacy support like GTK2.)
So we’re just reinventing the wheel with more bloat? Brilliant.
Yeah, that’s a big, weird if though. Most modern apps can rely on the runtimes for their dependencies and not have to ship their own custom dependencies.
It’s different from something like AppImage, where everything is bundled (or Snap, where a lot more needs to be bundled than a typical Flatpak, but not as much as with an AppImage).
Additionally, there’s always some level of sandboxing in Flatpaks (and Snap packages) and none at all for RPMs, Debs, or AppImages.
Also, Flatpak dedupicates common files shared across flatpak apps and runtimes, so there isn’t “bloat” like what you’re talking about.
https://blogs.gnome.org/wjjt/2021/11/24/on-flatpak-disk-usage-and-deduplication/
It sells security through isolation, but packages are not cryptographically verified after download. This is done in package managers like apt, but not flatpak
- 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.
complicate packaging, XML sucks (are there good editors or something?), I heard that the Flatpak builder is better for certain languages.
What has XML got to do with it? Flatpak manifests are either JSON (not great but OK) or YAML, which is great.
YAML, which is great
countries: - fi - se - no - dk => { "countries": ["fi", "se", false, "dk"] }YAML, which is great.
Well, someone had to finally believe that.
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.
I wish there was an option for an android style system where, when an application wants to use a permission for the first time, you get a pop up asking you to grant that permission.
Or, more generally, just some way to ensure that (a) a flatpak isn’t granted the permissions it wants automatically and (b) I can then manually grant those permissions as conveniently as possible
Are you aware of flatseal?
If you are, is there an issue with using it for you?
Flatseal is good, just not official.
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
