3 ms·
Given the choice I prefer native package -> AUR package -> AppImage -> Flatpack, in that order. (snap, you'll notice, is absent) Arch is pretty good at making
by zeta0134 4y ago
Given the choice I prefer native package -> AUR package -> AppImage -> Flatpack, in that order. (snap, you'll notice, is absent)
Arch is pretty good at making the native packages work, so that's always ideal. The community is generally pretty good at competently packaging AURs, and they'll do it for slightly less free things, so that fills a lot of gaps. AppImages and Flatpaks are great when they work, but opaque and difficult to diagnose when they don't :/ And snap is just... unpleasant. It's insistence to auto update separately from my package manager has really turned me off of it's whole ecosystem. No thanks.
- modzu 4y agoflatpak > appimage for security and updates.
- bombolo 4y agoWell you can statically link stuff in a flatpak… a distribution package however gets automatically rebuilt when a dependency changes, if it's statically linked.
- 0cf8612b2e1e 4y agoWhy AppImage over Flatpack? I like the Flatpack ability to easily restrict network access to binaries. Probably possibly in all of the packaging formats, but limiting permissions feels like a functional piece of Flatpack.
- bayindirh 4y agoBecause AppImages need no daemons and plumbing. They are self contained binaries which contain everything it needs to run. Running a big infra to run a single binary once in a while feels like a burden to some of us.
- viraptor 4y agoFlatpak also doesn't need daemons beyond what the app is using.
- bayindirh 4y agoYet you need to install flatpak package and its dependencies to run flatpak applications. Not to mention the flatpak package contains a four ".service." files, too. They might not be triggered and launched all the time, but this mode of operation is different from .appimage files, which are just ordinary binary files you directly run.