None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.
Yes, but not using those seems to defeat the point of using systemd.
The most convincing advocacy I have seen for systemd (by a BSD developer, its fairly well known) is that it provides an extra layer of the OS (on top of the kernel) to standardise things.
> Yes, but not using those seems to defeat the point of using systemd.
I don't see how it defeats the point - it still nice init / services manager, it still provide features say sysvinit couldn't do at all for my _services_ and management/lifecycle of services.
How often I tackle with resolved or networkd or timesyncd - not even sure, may be once a 2-3 months, while systemd-as-service-manager I do almost every day.
If you don't use them, you still have a standardized way of managing system services, including scheduled batch jobs. The other services are a convenient and integrated way of getting a basic version of that functionality, but they are by no means the entire point of systemd.
Apart from the comparison to NTDLL making no sense, you'd be wrong about the tools too. It aims to provide a basic standardized way to do most system-level management (set up networking, do DNS resolution, get a decently synchronized system clock) but it absolutely does not aim to replace more specialized tools like chrony or NetworkManager. For example, timesyncd doesn't do NTP or PTP, only SNTP.
systemd (the PID 1), journald and udev are different, though, because they're mandatory; and there's no alternative to logind while technically optional.
I came to the conclusion that people who complaining about systemd don't even understand, use or used it, like saying that everything run on PID1, just open htop and it's going to be proven wrong, or they know that, but their arguments are so meaningless that they resorted to lies
How so? The functionality of the kernel and of systemd are basically orthogonal: neither really provides features that the others do. There are some interfaces in the kernel which are basically intended to be delegated to one userspace process, like cgroups and the hotplug management done by udev, so talking to them directly as an application or library is probably not a good idea and those processes provide a means of co-ordinating that, but that's a kernel decision and the udev one predates systemd.
I remember that on one of the $dayjobs around 2014 we have used runit, but I honestly don't remember why and what it gave us. Very likely just as auxiliary tool, not main init system.
None of these are mandatory though. It's up to the distros whether to use them. For example at this point resolved is pretty commonly enabled by default, networkd not at all, and timesyncd is perhaps 50-50 with chrony.