Slashdot Mirror
The Open Container Project and What It Means
An anonymous reader writes: Monday saw the announcement of the Open Container Project in San Francisco. It is a Linux Foundation project that will hold the specification and basic run-time software for using software containers. The list of folks signing up to support the effort contains the usual suspects, and this too is a good thing: Amazon Web Services, Apcera, Cisco, CoreOS, Docker, EMC, Fujitsu Limited, Goldman Sachs, Google, HP, Huawei, IBM, Intel, Joyent, the Linux Foundation, Mesosphere, Microsoft, Pivotal, Rancher Labs, Red Hat, and VMware. In this article Stephen R. Walli takes a look at what the project means for open source.
Sadly, in this case, you're pretty much right on. Docker, et al., really prove the old canard that "any problem in software can be solved with another layer of abstraction."
The chroot jails have been around forever and IBM's been doing more robust forms of containers/virtualization for decades. The current crop of containers chose to ignore all the past work and no one called them on it (well, actually, a lot of people did, but in true hipster fashion, the feedback was ignored because this time, you know, it's different).
But, that ignores the problem that modern containers really exist to solve dependency hell (remember that thing we used to always mock Windows for? Yeah, Karma's a bitch). It's difficult to manage many applications that all rely on slightly different versions of libraries. So, let's just containerize/virtualize everything and pretend there's not a more fundamental underlying problem.
And, there's the annoying tendency of container users (and VM users) to treat everything as root within the context of the container/VM, reintroducing a bad practice that was almost eliminated after the initial outbreak when Linux first became popular. (are container users the anti-vaxxers of software?)
*sigh*
If you're going to containerize every little application, you might as well go back to statically linking application dependencies, save perhaps libc. Save a bit of overhead there.
A container is what used to be called a virtual machine running a single application.
Remember when men were men and such containment was the job of an "operating system"?
Escher was the first MC and Giger invented the HR department.
But, that ignores the problem that modern containers really exist to solve dependency hell
Uh, no, that is not why containers exist at all. Containers are the linux equivalent of BSD jails and Solaris zones, which have many use cases. While you CAN use containers to manage dependencies, there are many other (better) ways to do that.
And, there's the annoying tendency of container users (and VM users) to treat everything as root within the context of the container/VM,
I don't know anybody who does this. Who do you work with?
Jeez, slashdot really is a shell of its former self. None of my containers run "a single application." The benefits of a container over a VM when you are running on the same core OS on the same architecture should be obvious to anyone who manages servers. What Docker containers bring over "ordinary" containers is superior portability. So, yeah, it is good for software deployment, but nobody is going to use it to bundle libreoffice.