Comment by graemep
3 months ago
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.
Mind providing some example on your setup/cases?
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.
At this point, I am willing to believe the point of systemd is to be the new way to do anything. "If you want to talk to the kernel, go through me".
It's a new (ill specified, non standard) runtime to target. It's like what Win32 is to the raw NTDLL, or the dotnet or Java API. It hides the OS.
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.
1 reply →
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.
1 reply →
Of course. That standardized way is runsvdir, yes?
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.
Really curious now what it was so.