I wouldn’t call it a success it all. Almost managed to do was moving or forcing other software to get locked in. GDM, Podman, Pipewire…just to name a few.
Gnome is pretty guilty of adding hard dependencies on systemd, but podman and pipewire have worked fine for me without systemd... Not aware of any tight integration there that is mandatory (obviously quadlets, but you don't have to use that feature)
I've worked as a sysadmin/devops for a double digit number of years.
Across companies, jobs, and hobbyist collaborators - I've never met someone who didn't at least like systemd, if not sing its praises. It made so many incredibly painful things about Linux administration disappear.
E.g. logging, now that there is journald, you have to pay attention to another hop in your logging chain and take care of journald in addition to rsyslogd.
Boot and shutdown has previously been deterministic, now things just randomly hang. You do the "windows solution", reboot again, now it magically works through the power of race conditions that are inherent in systemd's mode of operations.
Network device naming is also a fun one. Remember how systemd was supposed to do away with the inconsistency and mess that is "eth0, eth1, eth2, eth..."? Well, now you get either eth0, or ens123, or enp17s7f9, or enx8b220b34. Each distro does it differently, so put in a live-CD to debug something and your network devices are suddenly weird. Reinstall to another version, suddenly weird again. Btw, the issue that names could change depending on boot order was already fixed by udev before, consistent-net.rules nailed it to a mac address on first boot. So systemd took a situation that was already fixed and better than before, and made it far far worse.
Oh, and all the fun that is systemd-dbus, policykit, systemd-logind and permissions on those. Because you always wanted a Javascript interpreter and libxml to tell who could be root on your system... And tons of confused deputy exploits on that cloud of confused systemd-subdaemons.
I'll grant that service files were a nice idea. But beyond that, it has been a very mixed bag, and in places a desaster.
I used to be fine with it, until I started writing my own software tools, then looking at how to actually do stuff with systemd and I'm like, nope nope nope nope. At some point when I have space for a new project I'm going to migrate from Arch to Obarun, which uses a modern update on the excellent daemontools to provide init. When systemd works it's mostly fine, when it breaks, path of least resistance is often to reinstall the OS. Which is fine if you're just working on it. Painful if it's your personal machine, and those are what's most likely to break systemd.
Does anyone actually use journald? The last time I tried(2 years ago?) it didn't even work with any log management software (like cloudwatch for example).
You had to either use some (often abandoned) third party tool or defeat the purpose by just reconfiguring everything to dump a text log to a file.
I personally love the init/service/unit-file portion of systemd and have few complaints. It has a lot of powerful features for security, cron, etc that are very simple to use. I also really like journald.
The parts I don’t really like are the half baked “ancillary” managers like resolvd, which are frankly baffling to use and tend to make simple things needlessly difficult.
I've been a fan of systemd even if just for how much simpler creating services is. I just need to write a simple config file instead of a complex init script.
Hi, author here. The title is intentionally a little attention-grabbing hyperbole but I've appreciated the discussion and feedback about the post. Thanks for reading!
No, it's terrible. I think what they mean by "success" here is that it functions, and is easier to use and more sturdy than init scripts. But any number of things would have been better than those. Instead of writing and adopting one or more, Linux allowed Redhat to take over the last piece of itself, its spine, after which Redhat sold itself to IBM. Linux is an IBM product.
They basically mediate all Linux access to the hardware, and can add arbitrary dependencies to the system at will. They could decide that we're all going to use leftpad now.
Cutting off my hand to get rid of that cancerous mole might have saved my life, but I wish you had just cut off the mole.
> The unix philosophy cries out: is this the end of Linux (or, as many are calling it, GNU plus Linux)?
I still see no counterarguments here. Meanwhile, systemd, like cancer, is eating Linux from the inside, breaking its flexibility and therefore future resilence:
I don't hate journald because it's not plaintext, I hate it because it's worse than plaintext.
Somehow journald manages to provide a database which is 40x slower to query than running grep on a compressed text file.
I'm all in favour of storing logs in an indexed structured format but journald ain't it.
systemd has been a success for 2 groups, Windows admins and Fortune 500 Companies.
For UN*X people, all it does is move Linux closer to emulating Microsoft Windows. It has left the UN*X philosophy behind. With secure boot and once Wayland becomes a real thing, the last step is in place. All that will be needed to become a M/S Windows Clone is geo-location and full DRM. That means you will only be able to take screen prints of "approved" applications. I heard SUSE may enable a kind of geo-location, not sure if I read that article correctly though.
For now, at least there are the *BSDs, they allow me to make a PC work the way I want it to, not a way Fortune 500 Companies dictate it should work.
I was pro-systemd at the time of the controversial discussions. I still think it's a net positive relative to what was there before. But personally speaking, it's only the core of the software (service management) that improved things for me. The other things (timers, journald) I either ignore or don't like, but perhaps they're useful for distributions.
> i used to think that systemd was made the default and adopted by most distros because of its ease of use and the fact it supplied a whole bunch of things in one suite and i see where the appeal is in that but after switching to artix openrc, im just lost on why they decided to use systemd when openrc is objectively better when it comes to being an init system and for managing services, and all the other components of systemd suite can just be replaced, like why would they do this?
I was following where the author was coming from until they quoted this, and rather than addressing it they just slammed it, slammed the author, and moved on.
It's weird to say that ini files are not a domain specific language. And this kind of hand waving away complexity is the crux of systemd putting a bad taste in my mouth. The whole thing is a vast kingdom of nouns (cf Yegge). Forgoing expressing semantics with the config file syntax means that expressing those semantics requires creating even more nouns. Splaying the config across a bunch of tiny files forgoes juxaposition and makes for even more nouns. Owning the aspect of whether a given config file is enabled or not creates even more nouns. Needing tools to analyze the distilled config (eg dependency graph) necessitates even more nouns.
... and this was all dumped on a community that very much focuses on a smaller number of verbs - ie command line utilities. The main problem with SysV scripts is that they are bare scripts doing anything they want with those longstanding verbs. So yes, some abstraction was necessary, and that was inevitably going to seem a bit unnecessary-complexity. But systemd just took that dynamic and went overboard with it.
Sure, I can read "type=forking" and know what that means, but no, I cannot change it without looking up the documentation. Any interaction with systemd beyond start/stop/journalctl involves looking up the documentation, re-figuring-out its implicit logical model, copying the right magical incantation, and then after I've solved the problem promptly forgetting everything I figured out because the next time I touch systemd I'm guaranteed to need to know something different.
I don't dislike it enough to desperately want to move to a different init system (although if there were an easy alternative on NixOS I'd try), and I'm certainly not going to defend SysV or BSD init scripts. But it certainly feels like there is plenty of room to implement systemd's comprehensive functionality in a more user-friendly discoverable way, especially for the main type of advanced-but-casual user that interacts with init systems.
(Also as a fellow NixOS user I think it's easy to have a blindspot about systemd because its config files align with our config format. A more user-friendly concise config format would make NixOS have to do more work to splay it out for its own composability)
I remember running Linux servers for the first time and couldn’t believe there wasn’t a straight forward way to get something to run on startup. Ask glue and duct tape and non portable.
Don’t get me started on the Python situation.
I assume it’s much better now.
With the clown services U hadn’t had to run bare Linux in a long time.
- a very opaque structure: it's actually not that opaque, since configuration files are still plain text, and better yet with more structure, but it first appears as inscrutable, since the programs aren't shell scripts;
- a set of new tools to learn: Systemd doesn't make use of the existing Unix tool-set (sed, awk, etc), ie. the vocabulary most sysadmins are familiar with in this ecosystem.
It seems on the outset that Systemd is trying to get away from the traditional Unix "one program should do one and only one thing well" (which is colloquial phrasing for separation of concerns).
Still, one idea that occurred to me is that in the early days of Unix, system programs might have been quite simple, with very few options (that man pages were probably very short), but that's clearly not the case nowadays. So haven't we left the "one program should do one and only one thing well" paradigm a long time ago anyway?
Actually, I think that one crucial issue with systemd is its specialization: can it be used for anything else than service management? At first, this seems to clash with the Unix principle, but even awk and sed are meant to do one thing, yet their field of action is very general, not just confined to handle one style of files or perform one style of transformation.
31 comments
[ 0.23 ms ] story [ 1311 ms ] threadIt made so many common things I had to do so as a sysadmin super straightforward.
So, systemd change is a pain for me.
Better to spend a minute searching for a command in a file than to waste an hour recreating it.
Across companies, jobs, and hobbyist collaborators - I've never met someone who didn't at least like systemd, if not sing its praises. It made so many incredibly painful things about Linux administration disappear.
E.g. logging, now that there is journald, you have to pay attention to another hop in your logging chain and take care of journald in addition to rsyslogd.
Boot and shutdown has previously been deterministic, now things just randomly hang. You do the "windows solution", reboot again, now it magically works through the power of race conditions that are inherent in systemd's mode of operations.
Network device naming is also a fun one. Remember how systemd was supposed to do away with the inconsistency and mess that is "eth0, eth1, eth2, eth..."? Well, now you get either eth0, or ens123, or enp17s7f9, or enx8b220b34. Each distro does it differently, so put in a live-CD to debug something and your network devices are suddenly weird. Reinstall to another version, suddenly weird again. Btw, the issue that names could change depending on boot order was already fixed by udev before, consistent-net.rules nailed it to a mac address on first boot. So systemd took a situation that was already fixed and better than before, and made it far far worse.
Oh, and all the fun that is systemd-dbus, policykit, systemd-logind and permissions on those. Because you always wanted a Javascript interpreter and libxml to tell who could be root on your system... And tons of confused deputy exploits on that cloud of confused systemd-subdaemons.
I'll grant that service files were a nice idea. But beyond that, it has been a very mixed bag, and in places a desaster.
You had to either use some (often abandoned) third party tool or defeat the purpose by just reconfiguring everything to dump a text log to a file.
If it’s my responsibility then I will use a non-systemd distribution or if I have a choice, FreeBSD.
The parts I don’t really like are the half baked “ancillary” managers like resolvd, which are frankly baffling to use and tend to make simple things needlessly difficult.
They basically mediate all Linux access to the hardware, and can add arbitrary dependencies to the system at will. They could decide that we're all going to use leftpad now.
Cutting off my hand to get rid of that cancerous mole might have saved my life, but I wish you had just cut off the mole.
I still see no counterarguments here. Meanwhile, systemd, like cancer, is eating Linux from the inside, breaking its flexibility and therefore future resilence:
https://wiki.gentoo.org/wiki/Hard_dependencies_on_systemd
https://news.ycombinator.com/item?id=42918448
https://news.ycombinator.com/item?id=42889792
(I reposted my comment from previous submission)
For UN*X people, all it does is move Linux closer to emulating Microsoft Windows. It has left the UN*X philosophy behind. With secure boot and once Wayland becomes a real thing, the last step is in place. All that will be needed to become a M/S Windows Clone is geo-location and full DRM. That means you will only be able to take screen prints of "approved" applications. I heard SUSE may enable a kind of geo-location, not sure if I read that article correctly though.
For now, at least there are the *BSDs, they allow me to make a PC work the way I want it to, not a way Fortune 500 Companies dictate it should work.
I was following where the author was coming from until they quoted this, and rather than addressing it they just slammed it, slammed the author, and moved on.
It's weird to say that ini files are not a domain specific language. And this kind of hand waving away complexity is the crux of systemd putting a bad taste in my mouth. The whole thing is a vast kingdom of nouns (cf Yegge). Forgoing expressing semantics with the config file syntax means that expressing those semantics requires creating even more nouns. Splaying the config across a bunch of tiny files forgoes juxaposition and makes for even more nouns. Owning the aspect of whether a given config file is enabled or not creates even more nouns. Needing tools to analyze the distilled config (eg dependency graph) necessitates even more nouns.
... and this was all dumped on a community that very much focuses on a smaller number of verbs - ie command line utilities. The main problem with SysV scripts is that they are bare scripts doing anything they want with those longstanding verbs. So yes, some abstraction was necessary, and that was inevitably going to seem a bit unnecessary-complexity. But systemd just took that dynamic and went overboard with it.
Sure, I can read "type=forking" and know what that means, but no, I cannot change it without looking up the documentation. Any interaction with systemd beyond start/stop/journalctl involves looking up the documentation, re-figuring-out its implicit logical model, copying the right magical incantation, and then after I've solved the problem promptly forgetting everything I figured out because the next time I touch systemd I'm guaranteed to need to know something different.
I don't dislike it enough to desperately want to move to a different init system (although if there were an easy alternative on NixOS I'd try), and I'm certainly not going to defend SysV or BSD init scripts. But it certainly feels like there is plenty of room to implement systemd's comprehensive functionality in a more user-friendly discoverable way, especially for the main type of advanced-but-casual user that interacts with init systems.
(Also as a fellow NixOS user I think it's easy to have a blindspot about systemd because its config files align with our config format. A more user-friendly concise config format would make NixOS have to do more work to splay it out for its own composability)
https://www.theregister.com/2017/07/28/black_hat_pwnie_award...
It's certainly been a successful takeover of all of the userspace runtime by one giant integrated set of executables.
Pwned off as an init replacement, then feature creeping it's way into every nook of userspace.
For me, it's still a disaster for distro and system s/w independence and the "do one thing well" philosophy.
While many welcome our new system overlords, the s/w is still not liked by many many people...
Move into the void! The DJB way and runit await...
Loonix developers: Now Loonix is windows
Loonix users: booo
… several hours later
Loonix users: yaaaay
/s
I remember running Linux servers for the first time and couldn’t believe there wasn’t a straight forward way to get something to run on startup. Ask glue and duct tape and non portable.
Don’t get me started on the Python situation.
I assume it’s much better now.
With the clown services U hadn’t had to run bare Linux in a long time.
I think however that a lot of hate comes from:
- a very opaque structure: it's actually not that opaque, since configuration files are still plain text, and better yet with more structure, but it first appears as inscrutable, since the programs aren't shell scripts;
- a set of new tools to learn: Systemd doesn't make use of the existing Unix tool-set (sed, awk, etc), ie. the vocabulary most sysadmins are familiar with in this ecosystem.
It seems on the outset that Systemd is trying to get away from the traditional Unix "one program should do one and only one thing well" (which is colloquial phrasing for separation of concerns).
Still, one idea that occurred to me is that in the early days of Unix, system programs might have been quite simple, with very few options (that man pages were probably very short), but that's clearly not the case nowadays. So haven't we left the "one program should do one and only one thing well" paradigm a long time ago anyway?
Actually, I think that one crucial issue with systemd is its specialization: can it be used for anything else than service management? At first, this seems to clash with the Unix principle, but even awk and sed are meant to do one thing, yet their field of action is very general, not just confined to handle one style of files or perform one style of transformation.