Debian To Seek A General Resolution Over Their Init System Policy

[fsfhfc2018]

Is it gratuitous?

I think there's a case to be made that it is. That case won't stand up to people ignoring the case altogether though. Either way, I'm not Steve Litt, I didn't name it that.

How are the critics being censored here?

Irrelevant. The damage is already done, there is a legacy of censorship and marginalised criticism (and a whole lot of bullying) stretching back to 2014 when the decision was being made. The fact that it has happened for 5 years and is well documented isn't at all addressed by asking about here and now.

The fact you can fork means it's still just as free. Yes, they depend on each other, gratuitous or not. But interested parties can fork and do things as they want.

Yes, people keep saying that. In theory it's completely true. In practice, it's a study in how even software under a free license can be made in a way that makes it almost proprietary. Of course if you prefer wordplay to reality itself, you're absolutely right-- it is strictly "impossible" for the freedom of users to be diminished by this!

Great authority fallacy. He is probably not an idiot,

This is the worst part of your reply, because of what it blatantly ignores and even invents. I never said or implied that people should choose Devuan because Perens uses it. I don't even like Perens (I used to) and I haven't used Devuan in over a year.

It's by no means "Great authority fallacy" to counter the ad hom attacks on all critics of systemd as idiots and trolls with "is Perens an idiot?" It ought to be a direct refutation.

If I said people should just follow Perens and his decisions, yes, that would be a fallacy.

[mrugiero]

I think there's a case to be made that it is. That case won't stand up to people ignoring the case altogether though. Either way, I'm not Steve Litt, I didn't name it that.

I'm not purposefully ignoring it, I actually don't know.

Irrelevant. The damage is already done, there is a legacy of censorship and marginalised criticism (and a whole lot of bullying) stretching back to 2014 when the decision was being made. The fact that it has happened for 5 years and is well documented isn't at all addressed by asking about here and now.

Same here. I'm not an all-knowing being, so chill a bit. I'd still be thankful for any pointers.
What I'm aware is that *in here* nobody is getting their posts deleted or the like, since we're all able to read contrarian opinions.

Yes, people keep saying that. In theory it's completely true. In practice, it's a study in how even software under a free license can be made in a way that makes it almost proprietary. Of course if you prefer wordplay to reality itself, you're absolutely right-- it is strictly "impossible" for the freedom of users to be diminished by this!

Of course someone has to do the work and not everyone can, and it can be made harder or easier.
But talking about wordplay, words won't achieve a thing, and if you can't do the work all software is proprietary-like, because you can't just choose to use it whatever way you want.
There's a spectrum, I guess.

It's by no means "Great authority fallacy" to counter the ad hom attacks on all critics of systemd as idiots and trolls with "is Perens an idiot?" It ought to be a direct refutation.

If I said people should just follow Perens and his decisions, yes, that would be a fallacy.

You're right, then. I just didn't read it as intended.
The context of the quoted post wasn't one of the ones stating only idiots dislike systemd.

[mrugiero]

So, I googled the term, got here: https://www.mail-archive.com/linux-i.../msg66786.html
There's no very clear definition, but in that context what he meant is rather intuitive.
The question remains: does this apply to this case?
Not all dependencies are gratuitous.
Which are we exactly talking about? The ones between logind and systemd (init)?
I repeat, *I do not know*, I guess someone should look carefully into how those work to determine if it's gratuitous or otherwise.
I assume there are other examples, but the one I recall had more emphasis was this.
On topic, I always found it odd that everything on the systemd umbrella depended on D-Bus, but I have no idea on technical aspects.

[F.Ultra]

Well you have an example right now so you can stop acting like I've never explained it. Honestly, I really can't be bothered to go back trough my post history on the subject as I've been bringing forward these criticisms for years now to be met by the same out of hand dismissals by the same people.

It's invalid as an example since it's not an example of this cross-dependencies that keep claiming that systemd has.

You're using a very narrow technical definition of a dependency there. If you want to find dependency issues just look no further than the issues the Deband developers have had with maintaining support for alternatives and why they're now considering the support is worth the effort.

No, I use a very perfect definition of a dependency, you however keep on claiming that it's a rats nest of cross-dependencies without being capable of providing a single example of your claims. The issue at hand for Debian have zero to do with dependencies on systemd.

Yeah... The cross-dependency issues with loginD have been with DEs like Gnome and you're trying to insist a use case without one is somehow proof of these issues not being real. That's like insisting that catalytic converters didn't sap the power from cars when they were legally mandated by using a car that never had one.

Still not an example of a cross-dependency.

I'm obviously not talking about utilities here and instead assuming basic level of competence from you.

So what are you talking about then? The "feature creep" that people complain about regarding systemd is that the systemd project adds another binary. Since you never give specific details I have no choice but guess what you are referring to. So if it's not one of the utilities provided by systemd, then what are your example of a "feature creep" in systemd that have increased the security footprint?

Now I get it... You just didn't get what the analogue was about and not the analogue itself.

The analogue was about how and why the two issues feed into each other so much as to effectively be the same issue. If you're anal beyond the point of being reasonable you can call then separate, but with the way they feed into each other they are still effectively part of the same issue.

To use another analogue; It's like how the self-certification and the need to cater to airlines' wishes to the detriment of safety came together to cause the 737-Max's MCAS safety system to become a deathtrap of bad thinking and workmanship. If they'd have sorted one or the other then the issue would have been much lesser or even resolved before it went badly wrong, but when they came together things went very wrong.

And you still don't get it. I wasn't asking you why you don't like systemd, it's plainly clear that you used the example of the bug-report replies as an ad hominem on the systemd projets technical merits but try to get into your head that this was not what I was asking you about. Are you seriously so ideology driven regarding systemd that you cannot see that this is shifting the goal posts?

Again, if I had asked you why you didn't like systemd then all that would have been a fine answer but I didn't. I asked specifically why you wrote that "the implementation is botched". "The Implementation" refers to the actual code base, aka how it's implemented and not any other issues.

[fsfhfc2018]

I just didn't read it as intended.

No worries then. As for "Gratuitous Interdependency" I don't think I understood your question the first time around, it is simply a term Steve Litt uses for programs with an arbitrary number of components that are (perhaps deliberately) difficult to detangle, that shouldn't be. It doesn't include programs that have a perfectly good reason for being that way.

There is a precedent here-- deliberately obfuscated (minified) code for the simulation/intended effect of compiled software without source is not considered free or open, but this is slightly different because it's a matter of design. The concept is accepted by some as a problem, nobody thinks it is on exactly the same level as being non-free. It's a bit more like "free, but just barely." The more people do it, the more problems we have. Some people are starting to call this "open source proprietary software" which is an obvious (tongue in cheek) contradiction in terms.

[L_A_G]

On the other hand, I don't see anything intrinsically positive in supporting many init systems or, more generally speaking, base systems.
And even if there weren't the problems you point out, supporting sysvinit comes with the unnecessary burden of pretty much reimplementing what a sane init would provide in the init scripts.

As someone who tries to avoid duplicating effort and suggests others do so trough things like code written in a clear and concise manner with re-use in mind and open source I'm with you on a fundamental level. However when the "One init manger to rule them all, one init manager to find them, One init manager to bring them all and in the darkness bind them" not only has some significant flaws in both implementation and design, is developed by people who refuse to listen to perfectly reasonable criticism it actually becomes vital that there are viable alternatives.

I really don't know enough to assert anything here, but I think that if it's hard to replace, then it's hard to refactor to make it easier to replace, and wearing Lennart's shoes, it wouldn't be my top priority, since I'm attempting to make systemd work, and not everything else. They should be more open to patches changing this, tho.

This ties into what us critics of systemD are worried about it's development methodology. They're simply too focused on feature work and not putting enough effort into bug fixes and just plain refusing to go back and doing anything about seriously flawed design decisions. It's a focus of features over quality.

Additionally the fact that you can technically still fork it doesn't really matter as what really matters is practice. One of the things that really irritated Stallman back in the day and was one of the things that drove him to start the free software movement and the FSF was one of these "Free, but only in theory" situations around the Symbolics dedicated Common LISP machines. It's operating system was technically developed as an early open source project, but eventually the company developers started messing with the open source developers by doing things like adding their copyright notifications to everyone's code until they bifurcated development such that they pulled code from the open source branch for their closed branch while contributing nothing back to the open source branch.

After this you could still have an open source version of the OS for the machines, but because they'd pulled support for the open source versions they were less functional and didn't support the newer machines that were coming out. Stallman apparently spent many nights working on this OS and even went as far as removing copyright notices they'd put on code that wasn't theirs.

[L_A_G]

It's invalid as an example since it's not an example of this cross-dependencies that keep claiming that systemd has.

That example wasn't about the cross-dependencies, it was about how the cavalier attitude to bug reports and other forms of criticism combine with bad architecture feed into each other to create and overall issue than these two issues individually.

No, I use a very perfect definition of a dependency, you however keep on claiming that it's a rats nest of cross-dependencies without being capable of providing a single example of your claims. The issue at hand for Debian have zero to do with dependencies on systemd.

In this thread I've kept pointing you towards, time and time again, the issues with loginD and DEs like Gnome3. Because they've tied that part of the OS to loginD and loginD to the rest of systemD, replacing loginD with something else like eloginD (which is supposed to be loginD without the rest of it) has become far from the drop-in replacement that defenders of systemD insist it is. Trying to define dependency in a very narrow technical way just doesn't change this in any shape or form. If something doesn't work at all or works very badly without something else, then there very clearly is a dependency.

This is what I mean when I call systemD a rat's nest of cross dependencies. Once you integrate one piece of it an integral way, as soon as you try to remove that piece, it becomes like trying to remove an individual playing card at the bottom level of a house of cards. I hope this finally makes it clear what I'm trying to explain to you.

So what are you talking about then? The "feature creep" that people complain about regarding systemd is that the systemd project adds another binary. Since you never give specific details I have no choice but guess what you are referring to. So if it's not one of the utilities provided by systemd, then what are your example of a "feature creep" in systemd that have increased the security footprint?

If you need to be reminded of how many different things systemD does then you probably don't have a picture of how much it does these days. It doesn't just do the work of init and secure login, it covers a large array of things ranging from setting up networking (i.e once you compromise that part of it, you can do all manner of nasty things in a very hard-to-detect manner), power management and mounting partitions and filesystems.

I'm not even being facetious when I suggest you go look up everything systemD actually does.

And you still don't get it. I wasn't asking you why you don't like systemd, it's plainly clear that you used the example of the bug-report replies as an ad hominem on the systemd projets technical merits but try to get into your head that this was not what I was asking you about. Are you seriously so ideology driven regarding systemd that you cannot see that this is shifting the goal posts?

Shifting goalposts? I'm trying to explain to you, trough an analogy, how two issues can feed into each other to create a much bigger issue and hence the non-constructive response to constructive feedback makes the errors in implementation so much worse. Not only do they exist, but the developers refuse to admit they do and as time goes on it just becomes harder and harder to fix them.

You also probably need to go and read up on what an ad hominem attack actually is because saying that they don't listen to feedback like they should really isn't one. An actual ad hominem would be something besides the point like calling Lennart a kiddie diddler or criticizing him for unkept appearances.

Again, if I had asked you why you didn't like systemd then all that would have been a fine answer but I didn't. I asked specifically why you wrote that "the implementation is botched". "The Implementation" refers to the actual code base, aka how it's implemented and not any other issues.

I keep pointing you towards the issue that Gnome3 brought up when it started doing logins using loginD and you keep dismissing it as it somehow doesn't apply when the issues caused by the massive pain in removing it are exactly what I'm talking about when I call it a rat's nest of cross dependencies. If there weren't any cross dependencies like you claim then eloginD would have been a completely problem free drop-in replacement, but both of us know that this is just very far from the truth.

Besides this, implementation as a concept isn't limited to just exact code, but also general architecture. Implementation starts where the "what" ends and "how" begins.

[mrugiero]

As someone who tries to avoid duplicating effort and suggests others do so trough things like code written in a clear and concise manner with re-use in mind and open source I'm with you on a fundamental level. However when the "One init manger to rule them all, one init manager to find them, One init manager to bring them all and in the darkness bind them" not only has some significant flaws in both implementation and design, is developed by people who refuse to listen to perfectly reasonable criticism it actually becomes vital that there are viable alternatives.

That's valid. And, in any case, even while I don't see value in supporting many inits by itself, it shouldn't be hard, and it shouldn't hurt. And it probably shouldn't break individual packages, even if the distro itself is tied to one.
For example, one of my two favorites features of systemd, socket activation, shouldn't be a hard requirement on programs, shouldn't be hard to use while at the same time not being required, and probably should be able to work without systemd as init (even if it works *better* with it). After all, it's inspired in launchd, which in turn took inspiration in inetd, which was a separate daemon.
Just for the record, my other favorite feature is networkd, for which applies the same (may work better with systemd, but there isn't an obvious reason why it shouldn't work without it; I *guess* it does work without it, tho). Mainly because network configurations in distributions is a mess, it doesn't make any sense that Arch, Fedora, Debian and what not have completely disparate ways to do something as simple as configure the network, With networkd I can be reasonably sure that any system bringing systemd has it, and I can use a sane and consistent way for it. I'm aware NetworkManager kind of fixes this, but it also added 20 seconds to my boot last time I used it.

This ties into what us critics of systemD are worried about it's development methodology. They're simply too focused on feature work and not putting enough effort into bug fixes and just plain refusing to go back and doing anything about seriously flawed design decisions. It's a focus of features over quality.

True, but not what I meant. I was focusing on them being closed to portability patches. I wouldn't count bug fixes as portability or the other way around. For example, not supporting musl is not technically a bug, and they rejected supporting it, when it was as easy as supporting a helper function. The same way changes in elogind, ejournald and eudev should probably be able to be merge (I'm guessing here, tho).

Additionally the fact that you can technically still fork it doesn't really matter as what really matters is practice. One of the things that really irritated Stallman back in the day and was one of the things that drove him to start the free software movement and the FSF was one of these "Free, but only in theory" situations around the Symbolics dedicated Common LISP machines. It's operating system was technically developed as an early open source project, but eventually the company developers started messing with the open source developers by doing things like adding their copyright notifications to everyone's code until they bifurcated development such that they pulled code from the open source branch for their closed branch while contributing nothing back to the open source branch.

After this you could still have an open source version of the OS for the machines, but because they'd pulled support for the open source versions they were less functional and didn't support the newer machines that were coming out. Stallman apparently spent many nights working on this OS and even went as far as removing copyright notices they'd put on code that wasn't theirs.

I see. Then the place to fix these should be upstream?

[mrugiero]

One last thing. As soon as Michael has space on his inbox to receive my request I'll be deleting my account, as I'm using it to feed my procrastination and that's not OK. I just mention it in case you wonder why I may stop responding.