Boycott Systemd (2014)
web.archive.org
web.archive.org
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.
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.
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.
But I agree with your general view.
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"
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?
I think (but I'm not sure) that it's primarily used by Gnome and KDE.
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.
Anyway, all the complexities of using sockets/FIFOs could be hidden inside libraries.
> udev and dbus are forced dependencies.
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).
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.
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*
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?
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.
"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)
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.
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.
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).
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.
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.
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?
And it's obvious why a monopoly is bad.
The systemd monoculture is the same kind of bad as a Google Chrome monoculture.
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.
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
The init system has way more control of a machine than a browser.
Boycott systemd - https://news.ycombinator.com/item?id=7639170 - April 2014 (232 comments)
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.
You may be thinking of “male chauvinism”, which of course has nothing to do with “systemd chauvinism” (or “SysV chauvinism” for that matter).
The first stanza of the Wiktionary definition: > Chauvinism is the unreasonable belief in the superiority or dominance of one's own group or people ...
The systemd-timesyncd also causes undesirable behaviour
This shouldn’t affect systemd-initd except it does because of the name.
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.
> 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.
I laughed, but Adolf was Austrian.