1. 15
  1.  

  2. 7

    How about we just fix the idiotic code that’s glibc specific if it breaks under musl? It would be way way better for the world if we did that and make it more portable across various POSIX-like systems as well. The world shouldn’t be a Linux & glibc only mono-culture.

    1. 3

      That’s a fine idea, but, any random application depends on lots of 3rd party libraries. It would be wonderful if they all heavily tested on musl and fixed things. In practice it’s unlikely. So the rational behavior for me as a user is not to use musl.

      Oh, also, a lot of this isn’t glibc-specific code. A lot of this is just bugs in musl. And again, many have been fixed.

      1. 4

        I agree musl isn’t perfect, but I’m glad it exists. We barely have 3 libc implementations (glibc, musl and BSDlibc), that nobody bothers to test against and now Google wants a 4th[0].

        Laziness leads to a monoculture, which is bad for everyone. Testing against 2 of the 3 is easy. Testing against all 3 isn’t hard.

        0: https://lobste.rs/s/xyq2pl/libc_llvm

        1. 1

          A lot of this is just bugs in musl

          GNU libc also isn’t free of bugs. Does musl have more bugs?

          1. 4

            AFAICT musl has had more commonly-encountered bugs. There’s huge amount of “run your full test suite against glibc” over the years. musl is now getting that treatment via Alpine, which is good… but it takes some time to shake out all the bugs.

      2. 4

        The discussion of apt-get is also incomplete, at best.

        It suggests pinning on the apt-get command line like package-foo=1.3.* and says:

        Version pinning forces the build to retrieve a particular version regardless of what’s in the cache. This technique can also reduce failures due to unanticipated changes in required packages.

        This technique will strictly increase failures by causing installation to fail if the package disappears from the repository. If you really need that exact version that may be what you want, but usually pinning packages like this makes your Dockerfile more brittle for no gain. You could avoid some of this pain with a caching proxy, but that’s not mentioned.

        This section is also missing any discussion of recommends/suggests dependencies. Passing --no-install-recommends and --no-install-suggests to avoid these optional dependencies is an easy way to reduce the weight of the built image. Anything actually required should be installed explicitly anyway. I bake the equivalent configuration into a custom base image (along with config to disable Pip caching).