Follow Slashdot stories on Twitter

 



Forgot your password?
typodupeerror
×
Open Source Programming IT Linux

The Open Container Project and What It Means 54

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.
This discussion has been archived. No new comments can be posted.

The Open Container Project and What It Means

Comments Filter:
  • by Chris Mattern ( 191822 ) on Wednesday June 24, 2015 @03:53PM (#49980659)

    At least in a lot of places: https://en.wikipedia.org/wiki/... [wikipedia.org]

  • by Anonymous Coward

    It means that we'll get to hear hipsters drone on about how "great" it is, until its serious flaws and limitations (which all software systems have) become very obvious and problematic, at which point they'll jump onto the bandwagon of the next fad technology, and the rest of us will be left cleaning up the messes they've left behind.

    • Re:It means... (Score:5, Insightful)

      by Anonymous Coward on Wednesday June 24, 2015 @04:16PM (#49980805)

      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*

      • by Anonymous Coward

        It's difficult to manage many applications that all rely on slightly different versions of libraries.

        True, but if the damn library writers coded the things properly in the first place (read "no stupid buffer overflows or similar vulnerabilities") we wouldn't have so fricking many versions of the libraries in the first place. Ditto if the software developers didn't insist on using the latest patch-du-jour just in case, rather than actually analyze their code (heresy!) for what it needs.

        • by Anonymous Coward

          Vulnerabilities and their ilk should not effect the use of their application programming interface. You should be able to change how something is implemented behind the scenes to close off those avenues of attack without breaking applications using your components. If an interface changes significantly to break compatibility, it should be renamed---continue to have the old interface supported even if that is routed to the new interface "safely" behind the scenes.

      • Re:It means... (Score:4, Insightful)

        by Anonymous Coward on Wednesday June 24, 2015 @04:52PM (#49981031)

        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.

      • Re:It means... (Score:4, Insightful)

        by Rutulian ( 171771 ) on Wednesday June 24, 2015 @10:40PM (#49982985)

        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?

  • by Anonymous Coward

    No Oracle? Shocking.

    • by Lennie ( 16154 )

      Why would they, they are not doing anything with Linux containers right now.

      And most of the Sun developers of Solaris had left after when Oracle bought Sun.

    • by dbIII ( 701233 )

      No Oracle? Shocking.

      They have zones.

  • When you get a project with a bazillion vendors and no "benevolent" dictators... It will end up as politicware.

    See Openstack or SDMI.

    • by Anonymous Coward

      When you get a project with a bazillion vendors and no "benevolent" dictators... It will end up as politicware.

      See Openstack or SDMI.

      "Open" idea comes about where entrenched vendors view it as a threat to existing revenue streams, and choose to band together to ensure the overall "open" project is anything but.

      I'm sorry...what seems to be the problem here again, other than failure is in fact the intended design and goal?

  • by Anonymous Coward on Wednesday June 24, 2015 @04:31PM (#49980909)

    A container is what used to be called a virtual machine running a single application.

    • A container is what used to be called a virtual machine running a single application which is fucking amazing, like a standardized cargo container on a boat from Hanoi to Wyoming.

      TFTFY [github.com]

      • Screw the computer stuff; I'm excited to hear about this new technology that lets gigantic cargo ships sail to Wyoming!

      • > which is fucking amazing, like a standardized cargo container on a boat from Hanoi to Wyoming.

        Which is the dumbest fucking analogy I have heard in a long time. Shipping containers come in a standard width and size, with standard size doors, standardised locks, and standardised locations for documents, cranes to attach to etc. It was revolutionary.

        A docker container, or any kind of similar thing, is no such thing, and is not comparable in any way, other than saying "you can execute whatever frankenstein

    • by TeknoHog ( 164938 ) on Wednesday June 24, 2015 @05:17PM (#49981201) Homepage Journal

      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"?

      • 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"?

        Yeah, but then we decide to adopt shared libraries and that messed everything up.

      • I remember and it was terrible! The OS was never designed to keep applications from talking to other applications on the system. (As an AS/400 novitiate and SE adherent, I should say "practically never.")

        OS application management is something that is not as secure as a virtual machine or a jail or a container, so if you miss the days when the OS was doing it, you didn't have the problems these things are designed to solve.

        Containers aren't just virtual machines running a single application either. VMs are a

    • by Rutulian ( 171771 ) on Wednesday June 24, 2015 @10:49PM (#49983015)

      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.

      • I've had a bit of time to play with Docker, and for the most part, it's gone pretty well and I quite like it (it feels like it has some rough edges, but I guess those'll get sorted out over time).

        In a (possible) future, $work wants to replace VMs with containers. Some of those VMs are imaginary at the moment, as we'll tend to run multiple instances (of say Tomcat, Apache, Postgres, whatever) on a single box, and then 'migrate' some of them to another box when things get a bit short on resource.

        At present, w

        • Well, containers (some variants, at least) do offer the ability to constrain resources. You should be able to prevent your Apache container from using up all of the memory on your system, for example. But the real strength of a container is the ability to just pick it up and move it to another machine, even while it is running. So it helps your situation quite a bit. Instead of needing to reprovision everything every time you move to a newer bigger box, you just configure the base system and drop the contai

          • by pnutjam ( 523990 )
            I've been toying with a container for a bit-torrent, so I can run a vpn without losing my external inbound ssh.
  • by fahrbot-bot ( 874524 ) on Wednesday June 24, 2015 @06:41PM (#49981733)

    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.

    And the band of new brothers and sisters set off on their Quest, little realizing that buried deep in the core code was this:

    One Container to rule them all, One Container to find them,
    One Container to bring them all and in the darkness bind them.

    Many would die along the way.

Truly simple systems... require infinite testing. -- Norman Augustine

Working...