4 ms·

What we're seeing emerge here is a new universal binary format. I've thought of Docker containers for a long time as gigantic statically linked binaries. This

by api 11y ago

What we're seeing emerge here is a new universal binary format. I've thought of Docker containers for a long time as gigantic statically linked binaries. This isn't necessarily a bad thing (though it does present issues). In some ways the process of installing the different moving pieces of a service and configuring them is a bit like manually "linking" something -- sub-services like MySQL, Redis, etc. are analogous to libraries. Now what we're seeing is a runtime for this binary being ported around to different platforms. This could get interesting.

vezzy-fnord 11y ago
What we're seeing emerge here is a new universal binary format. Insofar as libcontainer can ram as many ways to implement OS-level virtualization across platforms, that is.
toomuchtodo 11y ago
> Now what we're seeing is a runtime for this binary being ported around to different platforms. This could get interesting. With x86 being the primary server/workstation workhorse (lets exclude mobile platforms for the moment), is all of this abstraction necessary? Doing Infrastructure and DevOps, I definitely see the benefit of containerization for build reproducibility and decreasing the friction developers face for running applications locally as they run in production. Not everyone needs Borg/Mesos/Mesosphere. Not everyone needs containerization. When you have a hammer though, everything starts looking like a nail.
- alexchamberlain 11y ago
  I bet they all use HTTP to communicate too... Seriously though, I tend to agree, could this be solved by using more static binaries?
  - felixrabe 11y ago
    It could, but there are many existing technologies (apps, libraries, languages) that are easier (and more consistently) turned into a container than into a static binary.
  - XorNot 11y ago
    A return to statically linkable glibc would be a good start on that. It's definitely the weakest link in the chain (as in, the only thing which a pulled in cgo dependency tends to start complaining about).
kraig 11y ago
it's effectively what apple has been doing in OSX with .app
pron 11y ago
Containers won't run across different OSes (Linux/Windows) without VM virtualization. The spec doesn't actually cover the executable binary format. In the end, a container process is just a native process of the host operating system that is isolated from other processes. There is no OS virtualization taking place.
- SEJeff 11y ago
  That entirely depends on your definition of "virtualization". I for one would completely consider all of the namespace support that docker/rkt/lxc use to be virtualization. The reason being since the container has a different pid/network/mount namespace from the host, it is a "virtualized" version thereof. Now clearly this is different than traditional full operating system virtualization ala KVM/Xen, but it is absolutely still a form of virtualization. Just because something is different doesn't make it wrong.

by api 11y ago

vezzy-fnord 11y ago

What we're seeing emerge here is a new universal binary format. Insofar as libcontainer can ram as many ways to implement OS-level virtualization across platforms, that is.

toomuchtodo 11y ago

> Now what we're seeing is a runtime for this binary being ported around to different platforms. This could get interesting. With x86 being the primary server/workstation workhorse (lets exclude mobile platforms for the moment), is all of this abstraction necessary? Doing Infrastructure and DevOps, I definitely see the benefit of containerization for build reproducibility and decreasing the friction developers face for running applications locally as they run in production. Not everyone needs Borg/Mesos/Mesosphere. Not everyone needs containerization. When you have a hammer though, everything starts looking like a nail.

alexchamberlain 11y ago
I bet they all use HTTP to communicate too... Seriously though, I tend to agree, could this be solved by using more static binaries?
- felixrabe 11y ago
  It could, but there are many existing technologies (apps, libraries, languages) that are easier (and more consistently) turned into a container than into a static binary.
- XorNot 11y ago
  A return to statically linkable glibc would be a good start on that. It's definitely the weakest link in the chain (as in, the only thing which a pulled in cgo dependency tends to start complaining about).

kraig 11y ago

it's effectively what apple has been doing in OSX with .app

pron 11y ago

Containers won't run across different OSes (Linux/Windows) without VM virtualization. The spec doesn't actually cover the executable binary format. In the end, a container process is just a native process of the host operating system that is isolated from other processes. There is no OS virtualization taking place.

SEJeff 11y ago
That entirely depends on your definition of "virtualization". I for one would completely consider all of the namespace support that docker/rkt/lxc use to be virtualization. The reason being since the container has a different pid/network/mount namespace from the host, it is a "virtualized" version thereof. Now clearly this is different than traditional full operating system virtualization ala KVM/Xen, but it is absolutely still a form of virtualization. Just because something is different doesn't make it wrong.