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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
