On Wed, Jun 15, 2016 at 9:39 PM, Colin Walters <walters@xxxxxxxxxx> wrote: > Hi, > > On Tue, Jun 14, 2016, at 09:18 PM, Michael Catanzaro wrote: > >> Also, keep in mind that Flatpaks are not the only new type of software >> we intend to support in Fedora. I know other folks are looking into >> supporting Docker containers; I believe that's a Server WG initiative? > > One of the things that is still odd about Fedora is that people often > say "Fedora" and most of the time they mean as a desktop OS. > Why do you think that is weird? Fedora is a perfectly fine desktop Linux distribution. I'm wondering what your problem is if you think that it can't be. Yeah, I get that many of you guys at Red Hat don't care, but that doesn't mean that the rest of us don't. Besides, for a lot of people, mentioning "Fedora" and "server" in the same sentence in some positive manner would get you laughed right out! I personally like server platforms with fresh software, as I'm a firm believer in that keeping things fresh is the best way to be secure. Just because it's an unpopular opinion doesn't make it any less of a valid approach, though. > Anyways, so yes we've invested quite a lot in Docker for server containers, > and more specifically in Kubernetes and OpenShift v3. > > See: > > https://www.openshift.org/ > > for lots more, and the effort we spend on Docker and Atomic Host > is at http://www.projectatomic.io/ and that work lands in Fedora > as well as CentOS. Most of the production work honestly is in CentOS, > but there have been discussions about improving the server/cloud/OpenShift > state in Fedora as well. > Not that I don't like the underlying technologies that you're working on (I do, and I think rpm-ostree is wicked cool!), but it's pretty darn close-minded if you think of only one potential avenue for usefulness. Michael Catanzaro suffers from the same problem, but only from a different perspective. If we start off with the assumption that the approaches being done by Docker, Flatpak, and others is a reasonably sound approach (I could easily make the argument otherwise, and I have earlier in the thread), then it's important to pick apart what they are and what they do. Docker is a platform for distributing container construction scripts and base images. Much like how ebuilds and ports work, Dockerfiles are simple instructions to create *something* to use. However, the artifact it creates is a container filesystem tree, rather than a package that can be integrated into a system. Nothing about Docker provides any useful security in and of itself. Band-aids like using sVirt and whatnot help, but that's not available to everyone, so you can't assume everyone is using it. Flatpak is a mechanism for provided self-contained applications derived from already built artifacts, such as runtime images and application build artifacts. It's supposed to provide sandboxing and other things, but none of them are functional. It's also not very flexible, as it's designed exclusively for graphical applications. Snap is a mechanism like Flatpak, though it's also designed to support more use-cases than Flatpak. To some degree, it combines Docker and Flatpak into a single system. The big problem with Snaps is that they're effectively dead in the water security-wise on any distribution that isn't Ubuntu (and *maybe* openSUSE/SLES). Snaps, unlike Flatpaks, are able to handle *all* kinds of things, from web apps, to desktop graphical apps, to CLI and TUI apps, and even services and servers. Snaps have three big flaws: 1. For maximum usefulness an discovery, they have to be centrally registered with Canonical, who is the sole publisher. This is further compounded by the fact that none of the server components are planned to be open sourced (I asked this morning in #snappy), so there's not even a snowball's chance of democratizing the platform like there is with Docker. 2. Snaps are designed for apps that "bundle all the things" and don't provide an easy way to introspect and manage the state of the snaps included. There's no information on what a snap is composed of, and that's a huge security nightmare. The format is highly simplistic and encourages very fat bundles, which is not good for bandwidth or storage. Flatpaks are marginally better due to "runtimes" built into the design. 3. Snaps are expressly designed to integrate tightly with Ubuntu, and currently even relies on Ubuntu-specific code in various aspects of the OS (AppArmor, Ubuntu Software, etc.). It even goes so far as making it possible to compose and manage an operating system using Ubuntu packages as inputs. Snaps function very much like how Apple's ecosystem does for software delivery, and perhaps even Microsoft's UWP ecosystem too. It's very clear that the purpose of Snaps are to provide avenues to "encourage" people to lock into the Ubuntu platform. So far, I've seen people gloss over the real crux of the problem, which is that somehow we're trying to create walled gardens, and no one wants to fix that. The fact that LSB is a permanent failure is generally assumed and accepted and no one wants to try to solve the problem that way again. What in our world changed that made this an invalid solution? I'd argue nothing. It's still valid, and there are definitely ways to use that and combine it with sandboxing/security techniques to produce far more flexible alternatives than what everyone seems to want to push these days. But then again, who cares... Let's continue pushing for this where we just turn Linux into Windows in terms of security issues due to permanent vulnerabilities because we make it too easy for people to be irresponsible... Has everyone really forgotten the zlib nightmare of the early 2000s so quickly? -- 真実はいつも一つ！/ Always, there's only one truth! -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx
