Slashdot Mirror
Longtime Debian Developer Tollef Fog Heen Resigns From Systemd Maintainer Team
An anonymous reader writes Debian developer Tollef Fog Heen submitted his resignation to the Debian Systemd package maintainers team mailing list today (Sun. Nov. 16th, 2014). In his brief post, he praises the team, but claims that he cannot continue to contribute due to the "load of continued attacks...becoming just too much." Presumably, he is referring to the heated and, at times, even vitriolic criticism of Debian's adoption of Systemd as the default init system for its upcoming Jessie release from commenters inside and outside of the Debian community. Currently, it is not known if Tollef will cease contributing to Debian altogether. A message from his twitter feed indicates that he may blog about his departure in the near future.
Not so easy since it is in the process of becoming a dependency for most of the base system. Currently, for much of it, it is an optional one, but that is slowly changing. This is redhat's embrace and extend.
If the Debian team never shove that unneeded thing down the throats to the users
Serious question here: how avoidable is systemd currently?
It seems the number of holdouts among the distributions is shrinking ever more quickly.
systemd seems to be incorporating ever more functionality in itself. That in itself should be a problem, but it seems that the equivalent functionality outside of systemd is being lost at the same time.
Not sure what the status is with the other stuff systemd is preparing to replace.
Add to that the increasing hard dependencies, like with window managers that expect systemd to offload session management and login onto and I'm not sure how feasable holding out on systemd is anymore.
Sure, if a sufficiently large group of developers were bothered enough with the presence of systemd they could set out to provide the functionality the traditonal way and form a whole bunch of projects, including some sort of desktop environment.
But it seems systemd managed to assimilate responsibilities more quickly than resistance could form and forking of projects to non-systemd dependent versions could occur.
Yet both sides believe the other side is the idiots.
If you make that "some people on both sides", I agree with you.
There are certainly good people on the anti-systemd side (and I'm sure there are poisonous people on the pro-systemd side too). People being skeptical and saying that we should be careful adopting everything it provides. I don't agree with them (at least not fully), but my resignation from the maintainer team is not about people being skeptical, it's about personal attacks, it's about death wishes from project members and it's about people escalating conflicts instead of trying to resolve them.
(I do agree with them in that we should think about what technologies we adopt by default and which we don't. As an example, systemd-resolved is not enabled by default. As the recent CVE shows, that wasn't a bad decision. We might change it in the future, but we should absolutely think about the maturity of the components we enable, in particular those enabled by default.)
I honestly don't really care about this whole init debate, from a technical standpoint. I don't see a compelling reason to prefer systemd, and given the fact that it's changing a system that's worked fine (with a few tweaks) for more than 30 years, I'd just as soon stay with the old style.
But there's a few extremely troubling things I see from the systemd side:
- A complete disregard for precedent. Yes, it's good to be open to rethinking how we do things, but the fact is that Unix has worked for a very, very long time. There's many reasons for this, but the "Unix philosophy" is undoubtedly one of them. systemd is by no means "Unixy". Reading a directory of symlinks and executing shell scripts is simple, and minimizes the logic built into init - which a lot of people believe is a good guiding principle for pretty much the entire OS.
- An uncompelling value proposition. I don't much care about boot time (who reboots anymore, anyway?), and with Upstart my boot times were pretty quick anyway. If I'm running a server, I don't even care about boot time at all. What I do care about is simplicity of understanding and management. Systemd has failed to convince me that it does anything I want. Iin the absence of anything particularly valuable I'd just as soon stick with existing, robust, well-understood systems. I don't have my tonsils out for fun either - it's not change aversion to stick with things that worked fine in the absence of a compelling reason to change things.
- Poor architecture. The init system should be as simple as possible. Let it start things like dbus if the system needs it, don't build them in. Discrete components that are loosely-coupled, please - tight coupling is a black mark against virtually any multi-binary software package, but especially in the boot process. Building things into the startup process just reduces the number of things you're able to remove from a system that doesn't need them. DBus is a great example of this.
- Lack of concern for the server use case, and sysadmins in particular. People have raised concerns - many legitimate, some not - about systemd approaches, and the developers and (unusually rabid) community treat those concerns with indifference bordering on contempt. Here's a hint: when a group of competent professional acting in good faith doesn't understand why something is a good idea, it's your fault for having explained it poorly. Especially for an init system - the "average" user never did care about how his system booted! (Which, by the way, is something many systemd folk seem to disagree with - they say users are clamoring for it!) But the sysadmin does care, and has to manage it - best to treat him with respect, not contempt.
- Tying perfectly-good cross platform programs to Linux. systemd is, unabashedly, a virus. Why my window manager or graphics program has to depend on init, I don't know. But as long as it does and that package is systemd, it kills cross-platform compatibility. Compatibility is what got Linux off the ground, and with the exception of systemd it's not too hard to keep it going. Don't throw this away!
- Most importantly, the community is extremely toxic. What is Linux without community? Sure, there's bickering (since when is this bad, by the way?), but at the end of the day you have one of the most powerful and important pieces of software the world has ever seen. But the systemd mess feels like a Microsoft move, and the idea that there's a "Microsoft of Linux" able to move so unilaterally is extremely troubling. People voice concerns about systemd, and if they seem recycled it's because they haven't been well refuted! But the proponents are vicious, and vocal to an extent that makes one suspect astroturfing... which is even more troubling.
And the most troubling aspect of this toxic community are the attacks on opponents. The parent's comment is not the first, nor even the tenth, attack I've seen on a systemd opponent to claim that it's just someone afraid of losing their job and trying to set up some sort of
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
Death wishes are never cool.
But what do you think people should do instead of escalate? I think at this point it's pretty clear that there are fundamental (some might say philosophical) disagreements at play here that haven't been resolved yet - and may be unresolvable (people are talking seriously about forking Debian over this). Escalation seems like exactly the appropriate step. When I'm at work, if I don't agree with a decision I talk about it with my boss - but if we can't reach an agreement and I feel strongly that it's the wrong decision, I take it to his boss, and so on if necessary. I would be remiss if I didn't!
Honestly, many systemd proponents seem annoyed that people aren't accepting their decision without question, when what they propose is a pretty serious departure from a pretty fundamental system design philosophy. I don't know what to make of that.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
I have a question, which I hope won't be ignored simply because I'm the "token Windows guy" here, because this one has been puzzling me when it comes to Debian..
Since Debian is known as the "super stable" distro and from what we've seen systemd obviously still has some issues to be worked out why not simply have systemd in testing and have stable without? Correct me if I'm wrong but as I understand it Debian has stable and testing yes? So why the rush to put systemd in stable when it appears to make more sense to have it in testing until all the bugs are ironed out, or at least not make it the default until the thing is ready?
I mean I could understand this if it were Ubuntu, whose motto might as well be "so bleeding edge the ISOs have stigmata" but that has never the kind of image that Debian has projected. While I'm not the conspiracy nut type having every distro push this including the ones known for being conservative? It DOES smell hinky as well as give off the whiff of a bit of "good old boys club", especially since its from the same guy that gave the world Pulse way way WAY before it was ready.
So I just don't get it, why not diffuse the whole thing, leave it in testing until the bugs are ironed out and once its features are all ironed out THEN put it in stable? I don't know all the backstage politics so maybe there is political considerations but from a strictly logical standpoint that sounds like the best way to go...so what am I missing?
ACs don't waste your time replying, your posts are never seen by me.