This is the biggie for me. When the next heartbleed comes out, it would REALLY suck to be running a bunch of opaque images that you have no idea how to patch.

That's the thing, I surprised how many people were "ok" with that binary imagine that someone built on their laptop. Few saw an issue with it, and instead praised it as a great win.

I mean, it was a win, not having to untangle the hairball of rpm/deb dependencies. I like that part too. But not understanding the downside was what shocked me. It was like everyone drank the magic kool-aid potion.

> I surprised how many people were "ok" with that binary imagine that someone built

Really? This surprises you?

The gross majority of the world runs software this way.

The real issues are quality control and release process.

That's an unrelated problem. Developing your systems interactively, instead of reimplementing them over and over again produces the same results, just faster. If your servers aren't ephemeral, or you only have "one machine", or if you don't know about heartbleed patching, then you're going to be fucked anyway.

> How do you recommend applying security updates to the image, short of running (for example) `apt-get dist-upgrade`?

That's exactly how I recommend applying patches.

If it breaks things you can fix it.

You don't do this on a live system: If you're smart and your live systems are ephemeral you can copy your image, get it working, verify it interactively, and once you have a working image, you spin up new instances using the new system, and start shutting down the old systems.

There's tools like zypper-docker that make this possible.