[zaro]

And what drove my attention to the "I don't accept systemd patches" was the need to run systemd in docker container. Which by digging a litte bit about I found it will be possible in non priviledged mode, but docker didn't want to merge it.

I don't see anything philosiphical with that, it's just plain refusal to cooperate in any way with a potential compentitor.

This was several years ago, now this is not an issue anymore, but it's still telling of the toxic corporate culture Docker had back then.

[nikisweeting]

I think the reasoning was that you shouldn't need systemd in docker because the point is for docker itself to containerize each service unit, and use something like docker-compose to manage multiple units. Personally I think that's an aggressive but valid stance because by allowing systemd in docker they'd get a ton of low quality docker images floating around where they launch multiple services within containers, which is against the "do one thing per container" philosophy.

Now that docker has proliferated and the standard practices are clear and well documented, there's less of a danger allowing people to do messy things in their docker containers.

[zaro]

Sure but what ws their recommended way instead of putting systemd in the image, just use supervisord. Not even comparable.

Anyway , the past is the past. Docker were clearly wrong in their decision to put off systemd inside containers, and was most probably for political reasons because it was very very requested feature.

[nikisweeting]

I disagree that it was clearly wrong, because supervisord is a vastly simpler service manger than systemd. They wanted to put organizational pressure on people to move away from managing multiple units within a single container with an extremely complex octopus of a unit manager like systemd, and they arguably succeeded at that goal. (Even if it caused short-term discomfort for people who wanted to rely on systemd features within containers.)