Hacker News new | ask | show | jobs
by jeroenhd 1547 days ago
DEB is working fine for most users, for the corporate/Fedora users RPM also is good enough. Flatpak works great for GUI applications as well, it integrates nicely with most "app store" interfaces on Linux.

DEB vs RPM is an ancient debate, each comes with its pros and cons. Flatpak and Snap try to solve a different problem (sandboxing + dependency hell vs stable system-wide dependencies).

MacOS has PKG, but most software I've seen actually comes through DMG images or ZIP files. Windows has MSI, which, if you use it correctly, actually elegantly solves most problems; the features that were added to allow developers to bypass the declarative installation process are what usually breaks MSI installers.

But then modern Windows now features has packages installed through .appx, .appxbundle, .msix, .msixbundle, and plain old .exe. Windows Mobile (based on Windows CE) had .cab; Windows Phone 8/8.1 (based on Windows 8) had .xap; Windows 10 Mobile had .appx. Now Windows 11 also supports .apk files from Android!

In the end, the package method doesn't matter. Users don't care where the package comes from, they just want to install the application and run it. Deb, Flatpak, RPM and Snap all work fine from tools like Discover or GNOME Software; it really doesn't matter to normal users what kind of packaging system they use.

1 comments

Everybody I know strongly dislikes snap because of the machinery it brings and how untidy it is. Also it's forced upon the users.

AppImage and Flatpak are fine, and AppImage is the first choice amongst this "everything included" bundle formats.

However, Ubuntu is forcing snaps as a power move. Both the software, and the treatment from Canonical is off-putting a lot of enthusiasts right now.

The devil on my shoulder wonders if Canonical's pushing of Snap, rather than adoption of FlatPak, is another instance of the Not-Invented-Here organizational dysfunction that led it to slog on with its own Bazaar SCM rather than switch to Git (or Mercurial).
Bazaar, Upstart, Mir, Snap. Canonical really likes to do their own thing and usually it fails in the end. Competing implementations are great but competing standards only make more work for everyone else.
The worst part is that they sabotage their good software by insisting on these bad solutions. LXD and MicroK8s for example, are distributed only as snaps - not even tarballs. LXD is actually a great software. But it's available as native package only on a few less popular distributions, and that has hurt its adoption. I wanted to try MicroK8s, but completely abandoned it due to the snap requirement.
Snap server is closed-source (unless anything has changed?), so I believe this is more likely to be a nefarious intent to create a dependency on their service (which Canonical can monetize later) than a mere dysfunction