For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that. Yes, there's parts to systemd that not everyone will use, like container support, but in that case you can pretty safely ignore that use case.
For me, systemd has provided a much more consistent way of managing services. There's a tightly defined service definition format that allows one to comfortably modify any 3rd party service as well, (unlike random, variable-quality shell scripts), relatively small amount of commands to learn that work consistently across services, mounts, timers etc. There's also much better handling of modern hardware, hotplugging & the like.
I can't say I miss sysvinit. Also, stuff like  from the anti-systemd camp doesn't inspire confidence.
1 - https://lwn.net/Articles/786593
It is easier to configure and is convenient to have one holistic system in a lot of ways, but...
They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits.
They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up.
I don't think the code is high-quality, but even more than that I have a problem with the people being controlling, dismissive, and deceptive.
Additionally, this is not likely to stop, since they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++), thus enabling a whole class of systemic security issues that will keep popping up in the future over and over again as well. This is one of the design decisions behind systemd that irks me the most.
While Bash is memory safe, it is also very error prone to write and the potential of shooting yourself in the foot with it is rather big, especially with bigger scripts and considering these are executed mostly with root privileges, bash is not an ideal choice either.
I'd prefer if systemd was a Rust project for sure, but they went with C, presumably to remain consistent with the kernel, GNOME and most lower-level Linux system software, (also, Rust was pre-1.0 at the time).
That said I agree they should have picked Go instead /s.
I don't really have an opinion on what language should have been picked instead, though OCaml may be a good candidate.
EDIT: or maybe as PID 2, per https://github.com/omisego/ewallet/issues/108 , though I'd be interested in the idea of writing an OTP application that can reap zombies and forward signals.
Isn't that basically what SysVinit and a good-sized chunk of the management tooling in Linux is?
To their credit, Bash is a _weird_ language, but it's not going to corrupt memory when it crashes, and its failure modes are pretty well understood by the distro maintainers writing those scripts.
> Go was publicly announced in November 2009, and version 1.0 was released in March 2012.
The brand-new language that Google just announced last year was probably not considered a serious option here.
They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
Lua would have been a good candidate: memory safe, coroutine to structure the code in a concurrent-ish way if needed, and you have a configuration file parser for free (just use Lua as the configuration language, it was its very first purpose after all).
From system programming solely: libguestfs, Xen API, liquidsoap, Unison, MirageOS, google drive on fuse, 0install.
OCaml concurrency is great, and Lwt  would be exactly what systemd need: run daemon and poll the answer concurrently.
Ada, C++ and D would have been another great choices.
I wouldn't expect CPU-bound multithreading to be much of a concern in an init/rc system. And resource thriftiness and predictability would likely be a bigger concern.
> Mozilla began sponsoring the project in 2009 and a nnounced it in 2010.
> The first numbered pre-alpha release of the Rust compiler occurred in January 2012.
Look, I like Rust and all, but are we really suggesting it for projects that predate public release of rustc?
Rust might be better now; my primary concern would be community size and whether I was limiting my contributor base, which Go also has as a concern. In both cases though I'd take it over C/C++ being used on such a critical project at this juncture.
In 2010, though... yeah, choices are a lot worse.
I'm not against go, other than gc and some size considerations. Given that a lot of k8s infrastructure for the likes of CoreOS and similar are written in it, it's definitely not a bad option. I think that today, and more so in late summer as async/await syntax settles, that Rust should be a first consideration for any low-level system code.
Many init systems have been created in bash, and I'd hardly call that a low level language.
And that reason is that one rarely needs to write a million lines of Bash: http://catb.org/esr/writings/unix-koans/ten-thousand.html
You underestimate my masochism and/or overestimate my sense of restraint ;)
Let's just say the language choice went from bad to equally bad.
it causes the script to terminate with an error if it encounters use of an unset variable
This seems like it needs some citation. There certainly have been bugs. I think it's legitimate to talk (with specifics!) about cultural issues with systemd's development and its impact on security. But I don't see that this statement is particularly well supported. In particular I genuinely don't know what you're referring to with respect to ignored/suppressed bugs and CVEs.
I mean, systemd is a lot of code and makes up a big chunk of the system plumbing these days. Obviously it's going to make up a big chunk of the bug budget. People don't get upset about flaws in someone's random cgroup launcher or encrypted block device manager or daemon wrapper not because those projects don't have bugs, but because basically no one uses them. Because basically everyone is using systemd!
(Just in case, this is an security issue because it enables constant dosing, as well as clears the resolver cache making spoofing easier)
(Also... gotta be honest that's sort of a vanity CVE. Note the complete lack of details in the report itself, it never saw an eyeball after it was filed. It's valid enough, but frankly I'm with Poettering on the specifics here: if we filed a CVE for every theoretically-exploitable-but-unexploited-until-fix-released crash bug the system would be beyond useless.)
Poettering is dismissive of nearly every bug. Remember when systemd would default to starting units as root when it couldn't parse the username? We're not talking about some minor piece of software like a sound multiplexing daemon, we're talking about the core userland piece of every Linux install. Bug reports on something that central should be taken seriously and with a minimum of snark.
I'm with Poettering on the specifics here: if we filed a CVE for every theoretically-exploitable-but-unexploited-until-fix-released crash bug the system would be beyond useless.
All the more reason to reduce the attack vectors and ensure that your code is well thought out, and coded defensively. That you have too many security issues to generate CVEs for each and every one is a problem in and of itself. Ten years ago how many people thought that all of these speculative execution side channel attacks were possible or practical?
I have a serious contention with the statement that systemd is the simplest possible solution for this problem. Especially since it involves not only service management, but user logins, a data bus, logging management, file system mounting, initd, and a host of other things.
Are all of those pieces necessary? Arguably yes. But not all in one system(d).
So why should I currently opt for the worse solution? Is the overall design of it promising?
> Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key.
What complexities does it address? I lost track of everything an init system is apparently responsible for.
> It works well overall and end up being more portable and consistent in the long run.
Since systemd only runs on Linux APIs, I can't figure out what this even means. There are init systems that run perfectly fine in plain POSIX environments. systemd is not one of them.
What I mean is that there are init systems that only require POSIX compliant APIs and as such are portable across systems that implement POSIX, e.g. GNU/Linux, BSD, Solaris, AIX...
systemd requires (in addition to POSIX) Linux APIs and is therefore not particularly portable by any reasonable definition of the word. You can use it if you are running a Linux kernel, and that's it.
Those are irrelevant as they can't even do basic tasks like shutting down the computer or restarting it.
Feel free to find a POSIX API for Linux' reboot syscall.
Some systems also require mounting additional filesystems, again not possible in a world limited to POSIX interfaces.
Sandboxing, SELinux, ...? Not in POSIX.
And so on.
And nohup was always a hack. Now that we actually have a functioning user-level service manager keeping processes alive by throwing them at PID 1 to parent needs to go away. I really hope that systemd eventually uses subreapers to keep all user processes under the session leader.
I feel like it's weird to talk about scope creep when logind is pretty much the first system to define what a session even means on a Linux system.
We should standardize on the interfaces, avoiding hard dependencies. There is dbus for that.
As dbus user, or application, you just need some client library. As an operating system, you also need a daemon running, which is routing the messages among all the clients.
 - https://dbus.freedesktop.org/doc/dbus-specification.html
I am personally in the camp that doesn't mind that, Linux users should get the best possible software given their system capabilities, not the lowest common denominator one just for the sake of it. (Free)BSD developers are also not looking to make sure their stuff works with Linux, which I think it's a valid approach.
GNOME itself does exist on the BSDs, by the way knocking down the argument of systemd being a hard dependency of GNOME along the way.
If this claim were true it still is beside the point of my comment, that systemd itself has a "Linux only, and we don't care" approach, and dbus for the moment is not that.
> GNOME itself does exist on the BSDs
Yes the ports tree is a wonderful place for those things to sit for those who are interested and for a larger portion to not bother installing them. I don't know how many patches they applied to get it working or what the cost and effect of those patches may be over time.
The 'Imperialistic Culture' you speak of is one of those made-up things that systemd haters keep repeating, but has no basis in reality.
> They pushed for Gnome to have a hard dependency on it so that everyone would be _forced_ to use it instead of just letting it be accepted by merits.
Again, another fairy tail.
> They have a track record of labeling serious bugs as non-issues, ignoring them, or just not filing them as CVEs. Serious issues keep coming up.
A) This is par for the course in Linux software. See also: Linux kernel. One side you have is a bunch of security bros running around trying to fluff up their resumes and trying to turn themselves into heros. And on the other side you have devs working hard on various features and bugs and being resentful that most of their work goes unnoticed while stuff they already fixed is thrown back in their face.
B) Many of the bugs that make it onto Reddit/Hacker news are going to be ones that are largely changes in configuration defaults or behaviors that break things and are meant to be configured by the operating system designers that use it, not end users.
C) This level of scrutiny never existed before for low-level Linux features. The multitude of redundent and terrible shell scripts that made up the majority of functionality that systemd project seeks to replace was always a swampy mess of broken functionality and bad code. Having each and every major linux distribution rewriting 90% of it from scratch in a completely un-portable and estoric way didn't help matters.
Linux advocates actually went so far as to praising the fact that even though half of the scripts in their OS were completely broken and the OS still worked fine was a testament to it's robustness.
The fact that now, finally, after decades of this crap people can now track bugs related to low-level Linux userland 'plumbing' is actually a good thing.
> It is easier to configure and is convenient to have one holistic system in a lot of ways, but...
On the sysvinit side you had thousands and thousands of lines bunch of procedural code of dubious quality that is endlessly rewritten by hundreds of different teams with vastly differing levels of competency and success using a general purpose language for configuration. It was so unportable that you couldn't even use anything but the most basic and trivial (also broken) init scripts from one distribution to another without herculean levels of effort.
On the other side you have a even driven OS configuration and management engine that allows people to describe the state they want the OS to be in via a domain specific configuration language. It has managed to standardize the low level plumbing for Linux operating systems and allows distributions to share improvements with one another in a way that was previously impossible.
If people want a alternative to gain in popularity they need learn what systemd does and understand why Linux distribution makers switched to it. Then produce something of their own that takes those positive features and improves on it further.
All the hand waiving about 'Imperialism via releasing open source software to the public' is infantile.
The upside of all of this is that it's going to be a hell of a lot easier to make systemd unit files portable then it is to make Linux init shell scripts. There isn't any reason why a more capable init system wouldn't be able to parse existing unit files and know then how to start and manage the services and applications that use them... So the effort to move away from systemd should be significantly less then the effort to move to systemd.
You are repeating the there-is-only-sysvinit-and-systemd fallacy, pointed out years ago by the Uselessd Guy and decried by many others since but (alas!) still going strong today in this very discussion, and ironically you are doing it whilst erroneously ascribing things to systemd that it was intentionally designed not to be. systemd was explicitly designed not to be an event-driven system. The wholly event-driven system was Upstart, and in practice it turned out to be a problem. Lennart Poettering xyrself discussed the problem, as did some of the Debian Technical Committee members during the Debian Hoo-Hah.
The imperialism part is likely due to score creep into parts they just can't handle well enough. systemd-resolved for example had terrible security and functionality issues still after it was being deployed to many distros. These were simple "point a fuzzer at it and watch it crash" issues which should not be seen in a DNS resolver these days.
Maybe it's not for systemd to decide what I'm meant to do. If changes to behavior that they only meant for operating system maintainers to rely on results in angry end-users, they probably made the wrong assumption.
> On the sysvinit side you had thousands and thousands of lines bunch of procedural code of dubious quality that is endlessly rewritten by hundreds of different teams with vastly differing levels of competency and success using a general purpose language for configuration.
Meanwhile, I have ~400 LOC of init scripts (including service scripts) on my daily driver, an init system with <1% the LOC of systemd, and plain text readable system logs. I agree that hand waving about "imperialism" isn't very constructive, but on the other hand I don't think that misrepresenting the alternatives to systemd and exaggerating their faults is particularly useful either, nor is pretending that sysvinit is the only alternative. A lot of people have thought "sysvinit sucks" and done something about it.
The most recent gripe I have is that systemd people can't even do randomness properly and even use non-cryptographic randomness for DNS transaction IDs (ok probably benign). But just boggles the mind.
They're probably just busy.
And calling the "imperialistic" is annoying them, so you've destroyed your political capital with them.
When there is a bug with systemd, you have to fix systemd. And your version of systemd is completely different from the head, because head was rewritten last month (in a process that persists bugs) and yours is a year old. You can't just use head either, because every low level system on your computer is tied to systemd, and they work differently on head. You won't fork it either, because it's so large that a single person can't keep up.
Without a doubt, a declarative init is much better than an imperative one. But that relatively small number of commands is no gain if each command is more complex than the entire set it is replacing, and I'll completely disagree on the handling of modern hardware, hotplugging and the like. Besides, there is the entire logging saga against systemd.
The number of broken init scripts I have encountered throughout the years, that went unfixed for months if not years, stand in stark contrast to this statement. And I’m talking packages like uWSGI on Ubuntu 14.04! This is exactly why I gravitated immediately to systemd. The idea that init scripts actually worked and when they didn’t were easily fixable is not true. Yeah you can fix a broken script locally, but this doesn’t fly at scale n > 1. Submitting patches to distros is not a simple process, and not one that makes sense in this context either. Declarative beats imperative 9/10 times, and systemd is one of those 9.
This is demonstrably untrue. I strongly prefer SysV (which is not to say I think SysV is wonderful or anything) over systemD for a number of architectural and functional reasons.
But I do not enjoy digging into other people's init scripts. Fortunately, I rarely have to do that. I think the last time I had a problem with someone's init script was over 7 years ago.
Out of curiosity, what distros do you use that you've had such a good run with init scripts?
Or they can try out runit, openrc or nosh, if they feel adventurous. The last one is not yet in Debian proper.
To the extent that this isn't flat-out wrong, it's only because SysV init had so few features and so the actual patch had to go to one of many different upstreams. Having had to fix the same classes of problem in hundreds of different places like that has given me an appreciation for how long it's been since I've needed to do anything with systemd other than use it.
One important thing to remember is that the ability to have a standard way to start a process, as a non-privileged user, keep it running, with logging, etc. is something which has been standardized in the Windows world since the early 90s. It's really nice not to keep having to spend time working around the lack of a check-box competition feature for a quarter of a century.
Yet systemd is unfixable. The fact that it does too much was the most popular complaint at the time it got pushed into every distro... while I disagree, my main concern is that it's unmaintainable.
It's a monolith of sorts that breaks the loosely coupled toolbox concept of Unix.
It's worth watching Benno Rice (a BSD developer, actually) discuss systemd and some of the misconceptions, some of which you're expressing, therein: https://www.youtube.com/watch?v=o_AIw9bGogo
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
systemd has binary format data all over the place, and it is quite difficult to separate out an individual component and have it work properly on its own. Not to mention trying to replace a subcomponent with something else.
systemd is, in general, a tightly coupled system with lots of interdependencies. It is, in many respects, the antithesis of the UNIX design philosophy.
Hell, even modern Software Engineering practices still talk about decreasing coupling and increasing cohesion.
Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world.
The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world.
Sure. The UNIX Philosophy applies more to userland, I think, than the kernel.
Edit: I'll add with regard to the kernel, the internal structure of the kernel still has fairly well-defined subsystems that interact in clear, mostly consistent ways. So while from an execution standpoint it is monolithic, the philosophy is still something that is taken to heart to some extent.
> Also, how do you define doing "one thing" exactly? I can see it for `ls` or `cat`, but for anything more complicated than that...not so sure. Is Vi following the UNIX philosophy? If you say; yes, it's 'just an editor', despite 'an editor' being composed of several components, then I can say that systemd is just 'a service manager'. It's a semantics game that does not make sense in today's world.
I think dismissing it as a semantics game is taking it pretty far. It's clearly not a black and white rule, but more a guiding philosophy. When it works, it's beautiful and elegant.
The ability to pipe basic UNIX utilities and programs together is something that has always left me a little awestruck. The flexibility and simplicity there is almost profound. SysVinit was far from perfect, but you could at least trace the execution flow from basically start to finish and, if you understood basic *NIX utilities, have a good idea of exactly what was happening.
> The Unix philosophy has its uses for sure, but it's far from an universal truth in today's world.
Again, it's a philosophy, not a universal truth. A guiding light, if you will.
With systemd, that light is pretty dim, if it's on at all.
You really should. journald is not optional.
Also, since I've been "reading more", and I can check after I get back from lunch--at least at some point Debian shipped systemd without D-Bus on minimal installs. Maybe that's no longer the case, but the stuff I'm reading seems to be post-2015.
Or you can keep trying to big-time me instead of engage on the merits of your position. That's cool people stuff, I guess.
I'm happy to be corrected if I'm wrong. I invited it, even; I'm wrong all the time and being wrong is how one learns. The big-timing I referred to is the refusal to materially engage. Instead he quotes Lennart about D-Bus--out of context? who knows! It isn't an indication of the state of the software in question, just his opinion at a point in time--and to tell me to go read (read what, exactly? what generosity in citation!). Oddly enough, though, I don't see you tagging in to lecture him about that sort of sneering. Why's that?
As just one example, the nspawn owning package requires a libnss package which pulls in systemd-resolve. I believe it also requires dbus.
Apologists are engaging in apologia, which means a defense of one's ideas. It's not suggesting a hidden agenda, to the contrary, it suggests the agenda is fully on display since it's plain what is being defended.
Another thing that makes me forgive git more is that its underlying design is rather novel and powerful. There is something to "get" in git (hah!) that justifies the cognitive investment. In the case of systemd the problem of managing services and their dependencies is not novel or really all that interesting. The complexity of the systemd UX is significantly greater than the novelty or sophistication of what it's doing. It's a piece of software built to complexify the simple.
No. You still have to launch the Python process per command, which is "extremely" slow (relative to C programs). I air-quote extremely because the difference for a single command is small relative to human time, but it matters for automation that invokes many commands.
This post is from 2018, and maybe Hg's frontend is written in C or Rust now (I don't follow its development). But if it is still a Python-driven runtime, the same basic criticisms apply:
Also looks like there's finally python3 support in the recent mercurial 5.0 release.
That's not to say git is slow of course. It's just.. basically what you'd expect given it's architecture.
Distros that choose not to employ systemd do not necessarily retain sysvinit.
I guess it's part of the confusion too, most of the systemd work was replacing the "rc bits" (process startup and management) not replacing PID1 itself.
Still, the spats with the Linux kernel team and the rest of the community has earned systemd a reputation I can only say it deserves, even if the initial ire drawn towards it was over the top. Systemd is not a project I have strong confidence in to act in the user’s best interest, based on what I’ve seen with handling security issues.
> For example, people are complaining about logind being included, but forget that consolekit was unmaintained before that.
I use neither logind nor consolekit. These are solutions for problems I don't have. Moreover, they often get in the way: when I ssh into my media PC, I don't want logind/consolekit to tell me I'm not allowed to access the sound or video cards. The only function that machine performs is to do the thing that logind/consolekit are designed to prevent. And it's a required component of systemd.
I'm glad it's easier for you to manage services with systemd. But it's easier for me to manage services with OpenRC, and there's nothing wrong with that. As far as handling modern hardware- huh? I guess it's not clear to me what interactions an init manager is supposed to have with hardware.
Which really speaks to my primary issue with systemd: it's a freaking monster. It does nine million things, but I only need it to do like three things: start services when I tell it to start services, stop them when I tell it to stop them, and restart them if they crash. (if it's configured to do so) That's it. Why do I need or want it to interact with my hardware? Why does it need an integrated web server in order to start apache? Why does it a logging daemon in order to start syslog-ng? Why do I have to use its built in log reader instead of tail, less, grep etc? Where is the boundary between systemd and the rest of my system?
And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick.
> These are solutions for problems I don't have.
Good for you. But event handling is something that many systems today do need and I think we should try to optimize for the common use case.
As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems.
GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc.
It's also not like the GNOME devs are stupid and got tricked into depending on logind or something. Mo, it solves real problems for them, so they depend on it. Why is this hard to grasp?
It's also 3am my time, and I've had quite a bit to drink. If anything in my post comes off as aggressive, please let me know and I'll edit it in the morning.
> And sysvinit wasn't pretty much a monocultur?. I mean even OpenRC is basically sysvinit with a lipstick.
No. OpenRC is very happy sitting on top of busybox init instead of sysvinit. When I encountered problems with my gentoo system built on musl (instead of glibc, #1 source of problems) and busybox (instead of coreutils #2 source of problems, and sysvinit #3 source of problems) they got fixed. A major part of why OpenRC is what it is is to prevent reinventing sysvinit/busybox's wheel.
> event handling is something that many systems today do need and I think we should try to optimize for the common use case.
> As for you not needing logind/consolekit, sure, if security is not a concern on a system, they're not needed, but again, that's not true for most systems.
Security is a concern on all of my systems, however, I do not agree that logind/consolekit add any security (at all) to most systems, or that they add substantial security to a small minority (say 5%) of systems. I would wager that 95+% of all linux systems are one of the following: A) no one is permitted access to any hardware, (video/sound/input) (headless systems, ie server farms, multiuser systems in a university, etc) B) single user account systems, (ie, my laptop. If someone has write access to my .bashrc file, they might as well have root access, and consolekit/logind can't bandaid anything by limiting access to my video device hardware) or C) hpc compute farms. (where the assumption is that all processes have god given write access to the GPUs) In the first class of systems, consolekit/elogind do not add security because all accesses are blocked, (in fact, the existence of consolekit/elogind simply expands the attack surface, making it less secure) in the second class no security is added because the video card is a more difficult attack vector than editing all the common home scripts, in the third class no security is added because whitelist-asterisk-to-video-card is the only sane configuration policy.
logind/consolekit are super awesome for eg educational institutions which have computers with multiple seats. Have four schoolchildren sitting at four monitors and four keyboards attached to one desktop computer? Sweet. (actually most schools use chromebooks now, which last I checked uses OpenRC) It's great that projects like consolekit/elogind exist to support those groups. But pretending like that's a common usecase, or pretending that sysvinint can't support those usecases- stop.
> GNOME etc. also don't really have a hard dependency on systemd, they depend on logind, which does not necessarily require systemd and indeed GNOME ships on Gentoo, Void etc.
This statement is, at best, disingenuous. If you want to install Gnome on Gentoo, you need to do one of two things: install systemd (Gentoo supports systemd as a first.point.five class citizen (my terminology)) or install elogind. elogind is a Gentoo specific forked version of systemd with everything that is not logind-related removed. This code is still all upstream systemd code, and there is not a meaningful path towards an independent fork, the way busybox init exists independently of sysvinit, or syslog-ng exists independent of syslogd, or xorg-x11 exists independently of XFree11.
The fact that non-systemd installations of Gnome can possibly exist on Gentoo is a result of Gentoo developers going above and beyond the call of duty, despite barriers placed by the systemd team. And non-linux posix systems, eg FreeBSD - forget it.
> It's also not like the GNOME devs are stupid and got tricked into depending on logind or something.
I have nothing but respect for the Gnome team. I never implied anything of the sort. I am disgusted by your insinuation. Please walk this statement back.
I think that many of the things that the systemd monolith has to offer are valuable. If systemd were a federated constellation of small daemons speaking a reasonably stable API that didn't all have hard dependencies on each other, I would probably be quite happy with it. The problem - again - with systemd is the unforgiving, colossal monolith. I don't have the privilege of dipping my toes into the good parts without having to swallow whole the bad parts. And the bad parts are disgusting. (this is the same problem I have with Microsoft Windows) Modularity is a good thing; systemd is the antithesis of that.
That's the thing: there are lots of alternatives besides sysvinit specifically (OpenRC, Upstart, BSD-style RC, launchd, SMF, runit, etc.) on varying scales from "simpler than even sysvinit" to "more feature-rich than systemd". And yet, the best the systemd advocates could ever muster up is/was criticizing specific flaws with just sysvinit.
Of course sysvinit sucks, but you'll notice that (Devuan being the notable exception) most of the article's listed distros use something that's very much not sysvinit.
I first started using systemd with Arch before it got pulled into Ubuntu. It definitely took a little bit to get used to, but once you understand how to write services instead of cron jobs, it's way more betterer.
I do think that systemd is very useful but have concerns that they simply don't have the man power to maintain that broad feature set and scope they have set themselves.
What previously would be done in multiple different competing projects by different people with different ideas in different companies, is now done in a single code-base. I can imagine that innovation will be hindered that way, because systemd is not Linux. But maybe some day it will be, IDK. Currently it is just to big to scale that well to small systems though.
ConsoleKit was used in many commercial linux distributions and still wasn't maintained, now that its part of systemd and systemd is maintained, does that mean that every component of it is as well?
In theory. In practice systemd's actually much more transitive since many distros have adopted it and systemd services tend to work cross-distro, so once you learn systemd you can somewhat confidently manage Fedora, RHEL, Ubuntu, Arch, SuSE, Nix etc.
sysvinit shell scripts often differed in subtle ways between distros and the particular distro implementation was rarely transportable without quite a bit of work.
> You can do almost everything with shell scripts.
This cuts both ways. I'd argue the problem with sysvinit was precisely the fact that you can do almost everything with shell scripts, since now you're executing a script as root that can do almost anything, depends heavily on the bash abilities of the author to not introduce subtle bugs, or break easily, (which varied heavily from script to script and distro to distro), and to not be a security nightmare.
What was the problem with sysvinit that they tried to fix? I don't see any.
The problems with van Smoorenburg rc are widely acknowledged, however, and motivated the creation of Upstart, finit, init-ng, and many other softwares; indeed, the problems of System 3/5 init/rc, which van Smoorenburg rc began as a clone of, similarly motivated the creation of the SAF in AT&T Unix System 5 release 4, the Solaris SMF, and the AIX SRC. There is a history of superseding them that goes back for decades. It is clearly wrong to claim that they are without problem. They've been recognized as problematic and people have been replacing them since before Linux was invented.
Based on my experience and all the anti-systemd posts online, I expected to dislike it.
But on it's merits I really like the consistency it brings to the "system layer" of the OS.
I find it's shame when developers skip over systemd for consideration, adding extra layers of complexity when systemd alone would have been sufficient: For example, using Docker when the basic isolation features of systemd would do, or using "forever.js" to manage Node.js processes, when systemd could could be saving 15% memory overhead per process, using software already installed in the base system.
On the other hand, I do support diversity of software and am glad to see some other options still being promoted and used. The dangers and weaknesses of monoculture in the physical world apply to software systems as well.
From my understanding, alternatives _could_ be written, but haven't yet and that means we currently having to ignore more battle-hardened software in favour of whatever is in systemd by default.
Logging is a bit different, but you can tell journald to use syslog.
No. One can tell syslogd to read from the journal. There is no mode of operation for journald that does not have the journal, on disc or in a memory filesystem. And journald itself is not optional. The only optional part is choosing to have an extra old-style syslog daemon that is using the journal as input.
They really aren't. It took us a full week of work to get dnsmasq to work in place of systemd-resolved. The problem is that they are tied in to the dhcp client and it only seems to know how to update systemd-resolved's configuration. So getting our custom search path out of dhcp was a huge pain.
I like almost every other part of systemd, but trying to excise systemd-resolved from Ubuntu 18.04 was massively frustrating to the point where I started thinking, "maybe the systemd haters are right…"
The success of systemd is in that it solves problems for distros that none other was solving (or even looking other way). If you want to successfully replace it, you have to solve the same problems, and do it better, so it would be worth replacing systemd.
And because none other was doing it, you would have to write solution that does that. Slapping some bash scripts together won't do it.
This is wholly and totally imaginary. Every part of system has an alternative because it is all solving existing problems that people have been solving for decades with a variety of tools.
The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.
Alternative doesn't mean 100% substitute both ways. The pre-systemd didn't go in their abstraction in the way, that systemd does - it is basically system-level, event handling machine. The events could be not only boot, but also hotplug, timer, socket connection or others, and their handling is configured by the system or admin in unified way, including unified way of adjusting system-supplied units. Other inits just ran scripts at some order the boot and that's it, ignoring, that something doesn't have to happen at boot, but at some other time.
That's one of the things, that systemd handles way better, than any suggested alternative. By ignoring where systemd is strong, you won't make the alternatives any better.
> The only actual challenge is replacing just part of systemd while retailing compatibility with the rest of it.
No. I don't see why we should have the Sisyphos task of maintaing sysv/cron/etc idiosyncrasies forever. Sometimes, it is better to get rid of the collected warts, and not limit the system to existing semantics.
On the contrary, that's exactly what systemd's predecessor, Upstart, did. systemd, in contrast, did not. Basing the system around the concept of events triggering things turned out to cause problems, as discussed by Lennart Poettering and by Debian Technical Committee members during the Debian Hoo-Hah as their reason for not choosing Upstart.
See http://0pointer.de/blog/projects/systemd.html, section "On Upstart". It names two big issues with HOW.
I meant, that systemd solves some category of problems, that other tools didn't solve, didn't intend to solve and didn't even care for what the problems are. For distribution maintainers, systemd was something to welcome, that did address their problems.
So yes, there is no replacement (the requirement for it being drop-in only places the bar higher), because there's nothing else that scratches the same itch.
This is an interesting claim, mind throwing some pointers?
and some other directives documented on the same page.
The timing of these systems releasing does not equate to causation here. Google themselves (creators of cgroups) do not even use systemd on their own hypervisors which leverage cgroups heavily.
> For example, using Docker when the basic isolation features of systemd would do
Then you should not be wanting to see applications including a hard dependency to systemD.
The problem is basically that Linux used to be about choice (choose your distro! choose your DE! choose your shell! choose your browser!) but now that it's become big business, large corporations like Red Hat (developer of systemd) have transformed the evolution of Linux from a bottom-up consensus system to a top-down "we develop all the stuff you use and now it all uses our stuff so now you do too" approach. It's _very_ hard for me to build a system without systemd; I can use a niche Linux distro, I can use a BSD, or I can hack another init system (etc.) in myself. None of those are satisfying, I think for obvious reasons.
systemd is not well written, and it is not well designed. Its style and architecture are inconsistent. Parsing is mixed with validation and business logic. The types of CVEs its generated show that there was no coherent thought put into input validation, fuzzing, taint analysis, and so on. The effects of those flaws (your whole system crashes, etc.) show that failure strategies were never considered. And if all that sounds like overkill to you, maybe it is! But I can tell you that these techniques and design strategies are employed by experts to build software that must be robust, like software that controls medical equipment or transportation control systems. We know how to build software that works and that mitigates failures. Looking at systemd's code, it's clear they used none of that knowledge. And that, combined with its sprawling control over my system, makes me not want it on my machines.
I'm not qualified to judge the quality of the code in systemd directly; I've browsed it a little but I am a middling C++ programmer and while it hasn't stood out to me as smelly I would defer to more knowledgeable heads. I get the drive for very rugged underpinnings, and I'm on board with that; in things that aren't C++ I frequently am the one with the scalpels making criticisms similar to yours, so that totally resonates with me. I am not, however, convinced that any of the alternatives that currently exist are materially better, so I kinda shrug a bit? Further, it seems to me that the generally modular nature of systemd (regardless of how coupled one believes those separate modules to be) suggests that a determined programmer could probably build a drop-in replacement--Rust? Where's my Rust Evangelization Strike Force?--that plays nicely with it and grows to replace poor and soft design.
The social aspect you bring up is, to me, the most compelling argument against systemd (because monocultures aren't great in general, etc.--I think most people agree on that). Thing is, though, I think that that bottom-up consensus model was doomed from the start. I don't think it was ever going to be tenable as soon as there's any money in it. Red Hat wants consistency, their stuff is going to have consistency, you can use it or go off-roading.
I don't think there's a great solution aside from "build your own ecosystem and don't let it get capitalism.txt'd to death." Which is a deeply unsatisfying and impractical answer. And to be clear, people who feel strongly about it should do that. I'm not being snarky when I say that. I'm a pragmatist--if it's better, I'll use it, too, and submit patches if needed and when I'm capable. ;)
I do, it's "if you run a big mainstream distro like Fedora or Debian, let your users swap out init systems". I know there have been debates on this, and I know the general consensus is "it's not worth the trouble / it's not as simple as just swapping out something like systemd". My counter arguments are: there are distros that are doing it, so it doesn't seem like it's that bad after all, and when dealing with something as important as PID 1 (or your libc, or your filesystem) we should be conservative and let users swap things back when making a huge change.
The other thing that jumps out at me is just that this hypothetical is mostly kicking the can down the road. If Fedora suddenly decided to support multiple init systems I think it's hard to envision a future where the happy path wouldn't remain systemd; it's what the core folks think is best, otherwise they wouldn't use it now, and even with additional support the lion's share of attention would go to that happy path. To that end I think that any sort of init choice in those distros just becomes "so we'll support it for now, but the set of third party stuff that supports it is going to continue to shrink, so I hope you have an off-ramp in the future."
Between these two issues it seems like separate distros that have a firm commitment to not-systemd end up being necessary anyway and an ecosystem of not-systemd stuff will need to compete for value on those merits. What am I missing?
I never said it is.
What I said is that if someone values diversity of software, then they should object to applications including a hard dependency on systemD. That's just logical, as including hard dependencies on systemD reduces software diversity by requiring that the system it runs on uses systemD rather than allowing them the choice.
Basically systemd has nothing like a dockerfile, that's not what it's for.
I think there's a good argument though that Docker should be retargetting its encapsulation work to a lower level OS primitive where possible (which would be systemd on linux) instead of rolling its own.
I quite like systemd-nspawn too, though.
I’m not arguing that this is worth the overhead, or even a useful feature in practice (most companies and products tend to pick one environment and stick to it), but one that comes to mind that systemd would likely never have.
The naming in Windows and Mac, along with the limitations of the Desktop implementation are also frustrating. Don't get me wrong, I really like Docker as an orchestration base, I just don't think the cross-platform support is a value add in practice and in fact detracts as a whole imho.
BSDCan 2018—Benno Rice: The Tragedy of systemd
"systemd is, to put it mildly, controversial. Depending on who you ask it's either a complete violation of the UNIX philosophy, a bloated pile of bugs, a complete violation of the elegant simplicity it replaced or, it most cases, some or all of the above. So why have so many Linux distributions taken to it? Is it as bad as people say?
He's from the BSD world, so his POV is as an (mostly) outsider.
Systemd was criticizes right from the start for the same things that it is criticized now. No misunderstanding. No bad timing. No tragedy present.
> People don't like change
Wrong! People love change if it is an improvement. People don't like change if things get worse.
> Services, System configuration, daemons, etc are separate distinct things and need distinct C code to be managed
Nope. They are essentially the same thing and should be dealt with by small scripts.
> It does not really violate the Unix philosophy
Nobody really knows what "Unix philosophy" actually is. Therefore it does not matter if it gets "violated". However systemd definitely violates my and many others taste for good software. It is bad taste.
> It's not bloated and monolithic because it's not one binary
The stupidest argument ever. If you have a lot of tightly interdependent binaries that don't make any sense to exist outside of systemd you have a monolithic system were simple nuclear parts are not replaceable with alternatives. Besides from that: Its f*in bloated as hell.
> It's not as buggy as people claim
It is. Besides, the real problem is not the number of bugs, the prolem is getting rid of bugs. Recompiling C code just to get your init working is really a world of nightmares.
> People don't like systemd because they don't like Lennard Poettering
Most only care about technology and systemd is bad technology. Nobody cares about Poettering.
> UNIX is dead
Hearing that coming from a FreeBSD developer? Do his BSD buddy's agree? Why doesn't he switch to Windows? Sounds like conman to me. Remind me to never install FreeBSD.
A big part of what made Linux great are the things that were borrowed from Unix and Plan9.
To make it short: The dude loves change and he wants FreeBSD to go in the direction of what Windows is today. I love change and I want Linux to go into the direction of Plan9.
I'm not sure the presenter is condescending enough. Maybe he should have given an abbreviated history of Unix as well, oh wait, he did that.
Notepad.exe is also an alternative to Word, if the subset of functionality you're looking at is strictly text input.
It's like arguing that KDE or Gnome shouldn't exist as options... nobody removed anyone's options. Don't like it, fork it.
That said, to me systemd has been a large improvement. Maybe it has its problems, but at least there is consistency in handling services and logs between Linux distributions, which is a big improvement over a bunch of homegrown sysvinit derivatives, Upstart, and homegrown non-sysvinit scripts.
It's not comprehensive - in Guix there are services that exist above and below Shepherd and you can't define ordering dependencies between these (ex: a shepherd service can't depend on a mount (above shepherd), or an inetd service (below shepherd) on a database). I'm not sure that's a huge problem in practice.
Shepherd process stdout/stderr are sent to syslog. Shepherd automatically restarts services if they fail but not forever, and the retry behavior isn't configurable ATM.
Guix is for you if you want to run old software on a discontinued software stack simultaneously with a modern system.
The big wins for me though are: having all my system configuration in a small set of versionable text files (rather than gigabytes of mutable state), and being able to attach dependencies to the scripts that require them rather than to the system they're expected to be run on.
(I use NixOS, but it's the same concept)
The big thing, for me, that systemd brings to the table is consistency. Managing services on CentOS is the same as managing them on Debian which is the same as managing them on OpenSUSE. This makes it a lot easier to deal with the various different Linuxes.
Also, it seems to make writing a service a lot easier. Instead of the service needing to daemonize, write out a PID file, or whatever, it can just be a program that does its thing without forking, sends its output to stdout/stderr and systemd takes care of the details. I tried to go through this exercise on a FreeBSD system and ended up just installing 'pm2' to do it for me. I subsequently figured out what I did wrong, but pm2 is working and I see no need to change it.
Obviously systemd isn't suited for every use-case, but it doesn't seem nearly as bad as some people make it out to be.
It's not really the same, some systemd-based distros diverge a lot and anything non-systemd much more so, including FreeBSD. Even something as basic as network configuration could be completely different on systemd distros, like Ubuntu with its netplan weirdness and Archlinux going into the opposite direction and forcing you to choose how to deal with network yourself from the start.
But still, if you want any sanity in your deployment across different distros - you simply have to avoid using systemd or other host's init and service management systems for anything and bring your own service management with you. It could be as simple as a script starting from root's cron at @reboot (this particular trick survived for decades for example).
This might be true for your in-house app but if you want sanity in packaging your service for inclusion in various distros you include a .service file.
Networking is a little out of scope here - I'd guess that changing basic network configuration is something that's less frequent than the service management tasks.
What I _do not_ like are:
- systemd taking over disk mounts
- unit files spread out all over the place
- mandatory journald
- mandatory dbus
- only works on Linux
- pushing the BSDs farther towards being obsolete
This happens every time you significantly change something that people use and have existing workflows for, regardless of whether your change is beneficial on the whole.
Then one day several years ago I did an apt-get dist-upgrade and my system didn't boot after that. I have personally hit way more issues with unbootable systems or having to drop into single user mode to fix some BS with systemd. That was enough to make me dislike it, or convert into a hater, and switch most of my personal usage away from Linux.
I think it's gotten better since then. I still dread updating Linux boxes, because I know that some percentage of those updates will have a systemd bug introduced resulting in a non-bootable system or one where I have to manually fix it up.
I remember being absolutely floored when after that relatively complex procedure, not only did the system boot, but it booted faster. I think I became a fan that day.
What group is that?
It's a shame that a lot of core values are lost in favor of these viewpoints.
If you prefer an alternative or forebear to systemd, that is great. Use it. Advocate for the system you prefer. Convince people that the choice you have made is better.
Meanwhile the vast majority of distributions have voluntarily chosen systemd. Perhaps if its critics reflect on the reality of that shift, they could look at ways to improve the alternative to address its perceived deficiencies—just as GCC started doing now that LLVM has taken a bite out of their dominance.
As someone who really wanted the BSDs to get more credit ~20 years back, and spent a fair amount of time on various commercial Unixes as well, I find that phrase rather amusing. Historically poor standardization of the userland aside, GNU/Linux is the poster child for monoculture in Unix, and has left a whole lot of dead or dying software in its wake.
This is worrisome to me, because, while GNU/Linux is FOSS, "free and open source" doesn't actually mean "unfettered". A small number of large corporations such as IBM and Google have an outsize amount of influence. Doubly so now that IBM owns Red Hat. And, as the whole GNOME/systemd thing demonstrates, even the non-corporate entities have a lot of opportunity and incentive to engage in rent-seeking behavior now that things have been whittled down to such a tight software monoculture. They'd presumably not have even attempted such a thing as taking a hard dependency on systemd if maintaining decent compatibility with FreeBSD (or any other OS) were still a relevant priority.
Systemd and Docker do entrench the monoculture, but they can only have that effect because the monoculture is already so well-established. If this were EEE, they'd be part of the transition to the third E.
So open source is full of apparent forced goupthink and all or nothing half solutions, at least in the corporate world.
There's home and hobby and personal business systems that are really slick using the lesser known packages and things like "I forked this BSD kernel years ago and twiddled it since". We hear about them sometimes in news stories about "Airport HVAC system found to have been running on C64 for 19 years." Perhaps it inaccurate to say its 'dead or dying' software, until it's no longer appropriate for those use cases where we never even notice its still running.
1 - https://www.youtube.com/watch?v=o_AIw9bGogo
And a  that systemd is large enough to warrant being called a monoculture in the first place—and to flip the coin, that GNU init is small enough to not be a monoculture.
Let's not forget a huge  that the addition of another alternative into the marketplace of ideas could ever be described as monoculture.
And while we're at it, how about a big juicy  that a monoculture is a bad thing anyway, in this instance?
It's worth realising that the GNU project could never have happened in the first place - Linux could never have been a thing - if historical Unix had been designed like systemd.
It's all open source.
It's laughable to worry about Gnome taking a hard dependency on an API when hundreds of software programs take a hard dependency on Gnome. Hypocrisy, much?
Meanwhile if the maintainers of GNOME betray your trust, it sounds like you should hate this hypothetical GNOME for the same reasons you apparently hate systemd. Or rather than hating it, you could just fork it. If enough people agree with you, a disentangled fork will inevitably be maintained. Hell, people maintain forks of GNOME for BSD—and that's even more impressive since there is no open source monoculture more monolithic than the Linux kernel API dependency.
You could quite possibly be right that the open source movement couldn't have have started with the design principles of systemd but it's naive to assume that what was good for open source in its infancy is still what's best for open source in its coming maturity.
 Given that the open source movement has monumentally benefited from monolithic design principles in the form of the Linux kernel, I think that hypothesis is demonstrably absurd and easily rejected.
And then they move on to the next project and introduce a hard-dependency on systemd there. RedHat has more programmers than me, they're always going to be able to add systemd dependencies faster than I can fork things. The only way users will ever be able to have a choice of init system is if the community can agree that hard-depending on systemd is indeed a betrayal, and publicise this.
> it's naive to assume that what was good for open source in its infancy is still what's best for open source in its coming maturity.
Open source succeeded because it was easy to improve and replace things piecemeal. That's still as important as ever.
>  Given that the open source movement has monumentally benefited from monolithic design principles in the form of the Linux kernel, I think that hypothesis is demonstrably absurd and easily rejected.
Linux has suffered from its monolithic approach to kernel-space development, but the damage was mitigated by an extreme commitment to providing a solid API to userspace that never gets broken. So most progress took place in userspace and wasn't affected. There's no analogous boundary for systemd.
Linux-the-kernel was largely just in the right place at the right time, but to the extent that it had development advantages they were an openness to contributions and the absence of an imposed top-down design.
> Open source has succeeded because it was easy to improve and replace things piecemeal. But deciding that the individual pieces must begin and end at the process level is blinkered. You can perform "piecemeal improvements" to the scheduling component in systemd just as easily as you can to, say, cron.
You can submit changes and improvements to a given cron implementation. But if there's a really hard tradeoff or a disagreement, you can also fork off your own cron implementation, and in fact there are three or four different cron implementations in common use on linux. This is really important and not just in the cases where a fork actually occurs: the possibility of a fork encourages maintainers to be reasonable and come to a consensus.
Systemd's tightly coupled design makes that impossible - it's not about process boundaries but about having any kind of boundary where there's a stable interface between different components. E.g. reasonable people can disagree over whether the advantages of a binary logging format outweigh the disadvantages. But the systemd maintainers have taken a particular position, and, crucially, people who disagree can't just fork the logging component and swap it out for their piece, because there's no stable interface between that and the rest of the system.
Suggesting that you can fork cron and you can't fork systemd is patently absurd.
You say that "people who disagree can't just fork the logging component and swap it out for their piece" when in reality you really can. Getting systemd to output text logs is trivial, just point it to syslogd instead of journalctl. It sounds like you weren't aware of that. So much for being a tightly coupled design.
Am I supposed to take that seriously? The Linux kernel wasn't a top-down design? Do you remember the Linux kernel? Do you know who Linus Torvalds is?
Soon to be IBM, darling child of precisely nobody on HN. I think a lot of people are still in denial over this acquisition.
Ask RMS what he thinks about SystemD and I bet you he'll shrug and say it's fine because it's Free, and that's all he really cares about. Needless to say, most people have a greater diversity of concerns.
See, I think that's where you differ from most people. To most people, I believe open source is a means to an end, not an end unto itself. What they want first and foremost is something that works, and it happens to be the case that having the source code freely available facilitates having something that works and gives them a sense of comfort, an assurance, that it will continue to work in the foreseeable future. So appealing to "it's opensource, so you should like it" totally misses the mark. The argument should be "it works, therefore you should like it."
Had SystemD never given anybody any trouble, I don't think it would be hated. I think SystemD is hated because (particularly during early adoption years) there were a lot of things about it that didn't work for a lot of people. This made them angry, because it violated what they actually cared about. Not permissive licensing, but rather having something that works. The principle of open source is not axiomatic to most people; it only has value when it is part of having something that works.
Somewhere else I see this mentality: Android. There are a few among the 'community' who would have me pop open the champagne because "Linux won" on account of Android being an incredible commercial success. But why should I celebrate that? Why is "number of CPUs running Linux" the metric I should be glued to? Because Linux is open source? So what? Honestly, who gives a damn?
(Hopefully that makes my aggressive indifference to Stallman more comprehensible.)
It's Debian violating their social contract that was the problem for me.
What the vast majority of distributions do is irrelevant, a lot of them are chasing popularity or have a proprietary interest in having a "unified platform", but I had come to expect better from Debian. There is really no longer a "reality of that shift" to reflect on, since the SystemD problem has been more or less fixed: there are now debian-based distributions to upgrade to. If other people want to run that dumpsterfire of cowboycode on their computers, that's fine by me.
Which clause of the social contract did Debian violate?
Debian ranked SystemD adoption over their users, since it broke users' computers, even though there were viable alternatives available that would have not broken these systems.
I still like Debian, but I'm not letting them (directly) near my systems again.