5 ms·

For all the good things Musl does, its authors can often be downright ridiculous out of a dogmatism which is very unpleasant to deal with as a user. See also th

by brmgb 3y ago

For all the good things Musl does, its authors can often be downright ridiculous out of a dogmatism which is very unpleasant to deal with as a user. See also their stubborn refusal to give you an easy way to detect that the libc is Musl while compiling.

0xcde4c3db 3y ago
> See also their stubborn refusal to give you an easy way to detect that the libc is Musl while compiling. I suspect that the primary use cases for that would be applying half-baked workarounds and refusing to work with an "unsupported" libc, much like HTTP User-Agent.
- brmgb 3y ago
  Or, you know, taking into account the stupid things Musl does like not having TCP DNS fallback. I’m only half joking. Features detection in Musl is a generally pain. I don’t blame developers for sometimes taking the path of least resistance and not trying to support it.
yjftsjthsd-h 3y ago
Well, if musl is standards compliant, then wouldn't it make sense to detect when you're building on something different rather than musl? Like, if the standard didn't require TCP fallback, then in theory the application should handle that and only skip it if it detects itself being built on a libc with non-standardized extensions to obviate the effort.
- brmgb 3y ago
  Because as we all know the standard never changes potentially introducing new features, allows no variability and bugs don’t exist. It must be nice living in your. theoretical world. Here in the real world, I like libraries to actually help me do what I want to do rather than be needlessly annoying to take a stand no one actually cares about. But that’s me. Clearly it serves Musl right given the massive amount of use it’s seeing. Hmm, wait a minute…
  - yjftsjthsd-h 3y ago
    Okay, so nobody uses it and you can stop complaining because it'll never come up.
    - brmgb 3y ago
      Well I would like to use it. It’s code is mostly sane, easier to understand than glibc and it would make sense in a lot of places where performances are not critical. That’s why I am so annoyed by the non sense its developers keep pulling out. It’s an incomprehensible situation because they get absolutely nothing out of it. They are basically annoying people for the sake of it. It’s incredible that changes like the one we are commenting on which are just sanity being restored have to come from an evolution of the standard.
- zajio1am 3y ago
  Standards are not laws, they are reasonably well-written documents describing behavior that is supposed to be interoperable. If, for some reason, that is not true (perhaps because the standard is ambiguous, obsolete or some other reason), ensuring that there is interoperability is more important than just keeping it to the letter of the standard. See RFC 1925, The twelve networking truths: (1) It has to work
  - rcme 3y ago
    Yes, it has to work. That’s exactly the point the person you’re responding to is making. There are plenty of things libc doesn’t provide. Software authors find way to provide functionality to make their software work regardless. How is DNS different? Just because you’re used to one specific implementation?

by brmgb 3y ago

0xcde4c3db 3y ago

> See also their stubborn refusal to give you an easy way to detect that the libc is Musl while compiling. I suspect that the primary use cases for that would be applying half-baked workarounds and refusing to work with an "unsupported" libc, much like HTTP User-Agent.

brmgb 3y ago
Or, you know, taking into account the stupid things Musl does like not having TCP DNS fallback. I’m only half joking. Features detection in Musl is a generally pain. I don’t blame developers for sometimes taking the path of least resistance and not trying to support it.

yjftsjthsd-h 3y ago

Well, if musl is standards compliant, then wouldn't it make sense to detect when you're building on something different rather than musl? Like, if the standard didn't require TCP fallback, then in theory the application should handle that and only skip it if it detects itself being built on a libc with non-standardized extensions to obviate the effort.

brmgb 3y ago
Because as we all know the standard never changes potentially introducing new features, allows no variability and bugs don’t exist. It must be nice living in your. theoretical world. Here in the real world, I like libraries to actually help me do what I want to do rather than be needlessly annoying to take a stand no one actually cares about. But that’s me. Clearly it serves Musl right given the massive amount of use it’s seeing. Hmm, wait a minute…
- yjftsjthsd-h 3y ago
  Okay, so nobody uses it and you can stop complaining because it'll never come up.
  - brmgb 3y ago
    Well I would like to use it. It’s code is mostly sane, easier to understand than glibc and it would make sense in a lot of places where performances are not critical. That’s why I am so annoyed by the non sense its developers keep pulling out. It’s an incomprehensible situation because they get absolutely nothing out of it. They are basically annoying people for the sake of it. It’s incredible that changes like the one we are commenting on which are just sanity being restored have to come from an evolution of the standard.
zajio1am 3y ago
Standards are not laws, they are reasonably well-written documents describing behavior that is supposed to be interoperable. If, for some reason, that is not true (perhaps because the standard is ambiguous, obsolete or some other reason), ensuring that there is interoperability is more important than just keeping it to the letter of the standard. See RFC 1925, The twelve networking truths: (1) It has to work
- rcme 3y ago
  Yes, it has to work. That’s exactly the point the person you’re responding to is making. There are plenty of things libc doesn’t provide. Software authors find way to provide functionality to make their software work regardless. How is DNS different? Just because you’re used to one specific implementation?