Why Flatpak? Isn't Snap enough?

[Jasper St. Pierre]

On Wed, Jan 3, 2018 at 7:09 AM, Simon McVittie <smcv at collabora.com> wrote:

> On Tue, 02 Jan 2018 at 18:33:53 +0000, N. W. wrote:
> > Why develop Flatpak and Snap? Why not collaborate on Snap only?
>
> You could say the same thing about Snap and Flatpak the other way round,
> or about Linux and FreeBSD (either way round), or CentOS and Arch Linux
> (either way round). In each case, the reason is: while the goals of the
> two projects in a pair overlap, they are not identical; and the people
> doing the work believe (rightly or wrongly) that the project they are
> working on has enough advantages over the other one, when used to achieve
> their particular goals, to be worth their effort.
>
> Snap has advantages over Flatpak for some uses. Two of those are that
> its scope is wider/more universal, and it uses an LSM (AppArmor) to label
> processes in a way that's readily visible to the kernel and user-space.
>
> Flatpak also has advantages over Snap for some uses. Two of those are that
> its narrower scope makes it more focused on the use-cases it does support,
> and it provides useful sandboxing even on systems that do not enable a LSM
> or enable an incompatible non-AppArmor LSM (AppArmor and SELinux can't be
> "stacked", the ability to stack major LSMs is a time-consuming feature to
> develop, and some distributions already require SELinux, so this matters
> a lot). You'll notice those are diametrically opposed to the advantages
> I mentioned for Snap: you can't have both, and the one you should choose
> as more important depends on what your goals are. Different goals lead to
> different choices, and those choices can be advantages or disadvantages,
> depending on what you want to achieve.
>
> Open source development is not zero-sum - many of the things Flatpak
> developers work on also help Snap, and vice versa.
>
> > This is not meant to offend anyone.
>
> If that's true (and you're not just trolling), then I don't think you
> have achieved your goal. Dismissing people's hard work as not being a
> "sane" thing to do is not a very effective way to change their minds,
> regardless of whether your criticisms are grounded in true facts.
>
> If you aim to influence volunteer projects, I would recommend doing so by
> helping to do the work. If you think Snap is better than Flatpak, please
> spend your time on improving/helping Snap, not on disrupting Flatpak.
>

I want to give a response to this. I hope my time in the community means
that you know I'm not replying in bad faith.

>From a user experience perspective, this sort of fragmentation is awful.
LibreOffice ships a flatpak, Mailspring ships a snap. In order to get a
consistent experience, authors of tools like GNOME Software have to support
both. Users who "pick their favorite" in the same way they "picked their
favorite" between .deb and .rpm might refuse to install Snaps, meaning that
Mailspring has to ship both a .snap and a Flatpak. Sometimes this "pick
your favorite" comes in the form of a distribution or community choosing
for you.

I think Flatpak has made great *technical* strides in improving and
rounding off the round corners of the developer experience, but
fragmentation is a social problem, not a technical one. The goals you
mentioned are *technical* ones: "use this containerization technology for
this sandboxing benefit", "integrate more closely with yadda yadda build
system".

But Flatpak's overall goal isn't that. The problem Flatpak is solving isn't
"we need to use containers on the desktop". The goal is to remove
fragmentation and improve the developer experience. Long ago, when
"xdg-app" was being conceptualized at Red Hat, when I asked why this was
important, someone pointed me to this download page [0] and told me we
needed to fix that.

We haven't won if that page now says "Select Your Download Format: .snap,
.flatpak, .appimage, .zeroinstall", we've just shifted the yard lines. It's
good *technical* progress that all four of those now work no matter what
your underlying operating system is, but developers still have to do
cross-builds for all the possible formats users want, and users still have
to pick a favorite. As long as we fight on technical grounds alone and use
a "let the best flowers blossom" approach, we won't achieve our goals.

[0] https://web.archive.org/web/20170923025953/http://banshee.fm/download/

    smcv
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak
>



-- 
  Jasper
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20180104/674e80f8/attachment.html>