From a forum:
"Systemd provides a lot of network functionality in systemd-networkd, journald, timesyncd, etc. that is remote attack surface. All the systemd "cloud of daemons" is tightly coupled by dbus interfaces that enable an attacker to move from one exploited system service to the next. Even if the attacker doesn't manage to find an exploit in another system service, DoS is easily possible because the DBUS interfaces are quite fragile. Even as a benevolent admin it is easily possible to get the system into a state where e.g. clean shutdown is no longer possible because systemctl doesn't want to talk to systemd any longer and you cannot fix that. systemd-udevd also has raceconditions galore, so sending any message to it in the wrong order relative to another one will kill the system, maybe even open exploit vectors. At the very least I would, for hardening, recommend not using any network-facing systemd functionality.
And lines of code are not ridiculous, they are the best first-order estimate available. Of course an actual inspection of the code is better for a comparison, but that is a huge task. sloccount is quick and easy."
For daemons, its simply symlinking the services in the 'sv' folder to the var/services, it should be running after that.
Not sure how compatibility with systemd apps work on other inits but for what I know the packages that are shipped focus on specifically the init system that you are running (from whatever repo you use to install on the distro, for example artix has other inits besides runit).
Edit: Also you have the 'sv' command on runit that acts exactly like systemctl. You can stop, start and all that stuff