2:51 p.m.
Containers (and particularly, Docker-style containers with Kubernetes
orchestration) are rapidly taking over the server world. This is not
hyperbole, and while one might fairly throw "everything old is new
again", it's not a fad. This is a real generational shift.
We're at the forefront of this with Fedora Atomic Host (and OpenShift
Origin in Fedora as well). This is awesome.
I think these technologies are going to come to the desktop, too. Maybe
not Kubernetes for a while (although that certainly presents an
interesting picture of a hybrid-cloud-powered future), but certainly
container tech in some form — maybe it's an iteration of Jessie
Frazelle's Docker on the Desktop, maybe it's Snappy, maybe it's
Flatpak. I think Flatpak is a good bet, because I trust Alexander
Larsson's expertise in this space — and because it's aligned with OCI,
the Open Container Initiative. (Plus, using Docker inherently hacky,
and until Snappy gets the ability to use something other than an Ubuntu
binary runtime, it's a non-starter.)
In any case, I'm definitely interested in seeing the experiment.
Ever since Fedora started, we've had several somewhat-competing key
activities — making an awesome out-of-the-box operating system (in
whatever flavors), _and_ in packaging up a universe of useful
applications and tools for users. I know *I* love that when I install
Fedora, I can install a graphics editor or an alternate terminal
program or whatever without going out to a web search and hoping
whatever I come back with isn't sketchy.
We can definitely keep doing this as RPMs. That's fine; it's working,
and we're good at it. There's some pain, but we mostly know how to deal
with that pain. We also have a huge opportunity here to take that
accumulated wealth of packaged software and the expertise encoded in
that packaging and turn it into a trove of Flatpak applications. This
would bring the benefits of
* safe online updates
* a sandboxing model
* ability to mix and match versions and streams
* a sane way to install apps on Fedora Atomic Workstation
to Fedora users — but, also, it would immediately expand the reach and
impact of our work to users on other distros, where suddenly
Fedora-created packages run seamlessly. For graphical applications, the
work we do will immediately be multiplied in user impact. This is a
huge win with minimal effort on the part of packagers, once the planned
automation is all in place.
Is this a plan for expanding Fedora domination? Yes — but I think
it's a pretty friendly one. Let's share our awesome work with more
people!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
4:22 p.m.
Enviado desde mi iPhone
El 18 jul 2017, a las 21:51, Matthew Miller
<mattdm(a)fedoraproject.org> escribió:
Containers (and particularly, Docker-style containers with Kubernetes
orchestration) are rapidly taking over the server world. This is not
hyperbole, and while one might fairly throw "everything old is new
again", it's not a fad. This is a real generational shift.
We're at the forefront of this with Fedora Atomic Host (and OpenShift
Origin in Fedora as well). This is awesome.
I think these technologies are going to come to the desktop, too. Maybe
not Kubernetes for a while (although that certainly presents an
interesting picture of a hybrid-cloud-powered future), but certainly
container tech in some form — maybe it's an iteration of Jessie
Frazelle's Docker on the Desktop, maybe it's Snappy, maybe it's
Flatpak. I think Flatpak is a good bet, because I trust Alexander
Larsson's expertise in this space — and because it's aligned with OCI,
the Open Container Initiative. (Plus, using Docker inherently hacky,
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.
The basic vocabulary is there. You can define a base snap for any snap you make. There is
no nice out-of-the build system support yet but it will come in a few months.
There is more related stuff in flight that snapd team calls "layouts", that lets
developers describe the file system layout of the base snaps as well as for any app
snaps.
Combined you should expect a pure or hybryd fedora/suse/Debian/ubuntu system possible. We
have had untested fedora base (tongue-in-cheek called fedora core snaps) around but since
a lot of the things are not polished or final we didn't publish or publicize this more
yet.
In any case, I'm definitely interested in seeing the experiment.
Ever since Fedora started, we've had several somewhat-competing key
activities — making an awesome out-of-the-box operating system (in
whatever flavors), _and_ in packaging up a universe of useful
applications and tools for users. I know *I* love that when I install
Fedora, I can install a graphics editor or an alternate terminal
program or whatever without going out to a web search and hoping
whatever I come back with isn't sketchy.
We can definitely keep doing this as RPMs. That's fine; it's working,
and we're good at it. There's some pain, but we mostly know how to deal
with that pain. We also have a huge opportunity here to take that
accumulated wealth of packaged software and the expertise encoded in
that packaging and turn it into a trove of Flatpak applications. This
would bring the benefits of
* safe online updates
* a sandboxing model
* ability to mix and match versions and streams
* a sane way to install apps on Fedora Atomic Workstation
to Fedora users — but, also, it would immediately expand the reach and
impact of our work to users on other distros, where suddenly
Fedora-created packages run seamlessly. For graphical applications, the
work we do will immediately be multiplied in user impact. This is a
huge win with minimal effort on the part of packagers, once the planned
automation is all in place.
Is this a plan for expanding Fedora domination? Yes — but I think
it's a pretty friendly one. Let's share our awesome work with more
people!
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
5:55 p.m.
Correct me if I am wrong but Snap has other limitations too such as no sandboxing on
Fedora, no ability to add multiple remote repositories, limited desktop integration
compared to Flatpaks Portals.
6:08 p.m.
Enviado desde mi iPhone
El 19 jul 2017, a las 0:55, Patrick Griffis
<tingping(a)tingping.se> escribió:
Correct me if I am wrong but Snap has other limitations too such as no sandboxing on
Fedora, no ability to add multiple remote repositories, limited desktop integration
compared to Flatpaks Portals.
It is true we cannot rely on apparmor and SElinux support is only a possibility that
nobody is hacking on at the moment. On Fedora we still have the same seccomp snadboxing
and a few related mechanisms, such as udev tagging of devices, device cgroup and a dbus
xml configs. Apparmor may soon be stackable under SElinux (and vice versa I hear) so we
may get the same confinement as on pure apparmor distributions. Ideally someone would step
up and work on full blown SElinux support but that is a large task that nobody has
attempted yet.
Multiple repositories are a design decision that shifts the complexity and decisions away
from the edge. A device points to one repository that in turn may aggregate and filter any
number of repositories. This is already used in the field by various snap-based products.
As for desktop support I think we are only off on theming but that is benign pursued.
Snaps are not opinionated on existing software like flatpaks are. You can put gcc or
apache into a snap and it will work fine. It won't needs to use portals. You can also
put gnome apps in a snap and they can choose to use portals or can work the old way,
without any trusted helpers that mediate access and act as file pickers. I believe Ubuntu
desktop developers are working on integrating portals with snappy interfaces (so that they
can be used by apps that understand them). If tomorrow there is another portal or another
portal like thing that is all he same for snapd. It is just another interface.
Let me know if you have any questions. I'm eager to spread the knowledge and help
everyone understand how snaps work.
Best regards
ZK
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
1:49 a.m.
On Tue, 2017-07-18 at 15:51 -0400, Matthew Miller wrote:
* ability to mix and match versions and streams
Hi,
my personal knowledge of Flatpak is close to zero at the moment, thus
this is more a newbie reply.
My understanding of Flatpak, and the main advantage of it from my point
of view, is to get most recent versions of applications to the users as
soon as possible, without a need to reinstall whole system due to (up
or down) dependencies, which sounds pretty cool. One can run software
for the most recent Fedora on years old Fedoras (not only Fedora, but
let's make it simple here), everything is just a matter of using proper
runtime and bundle libraries which are required for the application.
The downside is disk usage, but I do not want to reopen this here, it
had been widely discussed in the "F27 System Wide Change: Graphical
Applications as Flatpaks" thread. I suppose you plan to have several
runtimes, to avoid having installed Fedora, then two other Fedoras as
runtimes, when one would like to test two different versions on a
running system, where the same application (and/or its possibly
incorrect dependencies) is installed as well.
That thread opened also one question about versions and user data. If
you use an application which changed its internal data format between
two versions, but you still want to run both versions (like to be able
to test differences and eventually catch regressions), then you cannot
share user data between them, can you? The application certainly
supports switch from old format to the new, not vice versa (how would
old software knew about the new format?). How is this dealt with in
Flatpak world? Should each application tell Flatpak to use different
XDG directories, in which case the user data will not be shared between
applications?
What about DConf settings. While at least I only add new GSettings
keys, once some version removes a key it cannot be shared with the
older versions (GSettings aborts the application on missing
schemas/keys), or it'll be a mess, on the first look.
What about critical path packages? Are those meant to be part of the
runtime? Or should each of the applications bundle them? Imagine a real
life example, gnome-todo, gnome-contacts, gnome-calendar and Evolution.
They all use evolution-data-server and it's evolution-data-server,
which takes care of storing locally cached data. The 3.26.x has changed
background data storage for contacts and calendars. If I want to be
sure that each of them uses correct data server, then either I bundle
it to each of them, or I use a runtime which contains it. Due to the
data format change I cannot use shared home, even though they all are
meant to share it, to avoid redefinition of the accounts for each
application (passwords/OAuth2 tokens through keyring could be probably
shared).
What about the connection to GNOME Online Accounts? To have consistent
behavior, bundle it as well? Or it'll be part of some runtime? Could
those GOA accounts be shared between different versions? There's
similar problem with internal data format like with the data server.
I've been told that debugging of Flatpak applications is no fun. I
didn't try it myself, thus I cannot tell for sure, but for me as a
consumer the use of Flatpak to deliver software early also means that
I'd be able to debug regressions easily, from getting debug logs turned
on with environment variables, down to getting useful backtraces of
crashed or running applications.
That is, if I want to deliver an application to the users early, no
matter what distribution they use, I'm meant to use proper runtime,
bundle as much as possible, thus the code can actually run anywhere and
consistently, and use specific XDG directories per each Flatpak. That
pretty much sounds like a work for the upstream, not for the Fedora,
because using Fedora runtime means getting tight to Fedora only. Or
not? My natural choice would be to use GNOME runtime instead (though
I've no idea about its usability on other distributions than it is
built on).
Am I understanding this wrong, both from the Fedora point of view and
from the upstream point of view?
Thanks and bye,
Milan
11:20 a.m.
On Wed, 2017-07-19 at 08:49 +0200, Milan Crha wrote:
On Tue, 2017-07-18 at 15:51 -0400, Matthew Miller wrote:
> * ability to mix and match versions and streams
Hi Milan -
Thanks for all the questions! Some of these are better brought up on a
Flatpak or GNOME mailing list and you'd get better answers, but I'll
answer to the best of my ability here.
I also think that Evolution is pretty much a worse case scenario for
putting into a Flatpak - it stores huge amounts of data, shares that
data with the rest of the GNOME desktop, and has all sorts of
complicated ties built up over many years of shared history. It's great
to think about how it will work in a Flatpak, but we shouldn't get
depressed if it seems hard - not all applications are that hard!
my personal knowledge of Flatpak is close to zero at the moment,
thus
this is more a newbie reply.
My understanding of Flatpak, and the main advantage of it from my
point of view, is to get most recent versions of applications to the
users as soon as possible, without a need to reinstall whole system
due to (up or down) dependencies, which sounds pretty cool. One can
run software for the most recent Fedora on years old Fedoras (not
only Fedora, but let's make it simple here), everything is just a
matter of using proper runtime and bundle libraries which are
required for the application.
The downside is disk usage, but I do not want to reopen this here, it
had been widely discussed in the "F27 System Wide Change: Graphical
Applications as Flatpaks" thread. I suppose you plan to have several
runtimes, to avoid having installed Fedora, then two other Fedoras as
runtimes, when one would like to test two different versions on a
running system, where the same application (and/or its possibly
incorrect dependencies) is installed as well.
I'm not entirely sure I follow the question, but yes, if you want to
run F27 applications, you'd have the F27 runtime installed as well.
It's not going to be tiny, but it will be a lot smaller than a full
install of F27.
That thread opened also one question about versions and user data.
If
you use an application which changed its internal data format between
two versions, but you still want to run both versions (like to be
able to test differences and eventually catch regressions), then you
cannot share user data between them, can you? The application
certainly supports switch from old format to the new, not vice versa
(how would old software knew about the new format?). How is this
dealt with in Flatpak world? Should each application tell Flatpak to
use different XDG directories, in which case the user data will not
be shared between applications?
Well, it's largely up to the application author to evolve their data
and settings in a way that is backwards compatible. I think a lot of
application authors do that anyways, because they want to be working on
new versions of their application while still maintaining a stable
branch. If an application has to break storage formats, it probably is
better to do it as a one-time-migration leaving the old data in place.
(This is obviously not practical if the data is 20GB of email!)
Flatpak bases where it stores the data of the application off of the
application ID. You can change the application ID and get a clean slate
- but then you don't have migration. (Nightly development builds in
particular may use a different application ID so that they can be tried
out "risk-free")
What about DConf settings. While at least I only add new GSettings
keys, once some version removes a key it cannot be shared with the
older versions (GSettings aborts the application on missing
schemas/keys), or it'll be a mess, on the first look.
GSettings schemas are considered part of the application, and are
shipped in the Flatpak. What would be shared is the (schema-less) DConf
storage. If the DConf storage mismatches the schemas, the schemas will
be used to provide default values.
There are certainly still cases where the application could change
settings in a way that would cause old application versions to have
problems. Application authors generally need to to take care not to
change the meaning of existing settings keys, only add new ones.
What about critical path packages? Are those meant to be part of the
runtime? Or should each of the applications bundle them? Imagine a
real life example, gnome-todo, gnome-contacts, gnome-calendar and
Evolution. They all use evolution-data-server and it's evolution-
data-server,which takes care of storing locally cached data. The
3.26.x has changed background data storage for contacts and
calendars. If I want to be sure that each of them uses correct data
server, then either I bundle it to each of them, or I use a runtime
which contains it. Due to the data format change I cannot use shared
home, even though they all are meant to share it, to avoid
redefinition of the accounts for each application (passwords/OAuth2
tokens through keyring could be probably shared).
evolution-data-server is definitely a problem for the Flatpak model -
the entire idea of Flatpak is that different applications and the
operating system can be updated separately. If Evolution, GNOME
Contacts, and the operating system (GNOME Shell) are bound together by
a complicated, evolving D-Bus service, then that simply isn't possible.
It would be possible to have contacts and calendar events as "portals"
- as services provided by the operating system to applications. But
then that would have to be tightly version controlled, there would have
to be a security model, and there would have to be some plan that would
work when the desktop doesn't include EDS (what if you are running on
KDE?) Would the flatpak runtime include a simple implementation?
Generally, it's least surprising if data is scoped to the application,
and that's the model we plan for. But I understand it's not how
Evolution works currently. I'd encourage you to discuss this within the
GNOME community.
What about the connection to GNOME Online Accounts? To have
consistent behavior, bundle it as well? Or it'll be part of some
runtime? Could those GOA accounts be shared between different
versions? There's similar problem with internal data format like with
the data server.
I don't think bundling GNOME Online Accounts makes sense - it appears
like part of the desktop to the user. In the unsandboxed case, you can
just access the D-Bus service from your application.
We'd need an "accounts portal" of some sort for the sandboxed case,
figuring out the security model and user interaction, since arbitrary
applications should definitely not be able to get your credentials from
GOA. Again you'd need a fallback implementation - which could simply be
"no I don't have any account information".
I've been told that debugging of Flatpak applications is no fun.
I
didn't try it myself, thus I cannot tell for sure, but for me as a
consumer the use of Flatpak to deliver software early also means that
I'd be able to debug regressions easily, from getting debug logs
turned on with environment variables, down to getting useful
backtraces of crashed or running applications.
We definitely don't want debugging Flatpak applications to be no fun!
Some of it is a matter of maturity of tooling, some of it is a matter
of experience... hopefully it's getting better all the time.
With Flatpaks built with flatpak-builder, the debug information is
available as an "extension" that you can install with the application.
The same will have to be done for Flatpaks built with Fedora content,
though we haven't fully figured out the details there.
That is, if I want to deliver an application to the users early, no
matter what distribution they use, I'm meant to use proper runtime,
bundle as much as possible, thus the code can actually run anywhere
and consistently, and use specific XDG directories per each Flatpak.
That pretty much sounds like a work for the upstream, not for the
Fedora, because using Fedora runtime means getting tight to Fedora
only. Or not? My natural choice would be to use GNOME runtime instead
(though I've no idea about its usability on other distributions than
it is built on).
It will be entirely possible to run Fedora Flatpaks on other
distributions - to say "if you want to try out Evolution 3.26 - install
the Fedora flatpak". A user that installs the Fedora flatpak will see
the Fedora stream of security updates - you'd need to be responsible
for that yourself if you shipped an application built directly from
source.
Owen
11:43 a.m.
New subject: Snappy [was Re: Fedora, apps, and the Flatpak opportunity]
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
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 would *love* to see more collaboration between Flatpak and Snappy,
possibly even leading to a unified, merged solution in the future, but
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.
(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.)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
2:36 p.m.
New subject: Snappy [was Re: Fedora, apps, and the Flatpak opportunity]
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
3:14 p.m.
New subject: Snappy [was Re: Fedora, apps, and the Flatpak opportunity]
On Wed, Jul 19, 2017 at 09:36:25PM +0200, Zygmunt Krynicki wrote:
> 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,
[...]
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).
We prefer to work with upstreams rather than making forks, though. I
guess that could be one approach but it doesn't really seem great for
anyone, especially not in the interest of universality.
> 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.
I'm not rejecting all CLAs. I find this particular one troubling when
used in conjunction with a copyleft license like GPL. It puts Canonical
in a particular privileged place to take the project to an "open core"
proprietary model. I don't think that Canonical is likely to do that
*now*, but the future is hard to be certain about. (And if that's not a
concern, why is it so important to have the CLA phrased this way?)
It's perfectly fine if Canonical wants to do this. You're right that
the initial investment in code is a big deal. I'm not saying it's
wrong; just that it's a big barrier to large-scale adoption in Fedora
and probably in other distros as well.
The Harmony CLA template Canonical uses has _other_ options for the
relevant sections, like promising to use licenses in the same family,
licenses approved the FSF, or just a list of possible licenses. If the
goal is to make a universal system, it seems like a better choice. (Or,
like I said, to use something other than GPL, which removes the
asymmetry.)
--
Matthew Miller
<mattdm(a)fedoraproject.org>
Fedora Project Leader
10:54 p.m.
Matthew Miller wrote:
Containers (and particularly, Docker-style containers with
Kubernetes
orchestration) are rapidly taking over the server world. This is not
hyperbole, and while one might fairly throw "everything old is new
again", it's not a fad. This is a real generational shift.
This premise is already questionable. I can see large organizations like Red
Hat using these (e.g., so they can easily move services from one physical
server to another), but for the servers that I take care of (my personal VPS
and my employer's server), I don't have any use for containers. All that
they would give me is a lot more maintenance work. The typical server
software is the same as always: Apache httpd, Tomcat, etc., which have all
been packaged nicely as native packages for years. I am surely not the only
admin who feels like that.
Kevin Kofler
2:27 a.m.
On Wed, 2017-07-19 at 12:20 -0400, Owen Taylor wrote:
...and there would have to be some plan that would work when the
desktop doesn't include EDS (what if you are running on
KDE?) Would the flatpak runtime include a simple implementation?
Hi,
there is no such thing like "simple implementation", if you mean
evolution-data-server. And even you highlight Evolution, it's not about
it. It's about evolution-data-server, which serves as a data storage
for Evolution, GNOME Contacts, GNOME Calendar, GNOME To Do, GNOME
Shell, bijiben, geary and so on. The evolution-data-server is a hard
dependency for these. When you run an application which needs any of
the services provided by evolution-data-server, regardless which
desktop environment you are running, then the services are run on
demand. Transparently. No problem with it.
The nice thing with the current RPM is that all the data is shared
between all those applications, thus you can check your calendars both
in Evolution and GNOME Calendar, without a need to configure them
separately to know about the same calendars. Similarly for other
products. And count to it also GNOME Online Accounts, as a central
place to define accounts, which can be picked by various applications.
That's an advantage and had been advertised as such when GOA became
alive. Such advantage should stay in place once you'd like to provide
GUI applications as Flatpak in Fedora.
If I understood it properly, then you suggest that these sharing will
be impossible in Flatpak delivered GUI applications. That feels like a
regression, at least to me. It's nice that there is used GNOME Recipes
as a "proof of concept" when it's used as a Flatpak-only delivery in
Fedora 26, but it's no real GUI application, it has no real
dependencies. You might use "nano" for the same "proof of concept".
The
worse that the plan is to have all GUI applications delivered as
Flatpak. You might pick something more complicated, what actually uses
core system services to deliver certain value to users, to have the
proof of concept. Otherwise you have "this works for this Fedora and no
where else". From my point of view. On the other hand, if GUI
applications delivered as Flatpak in Fedora are meant for certain
version of Fedora, then it's all fine. In that case the Flatpak would
not be meant as a generic runable package on any distribution, only on
that certain Fedora.
It would be different when trying latest stable/development version of
the GUI application on an outdated Linux. It is expected to not have
that data sharing advantage there, from my point of view. But on the
other hand, such Flatpaks would be provided by the upstream, not by
Fedora.
I briefly looked into the Flatpak build script for GNOME Calendar [1]
and it builds its own evolution-data-server. At least the upstream
version. It makes sense. If I would create a Flatpak for Evolution,
then I'll do the same. Might or might not it be done in Fedora too,
when built from rpm?
I don't think bundling GNOME Online Accounts makes sense - it
appears
like part of the desktop to the user. In the unsandboxed case, you
can just access the D-Bus service from your application.
Evolution-data-server links to it and it's a soft build-time
dependency. No D-Bus hacking, just using provided C API by GOA.
We definitely don't want debugging Flatpak applications to be no
fun!
Ah, great, then I've been misinformed. I'm sorry about that.
Thanks and bye,
Milan
[1]
https://git.gnome.org/browse/gnome-calendar/tree/org.gnome.Calendar.json?...
3:01 a.m.
I am no flatpack expert, but I think that really any container technology
in question should be just a porter of an rpm or set of rpms and there
should (could) be packaged ansible scripts that are able to setup and spawn
those containers e.g. in OpenShift or just on a host machine through ssh or
by other communication means. This approach is not bound to a particular
container technology and therefore provides huge amount of flexibility. We
could also actually provide flatpacks for downloading to create some 'halo'
effect but that again should be result of an automated image-creation
process in which we should be able to chose what kind of containerization
we want.
Really, if you can put rpms you want on the host system without any
container encapsulation, that will always be superior because containers
are just another added layer. They don't provide anything else than a way
to avoid conflicts. There is no gain in using them except portability but
that does not mean they need to be an end product. They can be an end
product but then that doesn't mean we need to stop working with rpm
internally. I am sorry if I am stating obvious things here.
clime
On Thu, Jul 20, 2017 at 5:54 AM, Kevin Kofler <kevin.kofler(a)chello.at>
wrote:
Matthew Miller wrote:
> Containers (and particularly, Docker-style containers with Kubernetes
> orchestration) are rapidly taking over the server world. This is not
> hyperbole, and while one might fairly throw "everything old is new
> again", it's not a fad. This is a real generational shift.
This premise is already questionable. I can see large organizations like
Red
Hat using these (e.g., so they can easily move services from one physical
server to another), but for the servers that I take care of (my personal
VPS
and my employer's server), I don't have any use for containers. All that
they would give me is a lot more maintenance work. The typical server
software is the same as always: Apache httpd, Tomcat, etc., which have all
been packaged nicely as native packages for years. I am surely not the only
admin who feels like that.
Kevin Kofler
_______________________________________________
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
7:25 p.m.
Michal Novotny wrote:
I am no flatpack expert, but I think that really any container
technology
in question should be just a porter of an rpm or set of rpms and there
should (could) be packaged ansible scripts that are able to setup and
spawn those containers e.g. in OpenShift or just on a host machine through
ssh or by other communication means. This approach is not bound to a
particular container technology and therefore provides huge amount of
flexibility. We could also actually provide flatpacks for downloading to
create some 'halo' effect but that again should be result of an automated
image-creation process in which we should be able to chose what kind of
containerization we want.
Keep in mind that Ansible is also something small-scale admins don't use. It
only makes sense at all if you have at least 2 servers, and it is only
really worthwhile if you have several, mostly identical servers. If you have
just one server, or two or three servers with very different configuration
from each other, it's just not worth it. So the workflow you suggest
introduces an extra learning curve.
Kevin Kofler
1:31 a.m.
On Fri, Jul 21, 2017 at 1:25 AM, Kevin Kofler <kevin.kofler(a)chello.at> wrote:
Michal Novotny wrote:
> I am no flatpack expert, but I think that really any container technology
> in question should be just a porter of an rpm or set of rpms and there
> should (could) be packaged ansible scripts that are able to setup and
> spawn those containers e.g. in OpenShift or just on a host machine through
> ssh or by other communication means. This approach is not bound to a
> particular container technology and therefore provides huge amount of
> flexibility. We could also actually provide flatpacks for downloading to
> create some 'halo' effect but that again should be result of an automated
> image-creation process in which we should be able to chose what kind of
> containerization we want.
Keep in mind that Ansible is also something small-scale admins don't use. It
only makes sense at all if you have at least 2 servers, and it is only
really worthwhile if you have several, mostly identical servers. If you have
just one server, or two or three servers with very different configuration
from each other, it's just not worth it. So the workflow you suggest
introduces an extra learning curve.
Actually I disagree with you, I know people that use ansible to manage
their laptop config (IE a single device) so that if they rebuild it
they can get all their configs back quickly.
While ultimately you do get better scale with ansible across a lot of
similar devices it's by no means the only way people use it, just
because it's not the way you would.
2:08 p.m.
On Fri, 2017-07-21 at 07:31 +0100, Peter Robinson wrote:
> Keep in mind that Ansible is also something small-scale admins
don't use. It
> only makes sense at all if you have at least 2 servers, and it is
only
> really worthwhile if you have several, mostly identical servers. If
you have
> just one server, or two or three servers with very different
configuration
> from each other, it's just not worth it. So the workflow you
suggest
> introduces an extra learning curve.
Actually I disagree with you, I know people that use ansible to
manage
their laptop config (IE a single device) so that if they rebuild it
they can get all their configs back quickly.
I agree with Peter, and I'll add another reason why Ansible is still
useful even if you only manage one system with it: it's a nice way to
describe everything that is different about your server from a clean
install (as code in git, so you can also get history). I find it
helpful to be able to answer the question "what is customized on this
system?"
2467
days inactive
2474
days old
14 comments
9 participants
participants (9)
-
Kevin Kofler -
Matthew Miller -
Michal Novotny -
Milan Crha -
Owen Taylor -
Patrick Griffis -
Peter Robinson -
Randy Barlow -
Zygmunt Krynicki