An Anonymous Coward writes:
Longtime Debian contributor Tollef Fog Heen has announced his resignation from the Debian systemd maintainer team. His announcement states that "the load of the continued attacks is just becoming too much."
He has since written a detailed blog article surrounding the circumstances of his resignation. As he puts it,
I've been a DD for almost 14 years, I should be able to weather any storm, shouldn't I? It turns out that no, the mountain does get worn down by the rain. It's not a single hurtful comment here and there. There's a constant drum about this all being some sort of conspiracy and there are sometimes flares where people wish people involved in systemd would be run over by a bus or just accusations of incompetence.
This is yet another dramatic event affecting the Debian project in recent months. The adoption of systemd has been extremely controversial, even going so far as to result in calls for Debian to be forked. There have been other problems as of late, too, ranging from a serious bug breaking Wine just days before the Jessie freeze deadline, to the possibility of Debian GNU/kFreeBSD being dropped from Debian 8. And it was only just over a week ago that Joey Hess — another longtime Debian contributor — left the project, citing the "very unhealthy directions" that Debian has been led in lately.
Is the internal tension and strife caused by systemd about to tear the Debian project apart? Recent events such as the aforementioned have suggested that this is becoming more and more of a possibility. The repercussions of this drama will no doubt be felt wide and far, given Debian's own popularity, as well it forming the basis of other major Linux distros such as Ubuntu and Linux Mint.
The way I see it, there are three factors leading to the widespread adaptation of systemd:
1. "Marketing": It was touted by its makers as the greatest thing since sliced bread, because sysvinit is just so obsolete, we have been using it without fault for like 20 years, surely there must be something more modern we can adapt our boring bank and hospital computers to. Sysvinit has only few features. Systemd has many features. Really, oodles of features. That's a fact. The words "nethack kitchensink" comes to mind. It is also not disputed that some of these features are genuine improvements aimed at solving problems the old-fashioned init didn't do by itself, such as "is a service still alive?"
2. "Red Hat": Many Linux distros (look at distrowatch.com) are descendants of three "tribes" defined by their packaging system: Slackware has its own way, then Red Hat came with its .RPM format, and Debian with its .DEB format. Many distros that descend from Red Hat also use the RPM packaging format. Red Hat is the main "sponsor" of systemd, and the popular Fedora distro uses its packages. Now it is difficult and costs quite a bit of work to properly package something. So, many distros are happy to re-use a working package that an "up-stream" distro has already made. And anything that uses Fedora's packages (SuSe? Mageia? CentOS? Arch) will be tempted to use those unchanged packages. Systemd dependencies included (what, you haven't switched over to the new cool shiny systemd yet? you're not OLD, are you?)When Debian is also "converted", this will mean its "down-stream" distros such as Ubuntu and Mint will probably follow.
3. "Network effect": Systemd is rapidly absorbing many different small "services" that were previously independent *nix projects: udev, D-Bus, ntpd, automounting, etc. That leads to a "network effect" where all programs that previously depended on "something that does printer setup for a USB printer that was just plugged in" now depends on "systemd, because it does that and lots more". The authors have helped this interconnectedness along: libpulse0, the pulseaudio system library, has a dependency on libsystemd-journal0. why? So that your audio daemon can log to the new binary log files. Why is this new, extra dependency necessary? I don't know; the authors put it in (same authors). If you don't take it out and recompile libpulse0 with --disable-systemd, then from this day onward everything that uses pulseaudio for sound on Linux has a dependency on systemd. That is how it could spread so quickly, IMHO. From the authors point of view (I'm just guessing here!!!) "everybody needs systemd anyway, so we might as well start with making our own audio daemon optionally log to our new shiny binary log format"
Sorry for the wall of text again but hopefully this was less ranting than my previous posts ;-)
We'd been begging for something to fix the obvious problems of SysV since the 90s. It was an obvious kludge even when it was the best game in town.systemd delivered. The other competitors all had fatal problems and lacked the requested features.
It is a major win, but is hated in a hateful way. It is like the gamergate of distros. There is smoke and there is fire, but all the fire is from the torches of the haters. There is no actual scandal that they are upset about, and the majority of the complaints are in the categories of "subjective opinion" and "debunked lie." There are basically no technical complaints that are not debunked. It is just hate-hate-hate.
And nonsense like here, "Systemd is rapidly absorbing many different small "services" that were previously independent *nix projects: udev, D-Bus, ntpd, automounting," this is just nonsense. Complete nonsense. ntpd didn't get "absorbed," systemd just offers a ntpd client daemon. You can still use ntpd. It just has a default lightweight client. Why? Because the existing ntpd implementations were all heavy-weight servers. There is real technical merit in having one that is only a client, especially for sysadmins who might not want to even have the time server installed locally. Same with the other stuff. The reason you swallow this whopper is probably that you were set up with the astroturfed lie; that systemd is monolithic. This sets you up for these other traps, without realizing that these are just optional things that are in the same source repo but that distros don't have to include. And even if your distro includes it, you don't have to use it. D-bus didn't get swallowed, it is just a dependency. It is natural for that to be a dependency, because d-bus is what much of the modern world is using for IPC. It is the new generic IPC mechanism that replaces the old SysV ways of doing things, which worked but were painful.
There are real technical reasons for having the automounter handled by systemd. If you go and look up what they are, hopefully you'll take that out of your list, or at least find some technical complaint with the reasoning that is... technical in nature and not hand-waving. I'll give you a hint, it involves networking and dovetails with another popular systemd feature.
Thank you for informing us that I was wrong about ntpd being absorbed. Could you explain, or point us to a link, what the design rationale was for the init system to include an ntp client? I.e. what is the purpose that was served by this decision?
"D-bus didn't get swallowed, it is just a dependency"I think I disagree with you here because I read something Lennart Poettering wrote about this. Unfortunately, I can't find it anymore :-( so I can't prove that.
You claimed there are real technical reasons for having the automounter handled by systemd, but you don't give a link to support your claim, and tell me to go look up those reasons. Sorry, no.
I'm very concerned that the major authors of systemd are causing an increase in technical debt [wikipedia.org] through a large and unnecessary coupling of packages. Even if systemd is voted out of Debian [debian.org], it will continue to cause unnecessary problems.
Debian's reputation has been irreparably damaged by this ordeal. It was once seen as a bastion of robust and reliable software, put together by some of the best software developers out there. But after these systemd shenanigans, Debian is widely seen as a farce. It has been perpetually disgraced. While I wish that some sort of redemption were possible, I don't think that it will be possible.