this post was submitted on 04 Mar 2024
213 points (80.5% liked)
Linux
48190 readers
1313 users here now
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
founded 5 years ago
MODERATORS
you are viewing a single comment's thread
view the rest of the comments
view the rest of the comments
I'm a Flatpak user myself, but a lot of those arguments against AppImage are outdated or invalid. Here are my counterpoints:
GearLever solves all the problems mentioned.
There are AppImages out there that self-update , but GearLever also solves the update issue. And if you don't want to use GearLever, there are other updaters like AppImageUpdate.
This is blatantly wrong - AppImageHub exists for this very reason. There are also GUI frontends like AppImagePool which makes it easy to discover/download/install them.
That is a fair point, however, AppImage never claimed to be a sandboxing solution, and for some use-cases this can even be seen as an advantage (any Flatpak user would've at some point run into annoying sandboxing limitations - such as password manager and browser integration, or themeing woes). But there are other sandboxing options out there, such as using containers, and IMO, using a proper container is a better option for sandboxing. Or even better, use a VM if you're actually running an untrusted app.
I completely disagree with making the entirety of /home as non-executable, when
$HOME/.local/bin
is recommended by the XDG standard as a place to store executables. As long as$HOME/.local/bin
is in the XDG spec, I'll continue storing my executables there. If you disagree, go argue with the XDG guys.This is a fair point but "they include all the libraries they need" is the entire point of AppImage - so mentioning this is pointless.
Then it's a good thing that they don't right? What's the point of making hypothetical arguments? Also, this is 2024, storage is cheap and dedicating space for your applications isn't really a big deal for most folks. And if storage space is really a that much of a concern, then you wouldn't be using Flatpak either - so this argument is moot and only really valid for a hypothetical / rare use-cases where storage is a premium. And again, in such a use case, that user wouldn't be using Flatpaks either.
Finally, some distros like Bazzite already have the above integrations built-in (GearLever/AppImagePool), so you don't even need to do anything special to get AppImages integrated nicely in your system, and there's nothing stopping other distros adding these packages as optional dependencies - but it's kinda moot at this point I guess since Flatpak has already won the war.
Personally, I'm pro-choice. If AppImage doesn't work for you, then don't use it, as simple as that. Stop dictating user choice. If AppImage is really as bad as you claim, then it'll die a natural death and you don't have to worry about it. What you really need to worry about is Snap, which has the backing of Canonical, and some dev houses new to the Linux ecosystem seem to think packing stuff as Snap is an acceptable solution...
While I overall do prefer Flatpak over AppImage these days, the sandboxing has indeed been giving me more trouble than I think it is worth so far.