4 ms·

If you want glibc, why use Alpine? Mainstream distributions are for glibc. Alpine exists specifically as a musl-based thing.

IshKebab 5y ago
Yeah I thought the whole point of Alpine was that it abandoned the insanity of glibc for the relative sanity of musl. My only guess is that they like Alpine but want to run some binary software that links with glibc.
- 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 ago
    Yes. Exactly this.
  - mattbnr32 5y ago
    100%
  - jart 5y ago
    This 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.
- yjftsjthsd-h 5y ago
  > My only guess is that they like Alpine but want to run some binary software that links with glibc. There's also gcompat for that, although I don't know how comprehensive that is
- stu2010 5y ago
  musl is definitely more developer-friendly than glibc, which may lead to a brighter future for it, but right now at this time there's significant downsides to choosing musl. Performance in real world applications is worse on musl vs glibc, at a level that can result in higher latencies and needing to spend more on compute resources to serve a given level of load.
ekimekim 5y ago
I want to use alpine for my containers because it's a minimalist distro with a nice package manager with up-to-date packages. Reasons I don't like common alternatives: * ubuntu - Increasingly hostile to container usage (I tried to install a package recently, the install "succeeded" but at runtime the installed binary simply printed 'oh actually this is a stub, use snap instead' and exited), along with all the other downsides of debian (see below) * debian - Very old packages if you're running a supported version. There's a ton of boilerplate to make apt behave itself in a container environment, something like "apt-get update && DEBIAN_FRONTEND=non-interactive apt-get install --assume-yes --no-install-recommends PACKAGE", compare to "apk --update add PACKAGE". * distroless - More work to create and manage, can't install things ad-hoc in a running container for debugging purposes As it is, I use debian and put up with the annoyances and need to occasionally install things from source to get a modern version. But there's really no good options. Alpine would be amazing, except I've hit too many problems with musl (though I'm sure it's not actually musl's fault). If someone was advertising "alpine but with glibc" and it actually WAS that (not "alpine with glibc tacked on top"), I'd use it in a heartbeat.
- WesolyKubeczek 5y ago
  > ubuntu - Increasingly hostile to container usage (I tried to install a package recently, the install "succeeded" but at runtime the installed binary simply printed 'oh actually this is a stub, use snap instead' and exited) Was it chromium?
- vbezhenar 5y ago
  What about RedHat or CentOS images? Check out redhat/ubi8-minimal for example.
- jleahy 5y ago
  Arch?
- WesolyKubeczek 5y ago
  Have you ever heard of Fedora? They have a base container image.
- 5y ago

IshKebab 5y ago

Yeah I thought the whole point of Alpine was that it abandoned the insanity of glibc for the relative sanity of musl. My only guess is that they like Alpine but want to run some binary software that links with glibc.

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 ago
  Yes. Exactly this.
- mattbnr32 5y ago
  100%
- jart 5y ago
  This 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.
yjftsjthsd-h 5y ago
> My only guess is that they like Alpine but want to run some binary software that links with glibc. There's also gcompat for that, although I don't know how comprehensive that is
stu2010 5y ago
musl is definitely more developer-friendly than glibc, which may lead to a brighter future for it, but right now at this time there's significant downsides to choosing musl. Performance in real world applications is worse on musl vs glibc, at a level that can result in higher latencies and needing to spend more on compute resources to serve a given level of load.

ekimekim 5y ago

I want to use alpine for my containers because it's a minimalist distro with a nice package manager with up-to-date packages. Reasons I don't like common alternatives: * ubuntu - Increasingly hostile to container usage (I tried to install a package recently, the install "succeeded" but at runtime the installed binary simply printed 'oh actually this is a stub, use snap instead' and exited), along with all the other downsides of debian (see below) * debian - Very old packages if you're running a supported version. There's a ton of boilerplate to make apt behave itself in a container environment, something like "apt-get update && DEBIAN_FRONTEND=non-interactive apt-get install --assume-yes --no-install-recommends PACKAGE", compare to "apk --update add PACKAGE". * distroless - More work to create and manage, can't install things ad-hoc in a running container for debugging purposes As it is, I use debian and put up with the annoyances and need to occasionally install things from source to get a modern version. But there's really no good options. Alpine would be amazing, except I've hit too many problems with musl (though I'm sure it's not actually musl's fault). If someone was advertising "alpine but with glibc" and it actually WAS that (not "alpine with glibc tacked on top"), I'd use it in a heartbeat.

WesolyKubeczek 5y ago
> ubuntu - Increasingly hostile to container usage (I tried to install a package recently, the install "succeeded" but at runtime the installed binary simply printed 'oh actually this is a stub, use snap instead' and exited) Was it chromium?
vbezhenar 5y ago
What about RedHat or CentOS images? Check out redhat/ubi8-minimal for example.
jleahy 5y ago
Arch?
WesolyKubeczek 5y ago
Have you ever heard of Fedora? They have a base container image.
5y ago