4 ms·

> Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone. For a practical ex

> Monocultures are bad because they eliminate competitive pressure for good design and create single points of failure that affect everyone. For a practical example of this, the XZ backdoor [1] affected liblzma which is (was?) a dependency for libsystemd, and some distributions patched OpenSSH to include libsystemd. As a result, the decision of putting journal file compression functionality directly into your init system means that a significant portion of all Linux systems out there came this close to being backdoored. [1] https://news.ycombinator.com/item?id=39911311 https://news.ycombinator.com/item?id=39911311

esseph 1y ago
If you think that's wild you should hear about kernel vulnerabilities!
- yjftsjthsd-h 1y ago
  Yeah, the Linux monoculture is also bad. In fact, one reason the systemd monoculture is bad is because it enforces the Linux monoculture.
  - esseph 1y ago
    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.
    - Izkata 1y ago
      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.
    - yjftsjthsd-h 1y ago
      > 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.
      - esseph 1y ago
        If openssh isn't a monoculture this whole thing you've got falls apart. And pipewire is fine and good? Ask a sound engineer.
Spivak 1y ago
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?!
- panick21_ 1y ago
  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.
  - Spivak 1y ago
    From the horse's mouth. https://mastodon.social/@pid_eins/112202687764571433 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.
- AlotOfReading 1y ago
  You're not wrong, but look at it from a user's perspective. The documentation (https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html 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.

esseph 1y ago

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

yjftsjthsd-h 1y ago
Yeah, the Linux monoculture is also bad. In fact, one reason the systemd monoculture is bad is because it enforces the Linux monoculture.
- esseph 1y ago
  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.
  - Izkata 1y ago
    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.
  - yjftsjthsd-h 1y ago
    > 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.
    - esseph 1y ago
      If openssh isn't a monoculture this whole thing you've got falls apart. And pipewire is fine and good? Ask a sound engineer.

Spivak 1y ago

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?!

panick21_ 1y ago
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.
- Spivak 1y ago
  From the horse's mouth. https://mastodon.social/@pid_eins/112202687764571433 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.
AlotOfReading 1y ago
You're not wrong, but look at it from a user's perspective. The documentation (https://www.freedesktop.org/software/systemd/man/latest/sd_notify.html 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.