Slashdot Mirror
Does Systemd Make Linux Complex, Error-Prone, and Unstable? (ungleich.ch)
"Systemd developers split the community over a tiny detail that decreases stability significantly and increases complexity for not much real value." So argues Nico Schottelius, talking about his experiences as the CEO of a Swiss company providing VM hosting, datacenters, and high-speed fiber internet. Long-time Slashdot reader walterbyrd quotes Nico's essay:
While I am writing here in flowery words, the reason to use Devuan is hard calculated costs. We are a small team at ungleich and we simply don't have the time to fix problems caused by systemd on a daily basis. This is even without calculating the security risks that come with systemd. Our objective is to create a great, easy-to-use platform for VM hosting, not to walk a tightrope...
[W]hat the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
The essay argues that while Devuan foisted another choice into the community, "it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people."
[W]hat the Devuan developers are doing is creating stability. Think about it not in a few repeating systemd bugs or about the insecurity caused by a huge, monolithic piece of software running with root privileges. Why do people favor Linux on servers over Windows? It is very easy: people don't use Windows, because it is too complex, too error prone and not suitable as a stable basis. Read it again. This is exactly what systemd introduces into Linux: error prone complexity and instability. With systemd the main advantage to using Linux is obsolete.
The essay argues that while Devuan foisted another choice into the community, "it is not their fault. Creating Devuan is simply a counteraction to ensure Linux stays stable. which is of high importance for a lot of people."
How are they going to get in and stay in if admins have real logs and can detect persistence?
Domestic spying is now "Benign Information Gathering"
it turns out that, on arm embedded systems at the very least, where context-switching is a little slower and booting off of microsd cards results in amplification of any performance-related issues associated with drive reads/writes when compared to an SSD or HDD, sysvinit easily outperforms systemd for boot times.
- Drop this selinux shit. It's too complicated and causes more problems than it solves. Vulnerabilities come from bad code, not a lack of complex call ACLs. Security is a process, not a feature.
If you want to disable SELinux then disable SELinux, but not writing "bad code" isn't an option when even OpenSSL get major holes.
As long as people want new features there will either be new security vulnerabilities or software you can't afford and never gets completed. If SELinux adds enough security to be worth your bother then go for it, if not then disable it.
I stole this Sig
while I don't fully agree with the implementation of systemd I do think conceptually it is far superior to what it replaces, and though is more complex is not THAT complex, and in return you get more flexibility and can do more (setting up services to start in parallel, easily make services restart or trigger other actions on failure etc)
In my experience managing systemd unit files is GREAT! You can (and should) leave the ones installed by the package/source alone and maintain separate files with your own overrides. It is super easy to manage services when you actually take the time to learn how it works.
Systemd has its problems yes, and it was foisted upon users too quickly, but it is 2017, the gripes are overstated or outdated, and the old init.d stuff truly is an old rotten pile of crap. Jury is out on the other systemd stuff that does logging etc.
Also systemd is NOT really monolithic technically speaking...it is actually quite modular. It is the *project management* that is modular, and the modules are "tightly coupled" vs. old school loosely coupled though pipes etc. like I and many others prefer and/or are used to.
I wish half the effort that went into b!tching and moaning would go into a decent alternative but compatible alternative/fork to systemd (ie. works with same unit files etc). There are real reasons systemd came to be (and no, it isn't just some conspiracy by a certain Linux vendor)...if you do not like it DO something about it.
I don't think there's a problem with the idea of systemd. Having a standard way to handle process start-up, dependencies, failures, recovery, "contracts", etc... isn't a bad, or unique, thing -- Solaris has Service Manager, for example.
the difference is that solaris is - was - written and maintained by a single vendor. they have - had - the resources to keep it running, and you "bought in" to the sun microsystems (now oracle) way, and that was that. problems? pay oracle some money, get support... fixed.
free software is not *just* about a single way of doing things... because the single way doesn't fit absolutely *all* cases. take angstrom linux for example: an embedded version of GNU/Linux that doesn't even *have* an init system! you're expected to write your own initialisation system with hard-coded entries in /dev. why? because on an embedded system with only 32mb of RAM there *wasn't room* to run an init service.
then also we have freebsd and netbsd to consider, where security is much tighter and the team is smaller. in short: in the free software world unlike solaris there *is* no "single way" and any "single way" is guaranteed to be a nightmare pain-in-the-ass for at least somebody, somewhere.
this is what the "majority voting" that primarily debian - other distros less so because to some extent they have a narrower focus than debian - completely failed to appreciate. the "majority rule" decision-making, for all that it is blindly accepted to be "How Democracy Works" basically pissed in the faces of every debian sysadmin who has a setup that the "one true systemd way" does not suit - for whatever reason, where that reason ultimately DOES NOT MATTER, betraying an IMPLICIT trust placed by those extremely experienced users in the debian developers that you DO NOT fuck about with the underlying infrastructure without making it entirely optional.
now, it has to be said that the loss of several key debian developers, despite the incredible reasonable-ness of the way that they went about making their decision, made it clear to the whole debian team quite how badly they misjudged things: joey hess leaving with the declaration that debian's charter is a "toxic document" for example, and on that basis they have actually tried very hard to undo some of that damage.
the problem is that their efforts simply don't go far enough. udisk2, policykit, and several absolutely CRITICAL programs without which it is near flat-out impossible to run a desktop system - all gone. the only way to get those back is to add http://angband.pl/debian/ to /etc/apt/sources.list and use the (often out-of-date) nosystemd recompiled versions of packages that SHOULD BE A PERMANENT PART OF DEBIAN.
in essence: whilst debian developers are getting absolutely fed up of hearing about systemd, they need to accept that the voices that tell them that there is a problem - even though those voices cannot often actually quite say precisely what is wrong - are never, ever, going to stop, UNTIL the day that the role played by http://angband.pl/debian/ is absorbed into the main debian packaging, providing "Replaces / Provides / Conflicts" alternatives of pulseaudio, libcups, bsdutils, udev, util-linux, uuid-runtime, xserver-xorg and many more - all with a -nosystemd extension on the package name.
ONLY WHEN it is possible for debian users to run a debian system COMPLETELY free of everything associated with systemd - including libsystemd - will the utterly relentless voices and complaints stop, because only then, FINALLY, will people feel safer about running a debian system where there is absolutely NO possibility of harm, cost or inconvenience caused by the poisonous and utterly irresponsible attitude shown by pottering, with his blatant disregard for security, good design practices, and complete lack of respect for other peoples' valuable input by abruptly and irra
Yeah, yeah I know the history of its development and how log files are binary and the whole debug kernel flag fiasco. And I don't care. By the time I used systemd, that had already long passed.
I switched from Squeeze to Jessie a couple years ago, had some growing pains as I learned how to use systemd... but that was it. No stability issues, no bugs. Can't say whether things run better, but they definitely don't run worse.
I had only really been using Linux for a few years before the onset of systemd, and honestly I think that's part of the problem. People who complain about systemd the most seem to have been using Linux for a very long time and just "don't want to change". Whether its nostalgia or sunk-cost fallacy, I can't say, but beyond that it seems much more like a philosophical difference than a practical one. It just reminds me of people's refusal to use the metric system, for no better reason than they are unfamiliar with it.
If systemd is so terrible, then why did a lot of the major distros switch over? If they didn't, it would just be a footnote in the history of open source: "Hey remember when they tried to replace sysV and init with that stupid thing with the binary log files? What was it called? SystemP?" The fact that Devaun has not overtaken Debian in any real way (at least from what I've seen, feel free to correct me if I'm wrong) indicates that my experience with systemd is the norm, not the exception. The market has spoken.
I read TFA, there is not one single specific bug or instability mentioned about systemd. What is the "tiny detail" that split the community? I have no idea, because TFA doesn't say what it is. I know that part of the philosophy behind Linux is "figuring it out yourself", but if you don't explain to me these low level kernel details (if that's even what they are; again, I have no idea), then don't expect people like me to be on your side. Linux is just a tool to me, I don't have any emotional attachment to it, so if things are working OK I am not going to start poking around under the hood just because someone posts an article claiming there are problems, but never specifying what those problems are and how they affect me as a user.
Honestly TFA reads like "We are having development problems, therefore systemd sucks." I get that when major changes to the platform happens there are going to be issues and annoyances, but that's the way software development has always been and will always be. Even if systemd was perfect there would still be all kinds of compatibility issues and new conventions that developers would have to adapt to. That's what I would expect to happen whenever any major change is made to a widely used and versatile platform like Linux.
Even Linus doesn't really care:
"I don't actually have any particularly strong opinions on systemd itself. I've had issues with some of the core developers that I think are much too cavalier about bugs and compatibility, and I think some of the design details are insane (I dislike the binary logs, for example), but those are details, not big issues."
I'm not saying systemd is "better" or "the right answer". If you want to stick to distros that don't use it, that's up to you. But what I am saying is, get over it.
Only crack the nuts that crack. You don't put the ones that don't crack in the sack.
I started out using Slackware over twenty years ago. Biggest reason I left it was the libc5/glibc2 debacle. It became nonviable for me to remain on Slackware at that time. Bounced around through several package-managed distros and eventually ended up on Debian. I've now watched Debian become increasingly complex, sometimes needlessly, and sometimes because different major components have features that other major components lack. This means even if one is running something like xfce for the windowmanager one has to have a lot of Gnome or KDE stuff installed for basic stuff to work.
It's gotten worse since Systemd entered the picture. Honestly pulseaudio is still not mature, not sure how the person who didn't get that working right was entrusted to replace init.
Do not look into laser with remaining eye.
Windows is a very complex system. Not necessarily because it needs to be complex, but rather because of "wouldn't it be great if we could also..." thinking. Take the registry. Good idea in its core, a centralized repository for all configuration files. Great. But wouldn't it be nice if we could also store some states in there? And we could put the device database in there, too. And how about the security settings? And ...
And eventually you had the mess you have now, where we're again putting configuration files into the %appdata% directory. But when we have configuration in there already anyway, couldn't we... and we could sync this for roaming, ya know...
Which is the second MS disease. How many users actually need roaming? 2, maybe 3 out of 10? The rest is working on a stationary desktop, never moving, never roaming. But they have to have this feature, needed or not. And if you take a look through the services, you'll notice that a lot of services that you simply know you don't need MUST run because the OS needs them for some freakish reason. Because of "wouldn't it be great if this service did also...".
systemd now brought this to the Linux world. Yes, it can do a lot. But unfortunately it does so, whether you need it or not. And it requires you to take these "features" into account when configuring it, even if you have exactly zero use for them and wouldn't potentially not even know just wtf they're supposed to do.
systemd is as overengineered as many Windows components. And thus of course as error prone. And while it can make things more manageable for huge systems, everything becomes more convoluted and complicated for anyone that has no use for these "wouldn't it be great if it also..." features.
We used to have a Bill of Rights. Now, with the rights gone, all we have left is the bill.
Unfortunately no. Let me explain.
You want to isolate services on your server primarily for security reasons. "Containers" alone are not it, of course, so I'm talking about SELinux or AppArmor to define exactly which resources, at the individual file/socket level, can be read from or written to, plus to broad isolation mechanisms like namespacing etc...
If you move all that to *BSD, you'll have far more work YET to be done.
OpenBSD has NOTHING in the isolation department. No jails, no SELinux/AppArmor kind of role based access control, or mandatory access control. You cannot isolate processes. OpenBSD's "security" is based upon writing correct code, and adding a few pledge calls into the mix.
FreeBSD at least has jails. But, to achieve the same level of protection, you need jails with read only roots, having installed ONLY executables that can be executed (which excludes vast number of bins from base), externally mounted read write paths etc... Good look with that as it's all manual work, no tool exists that does all that. All the jail tools are treating jails like "mini VM-s", meaning full OS installations in an isolated environment sharing only the kernel with the host, and the network stack unless you use VIMAGE.
Moving to BSD is _NOT_ an easy alternative. And there is plenty of sane and secure non-systemd choices in the Linux world. Gentoo (yes, gentoo, and don't kid yourself, if you wanna use FreeBSD, be prepared to compile a LOT because the official pkgs are nowhere near flexible in options they support, and flavors have yet to pick up support by maintainers who have to flavorize their ports), Devuan, Alpine, Void, Slackware, .....
... their only arguments are hyperbolic personal attacks. (Look, I can do that too!)
Hint: Your side is just as stupid as your opposing site. There is no sane or reasonable, let alone sensible side. Because that is how Americans are. At least it is beyond their *tiny* mental box.
Regarding systemd, I state *both* A and B:
A) Monolithic "frameworks" have always been a stupid idea. Because they disable you from plugging them into *your* system, and force you to plug into *theirs*. Because they want to dominate you! And they are mutually exclusive as a result of that.
B) Traditional init systems are very limited and badly limiting nowadays. Like still using DOS as the underpinnings of your actual system. A more generic event/trigger system is much more sensible.
THE PROBLEM IS: That systemd throws away what's good about traditional init systems (like "everything is a file"; modularity; being able to do things with a simple file manager, text editor and maybe a script.).
It could have done the event/trigger thing *without* sacrificing modularity (tools that do *one* thing, and do it right!).
It could have acted less like a dominatrix on a power trip, swallowing everything.
The base ideas were good. The personality of the way it was implemented, was that of a complete egocentric psychopathic asshole with a god complex.
Give me a sane eventd, and I will ditch the old init system before you can blink.
I don't agree. Systemd is the most visible part of a clear trend within Red Hat, consisting in an attempt to make their particular version of Linux THE canonical Linux, to the point that, if you are not using Red Hat, or some derived distribution, things will not work. In essence, Red Hat is attempting to out-MS MS by polluting and warping Linux needlessly but surely. The latest: they have come up with the 'timedatectl' command, which does exactly the same as 'date'. The latter is to be deprecated. Red Hat, the MS wannabee. They will not pull it off, but they are inflicting a lot of damage on Linux in the process.