Hacker News Reader

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 troubleshooting Alpine specific issues just doesn’t seem worth it.

View on HN

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.

> 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.

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

I use scratch or distroless with a static binary. No nonsense needed! I love go.

Reply on news.ycombinator.com