Adoption of Flatpak vs Snap (2018 edition)

This is an update to my blog post from last year.

Here some facts for context, should anyone read this sometime down the road:

  • Today is 8 June 2018
  • Latest Flatpak:
    0.11.8.1, released today (0.11.8.0 was released yesterday)
    0.10.4 “Stable” released on 14 February 2018 (last old stable was 0.8.9)
  • Latest Snapd:
    2.32.9 released 21 days ago

Because Flatpak comes in two types, regular release (0.11.x) and “Stable” (=LTS, 0.10.x), the latest Stable release counts as well. With Flatpak 0.11.8’s hotfix only released 4 hours ago, it could not have passed the QA of any serious distribution, so 0.11.7 counts as latest for now.

Green means the latest version is in an official repository.
Yellow means that either the latest version is in an add-on repo or the package is in an official repository but with some problems.
Red means either not available at all or in some barely maintained (or even abandoned) add-on repository.

Flatpak Snap
Arch Linux Extra / Latest release AUR only / Latest release
Debian Latest in Stretch Outdated everywhere (even Sid)
Fedora Latest release Outdated and clashing with SELinux
Gentoo Overlay with latest release Overlay outdated
Mageia 0.10.3 Not available
openSUSE Latest in TW / Latest LTS in Leap15 Outdated / In add-on repo only
RHEL/CentOS 0.8.8 Not available
Ubuntu Latest in Bionic Latest in Bionic

Flatpak is continuing to go strong. In case of Mageia it graduated from the development Cauldron branch into a proper Mageia release, even though they forgot to package 0.10.4 and only ship 0.10.3, so while more users can no use Flatpak packages, they went from green to yellow because of that update oversight.
openSUSE’s conservative Leap releases also carry Flatpak now, not only their rolling release, so things actually improved while staying green.
Weirdly enough CentOS, while shipping Flatpak and not Snapd, does not even ship the last Old Stable release.

Positive developments for Snap have been that it graduated in Fedora from a totally broken build in a user repository to the main one. There are problems with SELinux (which is enabled by default on Fedora) but I don’t know how serious they are, so I give them the benefit of the doubt and rate it yellow instead of red.

In Arch Linux Snapd got demoted from the Community repo to AUR, however that at least carries the latest release.

In an attempt to increase the adoption rate of Snap, Canonical hired people to package Snapd for competing distributors. To a degree it seems to have paid off because Arch, Fedora, and openSUSE packages at least have some outside contributors, however only the AUR package is not outdated. Even Debian’s Snapd package is no longer the latest release. So while Snapd managed to cut the number of red cells down, the Debian packagers also dropped the ball and now they’ve lost their green table cell.

Just like last year, smaller distributions seem to gravitate more towards Flatpak than Snapd (like OpenMandriva).

So while things changed here and there, IMO Flatpak is still the way to go, especially for those software vendors that target professional users with Flatpak being supported by CentOS/RHEL, Debian, openSUSE Leap, and even the current LTS release of Ubuntu. Snap packages OTOH are only 100% supported by Ubuntu. Even other distributions that carry it do with some downsides.

Advertisements

33 thoughts on “Adoption of Flatpak vs Snap (2018 edition)”

  1. > Flatpak is continuing to go strong. In case of Mageia it graduated from the development Cauldron branch into a proper Mageia release, even though they forgot to package 0.10.4 and only ship 0.10.3, so while more users can no use Flatpak packages, they went from green to yellow because of that update oversight.

    To be fair, Flatpak 0.10.4 released a couple of days after I pushed 0.10.3, and we had been focused on doing the “Grand Update” to rebase the Plasma Desktop stack: https://blog.mageia.org/en/2018/05/10/the-grand-update-brace-yourselves/

    I’ll likely update Flatpak in the coming days to the latest stable, and figure out what I want to do for Cauldron.

    1. Web polls are not quantifiable research and say exactly nothing because web polls are super easy to manipulate.

      If Ubuntu had such a great “market share”, Canonical’s revenue would dwarf Red Hat but instead it’s the other way around.

          1. That is very flawed logic. RedHat profits from businesses and has been doing that for many years, while Canonical for the most part of its history has been relying on private investment and community donations, and only recently started to explore the enterprise field. Of course they won’t earn as much.
            That doesn’t correlate to Ubuntu’s market share at all. It’s still The Distro all the people who are curious about Linux get and generally stick to it, and generally for a good reason.

            1. > That is very flawed logic.

              No

              > RedHat profits from businesses and has been doing that for many years, while Canonical for the most part of its history has been relying on private investment and community donations, and only recently started to explore the enterprise field. Of course they won’t earn as much.

              I’m sorry but you’re wrong. Canonical offers enterprise support since the first LTS release way over 10 years ago. See https://en.wikipedia.org/wiki/Canonical_(company)#Business_plans – the part about service provisions not being profitable in 2008.

              Canonical also never received donations. They are not a non-profit one can donate to (and then deduct taxes) and never have been. Individuals could optionally pay Canonical for Ubuntu.

              > That doesn’t correlate to Ubuntu’s market share at all.

              Yes, it does. A market is about selling goods.

              > It’s still The Distro all the people who are curious about Linux get and generally stick to it

              That’s a made-up claim without any verification at all. If everyone would being Linux with Ubuntu and then stick with it, every IT department since 14 years would have chosen Ubuntu when migrating to Linux. That would mean that Canonical would have way more revenue than Red Hat. If everyone would stick with Ubuntu, after becoming pros, its users would contribute to it. The crowd-funded Ubuntu phone, Mir, Upstart, Unity, etc. all failed – almost no contributions and Canonical’s financial troubles meant that they had to fire almost their whole desktop team and migrate to Red Hat-developed alternatives. See https://www.theregister.co.uk/2017/04/06/canonical_cuts_jobs_with_unity_bullet/ for verification. You can look at git stats for Gnome, systemd, and so on to see that these Red Hat-led projects have healthy numbers of outside contributors.

    2. … among developers who filled out the questionnaire for Stack Overflow in 2016.

      How representative you think it is?

      Snap will go the same way as Mir, Unity or Upstart. It will be widespread enough to cause unnecessary fragmentation, but ultimately abandoned in favour of the competing solution.

      1. Maybe it would if flatpak was serving the same niche, however, snap is targeting IoT/server use cases as well as desktop apps, so that’s unlikely.

  2. Flatpak is awesome IMO.
    Not only does it ease the workload on developers. It should make it possible to have better backwards compatibility than Windows for all Linux distributions. It might even be possible to have forward compatibility, such that old distro’s can run software that didn’t exist when they where released. This is the killer feature for IT production in almost any business that runs MS products.

    1. Asking for a admin password when performing a system-wide change is totally fine and what every other package manager does as well. Flatpak itself allows to install packages into the home directory. Gnome Software and Discover do not support that. IMO those are faults of Gnome and KDE.

      1. If one could at least check for updates without typing password it would be great.
        Currently there is password popup every time those apps try to fetch updates.

    2. Unfortunately, this is because of SUSE’s brain-dead policies regarding polkit. That is, almost all recommended polkit policies by upstream projects are not enabled in SUSE distributions.

      This is why, for example, you get prompted for things like installing printer drivers, installing *trusted* software, and so on.

      There’s an ungodly amount of paranoia in the SUSE Security Team about polkit policies, and it’s really hard to convince them to enable some. So this is not likely to improve.

    1. That’s true, I also mention it in my comment. Just to add, Solus had to do a great job migrating to AppArmor to offer support as good as in Ubuntu and although he did that, Solus did not lose compatibility with Flatpak.

    2. > is likely on par or surpassing Mageia in use.

      Since there is no way to actually verify this, I reserve the right to go with my gut feeling for my blog post. Maybe next year’s update.

  3. Flatpak is not perfect to this day, but I also believe that it is the way to go. I swear I have tried to use Snap, but always have to resort to external repositories and special packages (such as to add support for SELinux), being the experience of use very different from that offered by Ubuntu by default. On the other hand, AppImage is also an excellent portable format (in the sense of portable Windows applications), but it depends a lot on the features added by the developer, since not all of them, for example, generate a desktop file (*.desktop) to make things easier and that appimaged or the gpg signature are optional makes everything worse.

    It would be nice to add Solus OS to the list, it is an excellent workstation distro, which is where I think comparative aims (snap packages point to a complete replacement of traditional packages and not just desktop applications like flatpak). Solus offers excellent support for both formats and in the development versions of its software store will offer compatibility with both (yeah, snap has good support in a distro different than Ubuntu).

    1. Not really. Distributions don’t have to do anything to support AppImage because that format is just everything mushed into one binary. It’s not the distributor’s task to support AppImage but instead it’s the app vendor’s task to support as many distributions as possible. AppImage binaries are not automatically compatible with every distribution. The vendor has to make sure it works in every target: https://github.com/AppImage/AppImageKit/wiki/Creating-AppImages

      1. There is appimaged daemon for desktop integration of AppImages and a tool/daemon for updating AppImages.

        >appimaged is a daemon that handles registering and unregistering AppImages with the system (e.g., menu entries, icons, MIME types, binary delta updates, and such).
        https://github.com/AppImage/AppImageKit/blob/appimagetool/master/README.md

        >AppImageUpdate lets you update AppImages in a decentral way using information embedded in the AppImage itself.
        https://github.com/AppImage/AppImageUpdate

        Although they are not required to run AppImage, they are very nice to have.

  4. Hey

    Snapd developer here. I’d like to post some updates on the state of things and to correct some misconceptions. First of all, we are working to make sure that snapd can re-execute itself everywhere, so that even though the snap package is old the latest and greatest version of snapd is used from a .. snap 🙂 This is available in Debian, Ubuntu and a few other places and should be soon possible in OpenSUSE and Fedora (the choice of opt-in / opt-out is separate).

    As such the real measure of recentness is to “snap install core” and then run “snap version”, your results will differ then.

    OpenSUSE is not really out of date, all the releases since the one in the system:snappy archive were for bug fixes that don’t affect SUSE in any way. I plan to refresh the package to 2.33 once it goes stable.

    Fedora is almost always up-to-date and again, shares some of the characteristics with SUSE family. If you read the changelog for 2.32.x you will see that most of the point releases tweak either tests or things that only apply to Ubuntu in some way.

    The Arch package is similar, you can use snapd-git or the snapd package from AUR which is maintained by one of the snapd developers and arch users.

    Gentoo is pretty much abandoned and there’s no work on making it up-to-date. Given that the distribution is a bit of a special case we haven’t invested much time in integrating it into the process yet (we want to get more widely used platforms first).

    Speaking of used platforms, AFAIK there’s a test package for CentOS, I don’t know how far it is from being in the archive there but I’m sure Neal here will be able to correct me. It’s certainly on the radar.

    1. Ok, but the main issue with snap is that Ubuntu Bionic is released with something that does not really work for non English users… XDG variables not respected.

      Result, I installed flatpak on my friend’s laptop because it just works out of the box.

      1. That’s a bug in the snapcrafters/snapcraft-desktop-helpers and should be already fixed, notify the snap maintainer to trigger a rebuild should do.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.