Some of our Linux servers that are not exposed to any hostile networks and inconvenient to reboot (e.g. monitoring display server that is displayed, along with other stuff, on a 30mx6m video wall) have uptimes of 5 years or more.... I also can't think why systemd would have any impact on uptime ...
5 years? Seriously? You're running on an 5 year old kernel with multiple known issues (TLS, OpenSSL, etc)?
I didn't say they don't get any updates at all. They just don't have kernel updates applied. There are multiple firewalls protecting these specific servers from hostile users/networks, and 90% of the people who have any access at all (e.g. HTTPS access) have sudo rights to run various things as root on them anyway. The only systems that have any firewall access to them are the other monitoring servers, and all the monitoring software is kept up-to-date.
As for systemd, you must not be very well versed in it. SSH Fails,
Yes, some versions of systemd introducing new features may have bugs. Only immature distros would push such versions out to users of stable releases.
Using timesyncd isn't mandatory. The distro I use on my laptop doesn't use it, RHEL7.3 doesn't ship it.
Doesn't seem like anyone could reproduce that on other versions (shipped in stable distros, or current).
Of the 5 major complaints, 3 are about the journal. There are some advantages to it, and some disadvantages, and I think systemd should support not using journald at all, but you can avoid relying on the journal itself by forwarding to syslog and disabling storage.
Regarding giving block devices for filesystems listed as required in /etc/fstab, this is a conscious design decision that is required in environments with complex storage (many storage arrays in a complex storage area network). The alternative (with e.g. sysvinit) is to have your production database servers fail to come up at boot time because the init system didn't give enough time for all 100 LUNs to appear so that it could mount the filesystems required to let the database start. It is really fun to have to be woken up to get such systems back up after a rack has tripped because then engineer on standby can't figure out what to do, I'd rather have systemd do the right thing. As far as I know, the default timeouts have been reduced (systemd wasn't hanging though ... it was waiting for devices it was told were required to appear) and provide more information on why it is waiting.
The 4th issue is cosmetic, and applies to most kernel drivers ... only dracut namespaces its parameters (rd.xxx).
And that took all of 2 min to search, read, and compile, because I wanted to give you some solid backing for stating it sucks.
Yes, it is trivial to find old bugs that are fixed, and FUD complaints from systemd haters about behaviour that has been improved.
You're in RH land with supported versions, so it's likely that these problems, when they crop up, are offloaded as RH issues and you just monitor a trouble ticket. Lucky you. I guess I wouldn't care in that scenario either, as it's SEP.
Our production servers run Red Hat. We haven't needed to log a ticket for anything systemd-related.
My workstation, my laptop, and the desktop my wife uses at home run a different distro not associated with Red Hat at all that switched to systemd long ago, and I have seen no issues there either.