> systemd is a continuously-varying project, and just because your distro smoothly switched, doesn't mean there were no problems for early adopters, or that just because your configuration works, no difficulty with the multiple systemd components have, do or will arise.

Actually, I never claimed that my distro switched smoothly. Ironically, I literally commented just yesterday complaining that my distro (Arch) did not switch smoothly (and IMHO switched too early)[0]. I had a lot of issues when I first switched - I couldn't even boot my system, as a lot of stuff did not migrate cleanly.

Switching is always going to cause upheaval and breakage to at least some extent, and that's not what OP and I are referring to when talking about FUD.

What I'm talking about are people making factually incorrect (and worse, trivially verifiably incorrect) statements about systemd and what it does. Some of them are just blatantly wrong ("systemd forces you to use binary log files"[1], "systemd means you can't use init scripts"[2]), "systemd means you can't use crontab"[3], or my favorite "systemd gives QR code output"[4]). Others are technically true, but highly misleading ("I don't want everything to run in PID 1"[5], "systemd is the only way to run cgroups"[6])

There's a difference between disliking systemd on technical merit and disliking it based on false information that one hasn't even bothered to verify, and then vocally spreading that misinformation.

[0] https://news.ycombinator.com/item?id=8482950

[1] systemd by default does not use any log files (IIRC), and provides text logs as an alternative to the recommended binary default. You can keep using syslog just as always.

[2] systemd allows for init script compatibility. I won't claim that all init scripts will work without any modification, but it's not like you can't keep using init scripts instead of systemd configs if you don't want to

[3] systemd.timer is something you can use instead of crontab, but it will also run regular CRON jobs as well.

[4] systemd does have an option to display kernel dumps as QR codes. This feature is generally not compiled or available by default

[5] systemd includes some functionality that runs in PID 1, but most of what people actually are talking about does not run in PID 1

[6] systemd is the only way to run cgroups, because the Linux kernel requires that a single arbiter handle all cgroups, and systemd is (was?) the only program that has actually implemented the entire necessary ABI to do so. Anyone is free to write another program to handle cgroups instead of systemd.