Debian To Seek A General Resolution Over Their Init System Policy

[mrugiero]

Besides, I'd expect Debian to be running more systemd units and fewer init scripts on newer versions, when using systemd.
I think that's the root of this conundrum: maintainers wrote systemd units to use with systemd and nobody bothered to maintain the init scripts, or at least nobody wants to keep doing it.

[mrugiero]

Addendum. I forgot to check the Windows ones. Debian got consistently better results with exceptions here and there. Nothing big tho.
Also, I didn't think of mesa, which is quite relevant in many benchmarks, including the Selenium ones I think.
Which also supports our argument: there are many things that may change speed in applications that we should suspect before pointing at init scripts. They're for **INIT**. They generally don't do much, and if they do they're probably broken.

[intelfx]

Reading the comments (those who are relevant to the topic), I guess we can all agree that maintaining just the packages for other init systems (like openrc) is not a big deal, but the real effort is maintaining all the init scripts for the packages that need them.

Nope. Maintaining both packages for alternative inits and alternative init scripts for other packages is trivial. The real effort is dealing with packages and software with non-trivial dependencies on systemd (e. g. GNOME 3). It would appear their numbers is on the rise.

[andyprough]

Addendum. I forgot to check the Windows ones. Debian got consistently better results with exceptions here and there. Nothing big tho.
Also, I didn't think of mesa, which is quite relevant in many benchmarks, including the Selenium ones I think.
Which also supports our argument: there are many things that may change speed in applications that we should suspect before pointing at init scripts. They're for **INIT**. They generally don't do much, and if they do they're probably broken.

You've worked hard on this today, bravo! Good answers, very useful. That should set some readers' minds at ease.

[audir8]

The problem is that this "rat's nest" of yours is still unsubstantiated claims since you after all this time still do not provide any example(s), which is why people (including me) keep asking you. Also it does not follow my own experience since I use systemd as pid 1 on all of our servers and desktops but not any of the other systemd utilities so "you have to use the whole bloated mess" is not true.

The "internal API" is also just a D-Bus interface and if you check the list at https://www.freedesktop.org/wiki/Sof...tabilityChart/ you can clearly see that "Covered by Interface Stability Promise" is "yes" on all except for "udev session switch ACL properties".

https://chromium.googlesource.com/chromiumos/overlays/chromiumos-overlay/+/refs/heads/master/sys-apps/journald/files/242-support-journald-running-without-systemd.patch

Here's the patch not applied to current master: https://github.com/systemd/systemd/b...server.c#L2187

It's up to upstream to provide modular builds. Unless you don't consider Chromium OS to be Linux in some way.

[Karl Napf]

Nope. Maintaining both packages for alternative inits and alternative init scripts for other packages is trivial.

At least a significant number of Debian developers seems to disagree or there would not be this GR proposal in Debian.

The real effort is dealing with packages and software with non-trivial dependencies on systemd (e. g. GNOME 3). It would appear their numbers is on the rise.

Just to quote the void linux wiki: "Installing GNOME on Void Linux is very easy"

I do see two dependencies of 3rd party software mentioned rather regularly:

• libsystemd: A library that is there that wraps all the code that is needed to have its dependent software work with or without systemd. I doubt this would be any problem if that library would have been called libfoobar or something... in fact even Devuan rolled back their changes to remove this dependency once they figured out that the library does nothing:-)
• logind: A stable and fully documented DBus API with several implementations that do not need systemd to be PID1. Ok, systemd devs do not recommend that to be re-implemented elsewhere, but what do they know? Their judgement can't be trusted for anything else, so why here? :-)

Where exactly is the problem?

[L_A_G]

The problem is that this "rat's nest" of yours is still unsubstantiated claims since you after all this time still do not provide any example(s), which is why people (including me) keep asking you. Also it does not follow my own experience since I use systemd as pid 1 on all of our servers and desktops but not any of the other systemd utilities so "you have to use the whole bloated mess" is not true.

It's only "unsubstantiated" in the sense that you rather conveniently forget every example and explanation given to you. You don't just forget then in between conversations, in literally the post you're replying I pointed out that the cross-dependencies force you to pull in all of the major components and make it near impossible for third parties to replace, fork or otherwise improve parts of it.

Probably the best example of this is loginD, which has literally been forced upon almost every distro due to very heavy cross-dependencies and the herculean task of avoiding it's use. But I guess you're probably going to continue insisting that I'm not bringing up any examples or proof of my arguments seeing how I've seen you take part in arguments about this systemD module in question.

I could go into how the constant feature creep is not only making it a bigger and bigger attack surface, it's also making it a more and more critical one at the same time. However it's probably a waste of time when you're going to do what you always do upon reading arguments against systemD and forget it as soon as you've finished reading it.

It's a very different issue when talking about "the implementation" which was what you claimed and what I asked details about.

So you didn't understand the analogue, then let me spell it out as plainly as I can; Technically it's a separate issue, but when it takes place in the context of all the other issues it makes them even more serious.

[Karl Napf]

Probably the best example of this is loginD, which has literally been forced upon almost every distro due to very heavy cross-dependencies and the herculean task of avoiding it's use.

Logind is an essential piece of software that makes Linux more secure. Developers that want to write secure software need to use it, simply because nobody can be bothered to implement and then maintain a different approach to solve the same problem.

Basically we have a bunch of people unable to provide any idea on how to address problems that developers have and then complain that everybody uses systemd's solutions. To make things worse: Rather often the people that complain the loudest do not even understand those problems in the first place.

[L_A_G]

...

Security is all fine and dandy, but when the back and forth dependencies make it incredibly difficult to implement and maintain any other solution it's hardly the fault of anyone who isn't happy about it being forced upon them like this. In this instance systemD with it's back and forth dependencies really is the source of the problem and why I keep calling it functionally monolithic.

[andyprough]

L_A_G you've also made some very good points about why system-D is very troublesome. More people should be concerned. I think clearly that users need to be given a choice of init systems, and also a choice of ways to avoid pulling in system-D dependent packages to avoid system-D monolithic structures from creeping into the system. Seems like avoiding Gnome and Gnome packages may be an important part of that.