[atemerev]

I don't always run containerized applications, but when I do, I prefer them completely systemd-free, thank you.

Sometimes I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels — anything, just anything without this abomination.

[bryanlarsen]

Can you explain your position to me? I can understand somebody who dislikes systemd and dislikes docker. I can understand somebody who likes both systemd and docker. But disliking systemd but liking docker? That I don't understand. Any effective criticism of systemd that I've heard generally can also be applied to docker.

Like yours: "I wonder if systemd is actually a part of big plan of moving everyone to microservices and containers and maybe even unikernels" works even better if you replace systemd with docker.

[atemerev]

Docker is just a toolkit for composing and networking layered OS images. It improves isolation of things and adheres to simple principles (immutable containers, restarting instead attempting to recover, etc.) It structures things better. Inter-container communication is deliberately simple (env variables and, recently, networking).

Systemd spits on isolation, it embraces integration of everything. Supervision, logging, communication, IO, configuration, state management — everything goes through systemd. Everything is binary and opaque. Docker is transparent.

[bryanlarsen]

Your criticism of systemd still applies to docker. "Supervision, logging, communication, IO, configuration, state management — everything goes through docker"

If I use systemd I have to type 'systemd logs' to get at my logs, or I can use a plugin to move it somewhere else. If I use docker I have to type 'docker logs', or I can use a plugin to move it somewhere else. etc. etc.

P.S. Agree completely with your praise of Docker. I'm firmly in the 'love both systemd and docker and wish they got along' camp.

[qwertyuiop924]

Wrong. Docker manages containers, and only containers. 'docker logs' shows you the logs from your containers. Docker never tried to make me run my non-container logs through 'docker logs'. You know what else docker never tried to be? cron. Or udev. Or consolekit. Or init. It just tries to manage your containers.

[Etzos]

I think this is a little bit off. You're looking at them from two different perspectives.

Docker wants to manage your containers. And in that regard it is one monolithic daemon that manages everything about your containers.

Systemd wants to manage your computer and things related to init. It is a bunch of modular, but strongly integrated, pieces that manage everything about your init and process management.

[qwertyuiop924]

>>It is a bunch of modular, but strongly integrated, pieces that manage everything about your init and process management.

OH REALLY? well, can I just run systemd-udevd, without systemd? how about journald? No? well than, if everything depends on one massive daemon, it isn't very modular, is it.

[qwertyuiop924]

Also, cron isn't init and process management. Udev isn't init and process management. Neither is consolekit.

[vidarh]

Isolation and integration are not opposites. You can increase isolation (through e.g. judicious application of cgroups, which systemd encourages and makes use of) while also increasing integration (e.g. sharing APIs).

Docker is to me far more problematic when it comes to integration. It is trying to make everything go through itself, without providing a fraction of the scheduling and management capabilities that systemd does. Of of the motivations for Rocket is exactly that it allows for a far less monolithic experience than Docker - even when integrated with systemd.

[qwertyuiop924]

Integration is all well and good, I suppose. Until you put all your integration into a single process, which will kill your system if it ever crashes. Then I will have some words to say about you. Especially if you ever, ever, EVER, EVER, EVER, use assert, in ANY situation you could ever potentially recover from.

[the_why_of_y]

I disagree with your position on assertions and much prefer Bryan Cantrill's, because it results in bugs actually getting fixed:

  Hope is not a strategy, including for your
  software.  If your state has  become corrupt,
  it is incumbent upon you to die and donate
  your body to science, where it can be
  debugged.

[qwertyuiop924]

Well, yes, in that case you should die, but take steps to make sure that your state doesn't become corrupt in the first place. Like, for instance, doing less, and making your service less complex.

[atemerev]

Why recover if restarting is much simpler? Like in Erlang and Akka, this leads to incredibly reliable systems.

[qwertyuiop924]

But if you're PID 1, you don't have the choice. if you could conceivably recover, you HAVE to try and recover.