It’s not the ideal solution, but it is approachable and understandable for technically averse users. I think it’s good to have, but I only used it for one package, and that was as a separate Steam install that included an old version of glibc that was used in a particular game’s (Squad) anti-cheat until it updated it.
It’s good for a stable platform, but each package needs it’s own set of everything, which can be good (like the Steam example above having its own version of glibc instead of using the shared version on my system), it’s a lot of bloat. I’m not using it unless I require it for some reason, but again it’s nice to have around.
I don’t think Flatpak is going to be compatible with Steam anyway in the long-term because layering container solutions doesn’t generally work very well, and Steam is going to want to use its own solution for better control over the libraries each game uses. Earlier versions used library redirection and some still do.
Wastes RAM and disk space (compared to package-manager installed applications) by storing more libraries on disk and loading them into RAM rather than just using the libraries already installed on the distro. It’s probably better than Snap and Appimage though.
That is definitely a sacrifice being made here I agree with you. It gives developers more control over exactly how their app runs, but it does mean less storage efficiency.
Is it even a problem for a desktop in 2024? Never had an issue with RAM or diskspace. And even for those that have, they can just not use flatpak until they upgrade, no reason to kill it.
I assume the “kill it” comment was a little tongue-in-cheek. On small SBCs, like a Pi, or old hardware, it could be a problem. I’ve seen people with flatpaks taking up 30GB of space, which is significant. I’m not sure how much RAM it wastes. I assume running 6 different applications that have loaded 6 different versions of Qt libraries would also use significantly more RAM than just loading the system’s shared Qt libraries once.
I don’t see a problem with Flatpak in this. It does what it’s supposed to do. You find not using it better? That’s great, that option is the default in all of the distributives.
Yeah, I agree. I do use Flatpaks, Snaps, and Appimages sometimes if I can’t find a suitable deb repo/package. Flatpak is the best out of the three because they do try to avoid too much duplication through runtimes. I also use Docker quite a bit, which has similar issues (and benefits).
I love what Flatpak is doing for Linux desktop. Let it grow!
It’s not the ideal solution, but it is approachable and understandable for technically averse users. I think it’s good to have, but I only used it for one package, and that was as a separate Steam install that included an old version of glibc that was used in a particular game’s (Squad) anti-cheat until it updated it.
It’s good for a stable platform, but each package needs it’s own set of everything, which can be good (like the Steam example above having its own version of glibc instead of using the shared version on my system), it’s a lot of bloat. I’m not using it unless I require it for some reason, but again it’s nice to have around.
I don’t think Flatpak is going to be compatible with Steam anyway in the long-term because layering container solutions doesn’t generally work very well, and Steam is going to want to use its own solution for better control over the libraries each game uses. Earlier versions used library redirection and some still do.
Kill it.
But y tho?
There’s a big chunk of the Linux community that will always want to gatekeep it and push out anything that makes it easier for the layman to use
Wastes RAM and disk space (compared to package-manager installed applications) by storing more libraries on disk and loading them into RAM rather than just using the libraries already installed on the distro. It’s probably better than Snap and Appimage though.
That is definitely a sacrifice being made here I agree with you. It gives developers more control over exactly how their app runs, but it does mean less storage efficiency.
Is it even a problem for a desktop in 2024? Never had an issue with RAM or diskspace. And even for those that have, they can just not use flatpak until they upgrade, no reason to kill it.
I assume the “kill it” comment was a little tongue-in-cheek. On small SBCs, like a Pi, or old hardware, it could be a problem. I’ve seen people with flatpaks taking up 30GB of space, which is significant. I’m not sure how much RAM it wastes. I assume running 6 different applications that have loaded 6 different versions of Qt libraries would also use significantly more RAM than just loading the system’s shared Qt libraries once.
I don’t see a problem with Flatpak in this. It does what it’s supposed to do. You find not using it better? That’s great, that option is the default in all of the distributives.
Yeah, I agree. I do use Flatpaks, Snaps, and Appimages sometimes if I can’t find a suitable deb repo/package. Flatpak is the best out of the three because they do try to avoid too much duplication through runtimes. I also use Docker quite a bit, which has similar issues (and benefits).
What can flatpaks do that others -snap, appimage- can’t? At least they don’t have weird naming of program (com.sth.sth.fk)…
Different goals and different designs. Why are there so many Linux distro?
Snap is proprietary. Appimage does not include distribution and updates. It also doesn’t attempt sandboxing of any kind.
On the other hand, I find appimage very convenient to use.
deleted by creator