Thank you for the technical clarifications. In the boring, corporate, enterprise software bubble in which I have mostly worked for 25 years, musl/busybox/Alpine

Thank you for the technical clarifications. In the boring, corporate, enterprise software bubble in which I have mostly worked for 25 years, musl/busybox/Alpine are barely a blip on the radar. I have not ever seen an Alpine Linux install in 25 years, unless it is the basis of various busybox based appliances and I've not noticed. Certainly never seen it used for running "mission critical" bloated Java enterprise apps etc. So within my comment I thought it was implicitly clear I was referring to glibc based distributions, for example Redh^H^H IBM. You CAN statically link binaries against glibc on these distributions, and in many cases it will work. However NSS and PAM will not work in my experience. Is it a generally a good idea to static link against glibc? No. > If $code doesn't work on musl 99.9% of the time its due to $code, also musl has dlopen and a dyn linker otherwise alpine wouldn't work. Is sssd officially supported on Alpine Linux? Does it just work out of the box? It seems to be in "testing" branch from what I can see with over 600 open bugs. There is a reason that shareholders of large organizations want to pay a large, established Linux vendor for support, regardless of whether or not their engineers will ever use the support or not. They want to pay for stability/security updates. They are paying for a Linux distribution that 3rd party application providers have certified their application for. They want LDAP/AD and other pluggable PAM modules to work out of the box without too much tinkering. Alpine Linux may fit that criteria for all I know. Doesn't matter. My employers wouldn't use it whether I wanted to or not. Not saying that I like how things have turned out for Enterprise Linux necessarily, but it is what it is. Redhat and clones absolutely DOMINATE this particular space, at least in the USA, UK and Australia.