My POV: SystemD is a software driven not really by technical, but political reasons by RedHat, to put the most important parts of a GNU/Linux system under their control. (Appart from the kernel of course). It is modular, but also dependant as a whole, so in the end, it spreads almost like an invasion, slowly leaving the admins not other option than accepting it. That's quite off from the Unix philosophy (do one thing, do it well, be really modular)... so my conclusion going back to the beggining, that didn't happen by mistake, but is a deliberate design choice, with shaddy political reasons behind it, so I reject it. And then we could talk about the convenience or not of putting such amount of tools and complexity under PID 1, the crazy binary logs, the weird behavior of the service utilities, and the possibility of being able to modify/add services using regular scripts instead of binary excutables...
> My POV: SystemD is a software driven not really by technical, but political reasons by RedHat, to put the most important parts of a GNU/Linux system under their control.
it's really a dumb POV to have, given that systemd is FOSS (licensed LGPLv2.1+) like most of the software that red hat produces.
as a sysadmin, systemd is a godsend. really, it brings uniformity and waaay better debuggability/predictability and tooling in system startup and configuration and troubleshooting.
and, again, systemd is foss so red hat hasn't really that much control over other distros (and each distro had its own internal discussion and choose freely to adopt it).
on another side, red hat took the time and spent the money to bring that improvement to the world. other people just complain under the shield of a throwaway hn account.
I think people's beef with it is that it's hard to understand when things go wrong, Lennart's projects don't leave the best initial impression, and it's had significant scope creep since it was initially introduced.
well in fairness systemd's task (managing the system) is fairly complex as well.
I am not surprised I had to actually sit down and go through a short course on systemd and read some of the manpages to understand it enough and profit off its presence.
PS. I was expecting the kind of answers I received... as the whole subject stinks, talking about it stinks even more. What I wasn't waiting is to see people, in another time caring and loving this OS quietly yielding about such a big insanity. Thinking right now specially about Debian and ArchLinux mantainers.
It's fine when it works, but it's very hard to solve problems when they happen as it's so complex, and doing stuff outside of "the standard thing" can be difficult.
I once had "systemctl restart unbound" reset my volume, consistently. How do you even start debugging something like that without a deep dive in systemd? This particular issue turned out to be a systemd bug, and that such a bug can exist in the first place didn't exactly increase my confidence in the system.
In another case I couldn't get my NFS to work at all, and it turned out that rpcbind.service somehow went missing. Not sure how that happened and it's a simple enough problem, but it was really non-obvious because systemd doesn't issue clear errors on this and the system is so complex it's not easy to spot either.
You should know that this is a religious topic like vim vs emacs, but worse: vim and emacs users don't feel that the other side is a threat to allowing them to continue using the software they prefer.
Something I can't accept is the use of binary logs and the requirement for programs to access the contents of the logs.
Yes, most distros will put compatibility layers in place and create text "logs" in parallel. But if everyone is doing that maybe systemd's paradigm isn't right for the desktop even if it's great for servers.
Binary logs sound like a good thing to me since in most cases I want to just ship them off, and if I don't, a local consumer that can parse is just fine.
Yes. The ability to use the giant ecosystem of text processing and piping infrastructure that underlies the entire idea of the unix philosophy. That something besides eyes is required to parse the logs is absurd and unacceptable. And no one on desktop is shipping off logs to somewhere else. That's cargo cult behavior.
How do you "ship off" .journal files? Whenever I do it either the timestamps are off or you can't read the file at all. I resort to `journalctl xyz.journal > xyz.log` and send the resulting text file to outside the system.
I tried Gentoo and Artix, both being a very good experience. Some minor issues with laptop suspension and lightdm session handling in Artix tho. Flawless behavior with Gentoo, pity that an update broke my system a while ago.
I was going to mention the debian distro. I've got a 'cleanse' script that has grown over time for Ubuntu installs that I first install stock Ubuntu, then cleanse it of snap, systemd, modem-manager, and a couple of other things. And then add the packages that I like. But every release it gets more onerous to do this.