Hacker News new | past | comments | ask | show | jobs | submit login

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.




Why 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.


Because 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.


Flatpak also doesn't need daemons beyond what the app is using.


Yet 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.


flatpak > appimage for security and updates.


Well you can statically link stuff in a flatpak… a distribution package however gets automatically rebuilt when a dependency changes, if it's statically linked.


sorry, is this an argument that appimage has advantages over flatpak for security and updates? could u elaborate?


No I'm saying that flatpack can be as bad as appimage because nobody checks.




Consider applying for YC's W25 batch! Applications are open till Nov 12.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: