15 ms·

> What is the comparison between using musl and traditional glibc? you get weird bugs and failures that don't happen with glibc (like the incomplete dns resol

by znpy 3y ago

> What is the comparison between using musl and traditional glibc? you get weird bugs and failures that don't happen with glibc (like the incomplete dns resolving routines that would fail under some conditions) but you can brag about saving 30-40 mb of disk space. this project seems to be compromising on quality overall, in the name of having smaller size. Even BearSSL, by their own website is beta-quality: "Current version is 0.6. It is now considered beta-quality software" (from https://bearssl.org/ https://bearssl.org/).

deleted 3y ago
[deleted]
ghotli 3y ago
https://musl.libc.org/releases.html https://musl.libc.org/releases.html I maintain a large codebase, widely deployed, cross compiled to many cpu architecures that's built atop musl. You're right that historically in the context of people blindly using alpine for their container base that sort of thing might be the case. The newest version of musl solves the thing you're describing and in general most of the complaints about malloc perf or otherwise have been addressed. Avoiding musl to me seems like an outdated trope, but there was a time wherein that take was valid indeed.
- NewJazz 3y ago
  malloc performance is still sub-par IMO. It is not nearly as terrible as it was, but scudo, memalloc, and glibc's malloc are better.
  - raverbashing 3y ago
    Yeah, and with glibc you can even LDLIBRARY an alternative glibc, not so much with musl (unless it changed recently)
    - ghotli 3y ago
      I make statics usually so this sort of just never comes up. If I wanted another malloc it would just be linked in at compile time like the rest.
raesene9 3y ago
A small point on that last bit. The bearssl authors are pretty conservative when it comes to development milestones, I'd guess that their 0.6 would be pretty solid :)
- znpy 3y ago
  > I'd guess that their 0.6 would be pretty solid :) Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump? I think we should respect the developers here: they're not claiming production quality level (they're claiming beta-quality level) so it's not correct to use that library in any kind of product and claim any kind of production-level quality.
  - ComputerGuru 3y ago
    I would run away from using glibc on an insulin pump or pacemaker, so I’m not sure what point you’re trying to make.
  - foul 3y ago
    > Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump? God helps me I wouldn't implant anything so fundamental in my body with hard dependencies on encrypted communication to a remote agent elsewhere, no matter the advantage.
  - raesene9 3y ago
    If you go by version number and anything < 1.0 being not production ready, I recommend avoiding reading any of the dependency files for large software products which are often used in produciton, they might cause you some concern... https://github.com/kubernetes/kubernetes/blob/master/go.mod https://github.com/kubernetes/kubernetes/blob/master/go.mod for one obvious example.
electroly 3y ago
> incomplete dns resolving routines They eventually did fix this, as of musl 1.2.4.
- o11c 3y ago
  While not an issue for musl-centric distros if they keep updated, note that e.g. Debian stable doesn't have that version yet, so good luck testing.
  - electroly 3y ago
    At least we have light at the end of the tunnel now. This is a tremendous improvement from the previous status quo of the musl maintainers not even agreeing that it's a problem.
    - znpy 3y ago
      This alone “musl maintainers not even agreeing it’s a problem” should be a good reason to avoid musl imho
      - electroly 3y ago
        What's a better option for static linking? glibc is religiously against it; they have far worse dogmatic beliefs than this musl DNS thing. I'd be happy to choose a better alternative if one exists, but if one does not, I have to live with the options at hand. From where I'm standing, musl seems like the only game in town. uClibc doesn't seem like it's appropriate for general purpose Linux applications on desktop computers (maybe I'm wrong?).
        o11c 3y ago
        Static linking doesn't actually solve any problem. Just use dynamic linking with (probably relative) rpath, and compile against a sufficiently old libc. There's some common FUD about rpath being insecure, but that only applies if the binary is setuid (or otherwise privileged) and the rpath is writable by someone other than the binary's owner (all relative rpaths are writable since you can use symlinks; absolute rpaths are writable if they point to /tmp/ or a similar directory, which used to be common on buildbots). This is really not hard; working around all static linking's quirks is harder.
fullspectrumdev 3y ago
30-40mb of disk space is absolutely huge in some environments even today though

by znpy 3y ago

deleted 3y ago

[deleted]

ghotli 3y ago

https://musl.libc.org/releases.html https://musl.libc.org/releases.html I maintain a large codebase, widely deployed, cross compiled to many cpu architecures that's built atop musl. You're right that historically in the context of people blindly using alpine for their container base that sort of thing might be the case. The newest version of musl solves the thing you're describing and in general most of the complaints about malloc perf or otherwise have been addressed. Avoiding musl to me seems like an outdated trope, but there was a time wherein that take was valid indeed.

NewJazz 3y ago
malloc performance is still sub-par IMO. It is not nearly as terrible as it was, but scudo, memalloc, and glibc's malloc are better.
- raverbashing 3y ago
  Yeah, and with glibc you can even LDLIBRARY an alternative glibc, not so much with musl (unless it changed recently)
  - ghotli 3y ago
    I make statics usually so this sort of just never comes up. If I wanted another malloc it would just be linked in at compile time like the rest.

raesene9 3y ago

A small point on that last bit. The bearssl authors are pretty conservative when it comes to development milestones, I'd guess that their 0.6 would be pretty solid :)

znpy 3y ago
> I'd guess that their 0.6 would be pretty solid :) Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump? I think we should respect the developers here: they're not claiming production quality level (they're claiming beta-quality level) so it's not correct to use that library in any kind of product and claim any kind of production-level quality.
- ComputerGuru 3y ago
  I would run away from using glibc on an insulin pump or pacemaker, so I’m not sure what point you’re trying to make.
- foul 3y ago
  > Would you accept that kind of reasoning for software running on your pacemaker, or on your insuline pump? God helps me I wouldn't implant anything so fundamental in my body with hard dependencies on encrypted communication to a remote agent elsewhere, no matter the advantage.
- raesene9 3y ago
  If you go by version number and anything < 1.0 being not production ready, I recommend avoiding reading any of the dependency files for large software products which are often used in produciton, they might cause you some concern... https://github.com/kubernetes/kubernetes/blob/master/go.mod https://github.com/kubernetes/kubernetes/blob/master/go.mod for one obvious example.

electroly 3y ago

> incomplete dns resolving routines They eventually did fix this, as of musl 1.2.4.

o11c 3y ago
While not an issue for musl-centric distros if they keep updated, note that e.g. Debian stable doesn't have that version yet, so good luck testing.
- electroly 3y ago
  At least we have light at the end of the tunnel now. This is a tremendous improvement from the previous status quo of the musl maintainers not even agreeing that it's a problem.
  - znpy 3y ago
    This alone “musl maintainers not even agreeing it’s a problem” should be a good reason to avoid musl imho
    - electroly 3y ago
      What's a better option for static linking? glibc is religiously against it; they have far worse dogmatic beliefs than this musl DNS thing. I'd be happy to choose a better alternative if one exists, but if one does not, I have to live with the options at hand. From where I'm standing, musl seems like the only game in town. uClibc doesn't seem like it's appropriate for general purpose Linux applications on desktop computers (maybe I'm wrong?).
      - o11c 3y ago
        Static linking doesn't actually solve any problem. Just use dynamic linking with (probably relative) rpath, and compile against a sufficiently old libc. There's some common FUD about rpath being insecure, but that only applies if the binary is setuid (or otherwise privileged) and the rpath is writable by someone other than the binary's owner (all relative rpaths are writable since you can use symlinks; absolute rpaths are writable if they point to /tmp/ or a similar directory, which used to be common on buildbots). This is really not hard; working around all static linking's quirks is harder.

fullspectrumdev 3y ago

30-40mb of disk space is absolutely huge in some environments even today though