In <https://lists.gnu.org/archive/html/guix-devel/2019-10/msg00322.html> Svante Signell touched the topic of systemd. I think that it deserves its own thread.
I like several features of systemd: - Socket activation: the service might inherit a file descriptor (FD) with an open socket (TCP, UDP, unix domain socket, D-Bus) and not only that: the service can be lazily-started when the first request comes to the socket. It is similar to xinetd, but supports more socket types and seems overall better. - Declarative configuration: a simple service can be described in a few lines of config file. No procedural scripting or boilerplate code is necessary. - User-defined services – not only system-wide (root) ones. But I also seriously hate several features of systemd: - Complexity: circa 480 000 lines of code (and still growing). - Monolithic design: it is a single repository containing too much features and tools. And if you like only certain features, there is no easy way how to pick just them and enjoy less complexity. - Versioning: wrong versioning scheme (not semantic) and lack of stable and standardized API. Yes, we have GNU Shepherd and many other init systems and we can convert users/distributions from systemd to other init system. But what about doing – at the same time – some kind of „damage control“? Because we already live in the world where systemd is widespread. Some ideas: - Have a stable and standardized API: e.g. if some service takes advantage of the socket activation feature, it would be possible to start such service from another init system without loosing this useful feature and without the need of changing the source code. (note that it is not as easy as it looks because the service might use several sockets and you need an API to say, which FD is which socket e.g. one socket for management and several sockets for accepting client connections or one for encrypted and one for unencrypted communication, or one for IMAP4 and one for POP3) Or some watchdog API to check whether the service is running properly or it is jammed. - Convert – or even load at runtime – the systemd declarative configuration files. This also requires a stable standard. - Implement useful features of systemd in other init systems or software: like implementing socket activation feature in another init system or adding the unix domain socket support to xinetd[1]. It would be a great „selling point“ if we can say: „we can provide same useful features as systemd but with just a fraction of its complexity and in a modular way (so you install only features, you need)“. Franta P.S. I might missed some news. It is some time since I studied various init systems and compared them. So if something is already happening or done, I would be happy to hear about it. [1] yes, I know that it collides with the xinetd/inetd name which means „internet daemon“ and AF_UNIX != AF_INET, but…
