If you think that's wild you should hear about kernel vulnerabilities!

Yeah, the Linux monoculture is also bad. In fact, one reason the systemd monoculture is bad is because it enforces the Linux monoculture.

What about the Windows monoculture in business?

What about the seemingly Apple monoculture on HN?

What about the OpenBSD monoculture with OpenBSD!!!!!

You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.

I remember reading PipeWire is more stable than Pulseaudio because it removed a buggy and hard-to-implement-correctly feature. So not completely backwards compatible.

> What about the Windows monoculture in business?

...yes? Obviously?

> What about the seemingly Apple monoculture on HN?

I don't think that exists, but if it did then I would object to it.

> What about the OpenBSD monoculture with OpenBSD!!!!!

What would that even mean? ...Actually, no, even if I sort of pretend that the concept makes sense it's not really a thing; OpenBSD constantly exports their software to be usable on other systems (ex. OpenSSH is an OpenBSD project) and imports general unix-like software to work on it. So no, there is no OpenBSD monoculture and wouldn't be even if it was that popular.

> You know what Linux needs? Another audio stack. Be sure it's backwards compatible with all the others, just like the last dozen were.

See, the real reason that this is funny is that PipeWire is a new audio system, is mostly superior to its predecessors, and largely is successful because it is backwards compatibile. So... Yes, actually, exactly what you said but unironically and without the slightest bit of sarcasm.

If openssh isn't a monoculture this whole thing you've got falls apart.

And pipewire is fine and good? Ask a sound engineer.

This wasn't a systemd problem— this was distro maintainers doing something stupid problem. The thing the maintainers wanted to patch into OpenSSH was systemd-notify which is the way services can tell systemd that they're ready. The protocol is literally sending the string READY=1 over a file descriptor. libsystemd contains a reference implementation but it's a protocol specifically for the reason that every service isn't supposed to link to libsystemd. Maintainers thought it was easier to link in all of libsystemd (and therefore xz) into OpenSSH just for the sd_notify function.

Just link in a huge library into security critical code, what could go wrong?!

You're not wrong, but look at it from a user's perspective. The documentation (https://www.freedesktop.org/software/systemd/man/latest/sd_n...) explicitly says:

    using this library should be preferred in order to avoid code duplication

Then, if you're not intimately familiar with systemd you might wonder which is more standardized and less likely change between the API and the protocol. Maybe you make the reasonable assumption that it's the API.

Then, you look at the reference code and see some reasonably nontrivial stuff that's a bit outside the maintainer's remit to add.

All of that is going to lead people in the direction of linking the library rather than reimplementing from scratch.

Putting to much unnecessary stuff into libsystemd is something sub-optimal that they do. Its a bit lazy. But it is correct that people should link it like that.

From the horse's mouth. https://mastodon.social/@pid_eins/112202687764571433

> In the past, I have been telling anyone who wanted to listen that if all you want is sd_notify() then don't bother linking to libsystemd, since the protocol is stable and should be considered the API, not our C wrapper around it. After all, the protocol is so trivial

I'm actually surprised that they added the note about code duplication after adding the standalone implementation specifically so people won't do that.

It's not even that, that whole story's main point was about how an incredibly complex, sophisticated and lengthy social engineering attack was carried out, probably by a nation-state actor, after singleing out an over-worked open source maintainer of a core project (xz) doing a thankless job and getting pressured left-and-right until he caved (no fault of his own), and they managed to install an updatable, generic backdoor that could be used to attack literally anything. The initial version was chosen to target sshd <-- libsystemd <-- xz.

The takeway that sensible people go away with is that core critical infrastructure needs to be properly funded, and people need to stop harassing open source maintainers.

Idiots instead rant about "muh systemd" and use it to attack other maintainers.