The initd-inspired community has resisted the push for declarative and component-based core system infrastructure for so long, and it's causing very strange distortions to the linux ecosystem as solutions get sought for the problems it introduces.
Systemd, for all its flaws, fixes some very important problems that init and runit and similar systems left unsolved. It's complicated, but it's hard to argue it's unnecessarily so. We always end up at these tortured bike metaphors or some other garbage. There's a whole website devoted to criticisms and it feels like at least half of the site is devoted to this kind of baseless rhetoric.
As far as I can tell, systemd is a holy war. It's the new editor debate. It's vi vs emacs vs sublime vs atom vs ... down throughout time, with people arguing where the tradeoff between simplicity of execution is more important than delivering a system people asked for.
The second major issue is it growing way out of the bounds of being just an init replacement, thereby violating the so-called Unix Philosophy of doing one-thing well. For a user app to do that is one thing, but for a core OS component to do that just smells way too much like forcing Linux to be more like Windows, which a lot of hard-core Linux users are ideologically opposed to.
The third major issue is that on most major Linux distros, users are not given an easy way to avoid using systemd, no matter how much they hate it or oppose it.
The fourth issue is the apparent arrogance of the people responsible for systemd, and their off-hand dismissal of mature and widely respected unix conventions.
All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.
I keep on hearing this overly worn "Unix Philosophy" argument against systemd, which in the absence of any non-religious technical justification, basically boils down to "its different".
All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves. Had they just been more humble about their creation and waited until it was mature and well-tested and did all the wonderful things they claim it could and should do instead of stuffing what was widely seen as a broken-by-design piece of garbage down everybody's throat, maybe much of the Linux community wouldn't have been nearly so outraged by it.
Nobody shoved anything down anyone's throat, least not the SystemD developers. And the same goes for PulseAudio, DBUS, and all the other projects on freedesktop.org.
Anyway, in reality, software does not become mature and well-tested without early exposure to real users and systems. Chicken-and-egg problem there.
I feel absolutely no sympathy for those who are outraged. There are many distributions out there (including Devuan) which align with their particular vision of an OS should be.
If it is as broken as you say why was it adopted?
That ship sailed a long ago when Linus ranted against microkernels :) Linux was never meant to follow a 'do one-thing well' design. It was designed to be a monolithic do-all-things design that's also highly modular.
I agree this is a big part of the problem, and appreciate it being raised.
> All of this adds up to a storm of controversy that the systemd people mostly brought upon themselves
I think Systemd comports itself as project exactly like most free software projects do, including Linux. Linus creates a template and then rages about how he doesn't like it.
I think @pmoriarty here just nailed it. It's not necessarily that "SystemD sucks" or that it doesn't do what it proclaims to do. But the fact that it's so monolithic (in practice, if not in principle) and subsumes so much of the rest of the system, and introduces so much coupling, is a very real issue. That switching from SystemD to $SOMETHINGELSE is a huge undertaking is, in and of itself, a problem.
The "Unix Philosophy" of "do one thing and do it well" isn't just a tagline. That philosophy is cherished because it's been proven to be valuable. Replacing init with something that moves away from that is certainly worthy of questioning, if not outright criticism.
Now maybe it's the case that SystemD is really just plain "so much better" that it outweighs all of that. I honestly don't know. But I can understand why people raise these issues.
It's PR fluff -- AFICT it's actually never been true. If it were true, we'd not have a "sort" option for "ls". (EDIT: It would also require a better interchange format than "unstructured text", but that's an aside.)
It's also fuzzy enough that you can always claim it to be true: What is the "one thing", well for systemd[1] the "one thing" is to be a "system daemon" (not an "init system" whatever the definition of that is). I guess you could argue whether it does it well, but I claim that it does -- at least for every single system that I'm running it on.
[1] That's the correct spelling, btw. Not SystemD or any other variation.
Systemd is a whole group of small, factored tools that call to each other. This complaint gets trotted out a lot and I lump it in with the "It is different because it has new features."
It is interesting that you say that, because I am still waiting for the reasoned technical argument in favor of systemd.
Anyway, my main issue with systemd is how difficult it is to get rid of. It doesn't matter how awesome you think your software is, there is always going to be someone who disagrees. The beauty of FOSS is that it is easy to modify your system to suit your preferences. But for some reason systemd makes it difficult to switch. Even GNOME has a dependency on it. That seems completely insane to me.
>Systemd, for all its flaws, fixes some very important problems that init and runit and similar systems left unsolved.
I don't really know what you mean by this (and I hear people say it a lot). Systemd only rose to prominence in the last few years. Most systems worked just fine before then. What sort of significant open problems were solved by systemd?
> As far as I can tell, systemd is a holy war. It's the new editor debate. It's vi vs emacs vs sublime vs atom vs ... down throughout time, with people arguing where the tradeoff between simplicity of execution is more important than delivering a system people asked for.
There is a difference between systemd and the other holy wars, and that is that the other holywars were destined to end in a draw. No matter how much you like emacs more than vi, no one harbored the illusion that vi would stop easily installable on an average system. But for some reason a majority of the systemd supporters seem to view using an alternative as a serious crime.
In that case, you may be interested in https://news.ycombinator.com/item?id=13387989 and the other resources it links to.
The comment reviews Russ Allbery's analysis of systemd [1], which he wrote as part of Debian's evaluation of whether to switch to it. Russ lays out a number of detailed arguments in favor of systemd, and contrasts systemd to alternative init systems.
[1] https://lists.debian.org/debian-ctte/2013/12/msg00234.html
Here is the only solid criticism of systemd I've read that focuses on design (as opposed to bugs that surface from the sprawling throw-it-over-the-wall approach to development): http://blog.darknedgy.net/technology/2015/10/11/0/
Notably, darknedgy hosted/hosts uselessd, which was a lightweight version of systemd. On the whole i think the idea underlying systemd, of graph-based management of services and system state makes more sense that wonky initscripts garbage.
Technical discussion aside, I rarely see mentioned is that, what in my opinion, systemd resembles a lot of "politics-driven-development" i've worked on before. It's sprawling and ambitious--which means bugs--and like a high-politics project there's a certain incentive i perceive to downplay bugs--which also means it's a great way for RHEL to centralize control over things they didn't have say in previously as well as standardize, etc.
I'll go ahead and beat up on it more by saying that if the project is going to be used cudgel-like, I wish it would more loudly start talking about stuff like formal analysis, fuzzing etc., because it would be a great opportunity to promote research-y stuff in the "email your patches" world of OSS development.
Which is fine, but running Arch workstations for nearly ten years now, there's been a lot of gore with systemd... more than i'd like to see in PID1.
Of course, I hate writing C code with a passion so I'm just a whiner really.
There are not fundamental design flaws. They don't have to be, to be a problem. And it's a problem exacerbated by the developers' typical response to problem reports -- to try to transfer blame, or treat them as personal attacks, rather than dealing with the issue. An example of that is CVE-2017-1000082 -- a rare example of a real problem that was assigned a CVE number by request of someone other than the developer, because the developers are still insisting, after a week of well-deserved mockery, that it's not a problem (or not their problem, or something)...
Refs:
Buffer overflow: https://www.theregister.co.uk/2017/06/29/systemd_pwned_by_dn...
Cache poisoning: http://seclists.org/oss-sec/2014/q4/592
It would make sense if systemd delivered on its promise of automatically detecting service dependencies (through socket activation mechanism). In practice, it's still distro maintainers and sysadmins who need to specify any and all dependencies manually, and as such, systemd is in no way better than what we had with upstart or Gentoo's old initscripts (those before OpenRC).
I have not personally experienced this, but I've been in enough of these threads to realize that it's a big problem when, on a regular basis, you can't get these little problems solved because the creator insists it's supposed to work that way, to the bemusement of experts who chime in that know it has never worked that way before (and perhaps with very good reason), never in any other related system of the kind.
So we get to have all of the reasoned, technical arguments again. That's how progress works, I guess. In a modern, systemd world, maybe the arguments that led to so many system designers putting their systems together in "this way," for arbitrary values of "this" which are broken in some way by systemd, actually don't fundamentally hold water anymore. Maybe if you drink enough of systemd's kool-aid, you won't try asking these types of questions of Lennart anymore, you can just see it the way he does.
"Am I out of touch? No, it's the children who are wrong..."
This is a point that bears repeating, so I shall.
Lennart Poettering is not the only systemd developer.
In all of the discussion of Lennart Poettering's reaction to the User=0pointer gives superuser rights bug, almost no-one has looked at the other systemd developers. I have had to point out several times Zbigniew Jędrzejewski-Szmek's reaction, which was to work on https://github.com/systemd/systemd/pull/6300 .
Or you might want to look at Martin Pitt, the systemd developer who famously turned back off systemd's widely problematic DefaultTasksMax setting, for Ubuntu. https://news.ycombinator.com/item?id=11675133 https://anonscm.debian.org/git/pkg-systemd/systemd.git/tree/...
OR
We burn all those MLs into the ground.
Terrible culture in these projects is basically how everyone is conditioned to interact from the top down. We can't pick and choose which assholes are okay and which are not. We either push back on all of them to make a more professional environment or we accept this is what we want.
For a less politically correct one: http://suckless.org/sucks/systemd
For a personal experience: I remember that until systemd 21x (212? 213?) whatever core dump you got was cut off at around 700Mb (arbitrarily chosen by systemd developers due to journald limitations, a bug was left open without comments for 2 years, another person was essentially told that was the limit we're sorry [1], until a big customer of RH was hit by it maybe). Obviously preventing systemd from "intercepting" core dumps was (and it is still, IIRC) black magic. That made for some head scratching moments in our early RHEL7 installs.
[1] https://bugs.freedesktop.org/show_bug.cgi?id=55613, https://bugs.freedesktop.org/show_bug.cgi?id=59623, https://cgit.freedesktop.org/systemd/systemd/commit/?id=34c1...
Ted Ts'o: https://plus.google.com/+TheodoreTso/posts/EJrEuxjR65J
"For me a lot of "good taste" is about adding complexity when it's needed, and avoiding it when it's not needed. And if you do have complexity, making sure you have the tools so you can debug things when they break. And for me one of the things that I don't like about systemd is that it has added a lot of complexity, and when it breaks, trying to debug it can be almost impossible."
Also:
"Heck, I don't even I want to file bug reports, just so I can get abusive messages from Lennart. At least when Linus flames me, it's because I did something wrong which hurts users and which I d*mned well should have known better, given my years of experience in the community. Lennart just flames you because you're wrong, and he's right. By definition."
And:
"The high bit, in my opinion, is "not being able to admit you are wrong". If someone (such as Lennart) is always right, then it's impossible to have a technical discussion in a post-mortem to avoid similar problems in the future. In a company, if there are personnel issues like that, you can escalate to the person's manager, or use other mechanisms. In the open source world, all you can do is route around the damage. Whether you call the inability for someone to admit that he or she has contributed to the problem a "lie" or just that they were "mistaken" is really beside the point as far as I'm concerned."
This reminds me a lot of everyone complaining so much about Windows 10. If you're not prepared to vote with your feet, your complaints are just wasted breath (or keystrokes) when the vendor obviously doesn't care one iota about your grievances.
These are exactly the kinds of complaints I was saying I find less than compelling, because many of the same people who raise them then think the Linux project is okay to run like if UFC was also a papal state.
I don't think getting into the specifics is going to be productive here, but I just wanted to point out that the debate shouldn't be framed as "systemd" vs "non-declarative init systems".
(Though, I'm also a huge proponent of declarative init systems; I like both shepherd and PIES)
Replacing SysV init? Relatively easy. Replacing Systemd, all the ancillary programs, desktop environments that it ties into, etc? It's a ton of work. One of the arguments I've heard repeated is that it's all very modular, but that doesn't seem to be true in practice.
Your distro maintainers obviously thought it was a worthwhile decision for them to make.
But yes, I hate C, too.
Does nobody other than my alma mater cover the concept of Coupling and Cohesion? It's not hard to argue the point on those grounds. I just kinda assumed everyone would be familiar enough with them to see that's the main thrust of systemd arguments, but that doesn't seem to be the case.
Since it is politically incorrect to criticize Linux, people attack projects that try make a positive change...
How old are you? OpenSSH wasn't built because there was something wrong with Linux per-se, in fact it came out of BSD due to a licensing issue with SSH. SSH was a replacement for the rlogin/telnet type toolsuites due to them being ridiculously insecure. Nothing to do with Linux.
Xorg was released, again as mostly a licensing issue (although some architectural improvements) based on XFree86, which was first released in 1991, with UNIX type systems in mind. This fully working windowing system was released around the same time Linus released the first fledgling version of his kernel. XFree86 was an implementation of X, which was around way before Linux was around.
> The real problem is Linux
I lack the words or intellect to refute such a well-founded and self-evident statement.
GPLv3 is the future
Or: Those folks who write rants about system d are not very active in contributing to a distribution that runs without it. With some discussions, you have that feeling that there are "those who talk, and those who do".
I've been fairly vocal against systemd, and not because of Poettering. I'm no fan of the man, and I strongly agree with a lot of the points he made in his initial blog posts when introducing systemd. I think he's probably very talented---I'm not in a position to judge that. I wouldn't be against systemd if it were just an init system. The problem is that it's not. That's the end of my argument. If systemd were just an init system, I'd be very happy to have it on my machines. Poettering even admitted this himself [1]:
> Well, systemd certainly covers more ground that it used to. It's not just an init system anymore, but the basic userspace building block to build an OS from, but we carefully make sure to keep most of the features optional. You can turn a lot off at compile time, and even more at runtime. Thus you can choose freely how much feature creeping you want.
In response, I've decided to not use systemd on my machines. I'm a patreon of xtraeme [2], the creator of Void Linux [3] and xbps (the package manager used in Void). Void Linux uses runit [4], which is exactly as simple and fast as I'd like it to be [5]. Working in startups, I haven't had time to contribute code to either xbps or Void, but at least I'm contributing in the way that I can. I didn't contribute to Devuan (other than seeding a few hundred TB of ISOs) for the same reason that I haven't contributed to Debian in a long time: I don't use it any more.
[1]: http://0pointer.de/blog/projects/the-biggest-myths.html
[2]: https://www.patreon.com/xtraeme
[3]: https://www.voidlinux.eu/
All of systemd's functionality, as far as I'm concerned, is rationally motivated by wanting to orchestrate and instrument system startup in a sensible way. What functionality do you think systemd should not have that it has today? What is a better way of achieving the result provided by that functionality?
If your perspective is that you don't care about that functionality or the related user experience, and so all of its complexity is dead weight to you, OK. That makes sense. But as a software engineer and system administrator, I find the features extremely useful, and I think many other people do too. That's why systemd has been adopted by major distributions.
I wrote a comment earlier [1] about systemd that reviews Russ Allbery's analysis of systemd [2], from when Debian was evaluating switching to systemd and upstart. Russ's comment reviews a number of different systemd functions, such as its integrated journal, and then explains the pros and cons of each. Russ even said:
Integrated daemon status. This one caught me by surprise, since the
systemd journal was functionality that I expected to dislike. But I was
surprised at how well-implemented it is, and systemctl status blew me
away. [lots more details in linked comment]
Sure, you could argue an init system "shouldn't" have an integrated journal (for example), but then you'd lose the clear benefits that Russ outlines. You wouldn't achieve the same benefits or user experience. Similarly, systemd's configuration-driven approach to service definition makes it possible to employ a wide variety of standard configuration options across all services. From my previous comment:
> I can launch my service at the appropriate time during boot with configuration as simple as:
[Unit]
Description=Demo service
[Service]
Type=forking
ExecStart=/usr/sbin/my-daemon
PrivateTmp=yes
PrivateDevices=yes
PrivateNetwork=yes
CapabilityBoundingSet=CAP_NET_BIND_SERVICE
> I can drop capabilities with CapabilityBoundingSet=, or limit resource usage with CPUSchedulingPriority=, IOSchedulingPriority=, etc. I could even tell systemd to open the listening socket for me so the service doesn't need CAP_NET_BIND_SERVICE! Moving these options into the init system makes a ton of sense, because it gives administrators the ability to employ these features from outside applications, not just by enabling them within applications that bother to explicitly support them via command line arguments. Systemd better encourages the principle of least privilege: if a system daemon does not need the ability to "ptrace" other processes, or bind to ports <1024, then as the administrator I can take those away with CapabilityBoundingSet= in the unit file. Chrooting the service is as easy as RootDirectory=. This is a huge step forward compared to the world where every service must be relied upon to expose these settings, and must be trusted to implement them correctly.
I don't see what your point is.
So, SystemD affects me daily and yet I can do nothing, I'm helpless. Which is why I'm rather vocal.
The whole systemd shouting match has been dominated by anti-systemd people who are the extremely vocal majority, happy to blog incessantly about how "evil" systemd is, but apparently not that happy to contribute their time to an alternative that's more to their liking.
I'm not a systemd proponent (or detractor), as I'm not a professional sysadmin and just use Mint personally, but throughout that debacle it was fairly obvious which side was the more religious and less rational, and also less willing to put their money (or time) where their mouths were. Consequently, without doing any deep research on it myself, I tend to believe the systemd proponents far more.
It's not as simple as you think, unless the machine is a minimal deployment, in which case it works (I've got a docker host machine that runs runit instead of systemd)
* https://news.ycombinator.com/item?id=14580024
On that subject, the Debian Installer has an interesting bug in the current version.
* https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=866206 (https://news.ycombinator.com/item?id=14710986)
What makes you think they could "just" do anything in less than several years? :^)
Where can I download the precise set of requirements for this, so that I don't have to peek at the systemd source code?
What is systemd?
Where can I download the precise set of requirements for this, so that I don't have to peek at the Linux source code?
What is Linux?
Really, this doesn't make sense.
A good many of the Linux system calls and glibc functions are documented by POSIX. That doesn't cover 100%.
We can start by looking here:
The Linux man pages project covers system calls:
http://man7.org/linux/man-pages/dir_section_2.html
Many of these don't correspond to anything in POSIX, or not directly, so this documentation is crucial to anyone wanting to replicate Linux.
Microsoft seems to have done such a thing:
https://en.wikipedia.org/wiki/Windows_Subsystem_for_Linux
"WSL provides a Linux-compatible kernel interface developed by Microsoft (containing no Linux kernel code) [...]"
However, in all likelihood, they peeked at Linux code here and there.
FTFY
Having a would be second kernel metastasizing in userspace is no a good thing, full stop.
But then it became necessary to subsume udev and syslog and cron and more parts of the system, and each time, the justifications for this scope creep have been unconvincing to me. It comes across as a bunch of added complexity because it'd be nifty and because they can, without stopping to reflect on whether trying to subsume the rest of the OS or forcing tight coupling and integration is a good idea from a design or architecture perspective.
It would have been much more interesting to hear about what software had to be rewritten or replaced to support desktop environments like Gnome.