If this is true, then we're about to become locked-in to Docker's "kitchen sink" model of application packaging, where we're back to the bad old days of applications that can only run on a single platform.

So much for the portability of modern language runtimes (Ruby, Java, Python, etc), or even being able to cross-compile to other platforms.

Docker solves the wrong end of application packaging by essentially packaging up the entire damn global (and non-portable) OS environment.

> Docker solves the wrong end of application packaging by essentially packaging up the entire damn global (and non-portable) OS environment.

While that's the convention, I don't believe that will be the case going forward. I think it's a pretty negative and short sighted response.

I saw a demo very recently of someone creating an extremely barebones container - they were able to trace the exact dependency tree of an application, isolate it, and put it in to a Docker container. All that existed was apps+dependency, no userland. That's the future, imo.

> So much for the portability of modern language runtimes (Ruby, Java, Python, etc), or even being able to cross-compile to other platforms.

Funny you should mention that, because cross compilation happens in Docker all of the time.

Does that address your concern? If not I'd be happy to discuss further.

> All that existed was apps+dependency, no userland. That's the future, imo.

How do I run that on something that isn't Linux?

The Mac OS X portability story is to run a Linux virtual machine (!).

How is this a sane model when compared to building applications as a self-contained entity?

> Funny you should mention that, because cross compilation happens in Docker all of the time.

I can cross-compile a target for (Mac OS X, Linux, Windows, FreeBSD) and ship it as a self-contained application that runs on any of those systems?

> I can cross-compile a target for (Mac OS X, Linux, Windows, FreeBSD) and ship it as a self-contained application that runs on any of those systems?

Java did that and everyone went away from it since support became "least of all worlds" for anything non-trivial.

For server-side code, where Docker operates, this isn't an issue.

I for one welcome Docker's model, whereby I may remove as much of the kitchen sink as I feel I can get by without. Writing for one target is easier than writing for two. Obviously there is still the user/UI layer left out, but for middleware it's a solid win, IMO.

I mean.. I guess? Maybe?

Much better to focus on what we can control - making docker awesome for as many people as possible.