Why Flatpak? Isn't Snap enough?

Fri Jan 5 13:40:41 UTC 2018

> what it's actually good at: Shipping server appliances like Nextcloud or
invasive technologies like Anbox.

no, snap is loosing that war too. for shipping server stacks I guess docker
(and its friends) are winning at that front.

snap is loosing every where, just like all canonical stuff.
bzr lost for git
mir lost for wayland
unity lost for gnome

again, canonical has agenda for IoT market, and they are not going to join
any community
and they have a conflict of interest with any community effort (be docker
or flatpak) regardless of any thing
they already sold a white-labeled version of their proprietary snap server
to banana pie manufacturer

> We haven't won if that page now says "Select Your Download Format: .snap,
.flatpak, .appimage, .zeroinstall", we've just shifted the yard lines.

I guess there is nothing our community can do to convince canonical to stop
"not invented here" syndrome

On Fri, Jan 5, 2018 at 2:41 PM, Simon McVittie <smcv at collabora.com> wrote:

> On Thu, 04 Jan 2018 at 16:26:06 -0800, Jasper St. Pierre wrote:
> > On the Flatpak mailing
> > list, people will argue that Flatpak's solution is technically better.
> On the
> > Snap mailing list, they'll argue their solution is technically better.
>
> Yes. It's almost as though mailing lists are somehow self-selecting? :-)
>
> I don't have an answer for the fragmentation problem. It is a problem,
> but I don't see how telling Flatpak people "you should give up on this
> and contribute to Snap instead" is going to solve it, and I also don't
> see how telling Snap people "you should give up on this and contribute
> to Flatpak instead" is going to solve it. (Even, or perhaps especially,
> if one of those is in fact the right thing to do.)
>
> I don't think telling Flatpak or Snap developers "fragmentation is bad
> and you should feel bad for being one of the sides" is necessarily going
> to help either; people have chosen to contribute to that one and not the
> other because they think it's a better answer, so obviously that one is
> the one that should be the standard and the other should go away,
> reinforcing the "us vs. them" problem.
>
> I understand your frustration with Flatpak and Snap existing in parallel,
> some apps having one, some apps having the other, and some app developers
> feeling that they need to provide both. However, even if that situation
> persists, it's still less fragmented than feeling that you need to
> provide different RPMs for Red Hat, Mageia, SUSE etc., different .debs
> for Debian and Ubuntu, the Arch Linux package format whose name I can
> never remember, and so on; and at least it's possible to co-install
> Flatpak and Snap on the same system and have them work, without being
> forced to choose one or the other like you essentially have to do with
> RPM/dpkg/etc. Two steps forward and one step back is still a step forward.
>
> (I know I've written this as though Flatpak and Snap are the only
> options for app distribution. That's only for simplicity of wording;
> there are other projects in a similar space, like AppImage, and
> essentially the same things apply with some of the names changed.)
>
> > The social problem
> > we have to solve is that people on the Flatpak mailing list would rather
> insult
> > Snap rather than collaborate or pay any due respects
>
> That's what I was trying to pre-empt by getting a more balanced answer
> in first. Obviously, I failed. I'm biting my tongue trying not to say
> why I think Flatpak is the better answer, because *obviously* I think
> that, or I wouldn't be maintaining it in Debian; but it wouldn't
> contribute anything meaningful to the discussion, so I'm trying hard
> not to say it.
>
> I think a certain level of fragmentation might be a necessary and
> acceptable price to pay for deliberately trying to de-escalate the
> "us vs. them" attitude. The fragmentation is unfortunate, but any time
> a problem has several imperfect solutions with different tradeoffs,
> there's going to be some competition between them. If we can encourage
> it to be friendly competition with as much collaboration as possible
> (like the way GNOME, KDE etc. share various freedesktop.org bits, and
> the various Linux distributions contribute to the same upstream projects
> they all use) then that's far better than shouting at each other.
>
> Snap people seem to be interested in making use of xdg-desktop-portal and
> my current work on app-container-specific servers in dbus-daemon (which
> I started with Flatpak in mind, but aiming to make it general enough to
> support Snap too), both of which are good bits of infrastructure-sharing.
>
> Unfortunately, some sets of competing projects attract a vocal
> echo-chamber of fans who don't contribute anything except advocacy,
> which is occasionally helpful, but often degenerates into a negative
> contribution by wasting the time of the people who do the work.
>
> Not a reply to Jasper, just a general plea:
>
> To anyone currently composing a message to a Flatpak or Snap forum
> advocating Flatpak over Snap: please stop, delete the draft, and do
> something positive to improve Flatpak instead. Fix a bug, or write
> a detailed/useful bug report, or improve the documentation, or find
> something in Flatpak's scope that Snap does better and work out how to
> improve Flatpak until that's no longer true.
>
> If people have already invested time and energy in Flatpak, your advocacy
> is most likely not going to tell them anything they didn't already know;
> if people have already invested time and energy in Snap, your advocacy
> is probably not going to make them think "oh, I was wrong all along,
> I should have been working on Flatpak" because that's not how the
> sunk-cost fallacy works. If your advocacy insults Snap developers,
> it's more likely to have the *opposite* effect by making them assume
> the whole Flatpak community is equally rude. Please don't create that
> impression.
>
> Equally, to anyone currently composing a message to a Snap or Flatpak
> forum advocating Snap over Flatpak: please stop, delete the draft, and
> do something positive to improve Snap instead. The same reasons apply,
> in reverse.
>
> If one of Flatpak and Snap develops into an obviously better solution
> for app development than the other, then no advocacy will be needed,
> because it will already be obviously better. Writing flamebait emails
> to mailing lists about how much better the other app framework is does
> not improve the state of Linux software; making the other app framework
> *actually better* does.
>
> Thanks,
>     smcv
> _______________________________________________
> Flatpak mailing list
> Flatpak at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/flatpak
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/flatpak/attachments/20180105/a78793da/attachment.html>