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."
Who controls the system, the system administrator or software developers?
How many packages come with init scripts that actually work?
How many packages have dependencies that aren't documented?
How many packages work only on a narrow subset of environments that are tested by the developers?
The answer, of course, is "all of them."
Today, the competent administrator can control startup, dependencies, etc on a granular basis. With systemd, that control has gone - somewhere else.
Who gets called when stuff fucks up because some bozo fucked up their package's systemd configuration? It won't be the package developer, that's for sure.
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.
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.
Systemd articles have become the new Slashdot clickbait. It seems every freakin' day there's another "discussion" about that unholy abortion.
I do not fail; I succeed at finding out what does not work.
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.
Maybe. Currently we have every app maintaining its own configuration file(s) in miscellaneous directories under the user's home directory in non-standard format and each application implementing its own configuration parser.
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.
No, it does not. Problems happen mostly on reboot and on changes. The system administrator already has these ironed out with the existing init system. Any major change will give years of new and surprising problems.
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
1. systemd was FORCED down my throat by just issuing a "pacman -Syu". it took me THREE fucking days getting my desktop back to normal after sifting through a barely comprehensible arch wiki page. systemd had long since been adopted by other distros and i was amazed how BROKEN it still is.
2. systemd FORCED me to sit down and learn a new set of tools for NO reason. my system worked just fine before systemd. i've since migrated to openrc (thx gentoo devs and apg + artoo from the arch community for making it possible (relatively easy to adopt) on my system.
3. systemd VIOLATES EVERYTHING K.I.S.S. it tries to be much too clever and it makes me feel dumb
4. systemd GRABS everything. not just init. try to install gnome without systemd... no way you can do that without a major hassle.
5. systemd -FORCES me to jump through hoops and rely on the good will of some very nice folks to provide me with a viable alternative. i have to rely on experimental and often buggy packages to get back to before where i had NO PROBLEM with init.
i hate SYSTEMD and this pottering can go to hell for what i care. thx for a whole lot of lost time. if it where just nothing and didn't force me to waste all this time i wouldn't even have cared... but this means WAR!
fuck you pottering. fuck you arch linux guys for violating your core principles and fuck all those ZEALOTS not giving me a choice in the matter and think they know what's best for me. this is the worst time being a gnu/linux advocate in like EVER.
on a positive note: thank you windows 7 for staying predictably stupid and giving me a working system while my linux init was broken for three days.
Let's start by saying that the death threats against Lennart Poettering are ridiculous and should not be tolerated.
That being said, the design of systemd confuses me. It seems ripe for all manner of stability and security problems. As I understand it, it bundles a large number of services into a single process, which takes place of the init daemon. That's guaranteed to cause all kinds of system crashes.
What I don't get is why it isn't split up into multiple processes. All the same functionality could be provided by having a simple core init daemon that loads a set (perhaps a small set) of child processes. It wouldn't take longer to load. The services and behavior would be identical. But it would be a lot more stable, because a child process could be restarted if it crashes, keeping init to a bare minimum.
What's even more surprising is that someone with some sense hasn't done exactly that: Make a wrapper for the systemd build that patches a few things and just compiles it differently, into a slightly larger number of binaries. This way, we can benefit from the unification of services, while maintaining stability, and Poettering would have to be intentionally self-destructive to try to keep breaking that wrapper every release.
You really do not know what you are talking about. People with a lot of experience can judge the merit of a thing by looking at a description of it. People like you do not even know that is possible.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Things will go just like in MS Windows. Systemd as a supervision daemon - it is ok, but replacing the whole init system/login/logging/whatever is the thing that scares me off.
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.
It is, and this ridiculous claim that it's not so because it's not a singular binary is as telling as it is tedious.
Worse yet, it's a monolith that's ousted EMACS as the poster child for feeping creaturism.
Seriously, you think 20 year unix->linux veterans are daunted by the idea of "learning systemd"?
Yes. Absolutely. Positively. Yes, again and again. Mostly because they don't WANT to learn systemd, so the very process of doing so is agonizing enough that they don't get very far.
It is true that at least some 20-year *nix admins don't want to learn anything new.
On the other hand, there are a lot of 20-year *nix admins who love to learn about new things (I fit that category), but absolutely don't want to learn systemd because it is a waste of time in that it doesn't offer them any advantage over what they currently use.