<div dir="ltr"><div>hi,</div><div><br></div><div>the use case of flatpak is simple and very useful to me,</div><div>it does not compete with docker</div><div>it's not about containerized jailed system daemons</div><div><br></div><div>it does not compete with binary tarballs/self-extracotors shipping random binary rubbish as root and messing with your system.</div><div><br></div><div>it's clear and very useful</div><div>it's a standard (community-driven) way to deliver application and their runtimes</div><div>in deed, graphical user session apps, snaboxed, with their access is user managed.<br></div><div>does snap do this? definitely no.<br></div><div><br></div><div>for example, check this snap package < <a href="https://anbox.io/">https://anbox.io/</a></div><div>they not only were able to run things as root on the host,</div><div>but even worse they were able to load kernel modules.</div><div><br></div><div>does flatpak support this? of course not</div><div>from flatpak point of view this is not a good feature to have (for the use case of flatpak)</div><div><br></div><div>maybe it's a good feature for someone who want to inject random code into his/her host kernel</div><div>in order to get his/her favorite app running, that's not what flatpak is.<br></div><div>if you want this you might as well be happy using windows.<br></div><div><br></div><div>let's compare that to the following use case<br></div><div>I personally like Microsoft Visual Studio Code,</div><div>but I don't want to trust their repo<br></div><div><br></div><div>I can install snaboxed version of it as usual user (without root permission)</div><div><br></div><div>flatpak install --user <a href="https://flathub.org/repo/appstream/com.visualstudio.code.flatpakref">https://flathub.org/repo/appstream/com.visualstudio.code.flatpakref</a><br></div><div><br></div><div>I can deny it from internet access.<br></div><div><br></div><div>those are jailed applications, I can control what they see from my system, in the example below<br></div><div>I grant it access to only one directory<br></div><div><br></div><div><a href="https://twitter.com/muayyadalsadi/status/870986338111299584">https://twitter.com/muayyadalsadi/status/870986338111299584</a><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Jan 3, 2018 at 5:09 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">On Tue, 02 Jan 2018 at 18:33:53 +0000, N. W. wrote:<br>
> Why develop Flatpak and Snap? Why not collaborate on Snap only?<br>
<br>
You could say the same thing about Snap and Flatpak the other way round,<br>
or about Linux and FreeBSD (either way round), or CentOS and Arch Linux<br>
(either way round). In each case, the reason is: while the goals of the<br>
two projects in a pair overlap, they are not identical; and the people<br>
doing the work believe (rightly or wrongly) that the project they are<br>
working on has enough advantages over the other one, when used to achieve<br>
their particular goals, to be worth their effort.<br>
<br>
Snap has advantages over Flatpak for some uses. Two of those are that<br>
its scope is wider/more universal, and it uses an LSM (AppArmor) to label<br>
processes in a way that's readily visible to the kernel and user-space.<br>
<br>
Flatpak also has advantages over Snap for some uses. Two of those are that<br>
its narrower scope makes it more focused on the use-cases it does support,<br>
and it provides useful sandboxing even on systems that do not enable a LSM<br>
or enable an incompatible non-AppArmor LSM (AppArmor and SELinux can't be<br>
"stacked", the ability to stack major LSMs is a time-consuming feature to<br>
develop, and some distributions already require SELinux, so this matters<br>
a lot). You'll notice those are diametrically opposed to the advantages<br>
I mentioned for Snap: you can't have both, and the one you should choose<br>
as more important depends on what your goals are. Different goals lead to<br>
different choices, and those choices can be advantages or disadvantages,<br>
depending on what you want to achieve.<br>
<br>
Open source development is not zero-sum - many of the things Flatpak<br>
developers work on also help Snap, and vice versa.<br>
<br>
> This is not meant to offend anyone.<br>
<br>
If that's true (and you're not just trolling), then I don't think you<br>
have achieved your goal. Dismissing people's hard work as not being a<br>
"sane" thing to do is not a very effective way to change their minds,<br>
regardless of whether your criticisms are grounded in true facts.<br>
<br>
If you aim to influence volunteer projects, I would recommend doing so by<br>
helping to do the work. If you think Snap is better than Flatpak, please<br>
spend your time on improving/helping Snap, not on disrupting Flatpak.<br>
<br>
    smcv<br>
______________________________<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>
</blockquote></div><br></div>