> with Docker as a standard you will have a fully portable application that behaves exactly the same on one PaaS as it doesn’t on another
I wish this lie would go away. You have plenty of dependencies with a Docker app and it's trivial to either be missing them or have conflicting ones. Go ahead and copy some binaries from one random Linux distro three years ago to one made today and see if they work every time; not every chroot environment is backwards (or forwards) compatible.
While we're talking about "standards", can't we agree that LXC is still the simplest and most portable 'standard' for running Linux containers? Everyone wants a cool branded wrapper with an API, but LXC has the bare metal functionality that you need and costs you less container-specific maintenance.
Evidently you don't feel the need for Docker and don't believe it's useful of needed, which is of course totally fine. I won't try to convince you since I've tried before and failed :) (if other are interested I cover some of the differences between docker and lxc here: http://stackoverflow.com/questions/17989306/what-does-docker...)
However there are obviously people who disagree with you and find that Docker solves a real problem beyond what lxc can do. This seems to irritate you, to the point of "bullying" every thread about docker on hacker news. Why? Is it not a good thing that we toolmakers try new ways to solve a problem? If docker doesn't do a good job, people will stop using it, and the project will fail. It's really that simple. Why not let people make up their own minds instead of going on a crusade against a project?
I can't make anyone's mind up for them. But if all they ever read are the hyperbolic marketing pieces about the glories of one tool, they're less likely to take the time to vet the claims and compare it to other tools.
There's a lot of people on HN, and many of them simply aren't familiar enough with technology not to buy into every product shilled in a blog post or news article. It's like the "HN effect" is convincing people that because it's on the front page, it's somehow intellectually stimulating, superior, or factually correct, when often this isn't the case. Luckily we have comments to put forth alternate views.
Your post assumes that every one of us on here is dumb and will fall victim to these "traps", lest we be saved by your brilliant opinions and revelatory messages (hyperbolic in their own way, ironically)..
It seems peterwwillis picked up on one very specific claim (that Docker is a portable standard) and called it out as false. That's exactly what we should be doing with false marketing claims, or else we end up with MongoDB all over again.
If the two of you have a history, that's fine, but I think the OP made a fair comment, and you've attacked him personally rather than replying to the seemingly-valid point he made.
I think the answer is that Docker is in fact less portable than previous standards (e.g. bare disk VM images), but is potentially a lot more efficient (now that AuFS has been dumped). Is that correct?
peterwwillis makes 3 claims: 1) docker does not allow standardized, portable deployment of applications 2) docker is a "fancy wrapper" over lxc and adds no substantial value, 3) anyone who disagrees with this is spreading "lies" and "hyperbolic marketing claims" which will cause the readers of hacker news to form an incorrect and uninformed opinion.
I addressed points 1 and 2 by linking to this thread: http://stackoverflow.com/questions/17989306/what-does-docker.... It lists half a dozen ways that I believe docker is different from lxc. The first item in the list is "portable deployment across machines".
I then called him out on point 3 because I consider it unfair and harmful. First it insults the intelligence of the hacker news readers ("they eat the marketing up, but I don't!"). Second it introduces FUD as an substitute for facts. Shouting "marketing hype!" in hacker news is the equivalent of shouting "anti-american!" in Congress. How many people will come away from this thread thinking "huh I wonder if docker is marketing hype after all?" simply because peterwwillis claimed it? Talk about a marketing hyperbole.
I take it you two do have history, because I didn't really pick up on #2 and #3 from his comment. I would suggest that every time you say "docker is not just a fancy wrapper around LXC", mentally people assume that docker is probably little more than a fancy wrapper around LXC. Methinks you doth protest too much!
For #1, you've linked to a thread in which you claimed docker is more portable than LXC. I think you guys are arguing at cross-purposes here: you're saying that you're more portable because e.g. you abstract away the IP configuration (true), he is saying you're not portable because you're tied to specific kernel features (also true?).
I, for one, would like to hear more of Docker's benefits clearly explained (i.e. less shipping container metaphors, and more talk of IP configuration). I'd also like to hear more about the limitations of Docker (e.g. what kernel versions can I move containers between, on which kernel versions is it secure etc).
As for #2 and #3, those seem like non-fact-based arguments, so I'll let you and peter continue screaming at each other about who is more wrong on the Internet :-)
> I, for one, would like to hear more of Docker's benefits clearly explained (i.e. less shipping container metaphors, and more talk of IP configuration). I'd also like to hear more about the limitations of Docker (e.g. what kernel versions can I move containers between, on which kernel versions is it secure etc).
I'm sorry you took offense; it was intended as friendly feedback. I'm familiar with Docker. If you have actual answers, it would be much more constructive to post relevant links.
I was suggesting that MongoDB's marketing claims initially went unchecked here and generally. It seems a lot of people assumed that others had done the due-diligence for them.
They started using it not knowing that it was not very concurrent, that the default transaction mode allowed data-loss, that it was slow when run in safe-mode, that it was not reliable unless replicated etc. (And these were all design issues, not implementation bugs). A lot of those people were pretty badly burned, particularly in the early days.
A few thoughts on this, firstly you are right to an extent - Docker doesn't give you portability completely due to binary dependencies, but if for example I wanted to move my app from the same major version of CentOS or RHEL on a virtual machine to something running with the same major version in the cloud it should be relatively straightforward. You are right though that this won't work going from something like Ubuntu to Suse for example.
The key bit is that we are starting to converge on a standard container for the Linux OS and with Red Hat working to get things working with SELinux we should have a pretty awesome container for our apps.
Given the above I'd rather standardise on an Open project that adds a lot more value to LXC and hides that complexity away and given the largest linux vendor is putting it's weight behind this I'd say this is rather awesome!
<title>SELinux context</title>
<para>
If lxc was compiled and installed with SELinux support, and the host
system has SELinux enabled, then the SELinux context under which the
container should be run can be specified in the container
configuration. The default is <command>unconfined_t</command>,
which means that lxc will not attempt to change contexts.
</para>
Additionally, LXC is "Open" since it is GPL2, it has been around since before 2006 so it's as much a de-facto standard as you can get, it's already supported by multiple other projects and distros, and it doesn't lock you into "the Docker way" of doing things - you get to choose how you implement it. It's flexible, lightweight, simple, and stable. Docker will work for many use cases, but LXC will work for all of them. It's lynx vs wget, basically.
The libvirt-sandbox project looks like a nice way to manage sandboxed selinux-supported lxc instances that you can convert to qemu/kvm depending on your needs.
I wish this lie would go away. You have plenty of dependencies with a Docker app and it's trivial to either be missing them or have conflicting ones. Go ahead and copy some binaries from one random Linux distro three years ago to one made today and see if they work every time; not every chroot environment is backwards (or forwards) compatible.
While we're talking about "standards", can't we agree that LXC is still the simplest and most portable 'standard' for running Linux containers? Everyone wants a cool branded wrapper with an API, but LXC has the bare metal functionality that you need and costs you less container-specific maintenance.