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.
I am not resigning from Debian, just from the systemd maintainer team.
It's a pretty long story. If you want to read all of it, you probably need to read the entire debian-devel and debian-ctte archives from approximately a year and a half ago until February/March this year.
A shorter summary is something like (from my memory, coloured by my views, etc, but I believe it's largely correct). User names are generally @debian.org, finger $user@db.debian.org for full names and such. It's a bit rambling and written in one go, but it's what you get this time:
- I upload systemd to Debian about a month after its initial release, get it into a ok-ish shape for wheezy, but not anywhere near suitable for being the default.
- Other distros start switching to systemd as default, various people in Debian start discussing if we should switch to systemd. Some people say yes, some no, some want to switch to upstart. Bickering and discussions in equal measure spread out across all media (IRC, blogs/planet, mailing lists, in-person discussions). Most of it reasonably civil.
- At some point, paultag files https://bugs.debian.org/cgi-bi... (_massive_ bug report, you don't want to read it all) , asking the Debian technical committee to default on what the default should be.
- Lots of discussions happen, we use a bit of liw's and rra's Essay Debate System (https://wiki.debian.org/Debate, https://wiki.debian.org/Debate...) to structure the debate. It's Debian, it has to be A System.
- vorlon (Steve Langasek) sets up VMs using the various init systems for the Technical Committee members to play with. They do so and write up their findings and arguments. rra's writeup is at https://lists.debian.org/debia... and is possibly the best comparison I've ever read of init systems. Lots more discussions happen. I contribute a fair bit with my systemd maintainer hat on (though we're at this point a team maintaining systemd in Debian) and is very happy this happens while I'm holidaying in Spain so I don't have to deal with a day job at the same time.
- A lot of arguing internally to the CTTE whether to couple the question of what the default init system should be with whether it's ok for packages to require a given init system. bdale resolves the knot by calling for votes on a proposal very quickly after proposing a ballot. iwj sees this as backstabbing and is still very, very angry about this to this day.
The vote ends with systemd being the winner, after bdale's casting vote as the CTTE chair.
After this, there is an attempted General Resolution in March, which fails to get enough seconds, this is restarted by iwj on late October this year. The goal of this GR appears to be to forbid packages to depend on a specific init system.
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.
Debian have many good sides. It also suffers from fractions; the problem isn't so much that people disagree about some time petty technical things, but that they abuse the Debian bug tracker and governmental system in order to feud their petty wars on usually innocent package maintainers. By filling "political" bugs together with a lot of whining and twisted representation of facts, and then run and complain to higher ups in the hierarchy, they can force the package maintainer into endless, repeated explanations why things are like they. You can basically force the package maintainers to always be in defensive position. Not fun at all.
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.
The "anti-systemd" faction probably just think they are fighting with their backs against the wall, trying to claw out a place in Debian with any means necessary before it is "too late".
But if they keep on attacking Debian developers like they do now, I think their strategy will backfire. Before the bitter systemd debacles started, most Debian developers where probably quite keen to support non-systemd inits too. But this rather poisonous war just never seems to end, so some Debian developers are starting to think, that the only way forward is an outright banishment of official SysVinit support after Jessie is released.
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.
Well, no, it's not deliberate. They are dependent on systemd because ConsoleKit is dead and rotting, and no other system provides the features they need. They would be happy to lose that dependency if there was an alternative.
But you're not helping, 0123456
0123456: What do you mean, I'm not helping?!
I mean: you're not helping! Why is that, 0123456?!
...
They're just questions, 0123456. In answer to your query, they're written down for me. It's a troll, designed to provoke an emotional response... Shall we continue?
I dont see an issue with systemd,
the issue isnt with systemd per se, the issue is systemd becoming a dependency of things that should not require it. for example, since systemd decided to eat udev, that means that every package that used udev now needs systemd. if you use any of the major desktops, it is a requirement. one the upside, it's fuelling the development of other desktops environments.
... let people who do not want systemd simply configure their system either so that systemd will start regular sys v init or bsd type scripts, or let them change /bin/init to point to the alternatifve init system of their choice.
there is a problem with that, it means systemd is running. there is an additional opposition to systemd itself, the most universally relevant reason being that systemd has a HUGE attack surface. the other reasons all feed into this one issue, it's a blaring and blindingly bright security issue.
btw, if you are GNOME2/MATE holdout trying to escape systemd like me, consider using LxQt. it's still a work in progress but it's usable as an everyday desktop environment.
LxQt repo (works with debian jessie):
Anons need not reply. Questions end with a question mark.
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.
Just posted on my blog with a bit more background: http://err.no/personal/blog/te...
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.
And the criticism from those who are against systemd is extremely important to consider. The complaints are very sound, from a technological perspective. They're also based on decades of real world experience, which just cannot be ignored.
Systemd is inherently contrary to many of the core philosophies that underlie the Debian project, and that underlie UNIX and UNIX-like systems in general. Many of the criticisms of it just cannot be refuted. Bad ideas will be bad ideas, and systemd is objectively full of them.
In hindsight, it's obvious now that systemd should never have been integrated into Debian the way it has been. Debian should have indeed been forked, but with systemd going into this fork, rather than traditional Debian. Only after it had been proven as a suitable replacement should it have ever been considered for integration into mainline Debian.
Personally, I don't think the Debian project will survive. It may survive in name, but it will become weakened and irrelevant, like the XFree86 and GNOME projects have become. This truly is one of the most disturbing events to have hit such a major open source project. The worst part is that it's all so unnecessary. Debian didn't have to die as a project, and it especially did not have to die thanks to systemd of all things.
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....
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.
For what it's worth, I managed to purge everything systemd-related from my debian testing system the other day. I had to replace NetworkManager with WICD, which is a pretty good straightforward replacement (although you need to re-create your configuration). Also, I run KDE, so that made things easier.
As I understand it (if I correctly noted the packages which got removed), you can't run a gnome system without systemd; however, you can still run debian jessie with kde without systemd.
The only packages which are coming from the systemd source package on my system any more are udev and libsystemd0 - however, given that systemd-sysv and systemd-logind are no longer installed, I consider that basically a win.
libsystemd0 is only still there because cups-daemon and kde-runtime require it; but given that it only defines the interfaces, it seems benign.
udev and libudev1, despite being packaged as part of the systemd source, do not depend on it according to the package info...
"Go to CNN [for a] spell-checked, fact-checked summary" -- CmdrTaco
Having a 1000 different components doing 1000 different thing in 1000 different ways managed by 1000 different developers does not make an argument invalid and doesn't make the problem solved. For the most part people thank their lucky stars when a linux system works at all (unless of course it is a server sitting in the corner humming away on one task).
You're absolutely right though. The task is not part of the init system. It should be offloaded to a central system management daemon. Something that monitors hardware and system events and acts accordingly. It should have a fancy name like systemd. Heck while we're at it they can manage locales, login sessions, and the bootup process too.
Oh what you thought systemd was just an init system? Maybe you should read the project page sometime.