hard disagree. usually arguments are the other way, that systemd pid1 implies that there's not going to be competition for systemd-timesync or systemd-networkd

hard disagree. usually arguments are the other way, that systemd pid1 implies that there's not going to be competition for systemd-timesync or systemd-networkd or systemd-bootd. but none of these fears have panned out: it's easy to drop in other modules in these spots, and there are many offerings still. and to address this new concern, i dont think replacing systemd would be so hard. and i dont think it would be so difficult to replace systemd init/pid1 while still using other systemd services. systemd is more a mono-repo; there's very little notable hard runtime coupling between the different pieces. i expressed elsewhere in the comments a sadness that upstarts death has lead us to monoculturism. i do want to see us exploring & trying. but i dont think systemd init/pid1 is deeply rooted, i dont think it's a particularly difficult thing to replace. some not-very-big translation layers will get through 99.9% of what distos actually use, to address point 1. and i simply disagree on point 2..there already are competing offerings and what systemd kffers does not often insist on being run under systemd.