Why Flatpak? Isn't Snap enough?

Wed Jan 3 20:58:10 UTC 2018

my previous post was about the value of sandboxing in flatpak

in this one I'm going to talk about community.

flatpak is clearly a freedesktop.org project,
it's for community and by community
for example it uses ostree, it has no hard-coded central authority repo
(unlike snap which points to canonical's snap store)
and yet it does that without sacrificing usability
you can just go to websites like https://flathub.org/apps.html
and click on your favourite app it that would launch software center and
install it
(on any modern distro with recent version of software center)

flatpak was designed in public, their is no secret souce,

on the other hand, snap is just a client to a proprietary product of
canonical
just like all canonical products (remember ubuntu one cloud, opensource
client, proprietary sever)
let's not pretend that snap community designed a secret server, with secret
api with hard-coded server url
then reverse engineer the api, then release a dumb version of the server.
that's not how opensource community work.

On Wed, Jan 3, 2018 at 10:46 PM, Muayyad AlSadi <alsadi at gmail.com> wrote:

> hi,
>
> the use case of flatpak is simple and very useful to me,
> it does not compete with docker
> it's not about containerized jailed system daemons
>
> it does not compete with binary tarballs/self-extracotors shipping random
> binary rubbish as root and messing with your system.
>
> it's clear and very useful
> it's a standard (community-driven) way to deliver application and their
> runtimes
> in deed, graphical user session apps, snaboxed, with their access is user
> managed.
> does snap do this? definitely no.
>
> for example, check this snap package < https://anbox.io/
> they not only were able to run things as root on the host,
> but even worse they were able to load kernel modules.
>
> does flatpak support this? of course not
> from flatpak point of view this is not a good feature to have (for the use
> case of flatpak)
>
> maybe it's a good feature for someone who want to inject random code into
> his/her host kernel
> in order to get his/her favorite app running, that's not what flatpak is.
> if you want this you might as well be happy using windows.
>
> let's compare that to the following use case
> I personally like Microsoft Visual Studio Code,
> but I don't want to trust their repo
>
> I can install snaboxed version of it as usual user (without root
> permission)
>
> flatpak install --user https://flathub.org/repo/
> appstream/com.visualstudio.code.flatpakref
>
> I can deny it from internet access.
>
> those are jailed applications, I can control what they see from my system,
> in the example below
> I grant it access to only one directory
>
> https://twitter.com/muayyadalsadi/status/870986338111299584
>
>
>
>
>
>
>
> On Wed, Jan 3, 2018 at 5:09 PM, 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.
>>
>>     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/20180103/6cf38e55/attachment-0001.html>