<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Thu, Jan 4, 2018 at 4:10 PM, Michael Gratton <span dir="ltr"><<a href="mailto:mike@vee.net" target="_blank">mike@vee.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-">On Fri, Jan 5, 2018 at 6:38 AM, Jasper St. Pierre <<a href="mailto:jstpierre@mecheye.net" target="_blank">jstpierre@mecheye.net</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
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".<br>
</blockquote>
<br></span>
Sure, but Flatpak's technology is what makes it a better solution for shipping end-user apps, which makes it the better solution for solving the fragmentation problem.<br></blockquote><div><br></div><div>I'm not interesting in having a technology argument. 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. Neither is right, neither is wrong. I have plenty of gripes in both Snap's and Flatpak's respective architectures; places where I disagree with their choices. That's OK. Compromise and empathy are a lot more worthwhile to me than creating my own competing ivory tower perfect packaging mechanism.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">So in the end, this argument should be taken to the snap mailing list, since it's snap's technical limitations that make it less useful for solving the social problem. If those limitations can't or won't be addressed, then people should start preferring Flatpak alone for shipping end-user apps, and reserve using snaps for what it's actually good at: Shipping server appliances like Nextcloud or invasive technologies like Anbox.<br></blockquote><div><br></div><div>The rudeness isn't warranted here. Snap is a perfectly fine solution for shipping desktop apps, and is doing so today, even if the denizens of the Flatpak mailing list believe it to be technically inferior. 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, and argue that "we aren't the social problem, they are!"<br></div><div><br></div><div>That hostility splits the development teams into "us vs. them camps", confuses users, and drives away developers looking for clear answers to basic questions about application distribution on Linux. It's not a winning strategy. The technology of Flatpak is meaningless unless it actually accomplishes its goals of developing a saner distribution and development platform.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
//Mike<span class="gmail-HOEnZb"><font color="#888888"><br>
<br>
-- <br>
⊨ Michael Gratton, Percept Wrangler.<br>
⚙ <<a href="http://mjog.vee.net/" rel="noreferrer" target="_blank">http://mjog.vee.net/</a>><br>
<br>
</font></span></blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature">  Jasper<br></div>
</div></div>