top | item 25356367

(no title)

zaro | 5 years ago

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.

discuss

order

nikisweeting|5 years ago

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|5 years ago

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.