I agree with snubbing glibc, systemd, and apt-get. Seriously, it is about time to put an end to the bloated fatibubbul fest going on over there! I intend to move my dockers to alpine. I will only come back to debian after and not before they have downsized, trimmed and layed off all the useless fat around their bellies!
Dunno if it is about snubbing, but i get the impression that having systemd inside the container makes it damn hard to work it if you do not also have it outside the container. And at that point, systemd is likely to take over control completely rather than play nice with docker.
Na, that's not how it works at all. When you run a docker container, you'll be running your app directly, thus systemd won't be involved and isn't even needed within the container.
The problem with debian and centos is they weren't create with containers in mind, thus by default their base images pull in a lot of stuff that's required to actually init hardware.
We can see with fedora that efforts have been made to slim it down, I suspect as containers become a popular usecase we're going to see smaller base containers, except with access to 30,000 stable packages and a mainstream community.
You might find people attempting to start systemd as pid 1 then running their containers as sort of lightvm, but that's not really the typical use case.
More common is folks not wanting to deal with splitting processes that are grouped together such as an internal gitlab instance that has, nginx, unicorn, postgres, ssh, and sidekick running.
Best practice is arguably that you should be able to run all these processes in different containers and share the directories or sockets where possible, but the pragmatist is probably running them together using supervisor.
