Slashdot Mirror
Debate Over Systemd Exposes the Two Factions Tugging At Modern-day Linux
walterbyrd (182728) sends this article about systemd from Paul Venezia, who writes:
In discussions around the Web in the past few months, I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server. I've also seen a large backlash against systemd from Linux system administrators who are responsible for dozens, hundreds, or thousands of Linux servers, physical and virtual. ... The release of RHEL 7 has brought the reality of systemd to a significant number of admins whose mantra is stability over all else and who perhaps had not waded into the choppier waters of Fedora or Debian unstable to work with systemd before it arrived in RHEL.
I know quite a few of us in hacker culture who hate the fact tha systemd does not feel UNIXy at all. It breaks practically every principle of the UNIX philosophy. Reminds me of working with windows, and that is never fun.
I've seen an overwhelming level of support of systemd from Linux users who run Linux on their laptops and maybe a VPS or home server
I haven't seen an overwhelming support anywhere. Most people who run Linux on their laptops say, "meh, as long as it boots."
This article is a LOT better than the previous one by the same author. He makes his point clearly, that he doesn't like SystemD, as a sysadmin he doesn't want binary log files etc; but if someone else feels like they need systemD, maybe there should be a fork to make place for those people. It's a fairly kind, open attitude. Maybe we should have more of that around here.
"First they came for the slanderers and i said nothing."
How so? Systemd has removed my ability to start and stop services?
How would a package mess with systemd's configuration? It's readily apparently no clue about systemd. Hint, it's no different than it was before. A package drops its own service definition file in a directory (sound familiar?). That's it. It's no different in this area than any other init system. If the file is bad, the service just won't start. Just as it was before. Runlevels or targets are defined the same way: with simple symlinks. Really in this aspect, systemd is no different than upstart or plain old system v init.
This post is one example why the debate gets so heated. People like you post stuff that's only nearly half true, without knowing anything about systemd, except the name of one of the authors. FUD plain and simple. A technical debate is fine, but you've got to actually know what you're talking about before you start debating. So far I've seen zero technical debate on this site regarding systemd. Certainly no one is willing to own up to the flaws in traditional init that have led to systemd's development. It's extremely disheartening to see this kind of irrational fear instead of technical discussion.
Administrators dislike constraint based systems.
This should surprise no one. One of the problems with a constraint based system is that you don't control the precise ordering of things.
This doesn't bother the Debian folks, because their build system is a constraint based system. If they have a package to install which has dependencies, they don't control the actual build order of the dependencies, or of their dependencies, and so on. Turtles all the way down. You do an apt-get install foo, and it's going to try to build subcomponents when they become available to try to build. And if they fail to build, they don't care: they "try again later", in case something that happens later satisfies the dependency that wasn't satisfied the first time around.
This is very disturbing to system administrators, who like things to be both orderly and predictable. All dependencies should be mapped out, known, and explicit. If something gets tried now, and fails, the correct response isn't "We'll try again later!", it's "Stop! Someone fix this fucking thing, it's obviously broken".
The build system is not deterministic; if there are two components, and one has a subdependency on some X of "at least version N", and another has a subdependency on X of "at least version N+2", then depending on the vagaries of network overhead, it's possible that half your code gets built with version N and the other half gets built with N+2, and things break. Things breaking is in fact far more acceptable to a system administrator than "things act weird", and "things act weird" is at least deterministic for a given build instance, and far, far, more preferable than "things sometimes work and sometimes don't".
So system administrators dislike Debian for large system installations. And they dislike systemd for starting things up and shutting things down.
A desktop system is far, far more forgiving: "It's not working; I'll just reboot!". As long as things "mostly work", then things are great! "Look! It's as good as Windows!".
Note that launchd in Mac OS X has many of the same problems as systemd; it's also a constraint based system. It's somewhat worse, in that it insists on controlling file descriptors and sockets and Mach ports for the things it starts - which means you have to rewrite a lot of at least the startup code in most Open Source software to tolerate being run by something that opens the files and sockets that it expects to do itself. But that's just a lot of make-work, and people who are paid to do work are paid because it's not something they'd be willing to do voluntarily, for free, and that's what they're exchanging for the money they are getting in exchange for putting up with that part of the job.
Unlike the people making things work with launchd, though, the people expected to make things work with systemd aren't being paid. And so systemd represents make-work and change for chage's sake, which doesn't sit well with volunteers.
--
So yeah, a lot of people find systemd annoying. Kirk McKusick once accused "vnode" as being "the structure that's taken over the kernel"; in Linux, systemd is fast becoming "the program that's taken over user space".
How this will all play out, I don't know, but don't expect it to be resolved any time soon, given the dichotomy between the philosophies of the stakeholders involved.
It's not just the init, it's also the applications that are being infected with Lennart-ware, e.g. gnumeric. It's a great spreadsheet, but recently it's been picking up various egregious hard-coded dependancies that simply don't make sense. This occurs mostly via GTK, which seems to pull in a significant chunk of GNOME.
I run a minimalist Gentoo desktop, and I notice when additional dependancies are dragged in. The past year or 2 has seen goffice, ghostscript, harfbuzz, dbus, and various other crap become hard-coded dependancies for gnumeric. It was not necessary a couple of years ago. If I had several million dollars, I'd hire a bunch of progragrammers to port gnumeric from being dependant on GTK to being dependant on FLTK (Fast Light ToolKit) http://www.fltk.org/ Some of the money would go to ongoing maintenance.
Another few million dollars, and I'd like to hire a team to hack and slash away at Firefox. I was around when "Phoenix" was forked as a lightweight alternative to the Mozilla web-browser. I savoured that promise. That promise has been dashed into the ground, with a Firefox that's bigger, heavier, and slower than the original Mozilla ever was. Time for a new fork.
I want GNU-Linu-x, not GNOME-Lenna-x
I'm not repeating myself
I'm an X window user; I'm an ex-Windows user
Your'e close - the split is indeed between the older Unix types and people that just want to be "users", but you need to recalibrate where their relative positions. Those of us that are against being forced to use[1] systemd see this in a different light. As computers became inexpensive over the last decade, a new generation of younger people joined the Linux community. They were young an inexperience, and often made well-known mistakes in their software. Thats was ok - we were all n00bs at first, and many of us tried to gently nudge the inexperience developeers in useful directions. Very few listened, and have now decided that anything "old" is bad.
Listening to those that came before you is important, if you want to avoid making the same mistakes. A lot of those lessons are collected under what many refer to as the "Unix Philosophy". Mostly, that "philosophy" is jsut a handful of tricks that make maintainance saner. A lot of the stuff that people claim is "overcomplicated", "messy" or an "archaic design" is such an "ugly" state for a reason, and those messy bits are bugfixes. The nice ideal design we all starty with rarely fits exactly when we introduce it to the problems and unforseen circumstances in the real world. That ugly spaghetti-code-style hack that seems to ignore and bypass the "correct" way? That is probably a bug fix, and by removing it you probably reintroduce the bug.
You call us luddites, but heed our warning at your own peril. Some bugs and bad designs have happened before, and a key reason why we don't like systemd is that it makes one of the worst mistakes you can ever make when designing software: it throws out the supposedly "old" or "ugly" parts. I suggest readoing Joel Spolsky's famous essay on this topic:
Systemd is still at the early stage, where it can get away with this kind of bad design, but as more and more people start to use it and the never-ending list of Real World Problems starts to creep in, the systemd developers - and the distros that joined them - are goign to have one nasty mess on their ihands. It is going to be a nightmare to all of the bugfixes and real-world mess that was thrown away because it was "old".
We tried to warn them, and were labeled luddites.
Well, as B5's Londo Mollari put it:
Ce n'est pas une signature automatique.