1. 2

Well, actually about time … this is the next step towards OCI and getting rid of the proprietary, strongly coupled runtime.

  1.  

  2. 3

    This article seems to imply that a core component of docker was not OSS until now; is that true, or is it just shoddy reporting?

    1. 5

      From my novice investigating, it looks like containerd has been open source since it’s gotten PRs from non-Docker persons:

      https://github.com/docker/containerd/pulls?q=is%3Apr+is%3Aclosed

      The article mentions moving containerd out of the Docker organization and into a neutral foundation which the Docker blog re-enforces but TechCrunch definitely used “open sourcing”/“open sources” wrong =/

      https://blog.docker.com/2016/12/containerd-core-runtime-component/

      1. 2

        Before containerd, there was no single module that one could use to execute Docker images as containers (except rkt, which always seemed like a proof of concept than a reliable tool). The capability was always there in the Docker code, just buried. Over time, they factored it out into a separate module and announced this back in April: https://blog.docker.com/2016/04/docker-containerd-integration/. I remember Michael Crosby talked about it at DockerCon back in June and was very excited, because we don’t like the Docker daemon, but we do want to run containers. Not exactly sure what the current “new release” is about, other than moving it out from under Docker and into the Open Container foundation?

        1. 2

          I suppose https://twitter.com/mreferre/status/809074712290689025 captures it best. Especially relevant in the context of Kubernetes (vs. rkt/AppC ;)

          1. 1

            I don’t understand that tweet – containerd was in the works well before the dustup around the Docker “fork”, which is what I presume the tweet was referencing.

            1. 1

              Hmmm, maybe around the politics vs. CRI?