> instead they are almost stand-alone VM images lacking a kernel How are docker images even close to a VM image? Docker image is closer to shipping your applic

> instead they are almost stand-alone VM images lacking a kernel How are docker images even close to a VM image? Docker image is closer to shipping your application in a zip file with all the dependencies than it is to a VM image. In a VM image, you need a "minimal OS" which has to include the kernel, drivers, required OS binaries + everything that would be in a container. Docker processes are literally running natively on host machine making linux system calls just like any native executable would... except they only see the resources you want them to see. Docker processes don't need the docker daemon to be running. In contrast, if you were to run a VM, you'd have to have at least minimal OS kernel with all the required OS processes and drivers and the application on top of that... not to mention the hypervisor itself. > But with Docker it's so easy to delete a container by mistake You do have to write "docker rm" to remove a container. It doesn't just disappear. The only way I can imagine someone losing data is if they think they are writing to the host filesystem when inside a container (without using volumes as one should) and delete the container thinking that their data exists in the user filesystem. > But how about a "tool application", say a static-site builder; does it now make sense to use Docker to run this tool? This is how you can run a "tool application": docker --pull run --network none --rm -it -v $(pwd):/src klakegg/hugo:latest The above will only give the hugo process access to the current working directory and it has no access to your filesystem outside of that, not to mention it has no access to your devices, your network or many other things a host process would have. It makes sense to run it under docker just for that. Plus, you can be sure that it will never have any library incompatibility because you updated something else, even if something basic like glibc comes with breaking changes, will always run the up-to-date version (if that's not what you want, remove --pull or use a fixed version tag instead of "latest" tag) and you never ever have to worry about what programming language your tools are written in or how they are distributed. You also don't have to rely on the original author distributing docker files (in the case of hugo for example, the docker images are maintained by a third party). As long as they have one way to build and run it, you can create docker images yourself and make it available for others too.