@Wolf480pl@niu.moe My point here, as far as "freedom not to use" goes, systemd doesn't require individual services to be written in some systemd-specific way (e.g. as dynamically loaded plugins with some entry points, against systemd-specific API/ABI). No, they're just plain Unix executables launched as any other executable. They don't have to care if they're started (and watcher over) by systemd, another init system, from an interactive shell or whatever.
@Wolf480pl@niu.moe (That, and systemd also provides sysvinit's config format compatibility.)
This is why you can run pretty much anything that wasn't explicitly written against systemd (and often predates systemd) with systemd. This is why you can pretty much just swap out init systems and have all the services work the same. I imagine the situation on Windows is much different (though I don't know too much about Windows internals).
@Wolf480pl@niu.moe If a service wants to make use of systemd features such as socket activation, than indeed it needs a small systemd-specific codepath that checks if it's even running "on systemd" and does the appropriate setup. But again, this works without systemd (as a no-op) and you don't need this with systemd (but you won't get some niceties).
This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!