You can also read The problem with the anti systemd attitude.
This is not just hatred towards systemd, it can do things very well, the direction it is going isn’t great.
Linux is the second-most popular descendent of Unix, the first being OSX.
This ruffles my feathers. Disregarding servers where Linux has near monopoly, surely Linux is installed on more devices and has more users than OSX? OP is clearly counting only desktop users
Linux is the second-most popular descendent of Unix, the first being OSX.
Linux is not really a descendant of Unix. It is a Unix clone, but its roots do not trace back to Unix.
It might not be to your liking or follow your philosophical inclination, but systemd doesn’t suck at all.
It’s great software developed by talented people behind it. I’m grateful it exists and makes computing on linux better.
Definitely a very good post.
It reminds me of Chimera Linux’s stance on systemd, which I found to be the best explanation on systemd before these blog posts.
This is by far the most nuanced critique of systemd I’ve ever seen. I don’t fully agree with its conclusions personally, but I think it makes a lot of good and valid points about its architecture and its flaws. It feels like such a breath for fresh air in comparison to the most vocal anti-systemd types who vaguely and angrily gesture at “scope creep” and refuse to elaborate further.
This is by far the most nuanced critique of systemd I’ve ever seen.
It’s the same bullshit everyone has always bitched about.
Loosely yes, but I rarely see anyone expound on it beyond “It’s bloated and therefore bad”. I also rarely see specific criticisms outside of that like
journalctlbeing slow or using a binary format for log files.90% of his argument is just “UnIx PhIlOsOpHy” though. Or arguments (term used loosely) that are based on that. He keeps chanting “But systemd Is MoNoLiThIc” over and over as if that ended the discussion while handwaving away the same argument against Linux or Wayland. But somehow systemd is different. Systemd needs to be crap for some reason.
It turns out that system boot benefits from tightly integrated steps. Filesystem mounting can depend on network availability for example. Logging depends on filesystems to be mounted. The sub-systems are naturally inter-dependent. And service management and execution needs to know about all those things. Some services need networking, some need file systems, etc.
You match the design to the problem. You don’t pretend like the Unix Philosophy is some gold standard that everything must adhere to.
Except that the author does not end the discussion at “it doesn’t follow the Unix philosophy.” Granted, they do spend a number of words refuting the argument that systemd is modular; whether or not it’s a strawman, it sounds like you already agree with the author on that point. While they do pay some lip service to the value of the Unix Philosophy, their arguement hardly ends there.
From the article, (bold emphasis mine):
This lack of modularity – where “modularity” means free choice in interchanging components for other, unrelated projects – is where most of the criticism of systemd stems. It’s the purest, and most important, criticism of systemd, but my personal grievances against systemd go further. Because, in my experience, systemd isn’t good software.
The author provides evidence for that claim with examples regarding journald, networkd, and session keyrings. None of those criticisms are specific to the Unix Philosophy. Their whole point appears to be “yes, I value software that follows the Unix Philosophy, and systemd does not, but I believe there are many other valid reasons that systemd isn’t good.”
Of course these concerns play into each other, but the nuance there is kinda the whole point. The author points out that it would be a lot easier to use only the good parts if systemd had a more genuinely modular architecture, but it’s simply not built for that. And it’s a real and material example of a negative consequence of not following the Unix Philosophy. Rather than say “it’s not developed with the UP in mind, it must therefore be bad,” the author gives a tangible example representative of why they believe that to be important.
Just as the Unix Philosophy is a thought-terminating cliché (because of course it is), it is similarly unhelpful to claim that consolidation brings performance and cross-cutting capabilities. The proof is in the pudding, and as critical readers we should not overlook valuable perspectives like the one the author has brought.
(Not that it’s critical to your point, but we’re you trying to argue that Wayland is monolithic? I have to assume you didn’t mean it like that, since it’s a protocol that decouples clients and compositors, and it’s certainly not monolithic in that sense)
Not that it’s critical to your point, but we’re you trying to argue that Wayland is monolithic?
No - but that it’s monolithic in a similar way that systemd is. Modular but integrated. The author seems to reject this form of modularity as a violation of “the code”.
Did the author intentionally omit systemd-boot or am I missing something? The EFIStub part of it seems to be the only way to package a UKI. Void Linux even has a package with just the Sub for uses wanting to go that route.
I’ve seen a lot posts against systemd, most of them citing the unix principle as the main argument. But as a user on a desktop computer I don’t understand why would it be bad. Could someone explain it to me?
As a user you probably don’t know, and maybe don’t care.
This is more for developers, technology is not magic, vendor/technology-locking can be problematic. It’s not like systemd was made by bad people with bad intention. You may have heard of X11 too. The list could go on, there is a big amount of legacy in our technology, some would just keep it that way. But some argue for changes thus discussing (and criticizing) those legacy, why it fails on some points and what to do/build from that.
So right now if you’re a desktop user, I don’t see why you would bother indeed. This discussion are still interesting to some devs, for instance here I learned about dinit, and it’s code is damn small and clean, hence it was informative and I will definitely try it.
The Unix principle is the most over-rated design principle ever. It’s sole purpose is to be dragged out when somebody doesn’t like your application. Notably the systemd haters don’t levy the same complaint about Wayland…
It’s based on the idea of programs as “functions” that can be strung together like you often do with things like “cat /etc/passwd | grep user | tr ‘s/:/,/’” (cat put in there to trigger the right people). That’s a great philosophy for cli utilities. But it’s not universally applicable.
The goal is not to make things tiny but to make them “the right size.” You wouldn’t want to run 30 different applications to do what GIMP does and you shouldn’t have to.
And the idea of having dozens of viable replacements for different functions is not a Unix thing but pretty restricted to the Linux ecosystem. And it’s not like it was planned, it just happened because 12 people went out and wrote their own ntp daemons. There wasn’t really much benefit to it. “Oh boy, I can run a different ntpd… And half of them are partially implemented. Hooray?”
Listen, when I edit a video, the video editor literally just calls ffmpeg. They don’t implement the features that already exist. The Unix principle is real in GUI programs. I’m not typing the command line commands to edit my video by hand.
Neat.
Even if it is, the biggest problem is that there isn’t today a big distro that is not using it. Ubuntu, Fedora, OpenSuse, Arch, Debian, are all using systemd. One can say, you can try Void or Artix, Void repos are small, Artix is small (and kind of non-reliable) project. Or go to Gentoo and compile your applications, no ty.
Gentoo does support binary repos, I haven’t researched them in depth, but creating a binary-only child distribution should be very possible.
Except as you said - I don’t think is popular enough, I don’t know how comprehensive the current set of binary packages is.
But it should mostly be just a matter of actually precompiling everything with a reasonable config
There already are binary gentoo based distress.
Well if Void Linux is unpopular enough for it to be a problem, are the Gentoo-based ones better in that regard? Like, does it have comparable repositories to gentoo?
I haven’t read the whole article yet, but it bothers me how the author mistakenly calls the init (with the process id 1) pid 0, which is special and belongs to a part of the kernel.
Yeah, I noticed that too. At the end of the day, it’s not particularly important, but it is a bit of an embarassing mistake.
While I get the sentiment, isn’t the fact that systemd is broken into various components and you can use or choose not to use each part of it still within the unix philosophy? You can use the init system without using the rest. It just integrates well with the other components.
That argument is addressed in the article. With few practical exceptions, systemd components expect you to be running the other systemd services. E.g. running systemd without journald is not a supported usecase.
Not supported doesn’t mean it won’t work
Fair enough, but there’s a reason no one runs almost any of the systemd services in isolation. There’s a big difference between “takes a bit of tinkering” and “need to maintain massive patch files to make journald independent of systemd”
Yeah that’s fair. I will say that I’ve used distro’s that used systemd and journald, but not resolved, networkd, etc and it worked fine.
Every time someone posts about systemd I just paste in the link to the Tragedy of systemd video https://youtu.be/o_AIw9bGogo and move on
I’ve seen this talk before, but right at the beginning he links this blog-post which I didn’t read the last time: https://blog.aurynn.com/2015/12/16-contempt-culture
It’s worth linking here because it’s highly relevant to these kinds of discussions, and I like that he starts off his video acknowledging it.
“Soldier Found Deep In Jungle, Still Fighting For Extinct Empire!”
This guy was complaining in the blog post about how bloated systemd is because it uses 36MB of space and it could be done with ~6MB if you used different tooling.
If you’re the kind of user where 30MB of disk space genuinely matters either at scale or in some very niche edge case, then you’re also the kind of user who won’t have much trouble using an alternative init system or building/tuning your own.
Okay, I agree 30MB isn’t a big deal, but that’s not really an argument not to optimize. The entire Debian Stable mirror for example has like 70,000 packages in it. Let’s say all of those packages took the position that “A few extra MB doesn’t matter.” If each one had just 1 extra MB that is 70GB of extra bloat. If each one had 2 extra MB that is 140GB of extra bloat. If each one had 30MB of extra bloat that is 2.1TB of extra bloat. Now obviously thats a very unrealistic, and extreme, example, but the point is that with a super complex operating system things add up. We should appreciate the nit picky little dudes who yell over 30MB because they’re probably responsible in part for a good bit of cumulative extra disk space for the rest of us.
The article is full of dishonest nonsense. It compares file sizes without comparing features. Well, actually it’s blatantly lying by saying that the setups have the “same functionality” when they clearly do not. For example, systemd-homed supports encrypted home directories which is potentially a useful feature for shared PCs, but the non-systemd setup uses nothing for managing /home, so it takes 0 bytes. NetworkManager has a size of “N/A” apparently. It looks like there should be notes or citations but they’re missing. They’re archived here if you’re interested, but it’s just a bunch of upstream URLs; this doesn’t show us what the author is comparing.
The other related point is also nonsense:
We can evaluate the “systemd isn’t monolithic” claim based on how it’s packaged and distributed.
Well, no. We can evaluate how distros package systemd, not what systemd is or isn’t. The author uses Arch Linux to show that a systemd-based setup requires 36MB. But as the article itself states, arch linux puts every single binary into a single package. Not mentioned in the article is how Arch Linux also bundles other stuff most people don’t need in the packages, like header files, programming manual pages, completions for various shells, default configurations not part of systemd etc. Is the non-systemd setup done in the same way or is the author manually installing 6 executables and calling it “equivalent”? We can’t know because one the one side we have a real (worst-case) example of Arch Linux packaging systemd, and on the other side we have “to get the same functionality without systemd, a distribution could use”.
None of this illustrates any waste of space on the entire Debian Stable mirror if you’re worried about that. In fact the bundling of systemd component into a small number of packages saves space for Debian (though it potentially wastes space for your PC).
Ah okay. I was just taking issue with the idea that a few MB don’t matter. Thanks for expanding on your point. I’m very much pro-optimization got no real opinions on systemd tho.
