For context: I habe a PC with an 8gb SSD and I somehow need to get an app on there that only has a flatpak release
Flatpaks implement deduping, so they actually don’t take that much space when installed.
I habe a PC with an 8gb SSD
I think I found your real problem.
There’s very good reasons that app developers focus on flatpaks, which mostly revolves around how incredibly terrible the experience is creating native packages for each distro and each release version of those various distros.
Flatpak used to be problematic, but even a loud hater of Flatpak, Richard Brown of openSUSE, now lauds Flatpak as an excellent solution after his criticisms were addressed.
and 8gb ssd? at that size it’s surely a removable 2242 ngff drive, it’s like 10$ for a 64gb one. you’re quite literally throttling your systems read/write speed, cause ssds want at least 20% free to manipulate files.
8GB SSD
There’s your problem. The last time 8GB was plenty was in 1998.
Yup. Those 64 GB SSDs many retailers put into cheap laptops already come dangerously close to violating the Geneva Convention. 8GB is just stupid, even for a Linux system.
Are they booting of an SD card? Mabey is a Pi or WiFi router?
“maybe a software being excessively bloated isn’t a good thing”
“just buy more storage bro”
B*tch. i live in a third world country, with limited internet and data plan, and also is still a student. If i can just buy more storage and better hardware i will.
Flatpak seems to be the best choice for consistency and to have it working straight out of the box. I think Linux currently needs this because we’re getting a lot less tech-savvy Linux users nowadays. Don’t get me wrong; package managers should still be used, but how are we going to get people to change if they run into package conflicts or accidentally uninstall a wrong package?
And universal compatability. One repo, for all distros. That’s a big plus too!
Until it doesn’t work. There’s a lot of subtlety, and at some point you’ll have to match what the OS provide. Even containers are not “run absolutely anywhere” but “run mostly anywhere”.
That doesn’t change the point, of course; software that are dependent on the actual kernel/low level library to provide something will be hard to get working in unexpected situations anyway, but the “silver bullet” argument irks me.
Everything is flawed, there is no silver bullet. But again, it’s still a massive improvement over what we had previously.
It’s useful, but it isn’t the best option for everyone, so other options should be available.
Why would you want the app devs to make that? The whole problem with distro-specific packages is having to package for multiple formats and it’s a painstaking process that really isn’t worth any amount of time investment at all. If you’re an app developer, you’d much rather just make a universal package and hope that some distro package maintainer packages your app for their distro. That’s just basic common sense…
Because Flatpaks can’t share libraries or anything. It creates a lot of bloat that doesn’t need to be there. It’s great for users that want to make sure the app will always work, but it isn’t great for being efficient.
This is just a straight up lie. Flatpaks do share libraries, both as runtimes (as seen even in the screenshot here) and through deduplication between different runtimes and runtime versions. There’s usually very little bloat, if any, especially if you use Flatpaks a lot, which you probably should, given the huge number of advantages especially with proprietary apps.
and through deduplication between different runtimes and runtime versions. There’s usually very little bloat, if any, especially if you use Flatpaks a lot,
~20 different GUI applications, flatpak ended up using 14 GiB of storage while the appimage equivalent used 3.2 GIB.
And note I was not able to find flatpaks for ghostty, goverlay, kdeconnect and a few other apps, meaning the actual bloat of flatpak is even higher.
Edit: And this is even worse if you are an nvidia user, flatpak will download the entire nvidia driver as well.
AppImage isn’t a good comparison for a lot of different reasons and I think enough people have summarised that on the internet by now.
AppImage isn’t a good comparison for a lot of different reasons
Alright what does flatpak offer in this case?
-
Has performance issues 1
-
Has security issues even 1 2 3 and not to mention the whole bunch of flatpaks that use EOL runtimes which are even worse, not only for security, but also because that single flatpak ends up pulling an entire runtime for itself which makes even more bloated.
-
And is insanely bloated as you saw already.
I think enough people have summarised that on the internet by now.
Such as? but I likely know already what is going to be said, hopefully is none of the following:
-
“Depends on libfuse2” (not true since 2022 with the static appimage runtime, this also allows making appimages that work on musl systems, which several like ghostty, goverlay, Steam, gimp, cromite, citron already do)
-
“You need to build on an old distro and it is hard”, once again not true anymore since you can now bundle the glibc as well (and it is needed for appimages to work on musl systems).
-
“No wayland”, this is only true if you use linuxdeploy-qt to make the AppImage, the project has been abandoned already for several years and the only project I know that still uses it is qbittorrent-enhanced.
EDIT: And also hopefully you are aware that a lot of flatpaks are literary an AppImage shipped in a flatpak runtime, like:
-
https://github.com/flathub/dev.vencord.Vesktop/blob/master/dev.vencord.Vesktop.yml#L34-L46
-
https://github.com/flathub/com.ultimaker.cura/blob/master/com.ultimaker.cura.yml#L24-L44
-
https://github.com/flathub/xyz.armcord.ArmCord/blob/master/xyz.armcord.ArmCord.yml#L40-L43
-
https://github.com/flathub/chat.simplex.simplex/blob/master/chat.simplex.simplex.yml#L22-L31
-
https://github.com/flathub/menu.kando.Kando/blob/master/menu.kando.Kando.yml#L33-L40
So yeah AppImage isn’t ideal, lets ship it in a container anyway 😁
-
you probably have thrice that in your yay/paru or emerge cache
i know what you are.
Oh lmao, I decided to look into this. https://github.com/flathub/com.ktechpit.torrhunt/blob/master/com.ktechpit.torrhunt.yaml
Looks like it just downloads the .snap package (directly from Canonical’s website) and extracts it. It’s also, of course, completely closed source so who knows what it’s doing when it’s running.
No source to compile it yourself?
Personally I do like the ideas behind Snap/Flatpak. I think the sandboxing is a huge deal and will improve security going forward.
In a world where space is usually the cheapest and most available hardware on a PC, I tend to agree. That being said, it’s the kind of solution that comes from engineers who put the onus on the hardware to make up for their shitty software. Engineers like me.
Yeah. Someone has to put in the work for packaging an application if you want it as a .deb/.rpm etc. package and deal with any bugs that might come up, and it’s not going to be me (speaking as a user, not a developer).
That said, I also painted myself into a corner when it comes to harddrive space. LUKS can be complicated, man …
Cut the crap. Flatpak uses hardlink from repo where file names are jash of the file itself. The chance of duplication is exactly same as that of duplicate files of same name in same directory.
Flatpak repo grows because we trade uncertainty over abi stability with installing all needed versions of libraries. For abi incompatible builds you could already do that in many distros (versioned soname) but to a lesser extent.
Also I usually do not install nvidia GL with flatpaks that I won’t run on nvidia on hybrid gpu laptops anyway for energy reasons.
You hate people who spend hundreds of ours of their free time developing software, who then release that software for free, under no obligation to you or anyone else, and your reasoning is because they provide it in a packaging solution you don’t find ideal?
Maybe fuck off and write your own software.
No, they hate flatpak, one of the many option to distribute software, which is not the only one even if you consider the “must run on many distro” restriction (which isn’t 100% true, kinda like the Java write once run anywhere). There are other options, some more involved, some simpler, to do so.
They didn’t say they hate devs, that’s on you, grabbing a febble occasion to tell someone that voiced his opinion to “fuck off”.
I hate people who only release on flatpak
You could just read what OP said
You could improve your reading comprehension.
Then they should say they hate flatpak, or they are frustrated/disappointed when something they are interested in is only on flatpak.
Instead of doing that, they said they hate people who only use flatpak. Words matter, and that kind of entitlement needs to be shut down. The devs don’t owe them anything and they certainly don’t deserve hatred for their packaging solution. There are many constructive ways OP could resolve the issue. Open a feature request issue on the bug tracker, build it locally, send an email, offer to maintain another packaging method, etc.
Yeah flatpak won’t work on my Nokia 3310 either, what a shit software…
Edit: if you upvoted this comment, your kneecaps pop when you pick up things from the ground
I liked Snaps and Flatpaks fine when I first started using Linux, and the distro I was on treated them the same as software in the repo, but I eventually started to avoid them because of the space they take up, and because I got tired of constantly having to mess around with permissions to try to get things working. Now, if something isn’t available in rpm, I use AppImage or a tarball, or compile it myself.
- rpm: signed payload and manifest with signatures in bill of materials that integrates and coordinates with system db and allows enterprise content review and validation at every step and/or easy back-out.
- flatpack/app image - none of these.
Anyone interested in build, security, deployment, should have issue with that. But look at its corp champions and discover their motive.
Very true! Good points.
btrfs compression and dedupe. Saves a lot of space
