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."
I use LMDE on three laptops. I don't support systemd. Ignoring the technical arguments, it's been forced down people throats and that alone should be enough for people to step back and halt it's adoption.
That aside, will people please stop this constant masturbation about startup times? There are way, way, way more important things to deal with than edging out a few more seconds. Systemd provides me with no perceivable gains. I don't sit down, press the power button, then stare at the screen until I can log-in, then wait again for the desktop to load. I press the power button, plug-in the laptop, take out my mouse, manager whatever papers I'm going to use, etc... and then log-in. When I had a desktop, I almost never rebooted it. Startup times matters even less on desktops.
However, systemd does provide me perceivable losses. Time spent arguing over systemd could have been spent making everything else better. Systemd removes options, that while I'm not doing anything with at the moment, I like the ability to choose in the future. There are way too many instances of previously good companies/projects suddenly fucking over it's users (of which systemd is becoming an example of in and of itself). I prefer not being locked into something. Systemd didn't present itself as an option, it demanded that it be a requirement.
Personally, I find it crazy that Microsoft and other large software companies are doing more to support scripting while somehow the linux community is being dragged into less and less scripting. (article mentions desktop users don't want to know how to script anything). We need more scripting not less. I'd love to be able to pull out the couple commands I use that are buried in menus and place them as buttons on the menu bar. I don't want an AI to do it for me, I want to take my common commands and make them easier to navigate to and execute or completely automate them.
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
I wouldn't say that it's wrong - a system administrator expects a system to be up and running for maybe a decade with little effort. Major changes in how the system platform is designed causes headache because it costs time, both to re-learn and to re-document a large number of procedures.
As long as you use the standard services on a server it's no problem with Systemd, but when you use a number of tailor-made suites on that server you are getting more and more headache when you introduce a new structure of managing the startup.
If builders built buildings the way programmers wrote programs, then the first woodpecker would destroy civilization.
The shell is never going to be irrelevant (except for idiots) and no one is worried that the month they spent learning bash is wasted now. Seriously your post has got to be the dumbest thing I've heard or read in this whole debate. Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"? Christ boy, think about it, these are people that have had to become overnight experts on some thing, like dozens of times, and they still do it on a regular basis.
People that are older, smarter, and wiser than YOU realize that the basic concept of systemd is just fucked.
Are you one of those kids that thinks knowing Puppet is a skill?
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"?
Yep. That's exactly what I've witnessed. Most systemd haters haven't even used it.
Whether one dislikes systemd or not isn't necessarily because of what it does or doesn't do. The issue for many people (myself included) is simply that it's a monolith that keeps trying to grow larger in an "open" world that was meant to stand for a certain amount of platform agnosticism and component independence.
I realise that systemd can make life easier for some more novice users but to be true to the spirit of the open source community I would expect it to be optional where it can be so. When it starts to intrude into critical areas and make itself mandatory in some releases, that bothers me. It makes me think that the whole business is a sneaky attempt to subvert the Linux kernel and eventually take control of Linux as a whole.
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.
Systemd has it's downsides. The real downside is that you have so much complex code running as root. most other complaints can be dealt with.
Binary logfiles: You're not supposed to keep important log files on the local machine. Send them to your central logging facility where they are stored in a database. If the machine is still running, you can use the appropriate tools to look at the binary log files for debug. All your logging, stats and alerting should be centralized anyway.
Doesn't feel unixy: Get with the times. It's scriptable and tweakable more than ever. Just get used to the way it works.
Solution looking for a problem: Just not true, see the benefits.
Systemd is one of the options to solve some problems that have been pestering unix for a long time.
Dependency in services: Systemd can restart all dependencies on a service in the right sequence if you have to meddle with one part of a stack
long startup times: Systemd has the possibility to start up things in parallel. No long waits for earlier systems that your service doesn't depend on. Mostly useful for mobile users, but HA systems benefit too due to shorter maintenance downtime
Location/circumstances specific profiles: Depending on where you are and what kind of facilities you have available, your system can "adapt" by changing power profiles, network connectivity, firewalling and whatnot. Primary benefits are for mobile users, but servers changing load depending on things like overheating, having to run on UPS power and such are also quite useful.
Systemd isn't the only project that wants to work this way. Upstart is another one that at least wants to deal with the startup concurrency and dependency problems of classical init. Sun (Oracle) Solaris SMF is also a good example of this line of thinking.
While you can have doubts about the amount of complex code and forks to 3rd party code done by systemd while running as root, I don't think it's useful to complain that someone moved your cheese and took away the init scripts you used to use in the old days. Once you figure out how to work with the new tools, you'll find it's way more tweakable and controllable than classical init. If in the end you choose for init or a different alternative, that's up to you, but at least investigate and educate yourself, before you start complaining with arguments that just aren't true.
I was promised a flying car. Where is my flying car?
IMO you have no clue what you are talking about. There is no way to make "managing a cluster of servers a breeze", it will always be difficult. You can make debugging problems almost impossibly by too much automation though.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Actually, most of the new sysadmins who join my team do not get taught by crusty old sysadmins but learn by themselves. Every single one of them chooses to use a init script to start something up when given the choice though.
And, why would I need a portable init script for forking a daemon with or without a limited capability set and why would I want to do it in five lines when I can do it with one that everybody can clearly understand in /etc/inittab?
I have no problem with control groups. They provide features that have been more or less provided for in several different ways before and are a handy feature but killing daemons reliably has not been a problem for the forty or so years before cgroups came along.
You seem to believe these crusty old unix admins with years of experience have nothing to teach you so Im gad you dont work on critical systems but I urge you to re-consider your outlook. It will save you a lot of trouble in all aspects of your life.
Regards
The argument goes both ways.
New is not always better does not imply that old is not always better either. There have been some amazing examples of throwing away the old and replacing with new to large improvement (just think of the change in network stack between the older Windows kernels and Windows 7, or the change in driver design). A new implementation of the same system is not likely to be bug free first go, but it has every chance of being good, and can quickly grow to become a nice stable foundation.
While this is all great it really has nothing to do with the topic here. Systemd is not a re-write of anything. It's a fundamental change in the operating philosophy of the OS. The "old" folk are being ignored because systemd has nothing in the unix world to which it can be compared, and that raises a never ending triad of ignorant posts claiming it is an init system which does too much.
But worst of all the criticism is not at all constructive, it isn't at all pointing out bugs or complaining about re-writing working functionality. From what I've seen it seems to be entirely a case of "it's different and so it must be bad", and THAT is what gets people labelled as luddites.