11 ms·

Snap, Flatpak and AppImage, package formats compared

121 points by hydrot3k 8y ago

flaprimo 8y ago
Snaps size computation in the article is wrong according to official documentation https://docs.snapcraft.io/t/the-snap-directory/2817 https://docs.snapcraft.io/t/the-snap-directory/2817
- niemeyer 8y ago
  Yes, the size is wrong. It's looking at the unpacked size, but the snaps are never unpackaged. Here are the actual sizes for the mentioned snaps: $ snap info vlc | grep stable: stable: 3.0.4 (555) 204MB - $ snap info libreoffice | grep stable: stable: 6.1.2.1 (86) 501MB - $ snap info gimp | grep stable: stable: 2.10.6 (47) 192MB -
emilsedgh 8y ago
My biggest problem with them all is that I don't really have a problem with my apt. I understand that this situation is problematic with vendors who want to distribute their apps. But to me it feels like that the packaging situation has always been an excuse for them to drop Linux support. If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. And a lot of vendors are doing that nowadays. Sandboxing would've been nice for sure. But again, I don't have a security problem with my Linux Desktop as of right now.
- jcelerier 8y ago
  > If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. well, yes it is, because it only covers two families of distros over many. I develop a software with a fairly small niche and you wouldn't believe the weird distros on which people test it. With the AppImage, everyone is happy - and also the software can be installed without administrative permissions which is fairly useful when you want to use it in a class room without having to spend a week with the local system administrators to get the .deb deployed and just have the students download the AppImage and execute it.
  - xfer 8y ago
    It isn't really that hard to repackage it for any packaging format after extracting the deb file. I have used those distros(arch, void, now nixos) for a long time, i never had a problem with anyone providing just a deb file.
    - X6S1x6Okd1st 8y ago
      It sounds like you are exceptional
      - adrianN 8y ago
        It sounds like a software vendor that sells their product shouldn't have problems creating packages for their customers.
        jcelerier 8y ago
        yes, but a software vendor who provides FOSS on his free time certainly does not have time for this.
        syn0byte 8y ago
        Crazy novel idea; The FOSS developer could just give out the source code, maybe with some helper build scripts, and then users could just build the software on whatever platform they want. Maybe making changes to which features they need and which external dependencies they required. Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro? Nah, thats crazy talk. Lets repackage an entire OS so you can run an OS while your running your OS so you can listen to internet radio.
        zyga 8y ago
        It's not a crazy idea, just one that entirely limits the target audience to extremely technical people. Some people would like to make their software available to a wider audience.
- gregmac 8y ago
  > If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. There's also the issue of dependencies on other non-default packages. Do you ask the user to install another repository? Do you host your own repository and distribute the dependent packages in it along with yours? (Note this is much more complex than building and hosting a single .deb/.rpm) Not to mention "desktop Linux" is not a thing. Supporting Fedora, Ubuntu and opensuse, for example, are all distinct efforts with only minimal overlap in terms of effort (think not just initial dev, but ongoing maintenance and testing).
  - emilsedgh 8y ago
    As far as I know, Snap, AppImage and the rest are all statically linked. You can have static linked Deb's and RPM's as well. That's what most of the vendor-provided deb's and rpm's do.
    - faho 8y ago
      Technically, they usually aren't "statically" linked as such. They usually use dynamic linking, but then ship those dynamically linked libraries in the package. This has the advantage that the user can still replace the libraries if they want (e.g. for games this is sometimes useful to replace the sdl build with one with more options enabled), and I've heard rumblings that the support for static linking on linux isn't all that great.
    - zyga 8y ago
      Your knowledge is incorrect. Snaps don't have to be statically linked. They use a mount namespace with a predictable set of libraries that are maintained and receive security updates. In addition the application can bring additional libraries but those are on the application developer to maintain (or delegate to a hosted service like build.snapcraft.io to rebuild on security updates). Sure, you can do static linking, you just don't have to and this is not how snaps work.
      - emilsedgh 8y ago
- mjg59 8y ago
  There's a lot of corner cases that break under static linking - anything that dlopen()s stuff using a private API is an obvious one, and that includes glibc.
- jhanschoo 8y ago
  > If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. Many developers don't have the resources to go through the whole process needed to get their app into the distro repo. In that case, I'd consider these package formats better than deb and rpm.
  - michaelmrose 8y ago
    You can provide a repo hosting your software so that prospective users can add your repo. This is essentially trivial and can even be hosted for free. After your user adds your repo updates will be handled automatically with the rest of the system and installs can be done in the same software management gui as anything else.
    - SmellyGeekBoy 8y ago
      What if the user doesn't have root access? e.g. in a school setting?
      - michaelmrose 8y ago
        Schools almost exclusively use Microsoft Windows. Linux is almost exclusively used on servers, technical peoples workstations/laptops at work, and interested users personal computers. Optimizing for users you wish you had doesn't seem optimal. In the hypothetical school setting you probably want to actively prevent the user installing insecure crap in their home directory to the degree its possible to do so.
- sjellis 8y ago
  > I don't have a security problem with my Linux Desktop as of right now. Matthew Garrett (who does internal Linux desktop security at Google) gave a great talk at GUADEC about the current state of Linux desktops: https://www.youtube.com/watch?v=DUa-nnjjQcc https://www.youtube.com/watch?v=DUa-nnjjQcc TLDR: It's not good. User-level processes have free, unrestricted access to all of your data, unless you use Wayland and desktop containerization.
rainygold 8y ago
So basically AppImage is the standard we ought to be using?
_emacsomancer_ 8y ago
Snaps seem to work well where they work, but it's limited by their systemd dependency. So they're most useful on an LTS Ubuntu or Debian stable in order to get more up-to-date version (or missing) of a package. But if you're in a more esoteric environment with a different init, Snaps do you no good - which is a pity, because that's where they would actually be the most useful to me. Flatpak and AppImage aren't limited in this fashion, but have few packaged apps, and they're generally all the apps I already have access to. In practice, I've found Guix, Nix, and Docker to be most useful solutions to missing/outdated apps, though these are more complicated than Snap, Flatpak, or AppImage.
- sjellis 8y ago
  > Snaps seem to work well where they work, but it's limited by their systemd dependency. A more serious issue with snaps is that they rely on AppArmor as a security mechanism, which is not actually present on most Linux systems (only Ubuntu variants, SUSE and Solus). The snaps will still run elsewhere, but not with the same security as you might think you were getting.
  - apexalpha 8y ago
    will installing snapd not install AppArmor as well?
    - sjellis 8y ago
      > will installing snapd not install AppArmor as well? It can't, because AppArmor is a kernel-level feature that also requires some level of integration into the rest of the distribution. Red Hat/Fedora-based distributions already use SELinux in place of AppArmor, so using snap on those systems can't have full security capabilities (making SELinux and snap work together would be non-trivial, and I don't think anyone is motivated to do it). Flatpak uses other mechanisms for limiting the access that applications have, so does not rely on either AppArmor or SELinux being on the host system.
askvictor 8y ago
This is a pretty light-weight article - doesn't go into security/isolation differences, or disk usage comparison. Here's something I came across a few days ago while I was researching the differences: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others https://askubuntu.com/questions/866511/what-are-the-differen...
- gcb0 8y ago
  wait, "run without sandbox" is a pro-feature?!
  - StavrosK 8y ago
    That you have the option to, for applications that won't work without full access? Yes, definitely. I don't want my format to say "well this file manager application needs to access your filesystem so it's not available for your OS because your packaging format doesn't allow us to run unsandboxed, good luck".
    - gcb0 8y ago
      I assumed the goal of those systems was for end users with no system or programming knowledge. hability to escape sandbox will only cause pain and security holes, while serving one or two advanced users.
      - StavrosK 8y ago
        So? Just don't allow the app to escape the sandbox.
  - jhanschoo 8y ago
    Do you mean pro-feature as in it's a good feature or as in (as with the case for snaps) allowed outside of dev-mode only for paying customers of Canonical?
    - 8y ago
api 8y ago
There are three competing standards, so everyone will still use curl|bash.
- saderror256 8y ago
  the issue is though is that we have to make sure everything is safe, when passing custom install scripts through bash, in the future it could get hacked and end up running malicious commands, mainly the issue is that it just fetches and runs a script, which sometimes people blindly run these
eberkund 8y ago
I upvoted this only because of the discussion that it could spark in the HN comments, the article itself is actually very poor. It compares only disk space, memory and CPU usage and of those another user pointed out that the disk space calculation for snaps is not even correct. Furthermore these metrics are amongst the least important when discussing "next gen" package managers. I am more interested in hearing about developer tools, sand-boxing capabilities, the update mechanism, OS support, private distribution, enterprise pricing. I don't care if one packaging system uses slightly more memory or whatever because of how it handles shared libraries, and if I do care I would still be interested in hearing what the trade off for that increased memory usage is.
- niemeyer 8y ago
  Indeed the size calculation is incorrect. It's likely looking at the unpacked size, but snaps are never unpacked, which ironically is a difference missed by itself. These are the actual sizes for these snaps: $ snap info vlc | grep stable: stable: 3.0.4 (555) 204MB - $ snap info libreoffice | grep stable: stable: 6.1.2.1 (86) 501MB - $ snap info gimp | grep stable: stable: 2.10.6 (47) 192MB -
jake_the_third 8y ago
A very important aspect of snap that should have been noted in the article is the lack of user control over the a snap's updating process; Users are not allowed to control when updates are applied, leading to a windows 10-like user experience: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707 https://forum.snapcraft.io/t/disabling-automatic-refresh-for... From what I could understand, placing the update process under the control of snap app developers - rather that device owners - is deliberate design decision.
- techntoke 8y ago
  A poor one at that. I don't understand why they couldn't make the Deb packages portable to a containerized format, where all the work has already been done. They'd be much better off automating the package build process instead of creating a new format for package maintainers that doesn't align with Debian. At least Arch and Alpine has a simple and human readable PKGBUILD format that only takes 15 minutes to understand and update your own packages. They have up-to-date packages for pretty much everything, even though Debian and Ubuntu have been around longer. I'm all for containerizing a Linux distro, and think it is a great idea, but Canonical hasn't exactly proven to be the best at this. Right before Ian Murdock passed while working at Docker, he didn't have many positive things to say about Canonical and their leadership. Most reviews on Glassdoor also talk about the poor leadership there. Therefore I see no reason to use Snap at this time.
- SmellyGeekBoy 8y ago
  Indeed, Spotify (distributed via Snap on Ubuntu at least) doesn't scale properly on HiDPI screens for example, requiring a small tweak to the shortcut[1]. I know when Spotify has updated because I'll launch it and everything will be tiny again! [1]https://community.spotify.com/t5/Desktop-Linux/Linux-client-barely-usable-on-HiDPI-displays/td-p/1067272 https://community.spotify.com/t5/Desktop-Linux/Linux-client-...
- niemeyer 8y ago
  There's a long thread with in depth discussion about this: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/201 https://forum.snapcraft.io/t/disabling-automatic-refresh-for... For those that understandably won't want to go through it all, the short version is that by design snaps will force the update eventually, so that a system isn't simply left behind, but since snapd came out a few years ago we've been constantly working on multiple methods to offer control over when exactly the update takes place. These are features such as: - Fine scheduling of updates (https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/10 https://forum.snapcraft.io/t/refresh-scheduling-on-specific-...) - Disabling over metered connections (https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/8 https://forum.snapcraft.io/t/snap-refresh-over-metered-conne...) - Holding of refreshes after boot (https://forum.snapcraft.io/t/delaying-refreshes-and-registration-in-particular-for-pre-seeded-classic-images/4106/3 https://forum.snapcraft.io/t/delaying-refreshes-and-registra...) - Manual delaying of updates (can't find topic) So, the goal is actually to offer control, but we are indeed trying to prevent systems from getting out of date for good. Maybe that's a bad idea, and if it turns out to be we can change that in the future, but we've been making an honest effort to try to fix the problems of automatic updates instead of simply giving up. Once we give up, there's no going back since the dynamics around package updates will change. We have plenty of experience around these aspects with the traditional systems.
aritmo 8y ago
Half-assed article with several mistakes.
robotmay 8y ago
I really dislike AppImage when it's the only way to get an app. I find it quite annoying to get set up on my system in such a way that it behaves like a normal piece of installed software (I run a fairly basic i3 setup with dmenu for app launching). I mostly just keep an unorganised "AppImage" folder now full of random clicky items I can launch. It's like being on an early 2000s iMac. Flatpak has been good when I've used it; it works more similarly to how apt functions, and seems to need less faffing to get going on my system. Snap is almost good. I found the documentation for how to actually make snaps incredibly frustrating (hard to explain, it was like lots of little steps were missing) and I find the permissions model with them more awkward. I tried installing Gitea on my home server via snap the other day, and promptly got annoyed enough to just give up, as I wasn't that invested in it.
- techntoke 8y ago
  I use i3wm and Rofi (similar to dmenu). Pacman from Arch and apk from Alpine are so much easier at managing packages. Until they can make a containerized distro that works basically the same, then I don't see a good use case for changing, unless you want to try something out in a more isolated environment (and even then there is Docker).
  - cprecioso 8y ago
    Do you mean Ubuntu Core?
    - techntoke 8y ago
      No. I've not had much luck with Ubuntu Core and use Arch generally, Alpine for Docker, and have had better luck with other distros for embedded Linux.
- zdragnar 8y ago
  Are you using dmenu or i3-dmenu-desktop? If you're using the latter, I'm pretty sure you can create .desktop files for AppImage apps so they're added to the list: https://build.i3wm.org/docs/i3-dmenu-desktop.html#DESCRIPTION https://build.i3wm.org/docs/i3-dmenu-desktop.html#DESCRIPTIO... For myself, I've only needed to use AppImage once, and that's for a program that I only bother using from a terminal anyway; other than not showing up in dmenu out-of-the-box, I haven't had any other complaints.
elheffe80 8y ago
I couldn't make it past the third paragraph. So poorly written that it literally made me mad.
saderror256 8y ago
What Flatpak also does well wasn't mentioned, which is sandboxing applications (can snap do this as well i think), I use proprietary applications on flatpak sometimes so i can feed them the resources they only need, like discord, it does not need to see my files or my running processes for the running games feature, so i just restrict them with flatpak. Sandboxing is nice for proprietary software basically, or software that collects info or just any software that connects to a server, you can snip out useless stuff you don't need while it still hopefully functions well.
- erlehmann_ 8y ago
  http://flatkill.org/ http://flatkill.org/ claims that “The sandbox is a lie”: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it. > To make matters worse, the users are misled to believe the apps run sandboxed. For all these apps flatpak shows a reassuring "sandbox" icon when installing the app (things do not get much better even when installing in the command line - you need to know flatpak internals to understand the warnings). I have not used flatpack. Is this description accurate? Also: > Up until 0.8.7 all it took to get root on the host was to install a flatpak package that contains a suid binary (flatpaks are installed to /var/lib/flatpak on your host system). Again, could this be any easier? A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue.
  - bjoli 8y ago
    The first two are also the case with snap. No packages actually seem to use the sandbox feature.
  - Natela 8y ago
    There was already a post on this. Basically the argument about home is true but this is because 1) apps should not use filesystem access but rather portals (if they can) 2) nothing should be executable in the home folder (nobashrc, no script, etc...) If I remember well the second argument was about update not being frequent enough. So nothing fundamentally about Flatpak but more about the infrastructure (lack of updates) and the use of it (we should not allow home access and use Portals or we should disable bashrc).
cmurf 8y ago
It's not integrated in flatpak cli yet, but you can use ostree to do a rollback/downgrade. https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks
bfrog 8y ago
It honestly feels like these solutions are the wrong approach when compared to something like Nix.
- Fnoord 8y ago
  Would you mind elaborating on that?
apatheticonion 8y ago
Is this docker for regular applications?
- apexalpha 8y ago
  it's more like .exe on windows. It requires more disk space because some dependacies might be installed twice or more, but it saves both the end users, the distributors and the developers of a program an enormous amount of headache having to support dozens of different linux distro's with their own dependancies etc...
burtonator 8y ago
As a developer having these three formats is a real pain. I wish we had a standard already. The app I'm working on, Polar (https://getpolarized.io/ https://getpolarized.io/) is a cross platform document repository. The Windows and MacOS builds are pretty straight forward. But with Linux I now have Appimage, deb, rpm, snap, flatpak, and of course tar.gz (but maybe that doesn't count).
- petre 8y ago
  Just pick one. Appimage fits the bill quite nicely and does not depend on a certain distribution. It's drop and forget. No silly mounts or other "infrastructure" needed to deploy. I haven't used Flatpak but Snap is quite annoying and it was one of the reasons I switched from Ubuntu to Debian. Even if you unininstall snapd in Ubuntu 18 you are still stuck with the annoying mount points. That and the auto-updates.
- nsomaru 8y ago
  Saw a comment from you the other day on HN. Was really excited, even installed snap to try it out. For some reason the application is not automatically in my path after installation. That’s enough for me to go back to apt, and unfortunately Polarized is collateral damage. I preferred installing from a ‘repo’ which updates my software automatically, something it seems that your deb does not do.
  - hollerith 8y ago
    >the application is not automatically in my path after installation. That’s enough for me to go back to apt Wow, tough customer! I have resigned myself to the need to do the equivalent of `dpkg -L | grep /bin/` to discover where the binaries are.
  - zyga 8y ago
    It will be on the next reboot/login. Due to some bugs setting up PATH is hard (harder than other variables and much harder than it should be) so we did the best we could (require a logout/reboot)
amaccuish 8y ago
I'm not sure he included the runtimes that flatpak downloads in space usage requirements, so the results may not be accurate :/
tannhaeuser 8y ago
They're repeating the .rpm vs .deb situation again, for no-ones gain. Wake me up if they're actually collaborating on a common standard.
- CogitoCogito 8y ago
  I agree with you that there is nothing new to this sort of thing, but why does there need to be a common standard? Personally I'd prefer a few different standards with their own ideas competing instead of a single one that is just some compromise between the different ones.
  - tannhaeuser 8y ago
    "Let a thousand blossoms bloom" isn't the right approach for package management. A package manager is IMHO not the place for creativity, competition, bikeshedding, and fragmentation because that's what we have already. The focus should be on winning devs to actually use a package format, so that users can more easily install software without upstream devs needing to maintain yet another format.
    - CogitoCogito 8y ago
      We're not talking about thousands of formats...only a few formats make up the most popular formats around. I see nothing special about package managers that makes competition undesirable. I think creativity and competition are good for package managers. Besides why does an upstream dev need to maintain these new formats? They can choose to support whatever they want. Personally I don't understand why this is a big deal. Any fragmentation is the result of reasonable people disagreeing on the best approach. The plethora of different ideas is a feature of the ecosystem not a bug.
      - Riverheart 8y ago
        Because developers want to target the whole Linux desktop segment without having to reproduce the packaging process several times. Has nothing to do with whether the format is better or worse as long as it is consistent. Fortunately, gems like FPM have attempted to address this issue.
mathw 8y ago
I feel this article misses the point entirely. Flatpak runtimes - which unbundle a huge number of dependencies (such as GNOME's entire platform library set) and allow independent security updates for them - aren't even mentioned. Neither is sandboxing. I was hoping for something interesting about the technical tradeoffs between the three formats and why I might want to have Fedora support Snap in the future (or why I might not to), etc. Interesting to read the other comments and discover that Flatpak's really oriented towards desktop software only. I didn't know that.
- niemeyer 8y ago
  Yes, the article indeed is on the low end. It focuses mainly on the package sizes, and gets it very wrong as mentioned in other comments.
mitchtbaum 8y ago
I looked at these a tiny bit already and think it'd be better to package in each distro's standard channels. I'd be interested in good reading material about packaging for debian apt, ubuntu ppm, arch aur, red hat rpm, etc if anyone's got some.
- debiandev 8y ago
  https://wiki.debian.org/Packaging https://wiki.debian.org/Packaging is a good source and you can easily generate packages from other distributions from a .deb
auganov 8y ago
Had a pretty bad experience with snap. A project I wanted to try was distributed as a snap package, after fixing many download issues, finally got my package, it didn't work but that was okay, was going to make some changes anyways. Built from source just fine, but it turned out the project itself depended on snap's sandboxing heavily, so I'd have to create a snap package anyways. Unfortunately at the time (and likely still true), the dev tools didn't like anything that wasn't the latest Ubuntu (recent Debian didn't cut it). Apt purged snapd, but still had to manually delete a bunch of snapd related files (systemd units mostly).
bachir44 8y ago
I agree it is important to ensure security, we must be careful, nothing we guarantee that it can not be hacked. ___________________________________________________ https://www.minimilitia.mobi/ https://www.minimilitia.mobi/ https://www.applock.ooo/ https://www.applock.ooo/ https://www.7zip.vip/ https://www.7zip.vip/

121 points by hydrot3k 8y ago

Snaps size computation in the article is wrong according to official documentation https://docs.snapcraft.io/t/the-snap-directory/2817 https://docs.snapcraft.io/t/the-snap-directory/2817

niemeyer 8y ago
Yes, the size is wrong. It's looking at the unpacked size, but the snaps are never unpackaged. Here are the actual sizes for the mentioned snaps: $ snap info vlc | grep stable: stable: 3.0.4 (555) 204MB - $ snap info libreoffice | grep stable: stable: 6.1.2.1 (86) 501MB - $ snap info gimp | grep stable: stable: 2.10.6 (47) 192MB -

emilsedgh 8y ago

My biggest problem with them all is that I don't really have a problem with my apt. I understand that this situation is problematic with vendors who want to distribute their apps. But to me it feels like that the packaging situation has always been an excuse for them to drop Linux support. If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. And a lot of vendors are doing that nowadays. Sandboxing would've been nice for sure. But again, I don't have a security problem with my Linux Desktop as of right now.

jcelerier 8y ago
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. well, yes it is, because it only covers two families of distros over many. I develop a software with a fairly small niche and you wouldn't believe the weird distros on which people test it. With the AppImage, everyone is happy - and also the software can be installed without administrative permissions which is fairly useful when you want to use it in a class room without having to spend a week with the local system administrators to get the .deb deployed and just have the students download the AppImage and execute it.
- xfer 8y ago
  It isn't really that hard to repackage it for any packaging format after extracting the deb file. I have used those distros(arch, void, now nixos) for a long time, i never had a problem with anyone providing just a deb file.
  - X6S1x6Okd1st 8y ago
    It sounds like you are exceptional
    - adrianN 8y ago
      It sounds like a software vendor that sells their product shouldn't have problems creating packages for their customers.
      - jcelerier 8y ago
        yes, but a software vendor who provides FOSS on his free time certainly does not have time for this.
        syn0byte 8y ago
        Crazy novel idea; The FOSS developer could just give out the source code, maybe with some helper build scripts, and then users could just build the software on whatever platform they want. Maybe making changes to which features they need and which external dependencies they required. Even crazier; what if we had a standard, well supported build system that we could included with every OS and distro? Nah, thats crazy talk. Lets repackage an entire OS so you can run an OS while your running your OS so you can listen to internet radio.
        zyga 8y ago
        It's not a crazy idea, just one that entirely limits the target audience to extremely technical people. Some people would like to make their software available to a wider audience.
gregmac 8y ago
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. There's also the issue of dependencies on other non-default packages. Do you ask the user to install another repository? Do you host your own repository and distribute the dependent packages in it along with yours? (Note this is much more complex than building and hosting a single .deb/.rpm) Not to mention "desktop Linux" is not a thing. Supporting Fedora, Ubuntu and opensuse, for example, are all distinct efforts with only minimal overlap in terms of effort (think not just initial dev, but ongoing maintenance and testing).
- emilsedgh 8y ago
  As far as I know, Snap, AppImage and the rest are all statically linked. You can have static linked Deb's and RPM's as well. That's what most of the vendor-provided deb's and rpm's do.
  - faho 8y ago
    Technically, they usually aren't "statically" linked as such. They usually use dynamic linking, but then ship those dynamically linked libraries in the package. This has the advantage that the user can still replace the libraries if they want (e.g. for games this is sometimes useful to replace the sdl build with one with more options enabled), and I've heard rumblings that the support for static linking on linux isn't all that great.
  - zyga 8y ago
    Your knowledge is incorrect. Snaps don't have to be statically linked. They use a mount namespace with a predictable set of libraries that are maintained and receive security updates. In addition the application can bring additional libraries but those are on the application developer to maintain (or delegate to a hosted service like build.snapcraft.io to rebuild on security updates). Sure, you can do static linking, you just don't have to and this is not how snaps work.
    - emilsedgh 8y ago
mjg59 8y ago
There's a lot of corner cases that break under static linking - anything that dlopen()s stuff using a private API is an obvious one, and that includes glibc.
jhanschoo 8y ago
> If they consider desktop Linux supported during development, providing a couple statically linked deb and rpm files is no big deal. Many developers don't have the resources to go through the whole process needed to get their app into the distro repo. In that case, I'd consider these package formats better than deb and rpm.
- michaelmrose 8y ago
  You can provide a repo hosting your software so that prospective users can add your repo. This is essentially trivial and can even be hosted for free. After your user adds your repo updates will be handled automatically with the rest of the system and installs can be done in the same software management gui as anything else.
  - SmellyGeekBoy 8y ago
    What if the user doesn't have root access? e.g. in a school setting?
    - michaelmrose 8y ago
      Schools almost exclusively use Microsoft Windows. Linux is almost exclusively used on servers, technical peoples workstations/laptops at work, and interested users personal computers. Optimizing for users you wish you had doesn't seem optimal. In the hypothetical school setting you probably want to actively prevent the user installing insecure crap in their home directory to the degree its possible to do so.
sjellis 8y ago
> I don't have a security problem with my Linux Desktop as of right now. Matthew Garrett (who does internal Linux desktop security at Google) gave a great talk at GUADEC about the current state of Linux desktops: https://www.youtube.com/watch?v=DUa-nnjjQcc https://www.youtube.com/watch?v=DUa-nnjjQcc TLDR: It's not good. User-level processes have free, unrestricted access to all of your data, unless you use Wayland and desktop containerization.

rainygold 8y ago

So basically AppImage is the standard we ought to be using?

_emacsomancer_ 8y ago

Snaps seem to work well where they work, but it's limited by their systemd dependency. So they're most useful on an LTS Ubuntu or Debian stable in order to get more up-to-date version (or missing) of a package. But if you're in a more esoteric environment with a different init, Snaps do you no good - which is a pity, because that's where they would actually be the most useful to me. Flatpak and AppImage aren't limited in this fashion, but have few packaged apps, and they're generally all the apps I already have access to. In practice, I've found Guix, Nix, and Docker to be most useful solutions to missing/outdated apps, though these are more complicated than Snap, Flatpak, or AppImage.

sjellis 8y ago
> Snaps seem to work well where they work, but it's limited by their systemd dependency. A more serious issue with snaps is that they rely on AppArmor as a security mechanism, which is not actually present on most Linux systems (only Ubuntu variants, SUSE and Solus). The snaps will still run elsewhere, but not with the same security as you might think you were getting.
- apexalpha 8y ago
  will installing snapd not install AppArmor as well?
  - sjellis 8y ago
    > will installing snapd not install AppArmor as well? It can't, because AppArmor is a kernel-level feature that also requires some level of integration into the rest of the distribution. Red Hat/Fedora-based distributions already use SELinux in place of AppArmor, so using snap on those systems can't have full security capabilities (making SELinux and snap work together would be non-trivial, and I don't think anyone is motivated to do it). Flatpak uses other mechanisms for limiting the access that applications have, so does not rely on either AppArmor or SELinux being on the host system.

askvictor 8y ago

This is a pretty light-weight article - doesn't go into security/isolation differences, or disk usage comparison. Here's something I came across a few days ago while I was researching the differences: https://askubuntu.com/questions/866511/what-are-the-differences-between-snaps-appimage-flatpak-and-others https://askubuntu.com/questions/866511/what-are-the-differen...

gcb0 8y ago
wait, "run without sandbox" is a pro-feature?!
- StavrosK 8y ago
  That you have the option to, for applications that won't work without full access? Yes, definitely. I don't want my format to say "well this file manager application needs to access your filesystem so it's not available for your OS because your packaging format doesn't allow us to run unsandboxed, good luck".
  - gcb0 8y ago
    I assumed the goal of those systems was for end users with no system or programming knowledge. hability to escape sandbox will only cause pain and security holes, while serving one or two advanced users.
    - StavrosK 8y ago
      So? Just don't allow the app to escape the sandbox.
- jhanschoo 8y ago
  Do you mean pro-feature as in it's a good feature or as in (as with the case for snaps) allowed outside of dev-mode only for paying customers of Canonical?
  - 8y ago

api 8y ago

There are three competing standards, so everyone will still use curl|bash.

saderror256 8y ago
the issue is though is that we have to make sure everything is safe, when passing custom install scripts through bash, in the future it could get hacked and end up running malicious commands, mainly the issue is that it just fetches and runs a script, which sometimes people blindly run these

eberkund 8y ago

I upvoted this only because of the discussion that it could spark in the HN comments, the article itself is actually very poor. It compares only disk space, memory and CPU usage and of those another user pointed out that the disk space calculation for snaps is not even correct. Furthermore these metrics are amongst the least important when discussing "next gen" package managers. I am more interested in hearing about developer tools, sand-boxing capabilities, the update mechanism, OS support, private distribution, enterprise pricing. I don't care if one packaging system uses slightly more memory or whatever because of how it handles shared libraries, and if I do care I would still be interested in hearing what the trade off for that increased memory usage is.

niemeyer 8y ago
Indeed the size calculation is incorrect. It's likely looking at the unpacked size, but snaps are never unpacked, which ironically is a difference missed by itself. These are the actual sizes for these snaps: $ snap info vlc | grep stable: stable: 3.0.4 (555) 204MB - $ snap info libreoffice | grep stable: stable: 6.1.2.1 (86) 501MB - $ snap info gimp | grep stable: stable: 2.10.6 (47) 192MB -

jake_the_third 8y ago

A very important aspect of snap that should have been noted in the article is the lack of user control over the a snap's updating process; Users are not allowed to control when updates are applied, leading to a windows 10-like user experience: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707 https://forum.snapcraft.io/t/disabling-automatic-refresh-for... From what I could understand, placing the update process under the control of snap app developers - rather that device owners - is deliberate design decision.

techntoke 8y ago
A poor one at that. I don't understand why they couldn't make the Deb packages portable to a containerized format, where all the work has already been done. They'd be much better off automating the package build process instead of creating a new format for package maintainers that doesn't align with Debian. At least Arch and Alpine has a simple and human readable PKGBUILD format that only takes 15 minutes to understand and update your own packages. They have up-to-date packages for pretty much everything, even though Debian and Ubuntu have been around longer. I'm all for containerizing a Linux distro, and think it is a great idea, but Canonical hasn't exactly proven to be the best at this. Right before Ian Murdock passed while working at Docker, he didn't have many positive things to say about Canonical and their leadership. Most reviews on Glassdoor also talk about the poor leadership there. Therefore I see no reason to use Snap at this time.
SmellyGeekBoy 8y ago
Indeed, Spotify (distributed via Snap on Ubuntu at least) doesn't scale properly on HiDPI screens for example, requiring a small tweak to the shortcut[1]. I know when Spotify has updated because I'll launch it and everything will be tiny again! [1]https://community.spotify.com/t5/Desktop-Linux/Linux-client-barely-usable-on-HiDPI-displays/td-p/1067272 https://community.spotify.com/t5/Desktop-Linux/Linux-client-...
niemeyer 8y ago
There's a long thread with in depth discussion about this: https://forum.snapcraft.io/t/disabling-automatic-refresh-for-snap-from-store/707/201 https://forum.snapcraft.io/t/disabling-automatic-refresh-for... For those that understandably won't want to go through it all, the short version is that by design snaps will force the update eventually, so that a system isn't simply left behind, but since snapd came out a few years ago we've been constantly working on multiple methods to offer control over when exactly the update takes place. These are features such as: - Fine scheduling of updates (https://forum.snapcraft.io/t/refresh-scheduling-on-specific-days-of-the-month/1239/10 https://forum.snapcraft.io/t/refresh-scheduling-on-specific-...) - Disabling over metered connections (https://forum.snapcraft.io/t/snap-refresh-over-metered-connections/5001/8 https://forum.snapcraft.io/t/snap-refresh-over-metered-conne...) - Holding of refreshes after boot (https://forum.snapcraft.io/t/delaying-refreshes-and-registration-in-particular-for-pre-seeded-classic-images/4106/3 https://forum.snapcraft.io/t/delaying-refreshes-and-registra...) - Manual delaying of updates (can't find topic) So, the goal is actually to offer control, but we are indeed trying to prevent systems from getting out of date for good. Maybe that's a bad idea, and if it turns out to be we can change that in the future, but we've been making an honest effort to try to fix the problems of automatic updates instead of simply giving up. Once we give up, there's no going back since the dynamics around package updates will change. We have plenty of experience around these aspects with the traditional systems.

aritmo 8y ago

Half-assed article with several mistakes.

robotmay 8y ago

I really dislike AppImage when it's the only way to get an app. I find it quite annoying to get set up on my system in such a way that it behaves like a normal piece of installed software (I run a fairly basic i3 setup with dmenu for app launching). I mostly just keep an unorganised "AppImage" folder now full of random clicky items I can launch. It's like being on an early 2000s iMac. Flatpak has been good when I've used it; it works more similarly to how apt functions, and seems to need less faffing to get going on my system. Snap is almost good. I found the documentation for how to actually make snaps incredibly frustrating (hard to explain, it was like lots of little steps were missing) and I find the permissions model with them more awkward. I tried installing Gitea on my home server via snap the other day, and promptly got annoyed enough to just give up, as I wasn't that invested in it.

techntoke 8y ago
I use i3wm and Rofi (similar to dmenu). Pacman from Arch and apk from Alpine are so much easier at managing packages. Until they can make a containerized distro that works basically the same, then I don't see a good use case for changing, unless you want to try something out in a more isolated environment (and even then there is Docker).
- cprecioso 8y ago
  Do you mean Ubuntu Core?
  - techntoke 8y ago
    No. I've not had much luck with Ubuntu Core and use Arch generally, Alpine for Docker, and have had better luck with other distros for embedded Linux.
zdragnar 8y ago
Are you using dmenu or i3-dmenu-desktop? If you're using the latter, I'm pretty sure you can create .desktop files for AppImage apps so they're added to the list: https://build.i3wm.org/docs/i3-dmenu-desktop.html#DESCRIPTION https://build.i3wm.org/docs/i3-dmenu-desktop.html#DESCRIPTIO... For myself, I've only needed to use AppImage once, and that's for a program that I only bother using from a terminal anyway; other than not showing up in dmenu out-of-the-box, I haven't had any other complaints.

elheffe80 8y ago

I couldn't make it past the third paragraph. So poorly written that it literally made me mad.

saderror256 8y ago

What Flatpak also does well wasn't mentioned, which is sandboxing applications (can snap do this as well i think), I use proprietary applications on flatpak sometimes so i can feed them the resources they only need, like discord, it does not need to see my files or my running processes for the running games feature, so i just restrict them with flatpak. Sandboxing is nice for proprietary software basically, or software that collects info or just any software that connects to a server, you can snip out useless stuff you don't need while it still hopefully functions well.

erlehmann_ 8y ago
http://flatkill.org/ http://flatkill.org/ claims that “The sandbox is a lie”: > Almost all popular applications on flathub come with filesystem=host, filesystem=home or device=all permissions, that is, write permissions to the user home directory (and more), this effectively means that all it takes to "escape the sandbox" is echo download_and_execute_evil >> ~/.bashrc. That's it. > To make matters worse, the users are misled to believe the apps run sandboxed. For all these apps flatpak shows a reassuring "sandbox" icon when installing the app (things do not get much better even when installing in the command line - you need to know flatpak internals to understand the warnings). I have not used flatpack. Is this description accurate? Also: > Up until 0.8.7 all it took to get root on the host was to install a flatpak package that contains a suid binary (flatpaks are installed to /var/lib/flatpak on your host system). Again, could this be any easier? A high severity CVE-2017-9780 (CVSS Score 7.2) has indeed been assigned to this vulnerability. Flatpak developers consider this a minor security issue.
- bjoli 8y ago
  The first two are also the case with snap. No packages actually seem to use the sandbox feature.
- Natela 8y ago
  There was already a post on this. Basically the argument about home is true but this is because 1) apps should not use filesystem access but rather portals (if they can) 2) nothing should be executable in the home folder (nobashrc, no script, etc...) If I remember well the second argument was about update not being frequent enough. So nothing fundamentally about Flatpak but more about the infrastructure (lack of updates) and the use of it (we should not allow home access and use Portals or we should disable bashrc).

cmurf 8y ago

It's not integrated in flatpak cli yet, but you can use ostree to do a rollback/downgrade. https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks https://github.com/flatpak/flatpak/wiki/Tips-&-Tricks

bfrog 8y ago

It honestly feels like these solutions are the wrong approach when compared to something like Nix.

Fnoord 8y ago
Would you mind elaborating on that?

apatheticonion 8y ago

Is this docker for regular applications?

apexalpha 8y ago
it's more like .exe on windows. It requires more disk space because some dependacies might be installed twice or more, but it saves both the end users, the distributors and the developers of a program an enormous amount of headache having to support dozens of different linux distro's with their own dependancies etc...

burtonator 8y ago

As a developer having these three formats is a real pain. I wish we had a standard already. The app I'm working on, Polar (https://getpolarized.io/ https://getpolarized.io/) is a cross platform document repository. The Windows and MacOS builds are pretty straight forward. But with Linux I now have Appimage, deb, rpm, snap, flatpak, and of course tar.gz (but maybe that doesn't count).

petre 8y ago
Just pick one. Appimage fits the bill quite nicely and does not depend on a certain distribution. It's drop and forget. No silly mounts or other "infrastructure" needed to deploy. I haven't used Flatpak but Snap is quite annoying and it was one of the reasons I switched from Ubuntu to Debian. Even if you unininstall snapd in Ubuntu 18 you are still stuck with the annoying mount points. That and the auto-updates.
nsomaru 8y ago
Saw a comment from you the other day on HN. Was really excited, even installed snap to try it out. For some reason the application is not automatically in my path after installation. That’s enough for me to go back to apt, and unfortunately Polarized is collateral damage. I preferred installing from a ‘repo’ which updates my software automatically, something it seems that your deb does not do.
- hollerith 8y ago
  >the application is not automatically in my path after installation. That’s enough for me to go back to apt Wow, tough customer! I have resigned myself to the need to do the equivalent of `dpkg -L | grep /bin/` to discover where the binaries are.
- zyga 8y ago
  It will be on the next reboot/login. Due to some bugs setting up PATH is hard (harder than other variables and much harder than it should be) so we did the best we could (require a logout/reboot)

amaccuish 8y ago

I'm not sure he included the runtimes that flatpak downloads in space usage requirements, so the results may not be accurate :/

tannhaeuser 8y ago

They're repeating the .rpm vs .deb situation again, for no-ones gain. Wake me up if they're actually collaborating on a common standard.

CogitoCogito 8y ago
I agree with you that there is nothing new to this sort of thing, but why does there need to be a common standard? Personally I'd prefer a few different standards with their own ideas competing instead of a single one that is just some compromise between the different ones.
- tannhaeuser 8y ago
  "Let a thousand blossoms bloom" isn't the right approach for package management. A package manager is IMHO not the place for creativity, competition, bikeshedding, and fragmentation because that's what we have already. The focus should be on winning devs to actually use a package format, so that users can more easily install software without upstream devs needing to maintain yet another format.
  - CogitoCogito 8y ago
    We're not talking about thousands of formats...only a few formats make up the most popular formats around. I see nothing special about package managers that makes competition undesirable. I think creativity and competition are good for package managers. Besides why does an upstream dev need to maintain these new formats? They can choose to support whatever they want. Personally I don't understand why this is a big deal. Any fragmentation is the result of reasonable people disagreeing on the best approach. The plethora of different ideas is a feature of the ecosystem not a bug.
    - Riverheart 8y ago
      Because developers want to target the whole Linux desktop segment without having to reproduce the packaging process several times. Has nothing to do with whether the format is better or worse as long as it is consistent. Fortunately, gems like FPM have attempted to address this issue.

mathw 8y ago

I feel this article misses the point entirely. Flatpak runtimes - which unbundle a huge number of dependencies (such as GNOME's entire platform library set) and allow independent security updates for them - aren't even mentioned. Neither is sandboxing. I was hoping for something interesting about the technical tradeoffs between the three formats and why I might want to have Fedora support Snap in the future (or why I might not to), etc. Interesting to read the other comments and discover that Flatpak's really oriented towards desktop software only. I didn't know that.

niemeyer 8y ago
Yes, the article indeed is on the low end. It focuses mainly on the package sizes, and gets it very wrong as mentioned in other comments.

mitchtbaum 8y ago

I looked at these a tiny bit already and think it'd be better to package in each distro's standard channels. I'd be interested in good reading material about packaging for debian apt, ubuntu ppm, arch aur, red hat rpm, etc if anyone's got some.

debiandev 8y ago
https://wiki.debian.org/Packaging https://wiki.debian.org/Packaging is a good source and you can easily generate packages from other distributions from a .deb

auganov 8y ago

Had a pretty bad experience with snap. A project I wanted to try was distributed as a snap package, after fixing many download issues, finally got my package, it didn't work but that was okay, was going to make some changes anyways. Built from source just fine, but it turned out the project itself depended on snap's sandboxing heavily, so I'd have to create a snap package anyways. Unfortunately at the time (and likely still true), the dev tools didn't like anything that wasn't the latest Ubuntu (recent Debian didn't cut it). Apt purged snapd, but still had to manually delete a bunch of snapd related files (systemd units mostly).

bachir44 8y ago

I agree it is important to ensure security, we must be careful, nothing we guarantee that it can not be hacked. ___________________________________________________ https://www.minimilitia.mobi/ https://www.minimilitia.mobi/ https://www.applock.ooo/ https://www.applock.ooo/ https://www.7zip.vip/ https://www.7zip.vip/