I'm still not seeing the logic in your rationale. > The trouble is, that Docker doesn't get to choose what cgroup controller "everyone" will use, it has to sup

I'm still not seeing the logic in your rationale. > The trouble is, that Docker doesn't get to choose what cgroup controller "everyone" will use, it has to support them all. Yes, this is an unfortunate consequence of the new kernel changes. Docker will need to interact with a controller. That controller might be different on different systems. Ergo, if Docker wants to support those systems it needs to support multiple controllers. > And the idea of interfacing with systemd on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-systemd version of cgroups control came out. Yes. But this would be the case no matter what controller was chosen for a particular distribution. For example, if Red Hat decided to implement a controller called Skunk one could say > And the idea of interfacing with skunk on cgroups wasn't very appatizing because it was guaranteed to lead to Docker needing special compat code for whatever non-skunk version of cgroups control came out. Same situation. No matter how you slice it, Docker now needs to support compatibility code for interacting with cgroups on systems it wants to support. > I know that the distinction is subtle It seems pretty meaningless. It's beginning to feel like the opposition, as described here, had little to do with anything technical or even design oriented and is more religious in nature. Would the same opposition have been made against my hypothetical skunk controller? If not, seems more like an editor war than a design or engineering disagreement.