[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.

[ffk]

Sorry for the slow response, just got off an airplane. These were not after the fact. Instead, we knew these were the potential benefits and we moved over. I personally wasn't happy about having to run a daemon to get a container, but we saw the benefits far outweighed the downside for the approach. The other approach on the table was for docker (pre client/server split) to continue requiring sudo. I don't recall anyone suggesting an alternative approach though.

[ffk]

Oh on multi arch support. This was purely about keeping focus and reducing the original scope. I shared the same concerns and brought up this exact topic with Solomon. A change here meant changes in docker hub and other key places including devops which would further burden an already stretched team.

I should review the comment a bit more carefully sometimes.