Appimages totally suck, because many developers think they were a real packaging format and support them exclusively.
Their use case is tiny, and in 99% of cases Flatpak is just better.
I could not find a single post or article about all the problems they have, so I wrote this.
This is not about shaming open source contributors. But Appimages are obviously broken, pretty badly maintained, while organizations/companies like Balena, Nextcloud etc. don’t seem to get that.
I mean, I’m not saying they aren’t. I think the original argument is valid. I just think they’re better than the alternative, which isn’t Flatpak but self-extracting .sh files.
Yes thats true. But that talk specifically mentioned the horrible security practice of appimages, and that they dont run everywhere at all
No argument. The security aspect is something that seemingly a lot of people in this thread don’t get. The some-person-creates-a-package-I-install model works as reliably as it does without sandboxing only when that person is a well known trusted individual or group. For example the Debian maintainers team. It’s a well known group of people who are trusted due to their track record to not produce malware-ridden packages intentionally or unintentionally. That is the line of defense you got. If you remove that, you end up in download-random-shit-on-Windows land in regards of security.
What’s worse, this extends to the bundled libraries. Unlike central systems with shared libraries like Debian, bundling libraries means that the problem extends to the sources of those libraries! Package A and package B both include libjpeg-v1, it’s got a remote exploit gaping hole. Developer A has time to follow CVEs and updates theirs. Developer B doesn’t or has moved on. The system gets a patched libjpeg-v1, app A gets it, assuming it can be auto-updated. App B remains open for exploitation.
Therefore given all that, sandboxing is a requirement for safely using packages from random people. Even when the packages from those come from a central source like Flathub or Snap Store. Sandboxing is why this model works without major security incidents on Android.
Anyway, won’t be the first bad practice advocated by some in this community.
This matches very well with this talk of an OpenSuse microOS maintainer doing a followup on his thoughts of Appimages, Snaps and Flatpak.
Spoiler: Flatpaks are the only ones that work.
Here is an alternative Piped link(s):
this talk
Piped is a privacy-respecting open-source alternative frontend to YouTube.
I’m open-source; check me out at GitHub.
Snaps work too if you use Ubuntu and trust Canonical, as he mentions. I’m a bit annoyed at Flatpak for being inferior to Snap in that it can’t be used to install system components. Snap allows for a completely snappy system, without the need to build the base OS one way and the user apps another. The OS from-traditional-packages, user-apps-from-Flatpaks model is an unfortunate compromise but I guess we’re gonna get to live with it long term. It’s better than the status quo.
BTW I completely disagree with him that everyone should be using rolling releases. As a software developer, user, and unpaid IT support, this is a mind boggling position.
Yesno. Snaps are not sandboxed at all, which is a nogo for normal application distribution.
So while I think it also sounds nice to pack an OS into different immutable parts, if the entire system is flawed, its not worth it.
Flatpak is good for app distribution, the rest is job of the OS.
not rolling release but normal stable release, not some random LTS. Not every software is like Firefox ESR (which honestly is not needed as Firefox doesnt break), but Debian etc. often just randomly dont ship updates.
Fedora is a bit too rolling, but if you always stay on the older supported version, thats okay. Especially with atomic.