[qayxc]

It's a hammer problem. Docker is the new hammer and now everything starts to look like nails.

[joombaga]

Yep. We know it's not a nail though. It's a screw. And they duct taped a screwdriver to the hammer and called it "Driving screws with a hammer".

[hinkley]

It's the hammer problem because management and IT have locked up all of the other tools, so you're damned right I'm gonna try to use the hammer.

Spooling up a docker image is low friction at a lot of places. Doing anything else can take an act of Congress.

[dahfizz]

> Doing anything else can take an act of Congress.

Does fiddling with BIOS parameters and installing kernel modules fall into "anything else"? Because this project doesn't work until you've done that on your docker host.

[hinkley]

Not in this case, but in qayxc's more general statement.

[Frost1x]

I often wonder what it is that perpetuates hammer problems. When I look at a problem, all technologies are options. If I'm doing the work, I'll obviously try to choose from those I'm more familiar with or choose what seems like the best established/mature hammer.

It often seems like someone wants to use a specific hammer and tries to tailor/turn/reshape problems into nails. Some of it may be resume driven development, perhaps choosing comfortable technologies, etc. Perhaps hammers are the only tools they're familiar with and risk aversion in business leads us to only use our hammers.

Something is amiss because I keep seeing hammer problems and it never seems to stop.

[lostlogin]

Luckily, a lot of the things are nails. The number of applications you can keep neat and tidy with a fleet of containers is so great. Even a relative novice can get some great things working by poking about a few guides. And when it all breaks you can start again without too much collateral damage.

[qayxc]

I'd argue that I was able to do the exact same thing 20 years ago using VMWare Workstation - download a VHD image with OS and app(s) pre-installed and configured, optionally map to a drive on the host OS and get started instantly...

Maybe I'm too old to get the appeal of "a fleet of containers" in place of a single (and potentially throw-away) VM image along with maybe even a vagrant-script to make it easily reproducible... ¯\_(ツ)_/¯

[maccam94]

Running multiple containers is faster and more efficient than multiple VMs. Running a container on the same kernel as the host is faster and more efficient than a VM. If you're trying to run an app across different OS kernels, you still have to use a VM unless you can compile your app on that kernel natively. This project really doesn't do much beyond what a VM gets you, and you still have to configure the host outside the container to enable virtualization.

[hamandcheese]

The difference is tooling, particularly "just works out of the box" tooling.

[yjftsjthsd-h]

Yeah, tooling/workflows are the (possibly only) reason that Docker is popular. It's like how the FreeBSD folks will say that they've had containers (jails) long before Linux, which is true but misses the point that without the ability to pull and run images trivially they're losing, badly, on usability.

[lostlogin]

I’m going to look at this, thank you.

[rurban]

Docker is the old hammer. The new one is called podman.