it will only get "hard" if software projects bake in hard-dependencies to systemd, like the gnome project has (because they thought/think it provides a lot of benefits, and imho it does). Even so, there are plenty of shims being built that provide the small amount of api compatibility necessary to make things like gnome work on non-systemd systems (FreeBSD for example).
So, it is going to get hard, is what you are saying?
I mean, it could be that the shims are nice and easy, but it seems to be the expectation that this will not be the case, right? Especially since systemd seems to be on a very aggressive expansion of responsibilities campaign.
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 know the systemd developers are now planning on making udev depend on systemd in the near future, and that's pretty essential for desktop/server Linux.
Maybe not such a large hurdle though. udev was written by Kay mostly and he is on the systemd team. Before udev there was devfsd and hotplug[1], so it's feasible udev could be forked and/or an alternative introduced if it really becomes a burden for distros.
Udev is already forked, in the form of eudev. And Poettering is already having fun taunting them in systemd release notes, with lines like "This is your wakeup call".
Frankly i am reminded of the stuff we would see Jobs pull on stage. Like "Redmond, ready your copying machines"...
