Dhclient has a lot of hooks where you could easily stick a script or binary to report back to systemd what the state of the network config is. But that would require systemd folks to spend time and effort on thinking about how to integrate existing software into their ecosystem, so they rather roll their own, which obviously takes much more time in total, but it fits the general NIH attitude of the whole project. Oh and it gives them the opportunity to repeat every mistake ever made regarding writing DHCP/NTP/... clients made during the past thirty years, plus some bonus RCEs.

> Dhclient has a lot of hooks where you could easily stick a script or binary to report back to systemd what the state of the network config is.

So you're advocating making systemd even bigger and dependent on more stuff?

Im advocating using existing stuff instead of reinventing the wheel. Making it work with existing DHCP clients is certainly less code than implementing a whole new one.

Are you familiar with the development process? Like, do they one day go "ok we are gonna build a dns into systemd now, let's open up the RFC for that, print it out and stick the papers on the walls gogogo" or is it like, "let's incorporate vital parts of state of the art into our project" ?

Dependency graph is a tiny part of one of the programs.

systemd now is something like all except kernel, DE and applications. It's not clear.

systemd is a distro. I imagine it would have been a heck of a lot less controversial if it had been upfront about that, instead of stealthing into other distros as an 'init system' and then consuming them from the inside like a chestburster from Alien (1979)

systemd-networkd uses a ridiculously asinine process for determining something as simple as "network is ready", so I'd hope that isn't actually considered one of its core functions upstream.