systemd is 69 individual components (and binaries) last time I checked. You can opt to build some, or all when you compile it. Yes they work together, but they have an open and now-more-or-less standardized api. So nothing prevents another developer from writing against the api, be it a shim to reduce/remove systemd but provide compatible calls into another system (init, logging, etc), or a complete replacement for a specific component of systemd.
I see it only getting easier actually. Folks in the BSD projects for example have their own init system but still want software like gnome, so shims are used to provide the api abstraction. This can be applied elsewhere in the Linux world as well. Again, this is only for software where the developers have explicitly decided to hard-code in dependencies to systemd, which is not likely going to be everyone.
> Again, this is only for software where the developers have explicitly decided to hard-code in dependencies to systemd, which is not likely going to be everyone.
I'd put good money on this getting harder and harder going forward though. At some point it will be everyone, or at least practically everyone, because every Linux distribution with any mindshare will have been using systemd for years, and hard-coding systemd will be not a lot different than hard-coding calls to the C standard library.
Also, shims? How god-awfully inelegant can we be? "You don't like systemd? Cool. You can run something else (as long as it looks, feels, and behaves exactly like systemd)."
Look, I'm not a religious zealot. Systemd is what they want me to run; systemd is what I'm running. I can live with ugly software. It's not the end of the world. But oh dear god is it ugly.
I'd give the same answers as you've probably heard a dozen times before. Binary logs, D-bus fundamentally baked in, the whole "shims are a perfectly good solution" viewpoint, basically the usual things people like me don't like.
I see it only getting easier actually. Folks in the BSD projects for example have their own init system but still want software like gnome, so shims are used to provide the api abstraction. This can be applied elsewhere in the Linux world as well. Again, this is only for software where the developers have explicitly decided to hard-code in dependencies to systemd, which is not likely going to be everyone.