The 'overreach' people complain about exists for a good reason. Services need mounts/networks/etc to actually do their job reliably.
If people could discard the 'nyeh' sentiment, use recent releases, and actually engage with the system, they can only find more reliability.
It's about clearly laying out dependencies. Not a lot more.
The only bad experience I've had with systemd is on Ubuntu 18; where I've been forced to live at work.
It's not uncommon for systemctl daemon-reexec to be needed, to resuscitate it. It's woefully far behind.
I appreciate the mention though, never know how long people intend to keep things running.
Unit files are far more functional for the same amount of effort as SysV scripts.
Units can depend on networking managed outside of systemd-networkd using the target -- think of this as a 'run level'
Units can depend on mounts outside of systemd .mount units -- there's a generator that considers fstab
At a certain point, you might want to go further into systemd... but it doesn't require it
Linux is not systemd.
I did actually write systemd services and I'm not sure the "convenience" warrants what Microsoft (and Poettering) are doing to Linux.
The only one true savior we still have is Linus and, so far, Poettering still hasn't found a way to control the kernel's development.
But Microsoft/Poettering already won PID 1 on most distros/installs and, although I run systemd on several machines (including servers), it is not good that PID 1 is lost. It simply isn't.
Even if there were no technical objections (but there are: gigantic attack surface, lame binary logs, bugs regularly tagged as "not bugs" because Poettering feels like they're not bugs, etc.), it's still a huge problem how this gigantic squid spreads its tentacle everywhere.
Anyone finding it totally normal that the person in charge of PID 1 works for Microsoft is totally delusional.
People should at least acknowledge there are reasons to be concerned about that.
And whether sysvinit scripts do actually suck or not has nothing to do with PID 1 being controlled by someone working for Microsoft.
Nothing of huge value is lost. Distributions play an important part, we shouldn't forget. They can maintain something like this for users, if so inclined.
This mostly hurts third party/ancient/naive packages that you probably, eventually, won't want to install on your distribution for other reasons.
This won't affect any packages natively provided by your distribution of choice. Think those random RPMs/DEBs you get from an external vendor -- UPS, keyboard, whatever.
They've had over a decade to see the writing on the wall, adding approximately 12 lines to their entire codebase and packaging spec. Probably a net-reduction given the NIH-syndrome of these scripts.
Instead, I've seen them make this directory, put their scripts inside, and just expect things to work out. It did, arguably by chance. The compatibility was deliberate, but support isn't forever.
For those still worried, the pain is limited to about 15 minutes of writing a unit file, testing it, and waiting for ci or builds to finish!
I expect to have to do this for older or more esoteric stuff, but I also enjoy writing unit files.
You can’t even do that as those are not deterministic.
Also, what would be the point with Poettering? What does he gain from being constantly criticized by lunatics? Like honestly, these takes are some jewish space laser level ones.
My issue has been that getting an alternative set up was just painful enough that the related learning doesn't fit into a very full schedule.
Besides Nix, it’s the easiest way I’ve found to declaratively define a system that just works.