4 ms·
An unfortunate reality of development today is that we have developers with little to no systems experience having to decide on base images, even though they ha
by hibikir 5y ago
An unfortunate reality of development today is that we have developers with little to no systems experience having to decide on base images, even though they haven't built any expertise on OSs. It makes perfect sense for this to happen: A different OS is a line away in a docker file, and they have to pick something!
Among this rather large crowd, Alpine is popular for just one reason: it's small, and dealing with large images is more annoying, everything else being equal. But alpine and, say, ubuntu, aren't always equal. Those people then find one of the ugliest differences, often related to musl, or something they are using relying on glibc-like behavior, and then get to choose between a hack like this, or much larger images.
As an example my organization was moving everything to alpine, but as part of the switch we found out that some computationally heavy tasks were getting significantly worse performance under alpine than with a glibc-based distro, mainly due to the relatively well documented issues with memory allocation performance. It'd not be surprising that someone finding themselves in this kind of situation ends up just adding glibc to alpine, instead of switching back, or figuring out how to tweak the memory allocator.
- branneman 5y agoYes. Exactly this.
- mattbnr32 5y ago100%
- jart 5y agoThis is one of the reasons why I've been building Cosmopolitan Libc. https://github.com/jart/cosmopolitan https://github.com/jart/cosmopolitan Alpine and Musl aren't radical enough on the bloat-free angle (since they don't fix root problem which is dynamic shared objects) and their definition of portability is supporting architectures like sega saturn but do nothing to support intel/amd microarchitectural dispatching, which is likely why you encountered performance issues. It's like, I love Musl so much, but I just didn't see the value in being able to port my apps to Sega Saturn if my C Library only runs on Linux and has suboptimal performance on x86. [side note] I seem to recall there being something about the the way the musl header files are written that basically throws a wrench into any scientific computing code that's compiled with it. Might have something to do with security like those checks intended to prevent people from overlapping memcpy so someone should totally fix that.