[kristjank]

I hate to be smug here, but there are plenty of simple reasons outlined on the very same wiki: https://without-systemd.org/wiki/index_php/Arguments_against...

My personal relationship is a necessary-evil one. Without it, I'd have more problems with concurrency and service/session management, but I'd lose a lot of "systemd messed up resolv/nsswitch/hosts" scenarios.

Also, for most basic set-ups, even server ones, a classic BSD or SysV init works, as do simpler and more lightweight options, as proven by Alpine, FreeBSD and derivatives (FreeNAS, PFsense) and OpenBSD based solutions. And when stuff goes wrong, those are infinitely easier to decipher.

That doesn't mean, however, that systemd is hard to write config for, often when you need a service or script ran at bootup or login it's easier to make it work right than with a SysV-style init script. The problem is the growing config- and codebase, coupled with the binary logging system, which makes it even harder (AND NO, I REFUSE TO LEARN ANOTHER HIGHLY SPECIFIC TOOL TO READ THE BINARY FILES).

Ysall

[megous]

The logging system is one of those things that are just done right by systemd. I usually force everything to log to syslog and let journald handle it.

Just being able to see all potential new issues all over the system with a single command after system update + reboot is extremely time saving. Viewing only logs from the last boot, filtering, interleaving of all log messages from everything on the system, so you can easily see the timeline of things in one place, sane log rotation that doesn't make it harder to query logs, etc.

If I had to not use systemd, this is the first thing I'd rewrite or find some alternative that takes the same approach. :)