what I did differently was basically say that it should be a linux distribution. each layer should be equivalent to a debian/redhat package, with full dependency information between them. therefore it be easy to a) create an image (just pick the highest level things you want and the rest get resolved automatically, much like calling yum/apt-get in a Dockerfile) b) upgrade an image when you want to (i.e. similiar to upgrading an existing redhat/debian system, it just creates a new image artifact that can be tested and deployed)
you also don't have much hiding in the system as opposed to today. Yes, they might be built on debian, ubuntu or redhat, but you really can't verify easily what changes they made in the middle with ease. In my system, imagine there's a "Debian" layer repository, in general, you would end up with a bunch of easily verifiable debian layers and a small set of "user defined" layers (and when an image is deployed, the actual container layer). the user defined layers would be much harder to hide things in, i.e. it be very visible if one is overriding binaries or configuration files that you expect to come from a controlled package.
considering the amount of language and implementation that docker seems to share with mine that predates it, one has to wonder if they saw my talks / read my papers (though yes, its very possible they came up with it totally independently as well). They were active in the usenix and lisa communities (at least when they were more alive).
see: https://www.usenix.org/legacy/events/atc10/tech/full_papers/... and http://www.usenix.org/events/lisa11/tech/full_papers/Potter....
what I did differently was basically say that it should be a linux distribution. each layer should be equivalent to a debian/redhat package, with full dependency information between them. therefore it be easy to a) create an image (just pick the highest level things you want and the rest get resolved automatically, much like calling yum/apt-get in a Dockerfile) b) upgrade an image when you want to (i.e. similiar to upgrading an existing redhat/debian system, it just creates a new image artifact that can be tested and deployed)
you also don't have much hiding in the system as opposed to today. Yes, they might be built on debian, ubuntu or redhat, but you really can't verify easily what changes they made in the middle with ease. In my system, imagine there's a "Debian" layer repository, in general, you would end up with a bunch of easily verifiable debian layers and a small set of "user defined" layers (and when an image is deployed, the actual container layer). the user defined layers would be much harder to hide things in, i.e. it be very visible if one is overriding binaries or configuration files that you expect to come from a controlled package.
considering the amount of language and implementation that docker seems to share with mine that predates it, one has to wonder if they saw my talks / read my papers (though yes, its very possible they came up with it totally independently as well). They were active in the usenix and lisa communities (at least when they were more alive).