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.
Glad to hear. And for what it's worth, I think it's a shame some elements in the community behaved like they did. I chalk it off to them being immature twats, but mostly it's that people are people, and a good chunk of humanity are just idiots.
All those moments will be lost in time, like tears in rain... time... to... die...
Yet both sides believe the other side is the idiots.
Trolling is not disagreement.
If the Debian team never shove that unneeded thing down the throats to the users none of the heated exchange would have happened in the first place
And to call others "immature twats" you are showcasing yourself to the world how "mature" you really are!
These 'attacks' do not prevent people from working on what they want to. Stop equating heated debates online with getting mugged in the street.
The concept of being able to 'just fork' the system sounds great on the surface, but init is not your average package. I'd argue that init is just as important as the kernel itself, and possibly more important as it impacts how all init-aware applications and daemons will be developed. The use of System V init allowed Linux to be comfortablef for UNIX admins looking for a less expensive or more widely installable solution, and the end of the use of System V init means that Linux is starting to head away from the UNIX operating systems.
It's been said that Ubuntu switched to systemd because they anticipated that Debian was going to do so, not because they really wanted to, but since Ubuntu re-forks Debian for a lot of its packages and development, as a derivative work it really doesn't have a lot of choice unless they want to make a clean break of it. With other distros also going systemd, inevitably like when Slackware was extremely late to the party with the whole libc5/glibc2 switch, a bunch of us will end up on Slack again, even without the advanced package tools that we've come to like with more modern distros.
Do not look into laser with remaining eye.
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.
There is a difference between "attacks" and valid criticism. Calling everybody that criticizes systemd and its adoption into Debian a "troll" or an "attacker" is unfounded and represents an extreme form of trolling itself. One could get the rather strong impression that the systemd advocates do not want any dialog or have sufficient valid arguments to deal with the criticism voiced. Instead they revert to this form of primitive emotional manipulation.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
An example here is missing devices/mount points in fstab: sysvinit will happily ignore them, systemd won't consider local-fs.target reached and you'll have to fix your system for it to boot correctly.
And this is exactly the kind of thing that makes many of us wary of systemd. I saw a post from someone a few weeks ago complaining that systemd wouldn't let his system start up because there was a problem in /etc/fstab, and he couldn't edit /etc/fstab because systemd wouldn't let his system start up.
An elite crowd trying to force on everyone else what they think is the right way? Thats one of the many reasons people are against systemd! One thing I don't understand is how in the hell it is considered ok to have this in Debian STABLE? Maybe, in Fedora or OpenSuse but Debian stable???!
Exactly. Using ridiculous namecalling for folks challenging systemd such as "immature twats" is taking sides. It's not possible to have a reasonable collaboration so long as systemd has activist fans who do not take the time and care to understand the criticisms.
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.)
First post was 8 full minutes after the article was published. This just demonstrates how far Slashdot has fallen in popularity.
Never mind that with systemd, it goes beyond init. systemd as a project are sprouting tentacles everywhere, and projects closer to the user (Gnome for instance) is strongly encouraged to latch on.
This kind of tight coupling is unheard of in Linux history.
Taking the requirements in turn:
So what? OpenRC has dependency built in and the added improvement of integration with kernel-level events would bring only a very minor improvement.
In my experience, this is solving a non-problem. I don't experience processes dying and needing an immediate re-start without any other action.
So what?
Not sure what advantage this brings.
The real "Libtards" are the Libertarians!
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.
No. It should at least come up far enough to diagnose and fix. Did you miss the part about not coming up far enough to edit fstab?
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.
In this case it is the "anti-systemd" faction that is abusing the system and the developers, but there have been several other, perhaps smaller cases before this.
Lets not forget that this whole mess was kicked off because the pro-systemd crowd filed a "systemd is not default" bug. Hows is that even a bug? Did they seriously think people wouldn't retaliate with "systemd is default" bugs?
I think you have it backwards.
SystemD is forced down our throats by a small elite at Red Hat. This is, very obviously, a move right out of Microsoft's playbook.
One down, four to go!
Remaining team:0
Michael Bieble
Marco d'Itri
Michael Stapelberg
Sjoerd Simons
Tollef's smart to get out before Jessie is released. The looming spectre of broken systems that are going to haunt sysadmins everywhere when they update their Debian systems to Jessie is going to phenomenal. Who's gonna wanna stick around for that grief?
Sure, they'll all cry about "muh feels!" as the reason for leaving, but when you abandon a project (systemd packaging) this late in the schedule, everyone knows it going to be because you're trying to distance yourself from the inevitable shitstorm that going to happen.
Ah yes, the "la la la la la I can't hear you" tactic. Fact is, people against systemd have voiced technical omplaints, including one on this very page, which the maintainer who just resigned admitted is a severe bug, equivalent to "shooting your foot off" (his own words).
It's the people pushing systemd that are busy pretending that there aren't problems and refuse to acknowledge the issues, because they're inconvenient for them.
Good riddance. At least OpenBSD doesn't have this BS where they pretend a bug is a feature.
> what they think is the right way. That ties into what the mentality of this elite crowd is. For years this elite crowd has fought at every turn any attempt to make Linux easier to use for common, everyday users as a Windows alternative.
For decades, not just years. The Unix way predates the Windows philosophy by a rather significant margin. Those who appreciate the Unix philosophy have been protecting it from turning into something else for decades.
Imagine you joined the Ford F-250 design team. Would you insist that the F-250 should be redesigned as a Corvette alternative? Would you be surprised when the veteran members of the team pointed out that the F-250 is a work truck, not a sports car?
The Windows way works well for grandma to look at pictures of her grandkids. Mac may be even better for that use case. That's not suprising, as those systems were designed specifically to be "easier to use ... for the common everyday user." The Unix / Linux approach is designed for a different role or two; client/server first and portability also. Linux is designed to work in your router, your phone, and your web server. It's no surprise that Linux makes a better server than Windows, a much better phone, and works well on a router where Windows can't run at all. It was designed to have that flexibility.
If you want something that is just like a Windows desktop, your best bet is to get a Windows desktop. Linux isn't Windows, and of it tries to be like Windows it'll stop being Linux and being good at what Linux is good at.
It should be obvious to anyone that RedHat has a vested interest in making the vast majority of Linux distributions dependent on technology it controls. Linux is its bread-and-butter.
It appears RedHat has realised that, through systemd, it can readily provide preferential support for its own projects, and place roadblocks up for projects it does not control, thus extending its influence broadly and quickly. By using tenuous dependencies amongst its own projects it can speed adoption even faster.
Once it has significant influence, and the maintainers of competing projects have drifted away either out of frustration or because they are starved of oxygen, RedHat knows that they can effectively take Linux closed-source by restricting access to documentation and fighting changes that are not in their own best interests.
At this point, they can market themselves as the only rational choice for corporate Linux support -- and this would be perfectly reasonable because they would have effective control of the ecosystem.
Linux (as in a full OS implementation) is an extremely complex beast and you can't just "fork it" and start your own 'distro' from scratch anymore -- you would have to leverage a small army to do it, then keep that army to maintain it. It's just not practical.
At the same time, Linux has matured to the point of attaining some measure of corporate credibility, and from RedHat's point of view, it no longer needs its 'open source' roots to remain viable. RedHat also, understandably, fears potential competition.
Through systemd and subsequent takeovers of other ecosystem components, RedHat can leverage its own position while stifling potential competition -- this is a best-case scenario for any corporation. It will have an advantage in the marketplace, potential customers will recognise that advantage, and buy its products and support contracts.
I hope you can understand why many see this as an extremely compelling case. Arguing that RedHat has 'ethics' and would 'never do such a thing' is immature and silly -- RedHat is a corporation, it exists to profit from its opportunities, just like any other company. To attempt to argue that it would not do so is contrary to what we can assume is its default state.
It's no 'conspiracy theory' to assume that a corporation will behave like a corporation; arguing that it is just makes one look like a naive child. systemd is one large step toward RedHat gaining the ability to reap what it has sewn -- for its benefit and not necessarily ours.
I've read all of the comments in this thread (at -1), and I think you're the only one to have truly nailed what's going on here.
Systemd has been a total disaster for many Debian users already. The animosity toward it doesn't come out of nowhere. It comes out of a situation like this, described as a "horrible experience". People are having their Debian systems utterly trashed thanks to systemd being forced upon them during routine updates.
I, too, fear that these early disastrous results will just be amplified many times over once Jessie starts to become more widely used. There will likely be problems, and they won't be pretty. I wouldn't be at all surprised if Debian's reputation is completely ruined. That's a real shame, given how many decades of effort have gone into making it such a respected and trusted distro.
This is also where FreeBSD could make a triumphant comeback. If the FreeBSD project play their cards right, and end up on the right side of this (which is obviously taking a strong stand against systemd, and standing in favor of stability and reliability), they could win over many refugees who are fleeing Debian.
Death wishes are never cool.
But what do you think people should do instead of escalate?
Maybe accept that the larger group of people you're a part of has come to a decision you disagree with, and move on? People who can't let go of their personal hobby horse can be utterly poisonous to an organization, no matter how righteous they view their cause to be.
Lets say you have a laptop that is on one network and goes to sleep when you close it and arrives in a hotel room on another network? How would you do this with init without some serious hacks?
You don't, you open your laptop in the hotel room and select the new network. Was that so hard? why in the hell do you think the init system should be involved? You do show what's wrong with the systemd design philosophy, that's for sure. I'm glad one of the crappers of needless complexity has resigned. One down and a few more to go, and maybe Debian will be a good distro again....
Just because you don't doesn't mean no-one does. There have been enough users as vocal supporters of this feature that it clearly is an issue to be considered, and not just a non-problem. I've once had sshd randomly crash. Very randomly. Nothing appeared to cause it and it has worked ever since. A headless server with no management console. I wonder to this day if I had another option than simply hitting the reset button on the front.
So what?
Not all of us are programmers who want to churn out lines of shell script to get simple software started. 200+ lines of scripting to start sshd on my system is a design flaw not a feature imo. By comparison the upstart file for sshd is 13 lines and achieves more i.e. process monitoring, event based startup and re-starting.
Actually using SYSVINIT already handled this quite well. Mainly because it was NETWORK MANAGER's job. Not Init's job, to handle network connectivity. I close my laptop, it sleeps, I open it, network manager fires up my wifi and connects. This argument is already invalid because it's already been solved by network-manager.
All this makes me wonder why someone can't build some other piece of software which would perform the required session management in this particular case? It's not dependency for nefarious means, it's dependency which provides a specific feature that a programmer would like to use. Why can't that be coded separately from systemd by someone other than the systemd maintainers?
Systemd is also somewhat know for having no stable interfaces between its parts; combined with the increasing large number of parts it has, one would need to implement quite a lot to handle the required functionality. Systemd does have a chart of its API stability promises, but it looks to be last updated a year ago.
FWIW, I ran Debian Jessie with sysv for a while - and for about a month it was impossible to login via gdm (workaround was to switch to kdm or lightdm), so there's already been (testing-)user visible impact.
This is all very frustrating, especially since I really like the init/process-management parts of systemd, but not the glomp-up-all-the-projects and explicitly not working with others parts...
What a weird troll.
I don't think Netcraft has even suggested Debian is unwell yet
I don't know, this "troll" makes a valid point - for me, the core value in debian is its stablity. Debian loses about 99% of its value for me the instant it's not rock-solid.
Systemd makes it less rock-solid. to clarify: I have never, ever, ever had a problem with my init system. According to my assessment, systemd is inherently more risky than sysvinit, which means it's less rock-solid. Sysvinit might not be perfect in every conceivable circumstance, but for my use cases I'll take proven software over CADT software any day.
The first time systemd causes me the slightest hiccup there is at least a 50/50 chance that I'll just dump debian (and all other systemd distros) forever rather than even bothering to investigate the problem with systemd - I have better things to do with my time than research and debug your new init system, the old one works just fine.
Fact is, people against systemd have voiced technical omplaints, including one on this very page, which the maintainer who just resigned admitted is a severe bug, equivalent to "shooting your foot off" (his own words).
You mean the bug in a not yet released version of the OS which will be fixed before release?
You guys are incredible. Last week I complained about everyone expecting software to be 100% perfect on it's first release, and now you are expecting 100% perfection in the betas?
Grow up!
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.
Yet both sides believe the other side is the idiots.
And they are both 100 percent correct.
The shepherds did so well protecting the flock that the sheep no longer believed that wolves existed.
So is systemd-the-initsystem and systemd-networkd. Both are independent tools, where systemd-networkd uses an API provided by systemd-the-initsystem. Distributions routinely replace systemd-networkd. They replace other parts of systemd as well. So I fail to see the difference. There are about 60 different binaries, each doing one thing. They all communicate using a standard and even scriptable method that is widely used in unix desktop environments.
The BSDs tend to develop kernels and tools together, too, precisely to have a better integrated userland and I am pretty sure those count as unix:-) So that is not (only) the windows way. The systemd project is about providing similar plumbing for Linux. The developers clearly say so for a long time now. With the stated goal of being the plumbing layer the project tackles a lot of problems that were ignored. That is a good thing(TM). And that more and more developers of applications start to depend on the plumbing is proof to me that they are doing a good job. Actually that is where the value of systemd is, not in the init system.
Process management the core task of any init system, so I am not sure how that ended up in your list. Not sure what notifications does there either, since I am not aware of systemd actually doing that, but maybe I am missing something. The kernel devs have tried to clean up the console code repeatedly and have expressed interest in moving that code to userland. A brave soul stepped up and started to implement that. Putting it into systemd is the logical step for him to take: That is what all the major distributions are using. That there is finally some common ground makes projects like this possible in the first place! Or do you seriously think he would have written the code and then have bothered to integrate it into a dozen different distributions? Nope, no chance. Yes, there are packagers that help with the packaging, but he would still have a shitload of integration work to do to handle the different setups, init systems and whatnot.
Regards, Tobias