4 ms·

Having run into some of the musl-related issues mentioned in the article, I now opt for Debian-based images even for non-python use cases. Having to spend time

• dathinab 3y ago
  In my experience most issues are not really musel issues but incorrect usage of libc where glibc used some "magic" to make that incorrect usage somehow somewhat work, at the cost of higher complexity which more then one time lead to security issues due to a larger attack surface. So in general I would recommend testing with musel and fix whatever issues you run into in a non-musel specific way. Through then I guess at work many people do not have time/resources for stuff like that.
  • avtar 3y ago
    > So in general I would recommend testing with musel and fix whatever issues you run into in a non-musel specific way. But again, do all this just to save anywhere between 50-200mb of space compared to Debian slim images. I'd rather just use the latter and get on with my day.
    • dathinab 3y ago
      it's not to save 50-200mb but to correctly use libc to avoid any unexpected situations with glibc down the line, e.g. when a change needed to be done for security reasons or running it on a more hardened system might lead to similar slow downs as with musel
• asylteltine 3y ago
  I use scratch or distroless with a static binary. No nonsense needed! I love go.