I have 91 flatpaks, and it is my primary way of getting apps. But the (not very shared) dependencies have been bothering me lately.
I was primarily drawn in because Gnome Software has a cool UI and because I wanted the magic of one-click installs. I heard a lot of things about Flatpak and gave it a try.
I have a relatively small 72GB BTRFS root partition with zstd:1 (lowest) enabled. I think disk compression helps with the Flatpak dependency mess, as I only have 60% disk usage currently.
Idk how much extra RAM my flatpaks use, but I don’t want 4 versions of the same dependency taking up space in my RAM. Thought about enabling zram to compensate for this. As different versions of the same library in RAM are easy to compress.
I don’t think this compression mentality I instinctively adopted is healthy. Make stuff reliable in expense of storage/ram -> compress storage/ram in expense of proc. power
Another thing is slow Flatpak downloads. I have a gigabit connection, and Arch mirrors generally work around 30MB/s with WiFi. Flatpak, on the other hand, hits at max. 5MB/s with its “CDN”
Overall, even though it’s kind of ugly, I absolutely love the “don’t think about it” mentality of flatpaks. It just works most of the time. I simply use the system package manager for programs that heavily interact with the system (like IDEs, management stuff, and so on)
I am interested in hearing your opinions.
You must log in or # to comment.
If you have redundant runtimes then you have to push app developers to update their runtime. This problem will not go away by switching to native packages unless native packages and flatpak versions are not in sync.
This is why I’ve never liked the idea of flatpak, it really seems like the Windows way of doing things. It honestly still kind of surprises me that Linux people really wanted to download random binaries from non-trusted distributors that contain a copy of every library that software needs to run. wedontdothathere.jpg
Many modern programming languages like Rust and Go and Zig compile statically anyway, so don’t use any libraries. The whole “my distro supplies my libraries” model has been steadily losing relevance for years now. Flatpaks are just one more example of this.
Exactly what I’m talking about. It reminds me of the time microsoft introduced memory compression to compensate for every application bringing it’s own DLLs
But I still think flatpak is superior to windows way of doing things because it actually has dependency management. I kinda like the idea of having multiple versions of the same library but I wish they did not come in big bundles (runtimes), but instead, came in small 1-2MB pieces.
download random binaries from non-trusted distributors that contain a copy of every library that software needs to run This is overexaggeration. Flatpak, unlike places windows users get software from, is moderated, and flatpak (although chunky) has shared dependencies
Fedora Flatpaks are better in this regard. They are built entirely from Fedora rpms. When an rpm gets updated in the Fedora repos, rebuilding the flatpak will automatically pull in that updated rpm. And with flatpak’s deduplication feature, any reused vendored dependency should be perfectly deduplicated since the input is exactly the same (the rpm).
The problem just is that the repo is small, it’s affected by Fedora’s risk-averseness (so no codecs), and people don’t like them.
I kinda get it for immutable distros, where you can’t just install dependencies. But other than that the appeal is also very lost on me.
The appeal of Flatpak is not that I prefer it to my distro package manager.
The appeal is for the application author who finds the fragmentation in Linux a problem. It is a way for them to target “Linux” and not individual distros. It is a way for app authors to control the distribution and the support surface in a way that turning over control to package managers does not allow.
Which means the appeal for me is just that I can get apps as Flatpak that I cannot find in my distro repo.
On Arch, I hardly ever use Flatpak. On other distros, I use them more. I do use the pgAdmin Flatpak everywhere though because all the distro versions I have tried are garbage.
I will never touch flatpak for this reason, I’d rather deal with compiling software myself and faffing around with dependency issues than have 8 copies of every system library sitting around.
I have tons of hard drive space and RAM. I don’t care. I’m not running my os on a old PC trying to get some more life out of it. And I’m not one of the people who wants RAM sitting empty I want it to load programs cache stuff all of that. Otherwise what is the point of you have it doing nothing.
Neigsendoig (my producer) and I started to shy away from Flatpaks. We’ve hated Snap already, and rather distro packages, third-party compiled packages and AppImages.
Doesn’t have AppImages the same problem than Flatpak regarding dependencies duplicated for each program ? If so, what is their advantage over Flatpak ?
All the dependencies are stored in the AppImage itself. You can even make an
AppImage.homefolder so you can make it portable. That’s from my research on the matter, though I use them myself.It’s worse with AppImages since they bundle everything in the same file. At least flatpaks do a little bit of deduplication with their platform packages.
You use arch and have flatpaks? I never liked them. They’ve always been a burden for me. The idea of flatpaks on Arch just never crosses my mind anymore. I actually prefer even appimages over them. At least appimages bring their own baggage with them. Once you’re done with an app, you just delete it and it’s gone. The only place I use flatpaks and don’t even mind them is on my Bazzite Steam console. Because I only installed a couple of them (Sober and protonplus) since it’s a 100% gaming console.
It also kind of takes its roots from my frustration with garbage in my home or leftover bullshit in my root
It’s not viable to ditch native packages 100% (like immutable distros). But a combination of two is pretty comfortable imo
But as I said, I am not comfortable with the way flatpak does some things
I’m pretty sure you can remove flatpaks just as easily as AppImages + you have the option to delete user data specific to that app. Kinda sounds like you get all the problems OP describes without a clean way to manage it all.
True, but you still have to visit more than one place to clean or have to run some commands to remove leftovers. There are those runtimes that you’ll have to remove when you remove flatpaks. Appimages are just one file and you’re good.
I don’t think there’s a solution for RAM dedupe, so your only solution for runtime efficiencies is (RAM) compression
That has a performance hit for every read, write and paging operation, so, lower performance than you’d expect…
But, I guess you don’t run all 91 apps at the same time, so you’re probably into decreasing returns for the few apps you do run in parallel…?
Yeah that’s not going to work for you. The tradeoff with flatpaks and snaps are increased disk usage and the mess of dependencies. If possible consider putting the flatpak folder on a bigger storage partition and mount it to your root btrfs.
Small SSD + compression is faster than HDD with no compression ¯_(ツ)_/¯
Plus I’ve been planning to upgrade my (8gb) RAM and SSD, for like, the last 5 years? Never gonna upgrade lol
As someone who worked OS security after working build/release on Unix and Linux, don’t use flatpaks. The modicum of comfort you gain in brainless installs you lose far more in validation of package contents.
And brainless installs on Linux (yum install) is about the same via synaptic/etc. You’re not missing much.
You could try deduplication on the flatpak folder. With any luck that consolidates what can be shared between the dependencies.
I think disk compression helps with the Flatpak dependency mess
No idea how flatpak or snap works here (I want my rpm:s dammit) but I bet someone started adding compression to something at some point.
You can’t deduplicate already compressed data, except in theory. If you want deduplication, do that first, then compress the data. (i.e. use ZFS. Friends don’t let friends use subpar filesystems.)
I’ve got 4.6GB of flatpaks installed on their own subvolume and compression only reduces that to 4.1GB. I would guess that it’s mostly compressed already. The same compression settings reduced my root subvolume from 23GB to 8.4GB.
I’d imagine that BTRFS dedup works the same. Any other way would be stupid. Of course if the stuff is compressed by flatpak already there’s nothing either FS can do.
Everytime someone says something positive about BTRFS I’m compelled to verify whether RAID6 is usable.
The RAID 5 and RAID 6 modes of Btrfs are fatally flawed, and should not be used for “anything but testing with throw-away data.”
Alas, no. The Arch wiki still contains the same quote, and friends don’t let friends store data without parity.
So in the end, the best BTRFS can do right now is running RAID10 for a storage efficiency of 50%. Running dedup on that feels a bit wasteful…
(Sidenote: actually, ZFS runs dedup after per block compression, so it can only dedup blocks that are identical. Still works though, unlike when people do user level .tar.gz-style compression. The it’s game over.)
And even then, zfs dedup is a WHOLE can of worms.
Yup. Apparently got much better last year, but don’t turn it on unless you know what you ate doing.
![[Discussion] Flatpaks, ram/disk usage and compression](https://lemmy.ml/api/v3/image_proxy?url=https%3A%2F%2Flemmy.world%2Fpictrs%2Fimage%2F1154bf2d-78a5-42c7-bdde-ad9ed2d77587.png){kind=link}