This model of containerization is a grand error

Posted Jun 21, 2015 11:48 UTC (Sun) by misc (subscriber, #73730)
In reply to: This model of containerization is a grand error by ksandstr
Parent article: Systemd and containers

In the end, it all depend on how and what you put in the containers. Nothing would prevent automation of containers rebuilding if you assemble them from the existing distribution infrastructure. The problem is one of policy, not of technology, since tar.gz, static compiling, source code bundling or rpm/deb/whatever all suffer from the risk of having a component not cleanly separated. And that's not theorical, since that's why Fedora mandate to not bundle anything ( unless exceptions ). Debian do also have the same policy, following a zlib problem back in the days.

On the desktop side, getting application containers from Fedora rawhide running on a centos 6 might solve the issue of people wanting latest version of something without upgrading to rawhide. It doesn't solve every problem, likely bring some news, but that's worth testing and doing. Companies handling lots of traffic ( facebook, google, twitter among others ) have been using that since years on server side, so I think they would have noticed security issues.

And in a true UNIX lore fashion, no software but one should deal with SSL, since this otherwise would violate the idea of doing one thing and doing it right. So application containers push for more of the UNIX paradigm on the server side.

This model of containerization is a grand error

Posted Jun 24, 2015 4:06 UTC (Wed) by dlang (guest, #313) [Link]

> And in a true UNIX lore fashion, no software but one should deal with SSL, since this otherwise would violate the idea of doing one thing and doing it right.

you completely misunderstand the Unix "do one thing and do it well" mantra. That doesn't in any way prohibit you from having multiple things that do the one job, it just means that one tool shouldn't try to do lots of different jobs.

This model of containerization is a grand error

Posted Jul 4, 2015 15:13 UTC (Sat) by ksandstr (guest, #60862) [Link]

On the contrary, the question is not what I put in a container, or what the GNU/Linux distribution puts in one. Rather, containers used in this fashion create an interface for distribution-independent blobs from (tautology aside) outside any given distribution and its anti-bundling policies. Such blobs will invariably be bundled with their dependencies: how could it even be otherwise given filesystem separation to the degree of "soft VM"?

In the absence of standardization for intra-container automation (as stated in the "PM must reach" paragraph), this leaves users of security-broken web-download software with two workable options: either they wait for the container publisher's update (which may come in the form of a major version update, perhaps for a cost), or they build the fixed container themselves. Obstacles to the latter can be many, such as the recent Firefox bundling of in-browser DRM plugins; and alternatives to these two all boil down to bending over for the NSA.

The effect of containerzation in the manner proposed in the main article is that Debian, Mint, Gentoo, etc. users will be as ripe a target market for Linux desktop app stores as Red Hat's customer base is for its RPM repository. Iterated, this development converges in the death of the individual distribution in favour of an effective monoculture as preferred by proprietary software companies. With it comes the death of Free Software.

In closing, systemd must be destroyed.