Why Did It Take Devuan Two Years to Replace Systemd?
troubleshooters.com
Why Did It Take Devuan Two Years to Replace Systemd?
1–10 of 132 posts
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#2I keep waiting for the reasoned, technical arguments against systemd instead of veiled metaphors, complaints about its creator, or protestations that it's different.
The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces.
Systemd, for all its flaws, fixes some very important problems that init and runit and similar systems left unsolved. It's complicated, but it's hard to argue it's unnecessarily so. We always end up at these tortured bike metaphors or some other garbage. There's a whole website devoted to criticisms and it feels like at least half of the site is devoted to this kind of baseless rhetoric.
As far as I can tell, systemd is a holy war. It's the new editor debate. It's vi vs emacs vs sublime vs atom vs ... down throughout time, with people arguing where the tradeoff between simplicity of execution is more important than delivering a system people asked for.
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#3Sure, it might be because System D integrates so tightly with the whole ecosystem that it is hard to replace it.
Or: Those folks who write rants about system d are not very active in contributing to a distribution that runs without it. With some discussions, you have that feeling that there are "those who talk, and those who do".
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#4I keep waiting for the reasoned, technical arguments against systemd instead of veiled metaphors, complaints about its creator, or protestations that it's different. The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces. System…
Those of us who have participated in past debates about systemd, I think, would know that there is more nuance here than talking heads give. I have heard plenty of reasoned thought about why systemd is bad and good, so please stop trying to make a holy war where one doesn't exist. Also, Emacs is clearly supeirior due to GPL license alone. Not to mention it's an OS in itself.
GPLv3 is the future
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#5I keep waiting for the reasoned, technical arguments against systemd instead of veiled metaphors, complaints about its creator, or protestations that it's different. The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces. System…
> complaints about its creator
I've read many complaints and analysis about systemd, however it seems if they mention "Lennart Poettering" they are usually valueless rants.
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#6I keep waiting for the reasoned, technical arguments against systemd instead of veiled metaphors, complaints about its creator, or protestations that it's different. The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces. System…
I'm a proponent of declarative init systems, and I'm against systemd.
I don't think getting into the specifics is going to be productive here, but I just wanted to point out that the debate shouldn't be framed as "systemd" vs "non-declarative init systems".
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#7I keep waiting for the reasoned, technical arguments against systemd instead of veiled metaphors, complaints about its creator, or protestations that it's different. The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces. System…
You might have missed this: https://lkml.org/lkml/2017/7/6/577
Ted Ts'o: https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
"For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible."
Also:
"Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition."
And:
"The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned."
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#8I keep waiting for the reasoned, technical arguments against systemd instead of veiled metaphors, complaints about its creator, or protestations that it's different. The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces. System…
I don't think that most people have a problem with systemd itself. Only some people. Usually it's a minor problem. But then you take it to the mailing list, and if it gets all the way to Lennart, he'll treat it like that's a "You" problem.
I have not personally experienced this, but I've been in enough of these threads to realize that it's a big problem when, on a regular basis, you can't get these little problems solved because the creator insists it's supposed to work that way, to the bemusement of experts who chime in that know it has never worked that way before (and perhaps with very good reason), never in any other related system of the kind.
So we get to have all of the reasoned, technical arguments again. That's how progress works, I guess. In a modern, systemd world, maybe the arguments that led to so many system designers putting their systems together in "this way," for arbitrary values of "this" which are broken in some way by systemd, actually don't fundamentally hold water anymore. Maybe if you drink enough of systemd's kool-aid, you won't try asking these types of questions of Lennart anymore, you can just see it the way he does.
"Am I out of touch? No, it's the children who are wrong..."
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#9I keep waiting for the reasoned, technical arguments against systemd instead of veiled metaphors, complaints about its creator, or protestations that it's different. The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces. System…
One of the main problems was the speed with which systemd was rolled out on all the major Linux distros, despite it being relatively immature and very controversial at that.
The second major issue is it growing way out of the bounds of being just an init replacement, thereby violating the so-called Unix Philosophy of doing one-thing well. For a user app to do that is one thing, but for a core OS component to do that just smells way too much like forcing Linux to be more like Windows, which a lot of hard-core Linux users are ideologically opposed to.
The third major issue is that on most major Linux distros, users are not given an easy way to avoid using systemd, no matter how much they hate it or oppose it.
The fourth issue is the apparent arrogance of the people responsible for systemd, and their off-hand dismissal of mature and widely respected unix conventions.
All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.
Re: Why Did It Take Devuan Two Years to Replace Systemd?
#10This is why I've not been so enthusiastic about the systemd project. When I first heard of systemd, it seemed like a good idea: A new clean-slate design of an init system and service management that aimed to address shortcomings of the present common init and service management. And had the systemd project stayed just that, I'd have been fine with it, and may well have welcomed it onto my systems with open arms.
But then it became necessary to subsume udev and syslog and cron and more parts of the system, and each time, the justifications for this scope creep have been unconvincing to me. It comes across as a bunch of added complexity because it'd be nifty and because they can, without stopping to reflect on whether trying to subsume the rest of the OS or forcing tight coupling and integration is a good idea from a design or architecture perspective.