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.
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.
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.
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 ?
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
You could try deduplication on the flatpak folder. With any luck that consolidates what can be shared between the dependencies.
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.
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.
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.)
Linux
From Wikipedia, the free encyclopedia
Linux is a family of open source Unix-like operating systems based on the Linux kernel, an operating system kernel first released on September 17, 1991 by Linus Torvalds. Linux is typically packaged in a Linux distribution (or distro for short).
Distributions include the Linux kernel and supporting system software and libraries, many of which are provided by the GNU Project. Many Linux distributions use the word "Linux" in their name, but the Free Software Foundation uses the name GNU/Linux to emphasize the importance of GNU software, causing some controversy.
Rules
- Posts must be relevant to operating systems running the Linux kernel. GNU/Linux or otherwise.
- No misinformation
- No NSFW content
- No hate speech, bigotry, etc
Related Communities
Community icon by Alpár-Etele Méder, licensed under CC BY 3.0