The grand-parent post was about the general consensus: sysadmins generally like systemd. So I'm not sure answering individual concerns is useful, but I'll take the bait...

> now that there is journald, you have to pay attention to another hop in your logging chain and take care of journald in addition to rsyslogd.

No, you don't have to, because a syslog daemon is not required any more. BTW, rsyslogd is not the only syslog service, I've had to work with alternatives like rsyslog-ng.

And the daily usage is now much simpler: `journalctl -b -1 -p err` or `journalctl -u mariadb --since "24 hour ago"` were painful queries with (rotated and compressed) syslog files.

> Boot and shutdown has previously been deterministic, now things just randomly hang.

That was not my experience. IIRC, with sysv-init boot dependencies were declared with comments inside shell scripts and parsed by insserv. That was a mess, and race conditions did occur. I have no experience with other boot systems, but I remember that upstart was not immune either.

> Network device naming is also a fun one.

The naming policy is vaguely relevant to systemd. `net.ifnames=1` is the default configuration of the Linux kernel. I think it's still possible to configure the kernel, udev and systemd to work with the old naming, but if it's just because "shorter is better", I don't think it's worth it.

> No, you don't have to, because a syslog daemon is not required any more.

That is "not required" for the single-computer-sysadmin. If all you know is your laptop, then journald might be fine. If your computers are cattle and have numbers, you don't want to read your logs on each individual computer, if possible you don't want to read logs at all, you want some automation to do it for you, aggregate it, warn you about things, etc. journald just makes that harder, and going through some syslog protocol implementation (of which there are a few, you are right there) is the only relevant game in town.

> IIRC, with sysv-init boot dependencies were declared with comments inside shell scripts and parsed by insserv. That was a mess, and race conditions did occur. I have no experience with other boot systems, but I remember that upstart was not immune either.

Dependencies and insserv were a later addition. Basically you just defined a boot order by numbering your /etc/rc[0-6].d/S* links in ascending order, either manually or in a dependency-based fashion through insserv. This means that you can have a suboptimal ordering if those dependencies are wrong or you choose your ascending order poorly. But it also means that once you have a working boot order, it can be repeated, and it will be repeated. That is what I mean by determinism. Once you have a working boot, it will keep working. Solaris SMF did something more modern, you would define dependencies in service definitions, and it would compute a static deterministic ordering from that, without those /etc/rc[0-6].d/S* symlinks. Deterministic, but dependency-based. If it has worked once, it will work again. And they even had a rollback: if after a change, the next boot wouldn't work, you could go back to the previous boot order and fix things from there. And neither had race conditions, because you usually wouldn't do things in parallel, one service would wait for the previous one in the boot order (parallel was possible but rarely used, because of the inherent fragility and possible race conditions).

Systemd does it dynamically on every boot, no precomputation, just looking at all the files and starting everything that could possibly be started at the same time, in parallel. The reason for this is that this makes Lennarts laptop boot faster, which is true in the ideal case. But it is neither deterministic, nor debuggable. And other than the previous methods, it can lead to race conditions.

Note that there is one more race condition at boot, which is races against kernel devices and systemd-udevd. That neither got worse nor better with systemd, it just lead to the kernel people giving up and handling more things like firmware loading in kernel.

> The naming policy is vaguely relevant to systemd. `net.ifnames=1` is the default configuration of the Linux kernel.

Utterly totally completely wrong. https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin...

The Linux kernel does not have a net.ifnames parameter, and the kernel interface naming scheme is still eth[0-9]+. When you stick that parameter in the kernel commandline, the kernel ignores it and only systemd and systemd-udevd interpret it later on.

Please, if you want to sing the praises of software or deflect blame from broken crap, make sure that you know what you are talking about...

It's a little weird to reply to someone complaining about administrative problems caused by systemd with "generally sysadmins seem to like it."

That kind of response is exactly why everyone gets emotional in these discussions. Technical problems are one thing but when you gaslight people experiencing and reporting legitimate problems you should not be surprised when they get mad and rip your solution out.

GP is being far kinder to the systemd devs than they deserve, I gave up on the project years ago for exactly this reason.

> consistent-net.rules nailed it to a mac address on first boot

fails even harder for

> put in a live-CD to debug something and your network devices are suddenly weird

I don't know that there is really any good answer here. Just methods that break in ways you're used to, and methods that break in ways you aren't. I appreciate the attempt at static naming based on hardware connection, even if the realities of how these things are presented by the bios make the results an inscrutable mess.

Maybe pure enx would have been better? But that looks like crap for even the simple cases, and fails if you swap out a piece of hardware or start doing weird things with MAC addresses.

The only consistent naming scheme I've ever seen working was Solaris on Sun hardware. But that only worked because they controlled both the hardware and the software side of things.

And yes, consistent-net.rules doesn't solve LiveCDs and reinstallations. But as I've said, systemd doesn't solve those either, and in most cases actively makes them worse.

My experience has not been that the systemd device names are "actively worse". The biggest problem I've had is changing around VMs where subtle shifts in PCIe IDs (specifically subdevices) end up changing changing names. Meanwhile, consistent-net.rules seems like a hack, always in the back of your mind as an arbitrary stateful part of the system. Why should I think of my primary network device as eth2 if there is no reason for it to be eth2 other than merely being the order on the first install?

But if you prefer consistent-net.rules, then more power to you. I'm guessing most of your frustrations could have been addressed by systemd having some shame about changing functionality out from under users, and providing an up-front option to switch between the different methods.