5 ms·

Alpine’s use of musl means only the truly insane would be leaping to its defense. The inability to support DNS over TCP was a problem for years. Outside of that

Alpine’s use of musl means only the truly insane would be leaping to its defense. The inability to support DNS over TCP was a problem for years. Outside of that, so many things presuppose glibc. It’s an endless source of weird. It doesn’t make the news cause it’s a hobby os that was made important when we decided the size of the container mattered most.

nerdbaggy 3y ago
It has actually been around since 2008. I’m not sure how it became so popular for docker. https://wiki.alpinelinux.org/wiki/Alpine_Linux:Trivia https://wiki.alpinelinux.org/wiki/Alpine_Linux:Trivia
- duped 3y ago
  Bandwidth costs and download/upload speed
COGlory 3y ago
NAND is like pennies/GB. I seriously don't understand the musl thing. It has caused me endless headaches and drives me up a wall.
- outime 3y ago
  There are other things to consider, specially data transfer and build times (apk is much faster than apt in my experience). If these and other benefits are worth the trouble of musl is up to each individual.
- nerdbaggy 3y ago
  Alpine and musl were originally crated for embedded devices, hence the small size. It is interesting how it has become so popular in docker. https://musl.libc.org/about.html https://musl.libc.org/about.html
  - re-thc 3y ago
    Before other OS offered slim and smaller variants and optimized for size, Alpine was the best bet. At some point the difference was huge and that meant huge savings and a increase in productivity.
- GuB-42 3y ago
  As a non-user, I think such variety is a good thing. Not using the same thing everyone uses forces developers to care about standards rather than to assume compatibility just because it is how the favorite implementation works. Same reason why it is a good thing that a popular browser that is not Chromium-based exists.
- duped 3y ago
  Memory is not cheap in the cloud nor is bandwidth, so optimizing for image/container size is quite cost effective. Also every headache I've had with musl libc is because glibc is insane, not because there is a problem with musl. It should be trivial to swap out your standard library, as that is the entire point of dynamic loading. Yet you cannot actually swap out the dynamic library that nearly every program on your system will need, because it's not actually a library.
  - hinkley 3y ago
    People often forget that bandwidth is time. A significant fraction of redeploy time for me is docker images, and that's using alpine base images. It would be (was) far worse with something else.
    - dharmab 3y ago
      If you are optimizing for image size, Alpine is not the best choice. For example, Distroless (https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless) has options 50% smaller than Alpine.
      - hinkley 3y ago
        My other options seem to be to use more Google software or more RedHat software and both of those have been in the doghouse for some time. I’d be more likely to use CoreOS as at least I can claim peer pressure, and potential layer savings.
    - sofixa 3y ago
      That's why the best option is scratch containers, they have pretty much nothing outside of the stuff you add in manually (like your binaries).
      - hinkley 3y ago
        I’m not fucking around with a container that doesn’t have a package manager in it. apk does a pretty good job of not being populated with hot garbage.
- sacnoradhq 3y ago
  There are FOSS projects that sound nice and desirable but are too impractical to use in the real world. I call them "libmagicponies". On a related topic, I don't use Ubuntu, Debian, Alpine, Arch, Gentoo, Rocky, Alma, Fedora, or {Free,Open,Net}BSD. I use CentOS 9 stream for most things: it's basically RHEL's kernel and it powers 100M's-1 B machines.
  - adrian_b 3y ago
    Instead of saying "too impractical to use in the real world", which is obviously false, since many other people have been using at least a part of those in the real world for decades with excellent results, you should say that there are such projects that you have never felt the need to learn about, because you happened to find one that covered well your needs, so you never had any reason to explore alternatives, which is perfectly fine.
  - appleflaxen 3y ago
    That's a really funny comment, but it seems unnecessarily perjorative when there's an entire Linux distro built on this specific example of your magic pony. Your position might be sufficiently extreme that it warrants reconsidering.
- 112233 3y ago
  Yeah, and the devices with embedded linux firmware also are pennies apiece. Not every linux installation is a banking mainframe, and not every ARM soc even gets those NANDs.
firen777 3y ago
> The inability to support DNS over TCP was a problem for years. I'm no subject matter expert, [but support seems to be coming soon?](https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_295619 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_2...)
- silisili 3y ago
  Yes, but people have been complaining for -years-, because it was broken. And rather than listen to reason, the author ignored it because of his own misunderstanding of an RFC...
  - justinclift 3y ago
    Heh Heh Heh Looks like the patch isn't very long either, so hopefully it'll be fairly solid: https://git.musl-libc.org/cgit/musl/commit/?id=51d4669fb97782f6a66606da852b5afd49a08001 https://git.musl-libc.org/cgit/musl/commit/?id=51d4669fb9778...
qalmakka 3y ago
Glibc is a nasty piece of software full of nonstandard GNUisms that basically implements a separate standard. I've fought for years against the fact they've got functions that are not found in any other libc and have different behaviours depending on macros, often conflicting with POSIX or BSD variants. The fact the project was run for almost 20 years by a guy that managed it in a dictatorial style was a huge reason why so many alternative libc existed (that, and the licensing). Few people here remember about EGLIBC I guess. Glibc is also such a mess that it still does not compile with Clang, after _decades_, due to all the crazy GCC extensions they rely on. An attempt is cyclically started and then promptly aborted when some new crazy nonsense is found. For instance, last time I checked they not only used the completely insane folly that GCC nested functions are, but they also relied on GCC attributes so nasty that LLVM never bothered implemented them (like renaming functions at code generation). Using these extensions are not really necessary, and I've a strong suspicious it was more of an attempt by the GNU authors to prevent distributions to ever consider not using GCC as their main compiler. Also how name resolution is implemented in Glibc means you can't really statically link with it. If you've ever noticed, most "statically linked executables" are not in fact statically linked, but require ld.so just for libc. There are good reasons to disallow statically linking libc, but this is not one of them. Especially since the only stable API on Linux is the kernel interface, so the only way to not have to worry about future Glibc breakage is to either link with Musl or live with the risk.
- physicsguy 3y ago
  I get where you’re coming from but it’s impractical for many use cases to switch. I work in Python; pretty much no extension packages have a pre-compiled Musl version so you end up spending a ton of time compiling things!
  - ftaghn 3y ago
    https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/ >Using Alpine can make Python Docker builds 50× slower Musl is a dire mistake.
- CHY872 3y ago
qwery 3y ago
Who is leaping? Only the truly insane would be lashing out at Alpine just because of its use of musl.
Brian_K_White 3y ago
The size of the container matters most when we decided every executable needed to come wrapped in it's own OS.
planetafro 3y ago
This is patently false. Tons of Enterprise orgs use Alpine for security concerns, ease of administration, and size. I guess all those prod microservices existence is "insane".

nerdbaggy 3y ago

It has actually been around since 2008. I’m not sure how it became so popular for docker. https://wiki.alpinelinux.org/wiki/Alpine_Linux:Trivia https://wiki.alpinelinux.org/wiki/Alpine_Linux:Trivia

duped 3y ago
Bandwidth costs and download/upload speed

COGlory 3y ago

NAND is like pennies/GB. I seriously don't understand the musl thing. It has caused me endless headaches and drives me up a wall.

outime 3y ago
There are other things to consider, specially data transfer and build times (apk is much faster than apt in my experience). If these and other benefits are worth the trouble of musl is up to each individual.
nerdbaggy 3y ago
Alpine and musl were originally crated for embedded devices, hence the small size. It is interesting how it has become so popular in docker. https://musl.libc.org/about.html https://musl.libc.org/about.html
- re-thc 3y ago
  Before other OS offered slim and smaller variants and optimized for size, Alpine was the best bet. At some point the difference was huge and that meant huge savings and a increase in productivity.
GuB-42 3y ago
As a non-user, I think such variety is a good thing. Not using the same thing everyone uses forces developers to care about standards rather than to assume compatibility just because it is how the favorite implementation works. Same reason why it is a good thing that a popular browser that is not Chromium-based exists.
duped 3y ago
Memory is not cheap in the cloud nor is bandwidth, so optimizing for image/container size is quite cost effective. Also every headache I've had with musl libc is because glibc is insane, not because there is a problem with musl. It should be trivial to swap out your standard library, as that is the entire point of dynamic loading. Yet you cannot actually swap out the dynamic library that nearly every program on your system will need, because it's not actually a library.
- hinkley 3y ago
  People often forget that bandwidth is time. A significant fraction of redeploy time for me is docker images, and that's using alpine base images. It would be (was) far worse with something else.
  - dharmab 3y ago
    If you are optimizing for image size, Alpine is not the best choice. For example, Distroless (https://github.com/GoogleContainerTools/distroless https://github.com/GoogleContainerTools/distroless) has options 50% smaller than Alpine.
    - hinkley 3y ago
      My other options seem to be to use more Google software or more RedHat software and both of those have been in the doghouse for some time. I’d be more likely to use CoreOS as at least I can claim peer pressure, and potential layer savings.
  - sofixa 3y ago
    That's why the best option is scratch containers, they have pretty much nothing outside of the stuff you add in manually (like your binaries).
    - hinkley 3y ago
      I’m not fucking around with a container that doesn’t have a package manager in it. apk does a pretty good job of not being populated with hot garbage.
sacnoradhq 3y ago
There are FOSS projects that sound nice and desirable but are too impractical to use in the real world. I call them "libmagicponies". On a related topic, I don't use Ubuntu, Debian, Alpine, Arch, Gentoo, Rocky, Alma, Fedora, or {Free,Open,Net}BSD. I use CentOS 9 stream for most things: it's basically RHEL's kernel and it powers 100M's-1 B machines.
- adrian_b 3y ago
  Instead of saying "too impractical to use in the real world", which is obviously false, since many other people have been using at least a part of those in the real world for decades with excellent results, you should say that there are such projects that you have never felt the need to learn about, because you happened to find one that covered well your needs, so you never had any reason to explore alternatives, which is perfectly fine.
- appleflaxen 3y ago
  That's a really funny comment, but it seems unnecessarily perjorative when there's an entire Linux distro built on this specific example of your magic pony. Your position might be sufficiently extreme that it warrants reconsidering.
112233 3y ago
Yeah, and the devices with embedded linux firmware also are pennies apiece. Not every linux installation is a banking mainframe, and not every ARM soc even gets those NANDs.

firen777 3y ago

> The inability to support DNS over TCP was a problem for years. I'm no subject matter expert, [but support seems to be coming soon?](https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_295619 https://gitlab.alpinelinux.org/alpine/tsc/-/issues/43#note_2...)

silisili 3y ago
Yes, but people have been complaining for -years-, because it was broken. And rather than listen to reason, the author ignored it because of his own misunderstanding of an RFC...
- justinclift 3y ago
  Heh Heh Heh Looks like the patch isn't very long either, so hopefully it'll be fairly solid: https://git.musl-libc.org/cgit/musl/commit/?id=51d4669fb97782f6a66606da852b5afd49a08001 https://git.musl-libc.org/cgit/musl/commit/?id=51d4669fb9778...

qalmakka 3y ago

Glibc is a nasty piece of software full of nonstandard GNUisms that basically implements a separate standard. I've fought for years against the fact they've got functions that are not found in any other libc and have different behaviours depending on macros, often conflicting with POSIX or BSD variants. The fact the project was run for almost 20 years by a guy that managed it in a dictatorial style was a huge reason why so many alternative libc existed (that, and the licensing). Few people here remember about EGLIBC I guess. Glibc is also such a mess that it still does not compile with Clang, after _decades_, due to all the crazy GCC extensions they rely on. An attempt is cyclically started and then promptly aborted when some new crazy nonsense is found. For instance, last time I checked they not only used the completely insane folly that GCC nested functions are, but they also relied on GCC attributes so nasty that LLVM never bothered implemented them (like renaming functions at code generation). Using these extensions are not really necessary, and I've a strong suspicious it was more of an attempt by the GNU authors to prevent distributions to ever consider not using GCC as their main compiler. Also how name resolution is implemented in Glibc means you can't really statically link with it. If you've ever noticed, most "statically linked executables" are not in fact statically linked, but require ld.so just for libc. There are good reasons to disallow statically linking libc, but this is not one of them. Especially since the only stable API on Linux is the kernel interface, so the only way to not have to worry about future Glibc breakage is to either link with Musl or live with the risk.

physicsguy 3y ago
I get where you’re coming from but it’s impractical for many use cases to switch. I work in Python; pretty much no extension packages have a pre-compiled Musl version so you end up spending a ton of time compiling things!
- ftaghn 3y ago
  https://pythonspeed.com/articles/alpine-docker-python/ https://pythonspeed.com/articles/alpine-docker-python/ >Using Alpine can make Python Docker builds 50× slower Musl is a dire mistake.
CHY872 3y ago

qwery 3y ago

Who is leaping? Only the truly insane would be lashing out at Alpine just because of its use of musl.

Brian_K_White 3y ago

The size of the container matters most when we decided every executable needed to come wrapped in it's own OS.

planetafro 3y ago

This is patently false. Tons of Enterprise orgs use Alpine for security concerns, ease of administration, and size. I guess all those prod microservices existence is "insane".