Hi, On 10/14/19 9:33 PM, marinus.savorit...@tuta.io 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 a...@vapaa.xyz: > > 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
