I get that not everybody likes systemd, but a lot of the criticisms seem misguided and looking at sysvinit with role-colored glasses.
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 [1] from the anti-systemd camp doesn't inspire confidence.
Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug.
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.
> 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.
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.
> they took an init system that was (mostly) written in a memory-safe language (bash) and rewrote it in a memory-unsafe language (C++)
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).
Memory safety is not the alpha and omega of programming languages. People do not write million lines of code applications in bash, for a reason, trade-offs are to be made.
That said I agree they should have picked Go instead /s.
Sure, there are other concerns and bash is not an ideal language, but memory safety is responsible for quite a large number of security flaws, since its lack turns bugs into code execution vulnerabilities on a regular basis.
I don't really have an opinion on what language should have been picked instead, though OCaml may be a good candidate.
I think I know what my next Erlang project's gonna be. Erlang-as-PID-1, here we come!
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.
> People do not write million lines of code applications in bash, for a reason, trade-offs are to be made.
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.
Those are all not million lines of code applications, but that only speaks in favor of a more traditional Unix userspace design. With modularity on the process level you don't need a million lines of code to herd services. Why an init system should a million lines of code is a mystery to me.
Ocaml parallelism/concurrency story was not that good - but Haskell has just got its fancy new epoll based I/O manager (100000+ lightweight threads) around that time, with the 7.0.1 release (16 November 2010)
They could have even take inspiration, imagine: typed, functional, monadic init files - "systemd: avoid success at all costs" :)
The topic is memory safety, not concurrency support, FWIW.
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).
That's nice in theory, but where are all the people who know Ocaml to write it and contribute to it ? I might be clueless but I can't really name any significant projects written in it, which might imply something about the number of people using it and being able to work on and contribute to something as large and important as systemd.
> Ocaml parallelism/concurrency story was not that good
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.
Rust would have been more appropriate. Something like SystemD at such a low level in terms of hardware and service management should not be done in a language with a garbage collector imho.
I understand that... Go still isn't an appropriate language for SystemD, also, when did SystemD really take hold? Lots of projects will shift underlying options with time.
The only thing that I can think of for that 2019 Go that would be a problem for this use case is binary size. None of the rest of the usual complaints would be stoppers or even that big a deal, and most of them, I'd pay to have a memory-safe language being used at that level. Init systems are a type of code that we don't have a good word for, but that I tend to end up in a lot, the code that isn't CPU intensive, or disk intensive, or RAM intensive, etc., but is all just logic and correctness rather than any of that. So "but Go is GC'ed!" isn't particularly relevant, for instance, because an init system pretty much ought to settle into a steady state and not be executing at all, on average, so who cares about a handful of microsecond GC pauses that may or may not occur at startup time?
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.
I understand there's a much more limited subset of developers for Rust or even Go vs. C/C++. Also, I recall hearing about Rust before systemd, but am not sure. Today, it would probably be my first choice. Not that go is a bad choice, I just don't think it's a good spot for it. I also agree that either are probably quite a bit better than C/C++ options.
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.
It doesn't execute low level code in terms of hardware. It's a init system, all it (should do) is create a dependency graph and initialize the services in the correct order.
Many init systems have been created in bash, and I'd hardly call that a low level language.
If you run or write that command into script without checking what DIR variable contains, the problem is in your lack of experience with shell, not the language choice. Also nowadays, rm itself has --preserve-root as default, so this won't delete your root fs.
By the same logic, if an app written in C has a security issue due to a null pointer or buffer overflow, the problem is clearly the coder's lack of experience with C.
Actually yes, because it is possible to write correct C, and because they could have chosen other language less conducive to those pitfalls. But your analogy doesn't hold, because in case of shell, the situation is different: the pitfalls are easy to avoid, and for unix admin tasks, there is no compelling alternative to shell.
This is true if you are running the GNU userland. It's not necessarily true with other userlands that are often run on top of Linux. In a discussion touching on systemd, it strikes me as a little surprising that somebody would rely on a quirk of another replaceable component. ;)
I’m sure the irony is not lost on you regarding the fact that systemd can not possibly run on an alternative platform, thus the situation you just ascribed is not “better” with systemd.
Sure. That wasn't in favor of systemd, though? I comfortably write code against the GNU userland and I use systemd where it crops up. Just not a big deal to me; if somebody wanted to use my stuff elsewhere I'd just say "pull requests welcome!". I found the inconsistency striking, that's all.
Checking for content of a variable before passing it to rm is a basic instinct that should be done in all shell scripts. The comment about --preserve-root is just a reminder that the problem of deleting / is very rare.
Not just -u - always <set -euo pipefail> unless you have a good reason. Fail on non-zero exit code outside of some special cases, undefined variables, and non-zero exit codes in a pipeline. And always use shellcheck, shellcheck is too good not to use tbh.
He is saying that Bash can also cause catastrophic behaviors by an as simple mistake as unsetting $DIR. C++ at least reject to compile when a variable is not set.
Any language can cause a catastrophic scenario like that. It's not a feature of the language. Not even the goal of the language to protect from something like rm -rf. The variable could have been set to empty string and C++ would just comply with what the programmer wrote (not what they meant, but that's a completely different thing).
> 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.
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!
I think that's valid enough. Not sure it rises to the level of "OMG they ignore bugs" implied by the original comment though. I mean... they took the patch and fixed the bug, right? Poettering was just being a jerk about whether it deserved a CVE.
(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.)
I think that's valid enough. Not sure it rises to the level of "OMG they ignore bugs" implied by the original comment though. I mean... they took the patch and fixed the bug, right? Poettering was just being a jerk about whether it deserved a CVE.
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?
This is always the case with any new software. Things may get a bit worse before they get better. Honestly Systemd addresses the complexities of a modern system in the simplest fashion but no simpler, and that is the key. It is in the same spirit as launchd on macOS. It works well overall and end up being more portable and consistent in the long run. Hatred for it seems to come mostly out of dogma, something to be avoided in this age.
> addresses the complexities of a modern system in the simplest fashion but no simpler
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).
Thing is, though, most of those things are different systems. systemd-logind systemd, systemd-udevd, and journald (and others) are different systems in the same project. They're a bit tied together (through dbus and I'm not sure what else), but that doesn't mean they're the same system.
> This is always the case with any new software. Things may get a bit worse before they get better.
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.
I'm not going to discuss the merits of portability or what "typical developers use". I'm questioning the idea that systemd is somehow more portable than its alternatives. That belief can only be rooted in plain ignorance of the actual situation. It has absolutely nothing to do with what typical developers use, and to that end your comment is a pointless derailment.
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.
> What I mean is that there are init systems that only require POSIX compliant APIs
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.
launchd doesn't break nohup. It doesn't have any opinions about processes started from shells. systemd does, which is completely inappropriate scope creep.
I agree with the systemd developers on this one. It's weird that processes started by users when their logged in by don't end when they log out unless they voluntarily terminate when sent a signal.
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.
If a process is interactive, it needs a way to be notified that its user is gone. That became a distributed system problem a while ago. PID 1 doesn't know whether an X client is active on a remote display, or a batch job is doing useful work.
dbus is also a dependency though. If you are on the bus (heh) that says systemd is a hard dependency that should be avoided then dbus is also the same thing.
I agree with your logical consistency, but I'm curious: is D-Bus sufficiently specified that one could write an alternative to it? That is, is it a hard dependency or is it itself an interface? I'm not nearly sufficiently experienced with desktop Linux application development to know. ;)
Yes, DBUS is specified [1]. There are multiple implementations shipping (dbus reference implementation and dbus-broker), as well as several different client libraries.
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.
IIRC at least part of the reason for sd-bus is the need for using D-Bus between parts of systemd during early boot when "normal" D-Bus is not yet up and running.
FreeBSD developers are actually looking at something like systemd themselves. The fact that systemd itself doesn't run on it is just the consequence of POSIX being inadequate for its implementation, since it relies on a bunch of Linux specific features, like cgroups etc.
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.
> FreeBSD developers are actually looking at something like systemd themselves
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.
> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug.
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.
> On the other side you have a even driven OS configuration and management engine
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.
You're really not refuting anything here. Whatever bad situation existed with previous startup across, it doesn't excuse bad handling of issues in systemd. Whatever other projects do with CVEs, doesn't excuse Lennart complaining that CVEs should not be raised.
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.
> 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.
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.
At the end of the day it is the handling and haptics that count. So let me give you some anecdotical experience. A few weeks ago when the new Fedora came out i tried it as a live system from usb keychain, out of curiosity. It was the xfce live respin. Anyways, long story short, clicked around for a while, wasn't impressed much, shut it down. Flicker, flicker, the usual console messages scrolled by, and then it was stuck trying to unmount somesuch yadda yadda yarr yarr... for minutes. I wasn't in a hurry and waited, curious
WHAT would happen. Nothing, just finally powering off after 2,5 to 3 minutes. I sat there and wondered: could it really be THAT slow? Was my usb-stick slow? Nope. Tried another stick, another laptop, even some other respins. Always the same. Dumbstruck of the audacity of the so called leader in Linux i just thought to myself that they must be on crack or
some other bad stuff. Because when i tried a few other systemd-free live systems on the same sticks and hardware everything just whooshed by. Why is that? Are they living in
a parallel universe? Do i have outliers in terms of hardware? At least in one case i don't think so because it is a very well supported Thinkpad which accepts almost anything i can throw at it, and the other a similar HP Elite Book. So there is that. Now what?
> Most of the problem I have it is with the imperialistic culture that came with it and with the serious security bugs that they keep sweeping under the rug.
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.
When there was a problem with a sysvinit procedure, one could simply fix it. As a result, mostly nobody ever had a problem with it.
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.
> As a result, mostly nobody ever had a problem with it.
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.
> The people who prefer initv are the people who enjoy digging in other people’s (untestable) Bash scripts
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.
> When there was a problem with a sysvinit procedure, one could simply fix it. As a result, mostly nobody ever had a problem with it.
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.
> it's only because SysV init had so few features and so the actual patch had to go to one of many different upstreams
Yes.
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.
Systemd is a bunch of loosely coupled tools, though; it's not a monolith at all. PulseAudio was written by Lennart but isn't part of systemd. You don't have to use systemd's resolver. systemd-nspawn is a completely separate process and isn't required for systemd as a whole.
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
There are lots of variations on the UNIX philosophy [1], but two core points are to:
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.
Regarding the UNIX philosophy thing, it's worth noting that it is not automatically The Right Thing to stick by it at any cost. You could argue that UNIX itself does not use the philosophy when it's inconvenient, for example many UNIX-(like) kernels were/are monolithic, despite micro kernels with message passing akin to GNU Hurd embody the UNIX philosophy much better than the original UNIX kernel did(!)
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.
> for example many UNIX-(like) kernels were/are monolithic, despite micro kernels with message passing akin to GNU Hurd embody the UNIX philosophy much better than the original UNIX kernel did(!)
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.
Yup, seems you're right - journald appears to be the only mandatory non-PID1 process for systemd. Good to know. It also will forward happily to rsyslogd if that's your bag and then you never have to look at it, so I'm gonna just give a big ol' emoji shrug on this one.
D-Bus, as discussed elsewhere in this thread (where I learned about this, too), is a specification rather than a concrete implementation. Are you asserting that systemd does not work with alternative D-Bus implmentations? That would be weird, seeing as how they wrote an alternative one...
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.
Asking for clarification isn't a strawman, sorry. And it sure seemed like you were correcting me, which is why I asked. But I said that journald was the only mandatory component of systemd outside of PID1. You said this was wrong. I'm waiting for you to extrapolate? Does systemd only work with the "canonical" dbus-broker? Or does it want ("want" as I'm reading stuff that suggests it isn't absolutely required, but I'm not sure and I'm happy to caveat where I'm not sure) a D-Bus broker? Because if it's the latter, and as it's specified and they seem big on meeting specs I'm betting that it's the case, then what I said is correct and you're just being kind of a jerk about it.
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.
This is out of the line. You were given civil arguments for why systemd requires Dbus but in your response, you accuse the other person of being a jerk and "big-timeing". Please use the strongest interpretation of other people's claims on the topic, before using them as a means to accuse them of wrongdoing.
I am inviting the strengthening of his position in order to better understand it. I asked him to elaborate because as near as I can tell there is no hard dependency on any D-Bus broker. There is possibly--I genuinely can't tell from the documentation I've been browsing through--a dependency on a D-Bus broker. Requiring a D-Bus broker does not make any one D-Bus broker mandatory...and so, if that is the case, then my assertion that journald is the only non-PID1 part of systemd that is required would hold.
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?
That person is big-timing. Their tone ("you should read more" and so on) is in violation of the HN guidelines, filled with needless snark and condescension. The offending comment has been flagged by multiple users who agree that the comment doesn't meet community standards.
Perhaps the tone of JdeBP wasn't great, but they had a point. On the other hand, eropple's comment tone wasn't ideal either and they consistently miss the original point of systemd requiring dbus. Unfortunately, I am unable to check this since JdeBP post's have been censored.
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.
My gripe is bad UX. The whole system is needlessly obtuse and esoteric. Git is another popular thing with this problem, but in the case of git it provides so much value it's enough to get me to overcome its obtuseness. For systemd it's not "enough better" to get me to forgive it for being designed with no thought whatsoever to simplicity or ease of use.
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.
I strongly agree that git has a UX issue, and the widespread adoption of it over mercurial is a perfect example of inertia leading us to get stuck in a local minima.
I haven't tried hg but from what I've seen one major advantage of git that gets under-acknowledged is its speed. Git is fast and fast really does matter for a version control system you use constantly. Is hg as fast as git?
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:
Personally, I like pushing with hg, but I prefer pulling with git. An HgHub service at the scale of GitHub would probably result in massive end-user UX issues but maybe happier developers and repo administrators.
This reminds how pleasant it was to use hg as a git front-end (via an extention[0]) - compared to using the git cli. I think I'll have to revisit and see if that's still the case, and if I can make it work with feature branches etc.
Also looks like there's finally python3 support in the recent mercurial 5.0 release.
Git isn't really all that fast for what it is. The "git is fast" thing came about as a comparison to non-distributed version control systems, where changing what branch you were working on could involve coordinating with some (often overburdened) server on the other side of the planet.
That's not to say git is slow of course. It's just.. basically what you'd expect given it's architecture.
I like git's UX. Anything outside the typical flow is like walking into a garage filled with old stuff you thought you might need again some day, sifting through boxes of gadgets looking for that one thing you actually do need this time. Productive? Maybe not, but the experience is a much broader subject.
They probably do though, openrc defaults to sysvinit as its PID1.
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.
I don’t really have a strong opinion anymore. Scott makes the right move here for professionalism and modesty, and Linux is more united on this than it isn’t.
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.
I get that systemd works for you, and I'm not telling you (or others) that you shouldn't use it. The problem is the systemd monoculture. Wayland, Gnome etc are non-starters because they have hard dependencies on systemd, which is ridiculous.
> 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?
To start off with: Maybe I'm not on the same page, but your tone feels quite aggressive to me right now. I'm not telling you that you're wrong for choosing to use the software that you use. This isn't a flamewar, I'm not trying to tell you to do different things. I'm just explaining why the OP's criteria for an init manager don't apply to me.
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.[0] 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))[1] or install elogind. elogind is a Gentoo specific forked version of systemd with everything that is not logind-related removed.[2] 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.
Agreed, I very much like systemd. The documentation could be a bit better (though I haven't looked at it much in the last year), but overall it's a good improvement.
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.
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 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.
That's a valid concern, but it's worth noting that not every component systemd replaced, (ie consolekit), was actually being maintained, so arguably we're in a better situation now from that standpoint.
Isn't it now much more difficult to figure out if certain components are or are not maintained?
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?
sysvinit is easier to understand for me. It's just a bunch of shell scripts after all. So from the point of simplicity sysvinit wins for me and I never had much problems with it (while I had some problems with systemd). On the other hand, I recently had to write unit file for tomcat and it was extremely easy, systemd had all necessary options. Writing shell script was not that hard, of course, but it was some work.
One reason even big ol sysvinit is superior to systemd is that shell scripts are transitive knowledge. You can do almost everything with shell scripts. Learning some obscure (albeit very simple) systemd unit file format won't help you anywhere else besides systemd.
> One reason even big ol sysvinit is superior to systemd is that shell scripts are transitive knowledge.
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.
Actually I do.
systemd is too complicated for my needs, maybe it is usefull in some complicated system setups but for me (and probably others) it is too big, too complex and completely unneeded.
What was the problem with sysvinit that they tried to fix? I don't see any.
systemd was aimed at the problems with Upstart rather than the problems with van Smoorenburg rc. van Smooreburg rc had already been superseded for its creators. Fedora was using Upstart.
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.
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 [1] from the anti-systemd camp doesn't inspire confidence.
1 - https://lwn.net/Articles/786593