Debian To Seek A General Resolution Over Their Init System Policy

[pal666]

"When a wise man points at the moon the imbecile stares at the finger".

in case of wise men producing systemd, imbeciles cluelessly blame implementation, which they fail to understand "on purpose", just like write its name properly

[intelfx]

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

Correction: at least a significant number of Debian developers seems to not give a damn about maintaining initscripts (and rightfully so), hence the GR. That does not make the task itself any more complex.

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

Right. That's because in case of GNOME 3, that effort (to untie it from systemd and reimplement missing bits of functionality from scratch) has already been expended.

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?

In most cases, libsystemd is an example of a trivial systemd dependency. systemd-logind has indeed been reimplemented to a varying degree of success (which is really an argument for systemd, not against it), and reimplementing systemd-logind is exactly the kind of effort I've been talking about.

Still, that's not the end of story. For example, here you have GNOME 3.34 which now depends on systemd --user (the process manager itself) for session management. This dependency is now optional (the old code didn't go anywhere), but I'm assuming it will be made mandatory in a few releases or so (because that's the point of using systemd — to reduce the amount of code in your project via code reuse, not the other way around).

[F.Ultra]

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.

But that is not examples, that is just you making wide claims akin to people watching a 10h presentation and just yelling "you are wrong!" before running out the door.

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.

And how is logind an example of this cross-dependencies hypothesis of yours when systemd have exactly zero dependencies on logind?

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.

Once again wide sweeping allegations without any form of substantiation, point to a feature creep and how it created an attack surface and we can talk about it. Just arguing that because the systemd project gained another binary/utility the attack surface grew is disingenuous at best.

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.

So now pointing to some nasty replies to bug-reports is an analogue for "the implementation is botched". I'm sorry to be a Slashdot-asshole here but i don't think the word means what you think it means.

[F.Ultra]

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.

And how is this in any way evidence for a "rat's nest of dependencies" and "you have to run the whole bloated mess" when this is just a utility (journald) using the cgroups functionality when being launched under systemd.

Did you even look at the patch you linked to? All it does is:

s->cgroup_root = strdup("");

When detecting that it's running without cgroups. You guys aren't even trying!

[birdie]

...

Please stop using this criminal pictures/gifs/references in any shape and form. For a lot of people he is worse than Pol Pot/Stalin/Hitler combined.

[Karl Napf]

You probably should look at the mess that occurred with Gnome3 and loginD because it's pretty much a case study in what people are concerned about systemD dependencies going back and forth across very vital components.

There is no back and forth between systemd-logind and the layer below it nor the one above it. It's one layer in a stack that can be cleanly replaced, as repeatedly proven by now by alternative implementations.

this "You're not allowed to criticize anything unless you're actively working on something to replace it"-nonsense is just a lazy attempt at trying to avoid addressing criticism.

You are allowed to criticize for as long as you want. Be my guest. But for things to change somebody needs to put in the work. Neither of us here on Phoronix is going to do that, so no harm done in venting your frustration here:-)

When the issue is that the heavily cross-dependent nature of systemD and the resulting unnecessary difficulty of creating and maintaining alternatives to systemD modules like loginD then the blame definitely lies with it's developers. You can't make something incredibly difficult and then try to act like you're not the main reason it's not being done. That's just not how it works.

First of: I do not agree with the claim that systemd is heavily cross-dependent or needlessly difficult.

Second: Why are you so hung up on the systemd code and how they do things? Provide alternative ideas to solve the problems that Linux developers have. There is no need to care for how systemd or anybody else does things or which APIs systemd or any other system has chosen to implement, just solve the problems!

E.g. logind provides a way to securely manage access to device nodes. Write a piece of software that does that by printing tokens in the printer that the user has to scan to actually access a device node, it does not matter. Any robust and workable solution will be picked up by developers, even those currently requiring systemd. They have no other options, so they must use systemd.

Even the "evil" Gnome devs have repeatedly stated that they are willing to accept maintained patches using maintained software as its base for the functionality currently provided by logind.

[L_A_G]

Which back and forth dependencies? Systemd-logind depends on system-PID1 to manage cgroups/namespaces for it. That's it.

You probably should look at the mess that occurred with Gnome3 and loginD because it's pretty much a case study in what people are concerned about systemD dependencies going back and forth across very vital components. Once you start using it, then you're basically stuck because of the heavy back and forth dependencies within systemD.

WAAH WAAH!! STOP VOICING CONCERNS!!! YOU'RE SHOULDN'T CRITICIZE ANYTHING YOU DON'T HAVE SEVERAL MAN MONTHS TO REPLACE AND THEN CONTINUE MAINTAINING

I may be slightly paraphrasing you there, but this "You're not allowed to criticize anything unless you're actively working on something to replace it"-nonsense is just a lazy attempt at trying to avoid addressing criticism. It's what the developers themselves and their defenders do and it really doesn't make perfectly legitimate criticism any less legitimate. You don't need to be working on a replacement to have perfectly legitimate criticisms of something any more than you need to work at Airbus to be able to point out perfectly legitimate criticisms of the Boeing 737-Max.

Valid criticisms are still valid regardless of what the person who brings them up is doing. Most people have full time jobs so they obviously don't have the time to implement something as comprehensive as a replacement for systemD components once they're well and truly embedded within a distro or DE and particularly not the continuous maintenance burden that results because of it. After all the issue here is that systemD has dug it's tentacles so far within so many parts of debian that supporting anything other than whatever systemD module has dug it's tentacles within that part of the distro is a huge burden on the developers/maintainers of that part.

In other words the issue here is not just the development and maintenance of systemD alternatives themselves, but how difficult and time consuming systemD has made it, with it's back and forth dependencies, for parts of distros that it's dug it's tentacles into to support any alternatives.

Several devs have successfully managed to extract the logind functionality out of the systemd code base and maintained that for years, so dependencies can't be that bad.

The fact that it can be done doesn't mean that it isn't be unnecessarily difficult and time consuming to maintain. Open source is not immune to the scarcity of time and resources to maintain things, particularly when they're trying to achieve the same thing.

I do give you that we have a "systemd-API-or-nothing" situation right now, simply because nobody can be bothered to implement some alternative approach to solving the problem that logind addresses. That is indeed unfortunate. But till you can prove that systemd developers are threatening developers that try change the status quo: Please stop putting the blame for that at systemd's doorstep.

When the issue is that the heavily cross-dependent nature of systemD and the resulting unnecessary difficulty of creating and maintaining alternatives to systemD modules like loginD then the blame definitely lies with it's developers. You can't make something incredibly difficult and then try to act like you're not the main reason it's not being done. That's just not how it works.

[Karl Napf]

More people should be concerned.

That's not enough: You need people competent to actually do something about the issue.

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.

It is insane to do one init system independent distribution. The testing overhead is way too big.

Go out and help distributions focusing on *one* init system that is not systemd instead, that is way more workable. If all those distributions florish and share ideas and code, they could come up with an alternative to what the systemd project (not only the init system) provides. That would indeed be interesting.

Seems like avoiding Gnome and Gnome packages may be an important part of that.

You should be safe as long as you stay away from anything younger than a decade or so.

[Karl Napf]

Security is all fine and dandy, but when the back and forth dependencies

Which back and forth dependencies? Systemd-logind depends on system-PID1 to manage cgroups/namespaces for it. That's it.

(...) make it incredibly difficult to implement and maintain any other solution

Laziness and missing competence are the only things that can stop a dedicated person to do this.

It *can* be done, otherwise there would not have been several implementations of systemd-logind already. Systemd-shim (dead by now, but widely used and battle tested in ubuntu for several releases), elogind (by gentoo, used by Devuan and probably more). I read of some more, but AFAICT those never got used in earnest.

(...)it's hardly the fault of anyone who isn't happy about it being forced upon them like this.

You poor person, you are forced to use one particular piece of free software on your own computer. How dare they?! Why don't all Debian Developers stop by and listen carefully while you tell them that you want your computer to be? They could just create exactly the right distribution for you.

Stop complaining and fix stuff yourself.

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.

Several devs have successfully managed to extract the logind functionality out of the systemd code base and maintained that for years, so dependencies can't be that bad.

I do give you that we have a "systemd-API-or-nothing" situation right now, simply because nobody can be bothered to implement some alternative approach to solving the problem that logind addresses. That is indeed unfortunate. But till you can prove that systemd developers are threatening developers that try change the status quo: Please stop putting the blame for that at systemd's doorstep.

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