Hi, I agree too. Systemd has too much Corporate interests for my taste. Good or not ,(I agree is too bloated and has a history of contributor hostility), it is integrated with GNOME now.
So the questions we need to ask ourselves are: 1) Do we want to commit to Systemd or find something else? 2) Are we good with something corporate/profit driven or do we want something community based? Right now GNU has failed to go into any direction paralized and left in the past. The official environment of GNU doesn't even use GNU tools anymore. So do we endorse systemd and stop developing GNU Shepherd, or reevaluate if GNOME fits with the rest of the GNU system? Regards,Fannys Oct 14, 2019, 19:54 by [email protected]: > 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. >
