SoylentNews is people
SoylentNews
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.
(Score: 1, Interesting) by Anonymous Coward on Monday November 17 2014, @01:46PM
Posting AC since I already modded.
I've seen so much anger and gripe towards systemd but many major distros are using it. Why?
Now I don't want some sort of conspiracy theory about how redhat/nsa/illuminati is out to destroy linux and force us all to use windows me. But if so many independant groups are signing on for systemd there must be a good technical reason why.
(Score: 2, Insightful) by Anonymous Coward on Monday November 17 2014, @01:59PM
Major distros are using it because the legacy init system was antiquated and had become a pain in the neck: among other complaints, there is no good and reliable way to express dependencies between system services so every startup script had to do its own checking to see if it had the prerequisites to start. Package maintainers didn't like it.
It was obvious that an improved init infrastructure was needed. The controversy, as I see it, is primarily about whether the cure is worse than the disease, and secondarily about who did what with whose mother.
(Score: 2, Interesting) by jbruchon on Monday November 17 2014, @03:06PM
What Linux (and all UNIX-like systems) really needs is the equivalent of Microsoft's Service Control Manager. Everything in Linux/UNIX is a kludge by comparison; systemd uses cgroups to corral services, but there's no way for systemd to actively communicate with and poll the status of a program like Apache or dnsmasq so that they can be properly managed. Most init systems don't monitor services at all; a totally different (non-standard, since service management on UNIX-likes is the Wild West) program tends to be set up to handle this. There are no standards for "system services," they are absolutely indistinguishable from normal executables.
We need a standardized, minimal, and **very well documented** service control and monitoring C API that allows programs to interface with (and be polled by) an arbitrary "service control manager" on Linux. This could be done and not violate the UNIX philosophy of "do one thing and do it well." It would also fix the main problem that systemd was initially created to solve: kludgey "reinvent the wheel for each program and hope no PIDs sneak away" management of system services.
I'm just here to listen to the latest song about butts.
(Score: 0) by Anonymous Coward on Monday November 17 2014, @04:47PM
Huh? Are you for real?
Sysvinit isn't perfect, but I'd take it over the Windows approach any day. I say this as someone who has managed Windows systems since NT 4, along with all sorts of Linux, BSD and UNIX systems.
(Score: 1) by jbruchon on Tuesday November 18 2014, @06:15AM
I'm not advocating "the Windows approach." I'm suggesting that there be a standardized way for system services to be brought up and down and polled for lockups. I'm not suggesting that a service manager be the ONLY way to start services, either.
I'm just here to listen to the latest song about butts.
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @12:49PM
Let me quote what you wrote:
What Linux (and all UNIX-like systems) really needs is the equivalent of Microsoft's Service Control Manager.
You are advocating the Windows approach.
(Score: 1) by jbruchon on Tuesday November 18 2014, @01:11PM
By your logic, saying Nautilus is "the equivalent of Explorer from Microsoft Windows" is false. "Equivalent" does not mean "identical."
I'm just here to listen to the latest song about butts.
(Score: 2) by TheLink on Monday November 17 2014, @05:07PM
What?!! Pre-Vista stuff was like this: https://support.microsoft.com/kb/203878 [microsoft.com]
e.g. services have dependencies NO Windows doesn't check them during shutdown!
It took them so long, and then they implement it with preshutdown notifications AND that's not supported for .Net!:
http://msdn.microsoft.com/en-us/library/windows/desktop/ms685149%28v=vs.85%29.aspx [microsoft.com]
http://connect.microsoft.com/VisualStudio/feedback/details/641737/add-windows-service-preshutdown [microsoft.com]
See also: https://stackoverflow.com/questions/7437590/is-it-possible-to-register-for-preshutdown-service-events-using-net [stackoverflow.com]
Microsoft could in theory have created a C++ service that handles preshutdowns of .Net stuff. Maybe one day I'll do it if nobody else gets around to doing it (I'm not a great coder - so I'd rather not unleash another crappy C++ service on the world if possible).
(Score: 1) by jbruchon on Tuesday November 18 2014, @01:20PM
If someone wrote a "service manager" for Linux, none of what you just wrote would matter. No one suggested "porting Microsoft's services.exe program" here. Everything that attempts to improve on or replace sysvinit tries to manage services better; I'm saying that we need services to be able to talk back to the program that manages them and that program needs to be able to do things like poll the services to make sure they haven't done something bad, such as having crashed without the PID terminating.
I'm just here to listen to the latest song about butts.
(Score: 2) by forsythe on Monday November 17 2014, @05:13PM
there's no way for [an init system] to actively communicate with and poll the status of a program like Apache or dnsmasq so that they can be properly managed
I hope I'm misreading you, because if you're saying what I think you're saying, then you'll have to explain to `rc-status` that it doesn't exist.
(Score: 0) by Anonymous Coward on Monday November 17 2014, @11:25PM
He's saying what you think he's saying. And, yes, he's wrong. Pretty much everything in his comment is dumb. Seriously, he's suggesting using the approach that Windows takes, including its well-known problems, and bringing it over to Linux. That's really fucking stupid thing to suggest.
(Score: 1) by jbruchon on Tuesday November 18 2014, @06:02AM
Says someone who obviously had no better suggestions.
I'm just here to listen to the latest song about butts.
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @12:57PM
We don't have to suggest anything new. Sysvinit has worked perfectly fine for a long time. We don't need a "better suggestion" because nothing needs to change.
(Score: 1) by jbruchon on Tuesday November 18 2014, @01:13PM
I disagree. I have been using runit for a long time and it's definitely better than sysvinit. http://busybox.net/~vda/init_vs_runsv.html [busybox.net]
I'm just here to listen to the latest song about butts.
(Score: 1) by jbruchon on Tuesday November 18 2014, @06:12AM
http://dev.gentoo.org/~vapier/openrc/projects/openrc/ticket/120.html [gentoo.org]
http://dev.gentoo.org/~vapier/openrc/projects/openrc/ticket/145.html [gentoo.org]
Also, how can OpenRC know that e.g. httpd hit a bug and is hosed but the httpd service PID has not terminated?
I'm just here to listen to the latest song about butts.
(Score: 2) by cafebabe on Tuesday November 18 2014, @05:56AM
I thought that was #gamergate.
1702845791×2
(Score: 5, Insightful) by fritsd on Monday November 17 2014, @03:43PM
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 ;-)
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @04:12AM
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.
(Score: 1) by fritsd on Tuesday November 18 2014, @02:16PM
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.
(Score: 2) by cafebabe on Tuesday November 18 2014, @08:17AM
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.
1702845791×2
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @12:54PM
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.
(Score: 2) by forsythe on Monday November 17 2014, @04:23PM
fritsd has covered it better than I will, but here's what I see as the short, slightly oversimplified version:
Systemd is written by the same guys who write other omnipresent packages (GNOME, PulseAudio, etc.). They've added dependencies on systemd to those packages, so a distro that wants to ship without systemd now has to choose between letting well-known packages fall out of date or patching them to remove the dependencies (good luck).
Exceptions are distros that have strong ideological foundations (e.g. Slackware) and distros that were designed for myriads of configuration choices anyway (e.g. Gentoo).
(Score: 4, Informative) by Arik on Monday November 17 2014, @05:00PM
But adoption is not being driven by any technical advantages. It is 100% political. RedHat is the biggest player in terms of paying people to work on Free Software, and they are the ones developing this and pushing it into every distro they can get to, by hook or by crook.
I havent been too involved with debian, and I am glad at this point, because the way it's been co-opted would certainly have my blood at a full boil if I had been. What's the point of having such clearly defined rules and procedures if you cant be bothered to follow them anyway?
If laughter is the best medicine, who are the best doctors?
(Score: 2) by novak on Monday November 17 2014, @06:15PM
I've used Debian since about 2008, it's not my main desktop but I have some servers on it. That's fairly recent by most people's standards here, but I've always been more of a slackware guy.
I'm still hoping that the Debian general resolution to preserve init system choice passes. Maybe this is wishful thinking but here's how I see it: more distros depend on Debian than any other, and I don't want every linux locked into systemd. Most of these are crappy knock-offs that really don't set themselves apart in any way- it's usually "debian with X default desktop" or "Ubuntu with a few programs installed by default to do Y." But you know, one of the great things about linux is that you have the freedom to do whatever you want, and that includes making distros that I think have no real purpose. Who even cares what I say? Some of these little distros have done pretty well for themselves. I really don't want to see every distro forced into using the ever-expanding monster that is systemd.
novak
(Score: 2) by Arik on Monday November 17 2014, @06:56PM
Same here, but I have used Debian on and off when it fit my needs.
"I'm still hoping that the Debian general resolution to preserve init system choice passes."
Here's what I dont understand. Maybe I am missing something, but by my reading of the debian by-laws, this is the only way the change could have been accomplished in the first place. The technical committee doesnt have authority to re-architect the system by fiat, and fake manufactured bug reports cannot change that.
If laughter is the best medicine, who are the best doctors?
(Score: 3, Insightful) by novak on Monday November 17 2014, @07:40PM
Yeah, I don't really know or care who has the authority (except to fight back against systemd). In my experience, the best distros are those made for the distro maintainers, and are often basically dictatorial (obviously slackware comes to mind here, among others). Running everything via a massive bureaucracy has its downsides. Everyone keeps claiming that there has been a 'coup' in Debian. I honestly don't know if that's true, I don't keep track of who is in charge of what or where they are from, especially not for something on the scale of Debian. I'd rather stick with something higher quality made by people I trust, instead of trusting a giant system to not screw itself.
That being said, Debian is the only distro (that I know of at least) which has both been taken over by systemd, and is fighting the takeover. I applaud their efforts to keep choice open. There are any number of popular userspace daemons for various tasks, and I don't want a single replacement, especially one as poorly made as systemd. Gentoo and Slackware won't be able to hold out forever on their own, as systemd's roots go deeper. Once the big boys go down, smaller ones like crux and voidlinux will have an even harder time keeping their heads above water.
novak
(Score: 0) by Anonymous Coward on Tuesday November 18 2014, @04:20AM
We do agree on the merits, we don't repeat it over and over because you read the reasons years ago and just don't care.
http://0pointer.de/blog/projects/systemd.html [0pointer.de]
Maybe people are too busy name-calling the author to believe that he explains the reasons why the old sysadmins in charge of the decisions are often choosing systemd. ;)
There is really no reason to explain the reasons over again when they came on the box when it was first being introduced to the world.