SystemD controversy

SystemD controversy

[Nioclás Pól Caileán de Ghloucester]

[-- Attachment #1: Type: text/plain, Size: 224 bytes --]

Hello.

Ada-compiler makers used to target Red Hat and different Adaists used to
contribute to Debian.

Red Hat and Debian use disputed SystemD C code. Do you avoid it?

Regards.
Nioclás Caileán Pól de Ghloucester

Re: SystemD controversy

[magardner2010]

On 13/03/2024 16:07, Nioclás Pól Caileán de Ghloucester wrote:
> Hello.
> 
> Ada-compiler makers used to target Red Hat and different Adaists used to
> contribute to Debian.
> 
> Red Hat and Debian use disputed SystemD C code. Do you avoid it?
> 
> Regards.
> Nioclás Caileán Pól de Ghloucester

I'm pretty sure that the presence or absence of SystemD doesn't, or at 
least shouldn't, influence how compilers work.

So, unless one is writing software that directly interacts with the init 
system, or any of the other components that SystemD provides (and are 
not yet available in other init systems), it shouldn't matter if one is 
programming on/for Debian, Devuan, Arch, Fedora, Red Hat, or possibly 
even one of the BSDs.

Re: SystemD controversy

[Nioclás Pól Caileán de Ghloucester]

[-- Attachment #1: Type: text/plain, Size: 725 bytes --]

On Wed, 13 Mar 2024, MAGardner2010 wrote:
"I'm pretty sure that the presence or absence of SystemD doesn't, [. . .]
influence how compilers work."

Hello,

I agree.

"[. . .] it shouldn't matter if one is programming 
on/for Debian, Devuan, Arch, Fedora, Red Hat, or possibly even one of the 
BSDs."

GNU/Linux users debate about SystemD allegedly being buggy and insecure. 
Contributors to GNU/Linux distributions boast that such distributions do 
not use SystemD because of these reasons. A new GNU/Linux distribution was 
created specifically to avoid SystemD. I do not want to use (Ada-compiler) 
software on a buggy or insecure operating system. Do you?

Regards.
Caileán Nioclás Pól de Ghloucester

Re: SystemD controversy

[Keith Thompson]

Nioclás Pól Caileán de Ghloucester
<Master_Fontaine_is_dishonest@Strand_in_London.Gov.UK> writes:
> On Wed, 13 Mar 2024, MAGardner2010 wrote:
> "I'm pretty sure that the presence or absence of SystemD doesn't, [. . .]
> influence how compilers work."
>
> Hello,
>
> I agree.
>
> "[. . .] it shouldn't matter if one is programming on/for Debian,
> Devuan, Arch, Fedora, Red Hat, or possibly even one of the BSDs."
>
> GNU/Linux users debate about SystemD allegedly being buggy and
> insecure. Contributors to GNU/Linux distributions boast that such
> distributions do not use SystemD because of these reasons. A new
> GNU/Linux distribution was created specifically to avoid SystemD. I do
> not want to use (Ada-compiler) software on a buggy or insecure
> operating system. Do you?

All operating systems are buggy and insecure.  Some are less so than
others.  I have no particular opinion on whether systemd makes a system
more or less secure.  (The system I'm typing this on happens to use
systemd, a fact that I routinely ignore.)

If you prefer to avoid systemd, that's fine, but I don't see the
relevance to Ada.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */

Re: SystemD controversy

[Pascal Obry]

Hello,

> Ada-compiler makers used to target Red Hat and different Adaists used
> to
> contribute to Debian.
> 
> Red Hat and Debian use disputed SystemD C code. Do you avoid it?

Well as all new stuff... People like bashing. If one think systemd is
not good he can propose something better. Bashing people/projects seems
a way of life for some. This has been also the case for pulseaudio and
remember the new GNOME Shell at the begin... just to mention those as
examples.

That a non issue to me...

-- 
  Pascal Obry /  Magny Les Hameaux (78)

  The best way to travel is by means of imagination

  http://photos.obry.net

  gpg --keyserver keys.gnupg.net --recv-key F949BD3B

Re: systemd controversy

[Lawrence D'Oliveiro]

On Wed, 13 Mar 2024 16:34:14 +0200, magardner2010 wrote:

> So, unless one is writing software that directly interacts with the init
> system ...

If you are writing code that will run as one or more server processes, you 
will likely also want to provide scripts/config to manage those processes. 
For systemd, that could be service definition files.

Re: systemd controversy

[streaksu]

On 3/13/24 22:55, Lawrence D'Oliveiro wrote:
> If you are writing code that will run as one or more server processes, you
> will likely also want to provide scripts/config to manage those processes.
> For systemd, that could be service definition files.

Not relevant to the whole overarching discussion, but to my 
understanding, that might be better managed by distribution / OS 
maintainers, rather than developers. When thinking about programs like 
daemons, or other similar pieces on a bigger system, with all the 
variety of systems, init systems, and programs around, who best to do it 
than the people that are ultimately orchestrating the whole ecosystem.

Re: systemd controversy

[Lawrence D'Oliveiro]

On Mon, 18 Mar 2024 18:05:20 +0100, streaksu wrote:

> On 3/13/24 22:55, Lawrence D'Oliveiro wrote:
>
>> If you are writing code that will run as one or more server processes,
>> you will likely also want to provide scripts/config to manage those
>> processes. For systemd, that could be service definition files.
> 
> ... to my understanding, that might be better managed by distribution /
> OS maintainers, rather than developers.

I was thinking more about code being written for in-house use by 
particular customers--I should have made that clear.

However, what you say is true for open-source code that is being 
published. Though I suspect it would still be helpful to provide some info 
about how interlocking processes are supposed to fit together, and 
systemd .service files could serve as a lingua franca for that, even for 
distros that don’t use systemd. The declarative systemd unit-file syntax 
should be easier to translate to other forms than perhaps going the other 
way.

Re: systemd controversy

[streaksu]

On 3/18/24 20:56, Lawrence D'Oliveiro wrote:
> I was thinking more about code being written for in-house use by
> particular customers--I should have made that clear.

That is fair enough.

> However, what you say is true for open-source code that is being
> published. Though I suspect it would still be helpful to provide some info
> about how interlocking processes are supposed to fit together, and
> systemd .service files could serve as a lingua franca for that, even for
> distros that don’t use systemd. The declarative systemd unit-file syntax
> should be easier to translate to other forms than perhaps going the other
> way.

I agree that it could be useful for a project to provide some barebones 
units for that. If you are, for example, a maintainer for devuan (a 
systemd less debian) I imagine you will appreciate those being there for 
documentation rather than not.

Re: systemd controversy

[Lawrence D'Oliveiro]

On Tue, 19 Mar 2024 01:36:20 +0100, streaksu wrote:

> If you are, for example, a maintainer for devuan (a systemd less debian)
> I imagine you will appreciate those being there for documentation rather
> than not.

After they’ve recovered from an apoplectic fit at having to deal with the 
kind of systemd-related stuff they specifically set up Devuan to get away 
from.

;)

Re: systemd controversy

[streaksu]

On 3/19/24 03:36, Lawrence D'Oliveiro wrote:
> After they’ve recovered from an apoplectic fit at having to deal with the
> kind of systemd-related stuff they specifically set up Devuan to get away
> from.

Hahaha, that's fair enough.

Re: systemd controversy

[Kevin Chadwick]

>The declarative systemd unit-file syntax should be easier to translate to other forms than perhaps going the other way.

I can't see how non portable unit files backed by c code are more helpful
 than atleast more portable scripts with less c per command to interpret, to
 be honest.


-- 
Regards, Kc

Re: systemd controversy

[Lawrence D'Oliveiro]

On Tue, 19 Mar 2024 10:16:50 -0000 (UTC), Kevin Chadwick wrote:

>>The declarative systemd unit-file syntax should be easier to translate
>>to other forms than perhaps going the other way.
> 
> I can't see how non portable unit files backed by c code are more
> helpful than atleast more portable scripts with less c per command to
> interpret, to be honest.

The unit files are in the classic .INI file format, which has been around 
for decades. Code for parsing it should be readily available for every 
language in common use.

Scripts need an interpreter. Being Turing-complete, in general information 
cannot be extracted from them except by running them. Unit files have a 
fixed vocabulary of keyword entries, which can be easily enumerated, 
looked up, whatever. That’s what’s meant by “declarative”.

Re: systemd controversy

[Kevin Chadwick]

\r>Scripts need an interpreter. Being Turing-complete, in general information
 
>cannot be extracted from them except by running them. Unit files have a 
>fixed vocabulary of keyword entries, which can be easily enumerated, 
>looked up, whatever. That’s what’s meant by “declarative”.

Sorry but that is nonsense. The code behind those unit files is a lot of
 disparate C.

In my experience init scripts are made entirely of simple commands that are
 documented and editable, piece by piece.

https://cvsweb.openbsd.org/src/etc/rc?rev=1.572&content-type=text/x-cvsweb-markup

-- 
Regards, Kc

Re: systemd controversy

[Lawrence D'Oliveiro]

On Wed, 20 Mar 2024 00:58:30 -0000 (UTC), Kevin Chadwick wrote:

> On Tue, 19 Mar 2024 22:29:50 -0000 (UTC), Lawrence D'Oliveiro wrote:
>>
>>Scripts need an interpreter. Being Turing-complete, in general
>>information cannot be extracted from them except by running them. Unit
>> files have a fixed vocabulary of keyword entries, which can be easily
>> enumerated, looked up, whatever. That’s what’s meant by “declarative”.
> 
> Sorry but that is nonsense. The code behind those unit files is a lot of
> disparate C.

That’s purely down to how you choose to implement it--it has nothing to do 
with the format--and meaning--of those unit files themselves. Nobody can 
stop you from writing bad code to parse a good format.

> In my experience init scripts are made entirely of simple commands that
> are documented and editable, piece by piece.

sysvinit scripts are full of boilerplate sections that users regularly 
copy and paste from one to the next, without thinking too much about what 
they do.

Re: systemd controversy

[Kevin Chadwick]

\r>That’s purely down to how you choose to implement it--it has nothing to do
 
>with the format--and meaning--of those unit files themselves. Nobody can 
>stop you from writing bad code to parse a good format.
>

I'm skeptical of the flexibility being lost. Perhaps it is possible but Ada
 was specified competitively. Had Linux init been handled competitively then
 I doubt they would have attempted and failed to move away from scripts
 entirely. Likely openrc, runit or a new init system would have succeeded.

>> In my experience init scripts are made entirely of simple commands that
>> are documented and editable, piece by piece.
>
>sysvinit scripts are full of boilerplate sections that users regularly 
>copy and paste from one to the next, without thinking too much about what 
>they do.

SysV init scripts are quite horrid but OpenBSDs rc system is far more
 transparent, flexible and nicer to work with than systemd.


-- 
Regards, Kc

Re: systemd controversy

[Lawrence D'Oliveiro]

On Wed, 20 Mar 2024 09:56:18 -0000 (UTC), Kevin Chadwick wrote:

> I'm skeptical of the flexibility being lost.

systemd service definitions let you state dependencies between services. 
Furthermore, it separates them into ordering dependencies versus 
requirement dependencies.

E.g. an application that uses a MariaDB database requires MariaDB to be 
running before it can be started (ordering + requirement dependency).

An application that can (but doesn’t have to) make use of network services 
should be started after the network stack is up (ordering dependency).

I’m not aware of any other service-management system that provides this 
level of control.

> SysV init scripts are quite horrid but OpenBSDs rc system is far more
>  transparent, flexible and nicer to work with than systemd.

Does it have the equivalent of cgroups? These are a Linux feature (also 
used by OpenRC) to ensure that, no matter how service processes may fork/
exec/terminate, the service manager can always track them down.

Re: systemd controversy

[Alexis]

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> systemd service definitions let you state dependencies between services. 
> Furthermore, it separates them into ordering dependencies versus 
> requirement dependencies.
>
> E.g. an application that uses a MariaDB database requires MariaDB to be 
> running before it can be started (ordering + requirement dependency).
>
> An application that can (but doesn’t have to) make use of network services 
> should be started after the network stack is up (ordering dependency).
>
> I’m not aware of any other service-management system that provides this 
> level of control.

s6 supports both dependency management and readiness notification:

  https://skarnet.org/software/s6/overview.html

s6 is the basis for 66, used for service management by Obarun, an
Arch-based distro:

  https://wiki.obarun.org/doku.php?id=66intro

When i was running Void as my daily driver, i was using 66 for service
management. (And not runit, which doesn't have true support for
dependencies; kludges are required.)

The s6 site has a page discussing "socket activation":

  https://skarnet.org/software/s6/socket-activation.html

OpenRC supports integration with s6, and OpenRC itself provides
dependency management; cf. this excerpt from the openrc-run(8) man
page:

> You should define a depend function for the service so that openrc-run
> will start and stop it in the right order in relation to other
> services. As it's a function it can be very flexible, see the example
> below.  Here is a list of the functions you can use in a depend
> function. You simply pass the names of the services you want to add to
> that dependency type to the function, or prefix the names with ! to
> remove them from the dependencies.
>
> need
> The service will attempt to start any services it needs regardless of
> whether they have been added to the runlevel. It will refuse to start
> until all services it needs have started, and it will refuse to stop
> until all services that need it have stopped.
>
> use
> The service will attempt to start any services it uses that have been
> added to the runlevel.
>
> want
> The service will attempt to start any services it wants, regardless of
> whether they have been added to the runlevel.
>
> after
> The service will start after these services and stop before these services.
>
> before
> The service will start before these services and stop
> after these services.
>
> provide
> The service provides this virtual service. For example, named provides
> dns.  Note that it is not legal to have a virtual and real service
> with the same name. If you do this, you will receive an error message,
> and you must rename either the real or virtual service.

There's also dinit, which i don't have any direct experience of; here's
a page by the author, comparing it to other systems:

  https://github.com/davmac314/dinit/blob/master/doc/COMPARISON

(And of course, since cgroups is distinct from systemd, it can be
utilised by any init / supervision / service management system.)


Alexis.

Re: systemd controversy

[Alexis]

Lawrence D'Oliveiro <ldo@nz.invalid> writes:

> The declarative systemd unit-file syntax should be easier to translate
> to other forms than perhaps going the other way.

s6 author Laurent Bercot has written a detailed document discussing
converting systemd unit files to an s6 context:

  https://skarnet.org/software/s6/unit-conversion.html


Alexis.

Re: systemd controversy

[Kevin Chadwick]

So now you have moved on to inventing issues in search of justifications.
 One of which is concurrent startup of which there is no need at all and
 actually causes a number of problems...

It can also be accomplished very clearly and easily from a script.

-- 
Regards, Kc

Re: systemd controversy

[Lawrence D'Oliveiro]

On Thu, 21 Mar 2024 01:50:05 -0000 (UTC), Kevin Chadwick wrote:

> So now you have moved on to inventing issues in search of
> justifications.
>
>  One of which is concurrent startup of which there is no need at all and
>  actually causes a number of problems...

Which I never mentioned.