Hacker News new | ask | show | jobs
by notalaser 3217 days ago
In the meantime, a bunch of us developers are desperately trying to figure out what the fsck broke this time, drinking our sorrows about this new life where we can't debug anything that happens at boot, and frantically setting up BSDs on our laptops at home, so that we can at least get a break from this mess when we're at home.

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. 20% for the bloody init system sounds fine until you realize the rest of the time included stuff like writing or expanding device drivers.

2 comments

"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.

I avoid systemd like the plague, but have hit these bugs anyway:

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.

The way I read systemd news, it's not worth analyzing it because Poettering will say 'won't fix' or 'working as intended'.
FWIW, systemd uses GitHub for bug tracking these days:

https://github.com/systemd/systemd/issues

While I did prefer the good old SysV style init, systemd works fine for me.