|
|
|
|
|
|
by sjellis
3217 days ago
|
|
|
"I (thankfully only) used to do Linux BSPs in a former life. In the last year or so of doing that, I think we spent about 15-20% of a project's time debugging systemd problems and working around it being too smart for its own good." It would be great to see in-depth experience reports for systemd, good and bad. The overwhelming majority of anti-systemd commentary has just been noise for so long, and as somebody who is very much in favor of systemd, I'd love to see some real discussion and actual informed criticism. |
|
|
They keep having embarrassing security exploits (like remote code execution in the dns reimplementation, or handing root to strange usernames by design).
Many people say they broke logging because the binary files create administrative nightmares and are flakey by design. Ubuntu LTS' systemd logging subsystem definitely broke a bunch of production machines I work with by stealing control from rsyslog during a botched update. We have a bunch of tooling for log processing and shipping. The systemd binary format is a usability nightmare compared to .gz files.
Being a member of the "video" group is no longer enough to use DRI or the new rootless X11 stuff. One of the crucial system calls has been hardcoded to only work when invoked by UID zero. The kernel maintainer rejected a one line patch to fix it. The argument is that systemd can launder the call through its own authentication subsystem, so the kernel doesn't need to implement workable permissions for /dev/ anymore. I have no idea how far that brain damage has spread. Just "chown root:root /dev/video; chmod og-rwx" if you want systemd! Don't proactively break every non-systemd distro out there by intentionally crippling the kernel API!
I've noticed that systemd debian-derived desktops age poorly -- uninstall a bunch of packages and reinstall, and you will find you can no longer log in correctly. I never managed to root cause it. It looked like init issues with multiple repros across multiple OS vendors.