Originally posted by Developer12
View Post
If you take the time to read properly, I said exactly what you say here, maybe in a more detailed way. You can't run the higher level systemd components without (systemd as) init(1). You can use anything else that isn't part of systemd with (systemd as) init(1) instead if you wish, and that's what most mainstream distros do.
Originally posted by Developer12
View Post
Regarding replacing systemd tho, it depends on how much of the stack depends on each component. Just as things are now, off the top of my head I can only think about socket activation, readiness notification and logind as things commonly depended upon by userspace.
The first two could have been much more general and agreed upon but the sd guys decided to impose their own without discussion. skarnet wrote a protocol that is much more decoupled for that and should work just as well, and it will sadly get ignored because of corporate interests essentially; I think Ian Jackson wrote one as well. At the same time, I know of no server that forces you to use it to work, so it's probably isolated enough to make it easy to replace on projects.
The latter is the most problematic AFAIK, but it's still a single component. If you can do with just reaping logind in favor of, say, ConsoleKit2, you can probably remove systemd from a previously coupled system.
DNS resolver, DHCP client (systemd's implementations, obviously, but I need to be extra explicit it seems), etc, is simply not depended upon by userspace, and mainstream distros don't even enable them by default, so _currently_ you can use whatever is around for those functionalities rather than reimplement anything to replace systemd.
Not that it isn't systemd's devs' intent to make it harder to replace, the problematic part is that that criticism is completely accurate. I'm just saying we still have time, most higher level tools are not only not depended upon, but pretty much unused in the mainstream, so their "replacements" actually predate the effort.
Comment