2:36 p.m.
W dniu 19.07.2017 o 18:43 Matthew Miller pisze:
On Tue, Jul 18, 2017 at 11:22:54PM +0200, Zygmunt Krynicki wrote:
> > and until Snappy gets the ability to use something other than an Ubuntu
> > binary runtime, it's a non-starter.)
> Hey Matthew
> Snappy can do this today in the master branch. There are a lot of
> thinned missing and a lot of assumptions are still in place but we
> are well on our way towards a working Fedora based snapd installation
> on any host distribution.
Cool -- that's great news. I'll keep an eye on further developments. I
Thanks!
I know we still have plenty of things to improve in environments
different from Ubuntu but I wanted to highlight how much fantastic help
and engagement comes out of participating with the broader FOSS
ecosystem. I would love if more people using Fedora would look at snaps
and see how they can scratch their own itch with them.
do also have to say that the asymmetrical provisions of the
Canonical
CLA make it much less likely for Fedora to adopt Snappy as a
fundamental technology. That is, Snappy is GPL v3 for everyone except
Canonical, but effectively BSD/MIT-style for Canonical _including_
outside contributions. If we would decide to invest heavily in snaps,
Canonical would benefit immensely from that, and then decide to make an
"open core" offering including our work merged with proprietary
extensions. If snap becomes very popular, these proprietary extensions
could be used to put us at a disadvantage.
I understand but I honestly think we are at a disadvantage here. If
snapd is successful anyone could fork it and continue development around
a version that doesn't need a CLA. That would put pressure on Ubuntu
which could not use those improvements. (see the tail of this reply for
more licensing observations).
I would *love* to see more collaboration between Flatpak and Snappy,
possibly even leading to a unified, merged solution in the future, but
I think there are a few things we could collaborate but it is clear that
the design of both projects is different. I think we can contribute to
the larger community by competing on design and collaborating on means
to get there, including kernel features, fixes, toolchain fragments,
tooling and other things that we align on.
For instance I think that portals, or in general trusted helpers for
graphical applications, are a great idea and we should use and develop
them together. The work has to be extended to other essential projects
like pulseaudio (mediation of recording sound), network manager
(unprivileged API for network status and notifications without ability
to observe or configure things), wayland (still lots of insecurities
around keyboard injection and pasteboard stealing I heard) and many
others.
Another area where we can collaborate is the shift towards relocatable
applications. Coming from the world of ./configure --prefix=... we, as
a community, have a lot of work to do. I'm sure there are broad wins for
both projects if we collaborate share the benefit of enabling easier
relocatability of commonly used frameworks and language runtimes.
Finally, even if snapd and flatpak will be like GNOME and KDE, bound to
exist together for decades, I think every user wins. Both projects aim
to bring much better experience to every Linux-based operating systems
than what we have with traditional packaging today. Since we can install
both snaps and Flatpacks on multiple operating systems (alongside
traditional packages) we finally lessen the problem of balkanization of
the Linux desktop environment.
We should however not be shy to say we disagree on something and let
each project try to achieve its goals.
As for the differences, I'm naturally biased but I think the approach we
took in snapd is better. Off the top of my head. The simplicity and ease
of verification of squashfs images. The related assertion system. The
support for booting (kernel/bootloader/early boot things). Support for
hybrid classic+snaps or just snaps distributions. The whole approach to
the confinement story. All of those are huge topics and for a fair
comparison I'm sure I'd need to have a Flatpak expert to ensure I'm not
making any mistakes here.
One thing I'm more certain of is the confinement system with interfaces
rather than portals (and keep in mind that we too *can* use portals and
portal-like systems in our model). Flatpak apps must be patched (either
at framework level or directly) use portals or they are not going to
work. This doesn't scale to entire classes of interesting software.
Snapd has no such limitation, choosing to mediate the existing means of
communication or resource access instead.
Another big thing is the totally generic approach of snapd, that can
both exist in a classic distribution as well as drive a complete
pure-snap transactional system containing a kernel-snap, core-snap,
gadget-snap and any number of base-snaps and app-snaps. This puts one
central project, software and tooling in the space of flatpak, project
atomic and docker. One unified way to build and deliver graphical
desktop apps, command line tools, server software, kernels and base
system images. One set of tools to manage and build them. This is really
a nice and compelling story and I'm sure that anyone can agree, even if
they would rather see Flatpak become more the more popular choice. To
tie this thread to the somewhat exploding thread about "F27 System Wide
Change: Graphical Applications as Flatpaks", this makes snapd much more
general and much closer to a wholesale RPM replacement for future Fedora
releases, at least in my eyes.
Lastly I also prefer our choice of tooling as golang makes this
(critical system software) more reliable with fewer silly bugs per LOC
and better way to write testable software (I personally love C but I am
aware of the extra cost it takes to develop in it). I think that while
not being a popular choice in traditional FOSS projects, golang has the
right mixture of a safety, networking, parallelism and performance.
Having said all those things I'd love to meet and work more with the
people that work on Flatpack (hi Alex and others :-), exchange ideas,
argue and spend great time together (possibly over beers). Maybe at
FOSDEM or some other European event?
this is a pretty big stumbling block. And I don't think just for
Fedora. If you _really_ want to make Snappy a cross-distro success,
it's important to remedy this. In my non-lawyerly view, even
relicensing under MIT for _everyone_ would at least be more fair. I
personally think committing to GPL for everyone, Canonical included,
would be better.
I think some form of CLA is acceptable and it's unfair to say that
projects should not require CLAs. At Canonical we often contribute to
projects under CLAs simply because that's how they are developed (e.g.
golang itself) and we recognize the asymmetry of a single contribution
over a large investment to develop something in the first place. Lastly
many people just don't mind. I also recognize that some people *do* mind
and reject all but ultra-pure FOSS ideas and I'm okay with that too.
There's no way to please everybody.
(Compare for example Fedora's FPCA, which requires no grant of
license,
simply assurance that the code is under an acceptable free software or
open source license. Or Flatpak, for that matter, which is under simply
LGPL v2.1 or later.)
I'm not a lawyer nor am I aware of any survey of FOSS projects using
CLAs or how they compare to comment. I recognize that CLAs are important
to Fedora and I'll relay the message.
Best regards
ZK