>Is that really true, or is it just that some people have a grudge against systemd and sysvinit is the only other practical option?
Well, considering quite a few distros had already replaced sysvinit with upstart prior to systemd, obviously we have multiple options besides sysvinit. There's also options such as openrc, which will let you make use of whatever you want for pid 1, and manage services elsewhere.
In general, whether or not replacing systemd with something besides sysvinit/upstart is a practical option depends on how reliant you are on packages provided by an upstream distro or 3rd party. It isn't particularly hard to just swap init systems on several distros - debian included - but there are varying levels of tie-in with provided packages.
If you're building all of your required packages with a CI/CD pipeline and deploying with containers based on a minimal linux distro, you could relatively easily use a myriad of systemd and sysvinit alternatives. If you're just deploying on RHEL or Ubuntu VMs and doing yum/apt install to get your software, it's relatively more difficult.
Personally, I think sysvinit needs to be relegated to the annals of history. But I also have been bitten in production many times by systemd bugs, which due to the more... integrated... nature of systemd and it's components have been more trying to troubleshoot and have resulted in longer periods of problematic behavior, increased system level outages, and other headaches. Back when I worked with Solaris, I loved SMF - not so much the XML portion of it, but it worked well, was leaps and bounds ahead of sysvinit in usability in features, and didn't manage to induce nearly as many problems in my production environments as systemd has. And this isn't the first project I've wasted hundreds of hours of my life troubleshooting from the key systemd maintainers. My general experience with their projects has left the impression that they are not nearly as concerned at making their software bug-free as they are chasing features and use cases that interest them. Which is fine - they're welcome to write whatever software they want and prioritize things however they want.
My hope is that some other init system which recognizes the fact that it's no longer the 80s receives traction. Init scripts are awful, and no one should be writing them in this day and age, but I would prefer a system that only has a subset of systemd features but is instead focused on maintaining airtight code quality for those features. I don't need the vast majority of the features and services offered in today's systemd suite, and I don't want to suffer from the cost that all of those diversions extract on the core functionality. Crib the good parts, keep a high quality bar, and make sure a feature is likely to produce high positive impact before investigating resources in delivering it. Which is, I know, quite a lot to ask.
Well, considering quite a few distros had already replaced sysvinit with upstart prior to systemd, obviously we have multiple options besides sysvinit. There's also options such as openrc, which will let you make use of whatever you want for pid 1, and manage services elsewhere.
In general, whether or not replacing systemd with something besides sysvinit/upstart is a practical option depends on how reliant you are on packages provided by an upstream distro or 3rd party. It isn't particularly hard to just swap init systems on several distros - debian included - but there are varying levels of tie-in with provided packages.
If you're building all of your required packages with a CI/CD pipeline and deploying with containers based on a minimal linux distro, you could relatively easily use a myriad of systemd and sysvinit alternatives. If you're just deploying on RHEL or Ubuntu VMs and doing yum/apt install to get your software, it's relatively more difficult.
Personally, I think sysvinit needs to be relegated to the annals of history. But I also have been bitten in production many times by systemd bugs, which due to the more... integrated... nature of systemd and it's components have been more trying to troubleshoot and have resulted in longer periods of problematic behavior, increased system level outages, and other headaches. Back when I worked with Solaris, I loved SMF - not so much the XML portion of it, but it worked well, was leaps and bounds ahead of sysvinit in usability in features, and didn't manage to induce nearly as many problems in my production environments as systemd has. And this isn't the first project I've wasted hundreds of hours of my life troubleshooting from the key systemd maintainers. My general experience with their projects has left the impression that they are not nearly as concerned at making their software bug-free as they are chasing features and use cases that interest them. Which is fine - they're welcome to write whatever software they want and prioritize things however they want.
My hope is that some other init system which recognizes the fact that it's no longer the 80s receives traction. Init scripts are awful, and no one should be writing them in this day and age, but I would prefer a system that only has a subset of systemd features but is instead focused on maintaining airtight code quality for those features. I don't need the vast majority of the features and services offered in today's systemd suite, and I don't want to suffer from the cost that all of those diversions extract on the core functionality. Crib the good parts, keep a high quality bar, and make sure a feature is likely to produce high positive impact before investigating resources in delivering it. Which is, I know, quite a lot to ask.