Boycott Systemd (2014)
web.archive.orgPerhaps the issue with systemd is not technical superiority nor convenience, as many commenters routinely present it.
Perhaps the issue is actually user control.
Personally, I know that if I followed the philosophy of always picking the solutions that were the most technically superior, the easiest to use and/or the most convenient, I would have far less control over the computers I own. YMMV.
For the avoidance of doubt, the term "control" as used here refers to the ability of the user to control systemd and thereby control the computer, not the ability of systemd to control the computer. The later might be "technically superior" to prior alternatives.
Systemd doesn't remove any control, and in fact gives a lot of extra control over things like process dependencies, environment, etc. The big complaint people had/have really just boils down to someone moved the cheese--your bespoke and brittle startup scripts are now declarative config files. Some people had to learn something new and that _really_ angered them.
I don't care about a single one of those.
Computers exist to solve problems, not to be compliant with a particular philosophy. The appeals to Unix philosophy, dogma about how logs should be stored, etc, are all completely irrelevant to me. I don't run Linux because it fulfills an ideology but because it does a job.
Also, journald is actually extremely nice. Of all the complaints, I don't really get some people's love for text log files. They're an inferior technology, and rather silly when you think of it. For anything but the most trivial tasks, we have to parse them. Which means we're expending the effort to take some well structured inner state, often cut off a chunk of it (eg, remove milliseconds from timestamps), often convert it to a hard to machine read format (eg, human readable dates), and then proceed to try to reverse this process. This is nuts.
The “Unix philosophy” is a core part of the user interface to Unix systems. You might not care about this yourself, but I’d bet that most people do care about UI consistency.
Right now I'm looking at this in Firefox in KDE. I'm not sure what "one thing" either of those does. Neither deals with plain text in a terminal.
But if you want a comfortable commandline UI, I'd say journalctl does the job far better than grepping log files. And heck, it outputs text so you can still grep that if you really want to.
KDE, for one, is a big bag of specialized tools, built using a set of libraries that are also very modular.
But I agree with your general view.
For almost any arguments against systemd, you can replace "systemd" with "linux kernel" and it still will be a valid argument, yet I have not seen many opponents of linux kernel on these grounds.
As an example: monolith, single project, includes a lot of functionality that should be separate, invents conventions, crash takes down all system...
Yet nobody in my memory has gone "kernel includes JIT compiler, let us boycott"
The Systemd project largely follows the "Unix philosophy" anyway. Lots of sub-tools, each doing one thing well. It's a bit like complaining that the GNU coreutils don't follow the "Unix philosophy".
Can anybody explain to me what dbus is for, and why I sometimes have to start applications using "dbus-launch" because otherwise they can't connect to dbus. Or why sometimes when I login on other systems using "ssh -CY" I cannot even start applications like eog (eye of gnome) because dbus is in the way, but somehow mysteriously they DO start when I run them with "strace -f"?
Seems to me that Linux systems are starting to see the downsides of a microservices approach.
Edit: thanks for all the replies, yes, I get that dbus is for sending messages between applications, but what is wrong with e.g. UNIX domain sockets?
> Edit: thanks for all the replies, yes, I get that dbus is for sending messages between applications, but what is wrong with e.g. UNIX domain sockets?
I think the reason for dbus is that all of these processes want to talk to all the other ones, and they need to rendezvous somewhere. You probably don't want to open a unix socket for every 'topic' you want to respond to, and anyway if there's multiple programs interested in the topic, how do you make sure they all get all of the messages, if they all listen to the socket, only one gets the message.
For desktopy things, you could communicate through the X server, but some of the things you might want to communicate with are system daemons, not X applications. I don't know if Wayland provides a way for multiple clients to communicate? OTOH, dbus doesn't transit over the network, so eog on a remote host can't communicate with your desktop environment, so that's kind of a pain. Yet another capability lost overtime. grumblegrumble*
> if there's multiple programs interested in the topic, how do you make sure they all get all of the messages, if they all listen to the socket, only one gets the message.
Well, you could listen on a socket for subscribers ...
(Basically a decentralized approach vs a centralized approach)
> OTOH, dbus doesn't transit over the network, so eog on a remote host can't communicate with your desktop environment, so that's kind of a pain.
Yes, and what I find mysterious is that dbus was conceived by the freedesktop.org project. How could they have missed this important requirement?
> Well, you could listen on a socket for subscribers ... > (Basically a decentralized approach vs a centralized approach)
But who is going to listen on that socket for subscribers? When there's no owner of the resource, just some programs may want to send to it, and some may want to listen to it, you need someone to own all of that; and that's dbus, as I understand it.
> Yes, and what I find mysterious is that dbus was conceived by the freedesktop.org project. How could they have missed this important requirement?
My personal impression is that the freedesktop people have effectively abandoned network computing as X11 used to provide. Clearly, I haven't stepped up to do the work either, but both the single host / multiple user and single user / multiple host use cases are at best neglected, if not abandoned. It used to be feasible and useful to run a host with multiple X servers for multiple simultaneous users, and those sessions may have had a mix of local and remote X clients; but for various reasons, that doesn't work so well anymore.
Some of the lack of support is because addressing the full scope of everything is actually pretty hard. If you run networkmanager over remote X, which network is it expected to manage? If you have multiple users on a single machine with bluetooth and someone sends a file to the host, which user gets a notification?
That said, I think for many things where dbus fits, there's a connection to a graphical user session, and so IMHO, it would fit to coordinate in a way that all participants in the session could use, which for me would be through the X server (which already allows for communication between clients). And for things where it's really a connection to the host hardware, that should probably be through the host filesystem. And so some applications might need to connect to a message bus in both ways, and maybe sometimes tunneling --- an application may legitimately need to contact a system daemon on the host that controls the user's keyboard, but that might not be possible through X, or the host filesystem where the application is running. But that's super complex and weird, so it goes into the later pile, never to be solved.
Distributed RPC, i.e. dbus over the network, is an incredibly complex and still basically unsolved problem. To really do it right and guarantee correctness across systems (which may be in different states of working or failed!) you need a perfect message queue with exactly once delivery... but in practice implementing that is incredibly storage intensive (you'd have to store every message forever). You're basically asking for something as complex and difficult to run as kafka--it's not as simple as just send dbus messages over a network socket.
> Well, you could listen on a socket for subscribers ...
"I'm afraid to inform you that you have built a message bus with RPC features.
You had a program that needed to broadcast some information. You have built some simple mechanism using a UNIX socket. You send everything anytime someone connects to your socket and close the connection.
Then, your software grew and could provide various other things. It became impractical to send everything everytime so you needed some way to advertise what information your software provides, and receivers would send the list of what they need when they connect.
Your program grew again, and you needed people to be able to call your code to do some actions, so you added a way to call methods that can take parameters and to advertise them.
With the mess you ended up with, you felt the need to standardize how information and methods are represented and used. You designed a DSL to write schemas and some kind of code generator using this schema to automatically build interfaces for these methods and this exposed data.
You figured calling methods and requesting information through a UNIX socket directly is unwieldy, so you wrote a small library hiding this complexity to the caller and making everything more convenient to use.
Your program evolved again and you needed the callers to be able to receive events without having to poll. Your library now contains an event loop that the callers need to handle.
Your program kept evolving. Before the number of generated events and the performance issues it caused, you felt the need to add a mechanism to filter / subscribe to events to avoid flooding the callers.
Time passes, and your to had to write a new, unrelated program that also needed to communicate. You wanted to reuse the same mechanism. Callers needed to listen to multiple programs. Those multiple service providers could come and go and you noticed requiring callers to poll multiple UNIX paths to find out if there is a socket there was not practical nor efficient because of the syscalls and that it's better if they could tell some kind of daemon they are interested in a service and get informed when it becomes available. Therefore, you took the whole mechanism out of the first program and made it a daemon so callers had a central place to discover what is here, and providers to advertise themselves. This daemon of course needed to be run at system start, or at least in a lazy fashion, or the different actors would, again, need to do the UNIX socket path dance, which is not quite convenient after all.
Time passes again. In the bag of services you wrote, some are related to the system, and some are only relevant to a logged user. You wrote some kind of integration with your init system and your session manager.
I'm afraid you have built D-Bus."
In reference to the recent HN repost [1] of [2]
(edit: damned, I spent an hour writing this shit)
> "I'm afraid to inform you that you have built a message bus with RPC features.
No of course, not, I would use a shared object file to do it for me. I.e. all functionality inside a library instead of a centralized process that can crash or hang.
We were talking about bare UNIX sockets and their potential drawbacks. I think they don't really scale / answer to all the needs D-Bus fulfills.
Could you expand on your shared file idea? I'm interested. How do you implement this library without a central service? Note that in my humorous comment I still expose why I think a central program is necessary, now you can disagree with the use case of course.
It's quite simple, actually. There is no need for a central entity, just like computers on the internet do not need a central server to communicate. You might say that they need a DNS server, but the equivalent of that on a UNIX system would be the filesystem, where named sockets can live (or you could use X11 properties to communicate between desktop apps).
Anyway, I feel that all the microservices are making me lose control over my system (and systemd is quite literally the mother of all these microservices, hence why I bring it up here).
dbus is a sort-of standardised way for applications to communicate; generally used so that a service can make itself available to clients (e.g. battery status, bluetooth devices, plenty of other things that I don't happen to use).
Generally I only start it if an application won't work without it. Biggest issues for me (personally) is it's linux-specific and (unless I'm missing something) limited to the current host); otherwise it's client-agnostic sockets FTW.
"D-Bus provides a software-bus abstraction that gathers all the communications between a group of processes over a single shared virtual channel. Processes connected to a bus do not know how it is internally implemented, but D-Bus specification guarantees that all processes connected to the bus can communicate with each other through it." https://en.wikipedia.org/wiki/D-Bus
DBus is yet another message bus, but this time for a few desktop applications. Made famous by BlueZ's requirement of DBus and by it being the only Linux userspace thing that made it into Android before they completely rewrote the userspace stack for the phones.
A ton of "desktop linux" components will attempt to use DBus for inter-process communication because it's easier than a lot of the alternatives.
Eh, some of us would wonder what the easier alteratives are?
Unix domain sockets or FIFOs could be an alternative, but you'd have to do all kinds of complexity to support pub/sub style many to many communication over them (which is what dbus effectively does for you).
It depends if you are a fan of a centralized server vs decentralized communication.
Anyway, all the complexities of using sockets/FIFOs could be hidden inside libraries.
Once you hide the complexities of using sockets you just end up with some sort of message bus that each application connects to and registers an ID with... which is essentially what dbus is.
I specifically said libraries (as opposed to a centralized service).
dbus is a mechanism that allows different processes to communicate with each other.
I think (but I'm not sure) that it's primarily used by Gnome and KDE.
Dbus doesn't have anything to do with systemd FYI. It's a communication bus for processes to talk to each other through structured RPC messages.
From the article:
> udev and dbus are forced dependencies.
Not true (although maybe in the systemd world?). udev just populates /dev dynamically (rather than having to create all the /dev/ entries manually/via scripts).
Even udev is optional (upon upon a time, adding a new device involved knowing the right 'mknod' invocation in order to be able to connect to it - udev sort-of solves that).
Dbus isn't a systemd project any more than a libc is a systemd project. Systemd just requires it as a dependency. It's a freedesktop project.
It's from the same microservices ecosystem, and it was mentioned in the article. That's why I brought it up.
Yes systemd can use dbus, but plenty of non-systemd systems use and used dbus.
The whole argument about Systemd being counter to the Unix philosophy because it clusters a bunch of seemingly unrelated pieces of functionality(networking, device detection, process initialization, session management, power management, et. al) is not really applicable in my opinion.
All of the functionality on that list has two things in common that make them good candidates for Systemd: they all require programs to be started and stopped in response to state changes, and they all will require different programs to be started at initialization based on the initial state of the system. I was annoyed too when udev became systemd-udev and broke a few pieces of functionality I was relying on 15 years ago but if you're building a system around the Linux kernel it's a really useful toolkit if you have the resources to use it, because it does a ton of stuff for you.
Before Systemd I was having to write ifup/ifdown scripts and monkey with shell scripts in init.d and updating udev rules to control initialization, which was more Unixy but also riddled with edge cases. For example, there's nothing stopping ifup/ifdown scripts from running out of order with certain udev rules when you plug in a USB-to-Ethernet adapter without inventing your own ad-hoc synchronization mechanism. Systemd builds that same thing in and essentially makes it the default.
It's had some irritating teething problems, and I would also prefer some more interchangeability and some reduction in the amount of binary code, but I have a better experience with it than without it in the systems that I work with.
Related writeup: https://people.debian.org/~stapelberg/2013/06/09/systemd-blo....
That's from 2013 though.
You are right, I edited my post.
That piece is cited in the Reference section on the page under discussion.
Not sure why this is posted after 9 years. The page itself seems to have been hijacked by some scammy ad company, and one of the distros suggested as an alternative (CRUX) is still alive, but lacks mindshare.
From what I can see there's still a groundswell of anti-systemd sentiment, and there are distros that attempt to avoid it.
Edit I was mistaken about how active CRUX is, corrected.
CRUX is slightly more alive than that https://crux.nu/Main/News although yeah, other than rubbernecking at the past I'm not sure why this made it to the front page.
It's heartening to see the Luddites failed to stop progress on this occasion at least.
The "Luddites" were right about the monoculture becoming a problem, though.
I disagree with the Luddites designation.
That said, what problems do you see with the systemd monoculture? Well, I'm not sure it's a mono-culture neither, we still have different init systems, both in Linux distributions and in other operating systems, so let's say its widespread usage?
A monoculture means the same thing as a monopoly if that monoculture is in the hands of few people.
And it's obvious why a monopoly is bad.
The systemd monoculture is the same kind of bad as a Google Chrome monoculture.
> And it's obvious why a monopoly is bad.
No, it's not obvious.
- The Linux kernel is strictly more widespread as systemd, do you see this as a bad monopoly the same way?
- In Switzerland, trains are operated by one (public) company. That's a monopoly. The service is, however, fantastic. The same cannot be said as French trains, open to competition, operated by several entities. There are failures incurring delays all the time, making you miss connections. We were better off when they weren't and when it was a public monopoly.
Sometimes, monopolies are bad. I have a lot of arguments against the Chrome monopoly. I don't have any against systemd.
Since systemd has used its monopoly position to change the Linux kernel, and to force other things on distros, yes, their monopoly is bad.
Distros choose what they adopt. They willingly migrated to systemd. Ubuntu, of all distros with its in-house init system, upstart, followed Debian in this migration. They are not forced onto anything. Distro maintainers decided that systemd made their lives easier and switched to it. Or which actual, concrete things they were to do do you have in mind?
And yes, the Linux kernel has implemented features for systemd. It's obvious that in an healthy ecosystem, the init system and the kernel cooperate and both have influences between each over. What negative change did the Linux kernel have to implement because of systemd?
I'm quite sure systemd is not perfect, but I personally think it has dramatically improved my life as a Linux user. It has made my boot faster. It brought very convenient tools to instrument this boot to know what exactly takes time, or fails. It has made the logs incredibly easier to find and read. It has made writing services way easier. starting, stopping, disabling, enabling services is incredibly simple. It has replaced a mess with something clean and easy to user. I'm personally quite happy about some standardization over a solid software stack happening.
Upstart was already on this path and systemd further improved things.
I'm quite sure systemd has its flaws. I want to believe you on the fact it has bad aspects and even about the monoculture being bad but I can't because you haven't listed anything actually, concretely bad about systemd. What would you change in systemd?
The only concrete criticisms I've ever read about systemd are:
- it stores the log in binary format. Now, in almost 10 years I've dealt with it, on no occasion I've found it to be an issue.
- Projects like gnome depend on it. But it's a decision taken by those project, and if you want your OS to be coherent, of course the session manager or the desktop environment are going to need some kind of integration to the init system. If your system doesn't provide feature the DE needs, you'll have to provide it and build a shim, that seems actually fair enough. If your shim actually provides systemd compatibility, it could even be adopted upstream! See seatd/libseat [1].
- It is a monolith that wants to do everything. But I'm not sure it's actually true. Systemd actually provides many binaries, each with one, separate, purpose. I think that on the contrary, it is nothing like a monolith and it's more like the GNU tools, all under the same umbrella but each doing its own thing
They forced things after adoption.
What things? You never ever reply. It's like you don't like systemd without any actual, real reason. You just dislike it because.
This is only an abstract concern. It's the equivalent of NIMBYism.
Is it an abstract concern with Chrome?
The init system has way more control of a machine than a browser.
... are, are luddites known for their historic success rate?
Discussed at the time:
Boycott systemd - https://news.ycombinator.com/item?id=7639170 - April 2014 (232 comments)
Distributions that run without systemd: Gentoo, Guix, Alpine, VoidLinux...
>systemd's team is noticeably chauvinistic and anti-Unix
ONE OF THESE THINGS IS NOT LIKE THE OTHER, ONE OF THESE THINGS IS a serious allegation against the values of systemd's maintainers that is not backed up by anything in the text. Unless the writer just doesn't understand what "chauvinism" is beyond being a malword.
>systemd flies in the face of the Unix philosophy: "do one thing and do it well," representing a complex collection of dozens of binaries
>systemd clusters itself into PID 1 (...) This happens to be another example of SPOF.
PICK ONE! Either it's multiple binaries or everything's in PID1.
Also, the single-point-of-failure is not systemd's fault. Having a PID1 at all is the single point of failure. That being said, practically speaking there are loads of processes that will effectively crash your system if they fail. Does the user care (or even notice) if their system rebooted because systemd died, or because Wayland died and took the desktop session with it?
>Ultimately, systemd's parasitism is symbolic of something more than systemd itself. It shows a radical shift in thinking by the Linux community. Not necessarily a positive one, either. One that is vehemently postmodern, monolithic, heavily desktop-oriented, choice-limiting, isolationist, reinvents the flat tire, and is just anti-Unix in general.
By 2014 every relevant commercial UNIX-like was shipping the moral equivalent of systemd's all-encompassing setup. systemd clones modern UNIX in the same way GNU clones classical UNIX, because systemd does all the basic system maintenance tasks that people expect out of a modern desktop.
I'm not sure if "postmodern" is being used in the sense of "I can't figure this out" or "they put critical race theory in my userland". Perhaps this is me talking without the necessary historical perspective, but Mark Shuttlesworth's quip about the "Open Source Tea Party" comes to mind here.
If you're referring to the word "chauvinism" as a synonym for "male chauvinism": This is the common connotation, and the default understanding of the word. However, the dictionary definition of chauvinism isn't "male chauvinism," and it can be understood to mean something else in certain contexts (I argue such as this one).
The first stanza of the Wiktionary definition: > Chauvinism is the unreasonable belief in the superiority or dominance of one's own group or people ...
Nothing really backups the systemd maintainers displaying the dictionary definition either.
“Chauvinism” just means being prejudiced towards one’s own group. Chauvin was a 19th century French fictional character who was excessively patriotic.
You may be thinking of “male chauvinism”, which of course has nothing to do with “systemd chauvinism” (or “SysV chauvinism” for that matter).
I think the biggest flaw of systemd was "political" in grouping too many different tools under the single project name.
Yeah, that's why everyone hates the GNU project, and Freedesktop.org!
It's not comparable. You don't install either. Nobody assumes you get every GNU project when you install one because its name coincides with the organization as a whole, because neither put themselves in the situation of creating that kind of confusion.
Quite. Systemd-resolved breaks dns a lot by default, leaves a pasty taste in my mouth.
The systemd-timesyncd also causes undesirable behaviour
This shouldn’t affect systemd-initd except it does because of the name.
Summary of the points: and what they mean.
1. Systemd's Complexity and Scope: The increased complexity allows for better integration and coordination of system components.
2. Journal Files in Binary Format: The binary format improves performance and allows for richer metadata storage.
3. Systemd's Team Being Anti-Unix: The tight integration with the Linux kernel API optimizes the use of Linux-specific features.
4. Forced Dependencies on udev and dbus: The integration of udev and systemd provides more streamlined and coordinated system management.
5. Saving Core Dumps to the Journal: Storing core dumps in the journal makes it easier to correlate system logs with crashes.
6. Systemd as a Single Point of Failure: Proper maintenance and security practices can mitigate the risks associated with any critical software component.
7. Systemd's Viral Nature: The adoption of systemd by major projects like GNOME can be seen as the natural evolution of the ecosystem around a dominant technology.
8. Systemd Clustering into PID 1: The role of systemd as PID 1 represents a trade-off between integration and risk.
9. Designing Systemd with glibc in Mind: The tight coupling with glibc is a pragmatic choice to optimize for the most commonly used C library in the Linux ecosystem.
10. Systemd's Complexity Hinders Extensibility: More features and integrated behavior in systemd naturally lead to increased complexity.
11. Systemd's Symbolic Shift in Linux Community: The shift towards a more integrated and monolithic approach represents a change in the Linux community's direction.
I'm not a systemd hater by any means, but I think you're presenting some of these in bad faith.
> Systemd as a Single Point of Failure: Proper maintenance and security practices can mitigate the risks associated with any critical software component.
"Proper" meaning very expensive and very complex that only a limited number of sysadmins can do? Likely involving expensive virtualization and/or redundnacy technologies? Going down a never-ending rabbit hole that pays a lot of consultants or corporations trapping you with vendor lock-in?
> Systemd's Viral Nature: The adoption of systemd by major projects like GNOME can be seen as the natural evolution of the ecosystem around a dominant technology.
This is naive take. It should be seen as what it is: systemd and Gnome are both Red Hat products (no matter what anyone says, Gnome is Red Hat's desktop), and RH leaders mandating that Gnome depend on systemd in order to ram through systemd's adoption in the same way Microsoft did IE.
There's also a small chance it was a typical Lennart Poettering "fuck you, what are you gonna do about it?" act of pure contempt for what anyone else thinks. That guy has got to be the most hated German since Adolf.
> There's also a small chance it was a typical Lennart Poettering "fuck you, what are you gonna do about it?" act of pure contempt for what anyone else thinks. That guy has got to be the most hated German since Adolf.
I laughed, but Adolf was Austrian.