When I've seen them complain the systemd people tell them that they're just stuck in their ways and that systemd is a revelation on desktops where users don't have the historical unix experience holding them back...
Init scripts suck to test and debug. When manually-called, the caller's environment would get used, rather than a clean env, which would cause problems with the poorer-quality scripts. These showed up multiple times in production where an engineer would bounce a process manually and it got some configuration from their environment. We took some steps to alleviate this, like encouraging use of `service`, but using the scripts directly was reflexive for most because of years of indoctrination and it's portability to some other operating systems. systemd eliminated this entire class of issues, because unit files are just config files, not scripts.
Dependencies actually work. Usually, this came up when needing to wait on the network. With systemd, this is just a single dependency in the unit file. It also meant we stopped having to manage S## and K## which became something of a time-consuming art on machines with lots of services.
Not exactly init system, but systemd's triggered units absolutely destroy cron. Manually running a job (e.g. when testing or when a run failed) guarantees the same environment, whereas cron has no similar capabilities. It also actually keeping status means we can more easily see if the last run succeeded. This may ease our monitoring burden, too, but we haven't gotten to give it attention yet.
Other times, like oomd, I just want it to get out of the way.
Service dependencies are an area I love. With systemd making a service robust around dependencies like mounts and other services is a cake walk.
If you have manual hand-holding processes on services running under systemd, I suggest looking into supplying these kinds of directives.
- Requires / Wants
- Before / After
- PartOf
However, forwarding is significantly different. I'd think twice about using it on a system doing NAT/masq
I've had critical systems fail on reboot because the NICs swapped names so WAN port got configured as LAN and vice versa. That can also create a terrifying security problem too
Which also was wrong when switching hardware around, but that's a different issue.
eth0 tells you the first ethernet class interface that was activated that boot. Not particularly helpful.
I feel like if you need to care about these names as a user... the distribution has failed to provide effective wrappers. This is window dressing.
While sure, I would like shorter device names, the fact is... the only time I need to use them is when ambiguity is something I/we can't really afford.
So, I'm thankful for the cryptic-yet-specific names.
Everyone else (read: desktop people) can use whatever DHCP'd.
It’s only useful on desktop because of its similarities with launchd, which is particularly good on desktop.
At least it doesn't require a reboot. Yet.