I went to install some software today (Gradia) which is only available via Flathub apparently, the install size is larger than my distro which feels like a bit much for a screenshot tool. What’s the deal with the massive size of Flatpaks and is it really worth all the extra space? 4GB per application?
Flatpak does deduplication, if two apps include the same dependencies then that’s only stored once.
What this means is that the more you lean into flatpaks, the smaller the individual app footprint on your drive becomes.The main benefit as an end user is gaining access to software that might’ve never ended up in the distro repository either way. And not having to worry about missing dependencies is a nice bonus.
I recommend getting Flatseal to get a nice GUI for handling flatpak permissions.Thank you, yeah I noticed some apps are only Flatpak which is why I asked, I understand dependencies but that seems like a lot of extra software to lean on for a screenshot tool, thought there might be more to it. I’ll check out Flatseal if I need use them.
The size seem to be crazy large for you, yeah. Here’s my testinstallation for reference in Fedora 43 KDE:
But does that include any required deps?
Huh, interesting, here’s what the software install screen looks like in LMDE7… I have not installed any Flatpaks yet so that could be it? I’m not sure otherwise. I’ve run into several other large Flatpaks since, so maybe it’s some bug idk.
Yeah, me having the dependencies from earlier flatpaks would be the difference.
For me the benefit was apps actually install and work now. In previous attempts to switch to Linux in years past, I would always go back to windows due to apps not working and dependency hell. With flatpak everything just works. I also appreciate the ability to manage permissions easily, and the application data is stored in one consistent location.
4GB per app sounds extreme though. That is not my experience at all.
Thank you, yeah that does all sound pretty good, I’m curious if the estimate is accurate now, I suppose only one way to find out.
Flatpaks ship all the dependencies of the application (i.e. the libraries that the program uses) in a single bundle, which usually accounts for much of the size.
The upside to that is that flatpaked apps are universally compatible across distros; the downside is the file size.
Another catch to flatpaks is that they run in a sandboxed environment, and each application has its own varying levels of isolation from your main system. This can lead to unintuitive issues like not being able to see files you save in a flatpaked browser unless you save to
~/Downloads. This sandboxing does have some security benefits, but is not generally considered robust protection from malware.Thank you, that makes sense, I think I’ll just see how it goes without it, I don’t install a ton of applications usually and the install sizes are so large for someone who’s first computer had 64k of RAM.
Have you ever tried to install a package and the install failed because of a missing dependency? You spend time chasing down that specific dependency, you find it and try to install it, but then the dependency itself fails to install because of a further missing dependency of its own. This is two steps into “dependency hell”.
This doesn’t occur with a Flatpak install because all the dependencies are baked into the Flakpak.
I am going to consider myself lucky as I have never run into that in 15 years.
This doesn’t occur with a Flatpak install because all the dependencies are baked into the Flakpak.
The dependencies aren’t “baked into” the Flatpaks in the sense that they included in their archive, like e.g. AppImage, but Flatpak manages to install several different versions of depencies.
Thank you, that hasn’t happened to me in some time, but I understand how Flatpaks avoid that now.
Primarily, it is to the app developer’s advantage to use flatpak for distribution, as that lets you concentrate on getting one consistent version of your software out on an environment that is the same for everyone - the flatpak sandbox. If you use traditional methods, one of two things have to happen - you need to maintain multiple versions of your deb and/or rpm package, to cater to Ubuntu, Debian, Fedora, SuSE, and Enterprise Linux users. That didn’t include Arch, Gentoo, Slackware, or from scratch source compilers. Which gets to part 2, hoping each community will make and keep up to date the source code builds themselves, because: Having source code and build environment settings for different distros to build from source and have it work in each distro, which may require or have available only certain versions of any libs you call on, that might not work with your code. This is “dependency hell”, and it only gets worse the more linuxes you want to support directly.
It’s a lot easier to just ship the flatpak with the dependencies in them or linked in their flatpak libs as well. One set of dependencies and one build that runs on everything.
Thank you! Ah yeah I never thought of how difficult software distribution is for Linux, where typically users were compiling their own binaries from sources, but of course that’s not so user friendly.
Whoa! That’s a gigantic Flatpak. I like FP because I can centrally managing app permissions with flatseal. I also like it when installing apps that have x86 libraries that I didn’t want to install on my x64 only box. Not perfect, but it’s nice also installing apps that only live in userspace and didn’t touch my core os files. I like to to keep system and userspace separate. It’s also nice to uninstall and remove everything associated. Pro-tip: try to only install flatpaks from original app devs if you can.
I know right? I was surprised because I thought Linux was more concerned about efficiency but there’s all sorts of options for everyone I suppose.
deleted by creator
