logoalt Hacker News

Tooster • today at 10:42 AM • 0 replies • view on HN

AppImage works in the same way downloading a binary from the web and running it with `./program` works. It is dumb simple, but it has really poor integration with the system. I've been using AppImages for several years but the manual churn got to tedious — auto updates, system integration, background services, keeping it tidy. I contributed AppImage packaging workflow to some apps — mechanism itself is messy, supporting other systems is a pain (e.g. core libs between major ubuntu versions can pose a big problem, python apps as well),documentation is poor; even original proponents now advise against this format (citation needed). For some of the AppImages I still have to use (when authors don't distribute anything else), I use GearLever, but it itself is... a flatpak app (and we tried to port it to snap and it was dumb). Bottom line — they are ok-ish but you trade one kind of convenience for other and there is a lot more work on author's side. And a lot of the things about them are messy.

I did full circle of deb -> snap -> flatpak -> app image -> flatpak -> snap + deb + nix nowadays. Flatpak was overwhelming, required flatseal and often theming broke. FS sandboxing and permissions UX was annoying. Ultimately debs are the most convenient ones for now. Snaps get there but the cold boot time and occasional errors annoy me AF (ghostty as snap on fresh boot/after a while opens in several seconds vs miliseconds for deb, which becomes annoying day to day). I wish we had something like perms and portability of .apk + speed of .deb + compression and auto-updates/channels like snap + ease of distribution like AppImage + something from flatpak.

Ultimately on linux(es) I have a everlasting problem of "where shit/problems comes from" and tracking what comes from what and is where.