Announcement
Collapse
No announcement yet.
Debian To Seek A General Resolution Over Their Init System Policy
Collapse
X
-
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.
-
Originally posted by L_A_G View PostAs 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.
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.
Originally posted by L_A_G View PostThis 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.
Originally posted by L_A_G View PostAdditionally 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.
Leave a comment:
-
Originally posted by F.Ultra View PostIt's invalid as an example since it's not an example of this cross-dependencies that keep claiming that systemd has.
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.
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?
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?
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.
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.Last edited by L_A_G; 11 November 2019, 01:36 PM.
- Likes 1
Leave a comment:
-
Originally posted by mrugiero View PostOn 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.
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.
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.
- Likes 3
Leave a comment:
-
Originally posted by mrugiero View PostI just didn't read it as intended.
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.
Leave a comment:
-
Originally posted by L_A_G View Post
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.
Originally posted by L_A_G View PostYou'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.
Originally posted by L_A_G View Post
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.
Originally posted by L_A_G View Post
I'm obviously not talking about utilities here and instead assuming basic level of competence from you.
Originally posted by L_A_G View Post
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.
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.
Leave a comment:
-
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.
Leave a comment:
-
Originally posted by fsfhfc2018 View PostI 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.
Originally posted by fsfhfc2018 View PostIrrelevant. 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.
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.
Originally posted by fsfhfc2018 View PostYes, 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!
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.
Originally posted by fsfhfc2018 View PostIt'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.
The context of the quoted post wasn't one of the ones stating only idiots dislike systemd.
- Likes 1
Leave a comment:
-
Is it gratuitous?
How are the critics being censored here?
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.
Great authority fallacy. He is probably not an idiot,
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.
Leave a comment:
-
Originally posted by L_A_G View PostAt what point did I insist that people should drop what they're doing and do as I say? Did you actually read all that from my criticism of how systemD has been set up and developed? Because by that logic all criticisms as extensive as mine demands that people drop what they're doing and do what they think they should. This is about as asinine of an argument as the "Well you should either take loads of your time to work on a replacement or not bring up any valid criticisms you may have" deflection that I was originally replying to.
Originally posted by L_A_G View PostOne of the issues I have with the way systemD has been set up and developed boils down to the making use cases for those who don't want it unnecessarily difficult to implement and maintain. As you can see from what's going on with Debian, the additional maintenance burden is causing them to reconsider supporting these use cases.
What you mean I'd call implementations details/design.
And yes, something that is hard to replace is probably poorly designed.
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.
Originally posted by L_A_G View PostThere's nothing that I can see which actually prevents the systemD developers from returning to more unics-esque philosophy and removing most of my concerns with it. However Lennart & Co instead chose not to do this and have simply scoffed at the idea, claiming that this approach is old fashioned and unnecessary.
It also depends on what we accept as "Unix philosophy" here.
The point here is to build a complete system, not many unrelated tools that happen to be able to smash together, so not all approaches are valid.
If we just mean playing nice with not being running all together, then that's a different story.
I'm almost sure you proposed something that made sense to me in this regard, but I don't exactly recall what.
Originally posted by fsfhfc2018 View PostThis has several names now: Gratuitous interdependency (Steve Litt) Redix (anti-POSIX, my own) Punix (someone from the FSF) and "open source proprietary software" or OSPS (not mine.)
Originally posted by fsfhfc2018 View PostThere are ultimately cult tactics being used against critics, as well as censorship used to manufacture consensus (as documented thoroughly by Daniel Pocock.)
Originally posted by fsfhfc2018 View PostThe truth is, a lot of the reason critics seem like a minority these days is they keep getting shut down by pushy fanboys of "Hobson's choice." It makes free software less free, and open source less open, but we can pretend that nobody important cares.
Originally posted by fsfhfc2018 View PostEven Bruce Perens (2nd DPL ever, author of DFSG, author of Open Source Definition, co-founder of OSI) uses Devuan. Is he really an idiot?
Finally, when you make a choice it doesn't mean you think everyone deciding differently are idiots.
Leave a comment:
Leave a comment: