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.
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?
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.