[esamatti]

> If you are a Docker user, you understand that there is a daemon process that must be run to service all of your Docker commands. I can’t claim to understand the motivation behind this but I imagine it seemed like a great idea, at the time, to do all the cool things that Docker does in one place and also provide a useful API to that process for future evolution.

I guess that would be for the Windows and macOS support as it should make things easier implement in a cross platform way when you can just proxy the cli commands to a daemon running in a Linux VM even when you are on Windows or macOS?

[ffk]

There were a few reasons for this. The original golang version of docker required root, full stop. There was no difference between the client and server.

The first reason was to reduce privileges of the client interface. This would provide the possibility to reduce privileges and restrict what unprivileged could do later on. The communication over the socket is just http, which allows for remote management of docker containers.

A second reason was to build a strong contact between the client and server. The client became syntactic sugar for the rest calls, which helped stabilize docker. This would ultimately lead to enabling osx and win support via a VM on the host.

Another major goal was to enable the docker in docker use case which helped significantly when developing on docker itself.

Source: I was there. :)

[marmaduke]

Since you were there, can you comment on discussions you might have had, where tradeoffs were chosen which would have led to buildah instead of Docker e.g. prioritization on cross platform support? Your comment seems written in a very after the fact way, but surely someone was agonizing overs these choices before they became history.