Why is it not good? It is in line with the robustness / Worse-is-Better ethos, and importantly, it lets you get on with delivering business value, which is what we're supposed to be doing. (At least in a business context. If you want to rewrite code to perfection on weekends, for fun, so do I, I am all for that, but that's almost never what my employer needs.)

"Why is it not good?"

Because it still allows the base problem of crap coding practice to proliferate.

and don't forget that crap code == insecure code.

but nobody have to worry about it. just start a container the last guy left. /sarcasm

> and don't forget that crap code == insecure code.

I don't think I believe that equality is nearly as neat you'd hope. Unless we're willing to call all code crap code, a lot of projects with well-respected code and development practices have had serious zero days, and we've also found that sandboxing software is highly effective. Insecure code in a secure, well-written sandbox can get you a secure deployment, and you probably want to have your "good" code in a well-written sandbox anyway.

zero days and the privilege escalation are a luxury.

bad code is often plaged with injection/sql injection. Which sandbox does an absolute NOTHING to protect you from. After all, it is all within the expected side effects of your code.

What does this have to do with Docker then?

because a flawed argument in defense of containers is that it is safer, since it's harder to escalate priviledges.

my point is that false sense of security makes it even easier for an attacker to use readily available privileges in the badly coded application.

This seems to be the main point of the article to me. If your language's toolchain makes it easy to make sufficiently* self-contained 'fat binaries' (like Go or Java), then Docker doesn't add much. If it doesn't, like Ruby or Python, then Docker is very useful.

* 'sufficiently' is doing a lot of work here. Go binaries might still need libc; Java tars-of-jars (or fat jars, if you're confused) still need a JVM, which needs a handful of shared libraries. But those things are relatively stable, generally backward-compatible, and one single big thing (libc or JVM), so it's fairly easy to manage having multiple versions installed anyway. More than zero work? Yes. Less work than managing a Kubernetes or Docker installation? Also yes.

Spot on. Both fat binaries and containers very often translate in: "Nobody here cares about security. We deploy opaque blobs that will be unmaintained."