8 ms·

How are snaps universal and smoother than Flatpak? For once, they're only really supported by Ubuntu and not its derivatives.

loudtieblahblah 6y ago
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.
- scaladev 6y ago
  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.
  - mbushey 6y ago
    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.
- akvadrako 6y ago
  > 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.
  - jlelse 6y ago
    Flatpak apps are also faster to start (at least in my experience, Snaps always take multiple seconds while Flatpaks usually start instantly)
  - loudtieblahblah 6y ago
    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.
- AnIdiotOnTheNet 6y ago
  > 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.
- jcelerier 6y ago
  > 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 ?
  - zamadatix 6y ago
    Static linking doesn't require a container format.
    - jcelerier 6y ago
      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.
teekert 6y ago
Snaps work under Arch and under Fedora, and many more. They are only actively blocked for philosophical reasons on Mint (an Ubuntu derivative).
- curt15 6y ago
  The sandboxing is virtually nonexistent unless the distro uses apparmor.
  - teekert 6y ago
    There are many technical arguments but I open app center (or whatever it's called, that big A), search, click and voila. I was a cli purist but I have become a pragmatist over the years. It just has to work.

loudtieblahblah 6y ago

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.

scaladev 6y ago
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.
- mbushey 6y ago
  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.
akvadrako 6y ago
> 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.
- jlelse 6y ago
  Flatpak apps are also faster to start (at least in my experience, Snaps always take multiple seconds while Flatpaks usually start instantly)
- loudtieblahblah 6y ago
  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.
AnIdiotOnTheNet 6y ago
> 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.
jcelerier 6y ago
> 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 ?
- zamadatix 6y ago
  Static linking doesn't require a container format.
  - jcelerier 6y ago
    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.

teekert 6y ago

Snaps work under Arch and under Fedora, and many more. They are only actively blocked for philosophical reasons on Mint (an Ubuntu derivative).

curt15 6y ago
The sandboxing is virtually nonexistent unless the distro uses apparmor.
- teekert 6y ago
  There are many technical arguments but I open app center (or whatever it's called, that big A), search, click and voila. I was a cli purist but I have become a pragmatist over the years. It just has to work.