Re: systemd replacement or standardization

[Alexander Vdolainen]

Hi,

On 10/14/19 9:33 PM, address@hidden wrote:
> 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?

I suppose everybody can decide it for himself, but personally I don't
like systemd, so I will never be interested in committing for this
project. Systemd is ugly from many points of view.

> 2) Are we good with something corporate/profit driven or do we want
> something community based?

We're certainly need something corporate independent for the open and
free operating system.

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

As I asked before - are there somebody ready to commit for the other
init system with systemd features?

As I understood nobody is even interested on that, but yep - I've heard
a lot of "systemd sucks" critics.

> 
> Regards,
> Fannys
> 
> Oct 14, 2019, 19:54 by address@hidden:
> 
>     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.
> 
> 

-- 
Alexander Vdolainen,
Evil contractor.

signature.asc
Description: OpenPGP digital signature