Hi, On 10/14/19 2:22 PM, František Kučera wrote: > 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.
That's for sure! > > 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. It looks like a xinetd new feature, but - do we really need a dbus? > > - Declarative configuration: a simple service can be described in a few > lines of config file. No procedural scripting or boilerplate code is > necessary. But not in a way systemd implemented it. > > - User-defined services – not only system-wide (root) ones. Is it about a set of user processes running during the login process ? If so, I suppose it's out of scope the init system, it's some kind of extra feature. > > But I also seriously hate several features of systemd: I don't like systemd at all, but it's offtopic. > > - 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: GNU Shepherd is a nice thing however. > > - 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. I suppose to not follow the systemd story to be so invasive. It should be quite optional. > > - 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)“. I can start with that, because by a strange coincidence I have had a problem starting a set of daemons properly. Well, in my case there are a few daemons depends on other daemon and/or other service (service is a udp/tcp/unix socket(s)). Another problem was a requirement to start those daemons as soon as possible. Finally - I do *not* want to modify code of the well working daemons (and this is a bad way to get it works). So, I have decided to write another daemon runs them in a right order, waits for the sockets, solve dependencies etc ... Some code pieces might be located on sf.net, but I don't expect someone else might have a real interest with that. (but I need to point here - it works on linux only (relies on /proc and inotify() I guess)) I'm not sure is it interesting or not, however if somebody will join with that - I can spend some of my spare time with that. Going back to the systemd replacing - it might be done and, personally I want to replace it, but needless to say it's a huge effort for one man. BTW I suppose the following things should be taken onto account: - this new init should be a set of optional things like tools and daemons - new init shouldn't looks like a systemd-mess - sw architecture should be proposed first - features should be determined firstly > > 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. systemd is defective by design, but widely used - and it might be a reason other init-systems hasn't advance yet. > > [1] yes, I know that it collides with the xinetd/inetd name which means > „internet daemon“ and AF_UNIX != AF_INET, but… > > > -- Alexander Vdolainen, Evil contractor.
signature.asc
Description: OpenPGP digital signature
