Comment by cedws
9 days ago
Can you give concrete examples?
systemd-resolved: can be disabled and replaced with your DNS resolver of choice
systemd-timesyncd: can be disabled and replaced with your NTP daemon of choice
systemd-networkd: can be disabled and replaced with your own networking scripts
Modularity would be to be able to use, say, systemd-logind or systemd-udev without using systemd as your init, as there is no tangible or important dependency on the use of systemd as init for those functions.
On a fully-systemd system you can opt out of systemd features. But you cannot opt in to systemd features on a non-systemd system.
> there is no tangible or important dependency on the use of systemd as init for those functions.
How do you catch device events on very early startup (e.g., between start of pid1 and when processes start to fire?) if the thing that manages the devices isn't integrated with pid1 at a deep level?
logind does not "manage devices", it just provides an API for your display server to open privileged I/O devices and get a file descriptor, and have these file descriptors revoked later.
The difference with a plain `open` is that logind will allow only one process at a time to have access, and only for sessions that logged in physically (tracked using PAM), and does not require the process to have direct file access (which could enable key-logging). It will also revoke the file descriptors when switching sessions.
logind's other random features like dock and power button triggers can be done whenever logind is running and ready - the underlying API reports levels and are not timing critical.
The only thing logind really uses at runtime from systemd is temporary storage of file descriptors that it can get back after restart for graceful upgrades.
Projects like elogind and eudev exists that painstakingly strip out the systemd portions while retaining the functionality, but it's an uphill battle to constantly redo every time there's a change.
Thank you, that's what I was trying to say, but worded in a vastly superior way :-).
I am telling you that it is difficult to use systemd subcomponents without running all of systemd, and you give me example of running most of systemd and replacing a few subcomponents.
Can you run those 3 standalone?
>I am telling you that it is difficult to use systemd subcomponents without running all of systemd
Actually it's the first time you have stated that, but I'll bite.
How do you propose that would work, and why would you even want to do that? The entire point of having these modules is for them to plug in to core systemd, which enables a lot of magic that would otherwise require an amalgam of shitty shell scripts. If you don't want to use systemd, why not just use chronyd for NTP, dnsmasq for DNS, and so on? Your problem is completely imaginary.
> Actually it's the first time you have stated that, but I'll bite.
Fair point, I said it in another comment :-).
> How do you propose that would work
I don't. I merely state the fact that I don't like the way it's going with systemd, which is that many projects now assume that you have systemd and depend on it. And if you don't have systemd, you're screwed.
Similar to projects that assume that you have Ubuntu and depend on Ubuntu specificities.
And again I'm not saying that it should be illegal; just that I don't like it.
1 reply →