cgb_

Agree, and it's an opportunity for the candidate to demonstration their knowledge on whatever level they think is appropriate.

Interviewing is not about just showing you know x, y, z, it's largely a demonstration of your ability to communicate.

And the weaker candidates tend to get hung up on this question as being 'too simple' or confused about what level of detail they need to be supplying. Umm, look at the job description, tailor your answer, inform the panel you can elaborate further on something you're strong with, but avoid waffling on about irrelevant (to the position) technical detail. That's a bad thing in my book.

I think crucially, good candidates know what they don't know and have no problem communicating that. Weaker candidates feel pressure to "know everything" (impossible) and the moment they open their mouth with vague or incorrect responses, they become a risk if employed because when confronted professionally with something they don't know much about, they are more likely to try and wing it rather that stop and fill their knowledge gap or seek assistance from colleagues.

Wow this is the coolest thing I've seen in the terminal since I discovered a sparkline bash script. I've embarrassingly used gnuplot's ascii output to realtime chart Cisco network interfaces in a shell I'm writing, this looks 1000x better than gnuplot's output. Thanks for sharing.

One of the things I've found interesting about rapidly popular opensource solutions in the last 1-2 years is how quickly venture cap funding comes in and drives the direction of future development.

Docker has a whole ecosystem of bolt-on github projects that fill-gaps that the Docker project hasn't had time themselves to fill because they are too busy organising conferences, withholding features until the keynote of said conference, and working out how to spend the millions of dollars on future development.

Even the gap-filler github projects are getting VC funding (see http://weaveblog.com/2014/12/03/announcing-weaveworks-and-ou...). Weave will either become the standard networking stack, or be made irrelevant by an in-tree featureful implementation.

So Docker are on this tightrope trying to innovate whilst avoiding stepping on the toes of their VC-funded 'partners', so their response was simple-core with a plugin framework for partners to integrate into. Anyone else picturing fragmentation in 6-12 months time?

Docker has a lot of rough edges and it's most useful in large scale-out deployments. In-band devops tools like Chef and Ansible are relatively agnostic to the hypervisor or container solution, so if you only need a few OS instances & managed configuration, I suggest sticking with Chef/Ansible/Puppet (I prefer ansible :)).

You can always scale out with docker later and I know at least ansible are adressing this use case (http://www.ansible.com/docker).

But also to be fair, OpenVZ introduced VSwap (http://wiki.openvz.org/VSwap) to address some of the confusion that occurred under the previous resource management solution. User bean counters was notoriously hard to comprehend for mere mortals, and the default limits were reasonably tight, so most commonly Java based applications were unreliable in OpenVZ.

Otherwise I agree with you that admins should detect VZ-related OOM conditions. But a good project takes ownership over the most common pitfalls and finds ways of making their software easier to use (if their goal is to remain popular or grow).

What happens is you'd rearchitect (if needed) your stack so that it scales across N-nodes (for each tier). Then docker build files & snapshotting features allow you to 'recompose' the image from a base OS, one step of which is to apply all patches.

So when you are performing patching, you'd bring a container into service with the updated patches, send some traffic to it (possibly tightly controlled to minimise disruption), verify and then put into production. Iterate through your N-nodes per tier and you've patched. Every container after the first is rapidly started up (just the cost of a supervisor/init & the application process).