Live data from Hacker News

Systemd vs. Docker

lwn.net

91–97 of 97 posts

Re: Systemd vs. Docker

#91

Earlier quoted context omitted.

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.

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

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

Re: Systemd vs. Docker

#92
post #64

Earlier quoted context omitted.

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.

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.

>>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.

Re: Systemd vs. Docker

#93

Earlier quoted context omitted.

Yes, but I will never have to use docker if I don't want to. For that matter, docker doesn't try to be cron, it doesn't want to handle mounting, didn't subsume udev, and doesn't encourage other project to link against it, and to drop all compatibility with non-linux systems. Systemd does, did, and is doing that right now.

"but I will never have to use docker if I don't want to." I predict that fairly soon install instructions for a lot of different types of software will be "docker run ..." For example, try running discourse without using docker.

Install deps, configure it, done. Looks straightforward, if a tad undocumented.

The thing is, the inside of a docker container is by definition indistinguishable from a regular linux install. Discourse isn't dependent on Docker, not the same way GNOME is dependent on systemd: It just encourages you to use it.

Re: Systemd vs. Docker

#94
post #64

Earlier quoted context omitted.

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.

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.

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

Re: Systemd vs. Docker

#95
post #64

Earlier quoted context omitted.

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.

>>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.

The correct answer is actually "Yes, you can.".

Re: Systemd vs. Docker

#96
post #95

Earlier quoted context omitted.

>>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.

The correct answer is actually "Yes, you can.".

Not soon. You can't run journald without systemd now, and you won't be able to run systemd-udevd without systemd as soon as kdbus gets merged, which the systemd devs are pushing for heavily.

Re: Systemd vs. Docker

#97
post #95

Earlier quoted context omitted.

The correct answer is actually "Yes, you can.".

Not soon. You can't run journald without systemd now, and you won't be able to run systemd-udevd without systemd as soon as kdbus gets merged, which the systemd devs are pushing for heavily.

Your information is out of date with respect to systemd-udevd, per https://news.ycombinator.com/item?id=10518933 and others; and your assertion about journald is simply wrong unless something has changed very recently.
Post reply on HN