On one side, you have shell scripts that are generally pretty simple (FreeBSD’s init is something like 1000-2000 LOC for the implementation, and a simple service script is tens of lines).
On the other side, you have a monolith that hit 1.3 million lines of code a few years ago, and has gotten more and more complicated since then.
Assuming the waits are not a bug, then they are a misconfiguration. When I gave up on using it, the manual was long, incomprehensible, and the small documented fraction of systemd’s behavior didn’t match the manual.
Just a nit, that 1.3 million lines was reported incorrectly. You can see some talk at https://news.ycombinator.com/item?id=21935186 and I remember a Poettering tweet saying that was including things like documentation. At the time systemd was under 500k lines; still big but not quite so huge.
I'm also not sure if that count was for the full repository (which contains multiple modular projects like systemd-resolved that are not required for systemd) or just the actual systemd bin.
systemd suffers from the lack of systemic design, but it's still way better than the pile of scripts that it replaced.
I was strongly disappointed and shocked when I realize that Lennart was not able to write something like "my solution is better or comparable to daemontools, because".
Yep. For me, it's most often a 90 second delay that comes from the combination of the automagical conversion of fstab entries into services, an NFS mount in fstab, and an offline NFS server.
Sane init systems notice that this is a networked filesystem (I've even marked it with the _netdev option!) and don't hang the boot for a minute and a half screaming at a dead server. Systemd is anything but sane.