Hacker News Reader

Comment by loudtieblahblah | Hacker News Reader

imho - after the insertion of flatpak, appimage, snaps, and in some cases dockerimages...

i fail to see what problems we've solved. it seems to me we've just duplicated the problems of competing packaging standards across distros, except now they all take up more resources and disk space than before.

it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging.

View on HN

> it seems to me we've just duplicated the problems of competing packaging standards across distros, except now they all take up more resources and disk space than before.

Speaking about AppImage only:

They've solved the problem of requiring third party middlemen to include our package in a repo, using updated versions on older "unmaintained" distros, using old versions on the latest distro, using two different versions at once, and being able to store applications on different media.

> it may have made a couple of devs lives easier, but the average linux desktop now is messier than a Windows XP SP1 desktop. We have apps from official repos, downloaded DEBS and/or RPMs, flatpak apps, appimages that dont' integrate into menus, snaps (if you're locked into Ubuntu), maybe a docker image or two. Nevermind half these apps are probably Electron based regardless of their crappy packaging

Unfortunately this seems to be the best that can be done with the Linux Desktop community's extremely fragmentary and complexity-worshiping nature. There is no agreement on what constitutes the base "Linux Desktop" platform, and very little ABI back and forward compatibility.

> imho - after the insertion of flatpak, appimage, snaps, and in some cases dockerimages... > i fail to see what problems we've solved.

Any of those can be installed on most big distros, so you only need to release one for your app. Though I would use only docker for services and only flatpak or appimage for apps. Snap is proprietary; only Canonical runs a server.

Flatpak apps are also faster to start (at least in my experience, Snaps always take multiple seconds while Flatpaks usually start instantly)

yes, it solves problems for devs at end-user expense.

5-7 years ago, i could "apt upgrade" and upgrade, nearly, my entire box.

Now i have to manually upgrade DEBs, have separate systems or upgrade/management options for AppImages, Flatpaks, Snaps, docker images.

it's a mess and it makes keeping up with security patches an absolute nightmare.

Now, if you're lucky, apps do all their individual checking if an upgrade needs to be done and you do apps one at a time, piece meal, which requires a lot more time from end users.

I now spend more time managing my machine than using it.

so yay for devs saving some time on their end ,or something.

Just switch to Arch. I know it's become a meme distro, but the AUR really is amazing. I don't have AppImages, snaps, Flatpak, or anything of the sort on any of my systems. Everything is either installed from the official repositories, or automatically built as proper packages and installed the same way.

This is exactly what I did. Snap's are basically docker gone wrong. Snaps are sandboxed, blocking access to NFS shares which I use extensively. Under Ubuntu, Chromium is usually broke (apt-get installs a deb that then installs a snap); You have to install either a debian .deb or use a PPA to make it work. I love that Ubuntu is directly including ZFS, but the distro has gotten so bad that I don't want to go near it anymore. Arch works, and works well.

> it may have made a couple of devs lives easier,

how do you propose to have software depending on, say, Qt 5.15 for hidpi bugfixes and ffmpeg 4.3 for codec support, available for users stuck on ubuntu 16.04 or debian jessie ?

Static linking doesn't require a container format.

Static linking does not reasonably work for graphical apps on linux due to libGL, since you'd have to choose one libgl implementation at link time and basically embed the GPU driver in your program.

Reply on news.ycombinator.com