<div dir="ltr"><div><div><div><div><div><div>> what it's actually good at: Shipping server appliances like Nextcloud or invasive technologies like Anbox.<br><br></div>no, snap is loosing that war too. for shipping server stacks I guess docker (and its friends) are winning at that front.<br><br></div>snap is loosing every where, just like all canonical stuff.<br>bzr lost for git<br></div>mir lost for wayland<br></div>unity lost for gnome<br><br></div>again, canonical has agenda for IoT market, and they are not going to join any community<br>and they have a conflict of interest with any community effort (be docker or flatpak) regardless of any thing<br></div>they already sold a white-labeled version of their proprietary snap server to banana pie manufacturer<br><br>> We haven't won if that page now says "Select Your Download Format: 
.snap, .flatpak, .appimage, .zeroinstall", we've just shifted the yard 
lines.<div><br></div><div>I guess there is nothing our community can do to convince canonical to stop "not invented here" syndrome</div><div><br></div><div><br><br><div><div><div><div><br></div></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jan 5, 2018 at 2:41 PM, Simon McVittie <span dir="ltr"><<a href="mailto:smcv@collabora.com" target="_blank">smcv@collabora.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Thu, 04 Jan 2018 at 16:26:06 -0800, Jasper St. Pierre wrote:<br>
> On the Flatpak mailing<br>
> list, people will argue that Flatpak's solution is technically better. On the<br>
> Snap mailing list, they'll argue their solution is technically better.<br>
<br>
</span>Yes. It's almost as though mailing lists are somehow self-selecting? :-)<br>
<br>
I don't have an answer for the fragmentation problem. It is a problem,<br>
but I don't see how telling Flatpak people "you should give up on this<br>
and contribute to Snap instead" is going to solve it, and I also don't<br>
see how telling Snap people "you should give up on this and contribute<br>
to Flatpak instead" is going to solve it. (Even, or perhaps especially,<br>
if one of those is in fact the right thing to do.)<br>
<br>
I don't think telling Flatpak or Snap developers "fragmentation is bad<br>
and you should feel bad for being one of the sides" is necessarily going<br>
to help either; people have chosen to contribute to that one and not the<br>
other because they think it's a better answer, so obviously that one is<br>
the one that should be the standard and the other should go away,<br>
reinforcing the "us vs. them" problem.<br>
<br>
I understand your frustration with Flatpak and Snap existing in parallel,<br>
some apps having one, some apps having the other, and some app developers<br>
feeling that they need to provide both. However, even if that situation<br>
persists, it's still less fragmented than feeling that you need to<br>
provide different RPMs for Red Hat, Mageia, SUSE etc., different .debs<br>
for Debian and Ubuntu, the Arch Linux package format whose name I can<br>
never remember, and so on; and at least it's possible to co-install<br>
Flatpak and Snap on the same system and have them work, without being<br>
forced to choose one or the other like you essentially have to do with<br>
RPM/dpkg/etc. Two steps forward and one step back is still a step forward.<br>
<br>
(I know I've written this as though Flatpak and Snap are the only<br>
options for app distribution. That's only for simplicity of wording;<br>
there are other projects in a similar space, like AppImage, and<br>
essentially the same things apply with some of the names changed.)<br>
<span class=""><br>
> The social problem<br>
> we have to solve is that people on the Flatpak mailing list would rather insult<br>
> Snap rather than collaborate or pay any due respects<br>
<br>
</span>That's what I was trying to pre-empt by getting a more balanced answer<br>
in first. Obviously, I failed. I'm biting my tongue trying not to say<br>
why I think Flatpak is the better answer, because *obviously* I think<br>
that, or I wouldn't be maintaining it in Debian; but it wouldn't<br>
contribute anything meaningful to the discussion, so I'm trying hard<br>
not to say it.<br>
<br>
I think a certain level of fragmentation might be a necessary and<br>
acceptable price to pay for deliberately trying to de-escalate the<br>
"us vs. them" attitude. The fragmentation is unfortunate, but any time<br>
a problem has several imperfect solutions with different tradeoffs,<br>
there's going to be some competition between them. If we can encourage<br>
it to be friendly competition with as much collaboration as possible<br>
(like the way GNOME, KDE etc. share various <a href="http://freedesktop.org" rel="noreferrer" target="_blank">freedesktop.org</a> bits, and<br>
the various Linux distributions contribute to the same upstream projects<br>
they all use) then that's far better than shouting at each other.<br>
<br>
Snap people seem to be interested in making use of xdg-desktop-portal and<br>
my current work on app-container-specific servers in dbus-daemon (which<br>
I started with Flatpak in mind, but aiming to make it general enough to<br>
support Snap too), both of which are good bits of infrastructure-sharing.<br>
<br>
Unfortunately, some sets of competing projects attract a vocal<br>
echo-chamber of fans who don't contribute anything except advocacy,<br>
which is occasionally helpful, but often degenerates into a negative<br>
contribution by wasting the time of the people who do the work.<br>
<br>
Not a reply to Jasper, just a general plea:<br>
<br>
To anyone currently composing a message to a Flatpak or Snap forum<br>
advocating Flatpak over Snap: please stop, delete the draft, and do<br>
something positive to improve Flatpak instead. Fix a bug, or write<br>
a detailed/useful bug report, or improve the documentation, or find<br>
something in Flatpak's scope that Snap does better and work out how to<br>
improve Flatpak until that's no longer true.<br>
<br>
If people have already invested time and energy in Flatpak, your advocacy<br>
is most likely not going to tell them anything they didn't already know;<br>
if people have already invested time and energy in Snap, your advocacy<br>
is probably not going to make them think "oh, I was wrong all along,<br>
I should have been working on Flatpak" because that's not how the<br>
sunk-cost fallacy works. If your advocacy insults Snap developers,<br>
it's more likely to have the *opposite* effect by making them assume<br>
the whole Flatpak community is equally rude. Please don't create that<br>
impression.<br>
<br>
Equally, to anyone currently composing a message to a Snap or Flatpak<br>
forum advocating Snap over Flatpak: please stop, delete the draft, and<br>
do something positive to improve Snap instead. The same reasons apply,<br>
in reverse.<br>
<br>
If one of Flatpak and Snap develops into an obviously better solution<br>
for app development than the other, then no advocacy will be needed,<br>
because it will already be obviously better. Writing flamebait emails<br>
to mailing lists about how much better the other app framework is does<br>
not improve the state of Linux software; making the other app framework<br>
*actually better* does.<br>
<br>
Thanks,<br>
    smcv<br>
<div class="HOEnZb"><div class="h5">______________________________<wbr>_________________<br>
Flatpak mailing list<br>
<a href="mailto:Flatpak@lists.freedesktop.org">Flatpak@lists.freedesktop.org</a><br>
<a href="https://lists.freedesktop.org/mailman/listinfo/flatpak" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>mailman/listinfo/flatpak</a><br>
</div></div></blockquote></div><br></div>