Live data from Hacker News

Celebrating the Open Container Initiative Image Specification

coreos.com

11–19 of 19 posts

Re: Celebrating the Open Container Initiative Image Specification

#11
post #8

Weren't containers supposed to solve the whole "one interface for everything" nonsense? Now we have a standard interface for the standard interface?

This is a community standard for how image artifacts should look. Right now, everyone is building systems against the Docker image specification which is problematic because Docker can and should be able to modify and extend it however they please. By agreeing on a common image spec, support for features can be more consistently available as they appear while Docker and others can extend and innovate for customers that want those specific features.

As an comparative example, we have common CSS specs which provide consistent support for most features as they are included, but Chrome, Mozilla, and WebKit are still able to experiment with new features.

Re: Celebrating the Open Container Initiative Image Specification

#12

CoreOS has done a lot of work to avoid a monoculture of Docker containers, and I think we all benefit from the interchangeability of different implementations/runtimes. The future of containers just keeps getting brighter and brighter.

Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

Re: Celebrating the Open Container Initiative Image Specification

#13

CoreOS has done a lot of work to avoid a monoculture of Docker containers, and I think we all benefit from the interchangeability of different implementations/runtimes. The future of containers just keeps getting brighter and brighter.

Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

Not necessarily. You need a platform which supports Linux syscalls, but you don't need Linux per se. Unlike VMs, containers sit above the kernel so you're tied to its interface but not its implementation. For example, see Solaris' LX Branded Zones.

Re: Celebrating the Open Container Initiative Image Specification

#14

Earlier quoted context omitted.

Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

Not necessarily. You need a platform which supports Linux syscalls, but you don't need Linux per se. Unlike VMs, containers sit above the kernel so you're tied to its interface but not its implementation. For example, see Solaris' LX Branded Zones.

At Joyent, our Triton cloud stack is built on illumos (nee Solaris) LX branded zones. We also have a Docker-compatible remote API, so not only can you run unmodified Linux binaries in containers, you can do so using the regular Docker client CLI!

Re: Celebrating the Open Container Initiative Image Specification

#15

CoreOS has done a lot of work to avoid a monoculture of Docker containers, and I think we all benefit from the interchangeability of different implementations/runtimes. The future of containers just keeps getting brighter and brighter.

Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

While not true yet, Docker is working on this by replacing the underlying LXC with their own secret sauce (at least last I checked). I suspect this is a result of their partnership with Microsoft (http://www.zdnet.com/article/dockers-unikernel-acquisition-t...). They were also moving towards creating proprietary and unique management tools before CoreOS started putting pressure on them.

Also notable is Docker isn't just containers, but they also have strong design opinions and container "philosophy".

Re: Celebrating the Open Container Initiative Image Specification

#16
post #6
post #4

Earlier quoted context omitted.

No, appc isn't moribund; the appc community continues to maintain the spec[1][2]. Our hope is that the best parts of the appc will be added into the OCI for a shared industry standard. And today I am optimistic the OCI will do that. The OCI membership includes important parties in the ecosystem from container engine implementers to public providers with container registries: Google, Microsoft, Amazon, Docker, CoreOS,…

Your first link says this: >>Q: What happens to AppC or Docker Image Formats? >>A: Existing formats can continue to be a proving ground for technologies, as needed... Sounds pretty moribund to me. It exists only if it wants to be a proving ground, "as needed".

That depends on what happens with OCI.

Re: Celebrating the Open Container Initiative Image Specification

#17

Earlier quoted context omitted.

Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

Not necessarily. You need a platform which supports Linux syscalls, but you don't need Linux per se. Unlike VMs, containers sit above the kernel so you're tied to its interface but not its implementation. For example, see Solaris' LX Branded Zones.

Dropping POSIX in favor of a syscall ABI implicitly defined by Linux's implementation is a pretty substantial backwards step.

Re: Celebrating the Open Container Initiative Image Specification

#18

CoreOS has done a lot of work to avoid a monoculture of Docker containers, and I think we all benefit from the interchangeability of different implementations/runtimes. The future of containers just keeps getting brighter and brighter.

Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

It would work fine on OS X if that operating system actually had equivalent control group or namespace functionality. OS X / Darwin lack these features, hence the boot2docker VM.

Re: Celebrating the Open Container Initiative Image Specification

#19

CoreOS has done a lot of work to avoid a monoculture of Docker containers, and I think we all benefit from the interchangeability of different implementations/runtimes. The future of containers just keeps getting brighter and brighter.

Isn't this just a Linux monoculture? It's not like you can run most containers as-is on a platform like OS X without actually virtualizing Linux itself.

Docker runs natively on FreeBSD as of release 11 (which does require the new Linux 64-bit compatibility facility). It uses jails to achieve the same effect and in fact uses the very same images available on the default Docker hub. Also Docker has released beta engines for both Mac and Windows. So no, it's not a Linux monoculture even when considering only Docker.
Post reply on HN