This is all stuff that needs to be taken care of, on every system. So I'm happy that systemd handles the basics in a sensible way. Why do I as a sysadmin need the choice here? Everything I need is covered by systemd, and in a less painful and more consistent way.

For example, I really do like how systemd-journald takes care of logging, although I don't know why it's not using plaintext log files internally. journald gives me the choice to not log to disk at all, which is nice on embedded systems and my notebook SSD. If i wanted to have logs the old way, i'd just attach a syslogd on journald's socket. With systemd and journald I can have my services log to stderr and everything just works.

I don't have to: * Log to stderr if my service can't start for some reason * THEN daemonize (which is a pain to do in node.js and python, and not possible in golang) * Then switch logging to syslog or my own logfile(s) * Think about logfile rotation * use supervisor or monit to make sure my services stay up

Sure, it needs to be taken care of and the creator of that page recognize that when they say "We do recognize the need for a new init system in the 21st century". Systemd is trying to do TOO MUCH, instead of being a part of a larger system it's trying to become the system. Ad I don't like it, because I don't like tight coupling.

PS: as an alternative you could use a tmpfs to move /var/log (and other log directories) to RAM on an SSD system. Far less configuration required, in my experience. And it works with every *nix out there.

That is a terrible alternative. It is a colossal pain chasing down processes which are still doing open-ended logging into /var/log on a RAM-only system, or guessing which ones may or may not be properly rotating their log files.

The OP is right: some stuff is so essential it should be centralized. Whether systemd is the right way to do that I don't know, but it certainly seems to the compromise we'll live with in the near future. Just as SysV was in the past.