TechTakes

1429 readers

98 users here now

Big brain tech dude got yet another clueless take over at HackerNews etc? Here's the place to vent. Orange site, VC foolishness, all welcome.

This is not debate club. Unless it’s amusing debate.

For actually-good tech, you want our NotAwfulTech community

founded 1 year ago

MODERATORS

[email protected]

the suckless.org devs seem to like posting Nazi dogwhistles (oldbytes.space)

submitted 1 year ago by [email protected] to c/[email protected]

40 comments fedilink hide all child comments

kinda glad I bounced off of the suckless ecosystem when I realized how much their config mechanism (C header files and a recompile cycle) fucking sucked

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 4 points 1 year ago (1 children)

Huh? Most of systemd’s features, including all in the above list, work even if you have no GUI installed at all.

user session features don’t work properly unless your DE sends session start/end information to systemd (and when I found this out, only gnome, kde, and enlightenment did). this breaks various systemd features in surprising ways; I found out about this when my user services wouldn’t work, but I stopped keeping track of what was broken when I realized it was all WONTFIX anyway

If systemd were hard-forked right now, and the new maintainer did little more than the occasional bug fix, systemd would still be useful for the foreseeable future.

historically, hard forking systemd has gone about as well as hard forking bitcoin, for very similar reasons. technologically, systemd forks tend to accumulate compatibility issues with the rest of userland very quickly due to breaking API and functionality changes in the interdependent systemd process ecosystem (and these breakages can very quickly propagate to downstream programs — a breakage in logind can be expected to be catastrophic for auth in general, for example). note too that breaking changes in the systemd API are rarely signposted in advance, which makes the job of a systemd fork and its dependent distros even harder. practically speaking, this means that a systemd fork must either excise the service ecosystem entirely (and would probably be better off just being a completely different init system at that point) or must have the wealth and support of a very large corporation behind it. this is similar to the technological means by which cryptocurrency projects maintain control: in a fork, the chain with more wealth behind it quickly becomes the longer one, and the shorter chain is extremely vulnerable to various attacks.

socially, both cryptocurrency projects and systemd possess notably toxic communities which severely punish forks and dissent, which is also used as a mechanism by which control over the project is maintained. the upshot to this is an additional high cost to the morale and community resources of a fork, which particularly harshly punishes forks run by individuals and small teams.

[–] [email protected] 0 points 1 year ago (1 children)

user session features don’t work properly unless your DE sends session start/end information to systemd

Which features, exactly? I just tried IceWM, which has no systemd-related dependencies and vastly predates systemd, and the session appears correctly on loginctl and disappears from there a few seconds after logging out, same as logging in and out of Plasma. Seems like it works fine.

I did notice that loginctl lock-session doesn't work with IceWM, and presumably neither does anything else that involves sending D-Bus messages to the process controlling the session, but that's not the end of the world.

this breaks various systemd features in surprising ways; I found out about this when my user services wouldn’t work

I definitely have not observed this issue. I have loginctl enable-lingered myself, so my user services start during boot, before any desktop environment is loaded. I haven't tested whether user services work in IceWM without that, but as far as I know, user service managers are started and stopped by logind in response to session start/stop, and logind gets notified of session start by the PAM module pam_systemd, not by the desktop environment.

systemd forks tend to accumulate compatibility issues with the rest of userland very quickly due to breaking API and functionality changes in the interdependent systemd process ecosystem (and these breakages can very quickly propagate to downstream programs — a breakage in logind can be expected to be catastrophic for auth in general, for example).

Breaking changes affecting programs outside of the systemd suite? Can you give me some concrete examples of such breaking changes and the problems they caused? I wasn't aware there were any. I would have expected to see some serious fireworks if such a thing ever happened.

socially, both cryptocurrency projects and systemd possess notably toxic communities which severely punish forks and dissent, which is also used as a mechanism by which control over the project is maintained. the upshot to this is an additional high cost to the morale and community resources of a fork, which particularly harshly punishes forks run by individuals and small teams.

We're discussing a community hard fork that leaves IBM behind, like what happened with XFree86. What IBM says or does after that is irrelevant, I would think.

[–] [email protected] 2 points 1 year ago

not gonna dig around in the source to my distro for examples, but here’s the hack NixOS uses to make graphical-session.target run with WMs that aren’t Gnome or KDE. since a lot of the session management stuff I want to do relies on being able to sensibly handle both text and graphical sessions (and the NixOS hack wasn’t too reliable the last time I tried it), this was one of the factors that pushed me towards using Shepherd to manage the session process tree on my systems

Can you give me some concrete examples of such breaking changes and the problems they caused?

this is a really weird question to ask, given that the context is a hypothetical systemd fork running into breaking changes in the systemd API. maybe look up a postmortem for uselessd or any of the other dead systemd forks?

What IBM says or does after that is irrelevant, I would think.

leveraging an existing toxic community against a newer, smaller one is very much a way to retain control after a fork; again, this is pretty much a known quantity, and there are a bunch of examples of it happening in cryptocurrency projects