Be careful, it using musl instead of glibc can be a headache, especially if you ever use any pre-compiled software.
Another point for flatpak/snap style proprietary apps distribution though - they don't assume anything about the distro will be there.
Also, dealing with DNS issues in Alpine based containers (which was caused by musl implementation, iirc) was one of my biggest nightmare at work. Just search for "Alpine+DNS" on Google and you can see what a mess it had brought.
As for DNS, it's extremely unfair to blame musl for properly implementing the POSIX standards for name resolution. It's not Alpine's fault that so many people wrote software which explicitly depended on specific glibc quirks. If anything, it's a good lesson on the dangers of monocultures, and how even FOSS software is at risk.
What I was trying to say, was that many people choose it for wrong reasons without fully understanding the implications. This included us. It was a nightmare to me because at that time I didn't know it has different behavior in DNS resolution. And our developers expected their code, which ran fine on their workstations and in CI (Ubuntu/Debian environments), to behavior the same when running in an alpine container in production.
This, I remember jemalloc and musl/ Alpine issues. In the end it just isn't worth the hassle. Although that was may be two years ago.
I don't base any decisions around micro benchmarks but that example struck me as interesting because this was a case where the performance difference between using Alpine and Debian was real and affected user level applications.
For the last few years I also run Debian Slim for my base Docker images and don't worry about it.
Yes my images might be a little larger than Alpine but it's non-issue in the real world. For smaller scale deploys once the base image is pulled down initially it's there in both cases, so now it comes down to pulling app level changes (code or package deps) which is comparable in size with both distros.
And for huge scale deployments it doesn't matter because typically you'd use custom ISOs with as much pre-loaded static content as possible, so you could easily bake in a specific Debian Slim image into the ISO so when you pull down your application image at deploy time it skips having to pull the base image entirely negating any wins that Alpine might have had for pull speeds and network usage.
Sure Alpine has less attack surface since it's a smaller code base but we're comparing it to Debian here. They have a 28 year track record of being unbelievably dependable and well supported.
But that's a pretty bad idea in most cases I guess. Good to see that Musl might be supported properly.
I don't think it's any sort of Mac generation downvoting, I think it's more the opposite: they're preaching to the choir. Yea. We Know.
Not is it just acceptable, it's your obligation to tell peoples what the downside (or upside) of closed down software is. Is a closed source webserver a good idea? probably not. Is THE closed source Photo-editing program a good idea? Probably yes....if you really need it.
To contradict myself: I do find myself frustrated when 'obvious thing that should work' doesn't but I save that ire for things that break between versions!
I am really against the idea that just because something is "free", it is exempt of any judgment. We should always strive to improve everything, free or not.