Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There is no such thing as a “glibc based alpine image”

ariadne.space

Post reply on HN
Print view View original

91–100 of 204 posts

Re: There is no such thing as a “glibc based alpine image”

#91

Post by vbezhenar »

ekimekim wrote: post #84
WesolyKubeczek wrote: post #63

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

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 d…

What about RedHat or CentOS images? Check out redhat/ubi8-minimal for example.

Re: There is no such thing as a “glibc based alpine image”

#92

Post by masklinn »

WJW wrote: post #68
p2t2p wrote: post #28

Earlier quoted context omitted.

Adding to the other responder. Traditionally, in Unix libc is part of the OS. This situation is different in Linux but Linux is an outlier here, if we look at various BSDs they keep libc in the same tree as kernel.

If the outlier has >100x as much market share as the rest of the other unixes combined, is Linux really still the outlier?

Yes. It explains why things work the way they do, and have since long before linux was a thing.

Re: There is no such thing as a “glibc based alpine image”

#93

Post by hibikir »

IshKebab wrote: post #67
WesolyKubeczek wrote: post #63

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

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.

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.

Re: There is no such thing as a “glibc based alpine image”

#94

Post by Karunamon »

faho wrote: post #51
im3w1l wrote: post #50

Earlier quoted context omitted.

FROM frolvlad/alpine-glibc That namespacing does make it look pretty unofficial to my eyes.

But do you know if alpine does official docker images namespaced as e.g. alpine/? Is "alpine-glibc" an official project and someone just helpfully made the image (or an image including an official glibc package)? Or is this a prerelease? Without a deep knowledge of alpine (or now reading this post) I couldn't answer any of these questions and I'm not sure I wouldn't try to go to alpine for bug reports. I think there'…

The answer to the first question is an obvious yes, and it's obvious to anyone that uses Docker. No deep knowledge required.

If you want Alpine, you do FROM alpine:(version).

https://hub.docker.com/_/alpine

Re: There is no such thing as a “glibc based alpine image”

#95

Post by yjftsjthsd-h »

IshKebab wrote: post #67
WesolyKubeczek wrote: post #63

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

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.

> 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

Re: There is no such thing as a “glibc based alpine image”

#96

Post by masklinn »

synergy20 wrote: post #64
hygh wrote: post #56

musl's thread stack size is too low (128K), so many open source test suites segfault. I do not understand why musl doesn't move to at least 512K like OSX. The generous 8192K glibc thread stack size isn't actually used on Linux with overallocation, so I fail to see why musl chose that small default in the first place.

maybe, musl by design, is for resource limited embedded boxes. multiple threads with large stack size will eat up RAM. If you need larger thread stack I believe you can set it in the code. "Since 1.1.21, musl supports increasing the default thread stack size via the PT_GNU_STACK program header, which can be set at link time via -Wl,-z,stack-size=N." Of course you can always use pthread_attr_setstacksize

> maybe, musl by design, is for resource limited embedded boxes. multiple threads with large stack size will eat up RAM.

It won’t really: that’s vmem, it’ll only need a bit of memory for the accounting of the mappings in the kernel.

Re: There is no such thing as a “glibc based alpine image”

#97

Post by jleahy »

ekimekim wrote: post #84
WesolyKubeczek wrote: post #63

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

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 d…

Arch?

Re: There is no such thing as a “glibc based alpine image”

#98

Post by lalaithion »

ricardobeat wrote: post #65

This post would have done fine without the whole “we do not approve” / “we need to take them down” attitude. Call it a terrible idea, explain why, recommend against it, and be done with it; one shouldn’t need approval to maintain a fork, and they are not misrepresenting what it is. I find the animosity a little off-putting.

The only reason to have the "we need to take them down" attitude would be if they are violating your license or glibc's license.

Re: There is no such thing as a “glibc based alpine image”

#100

Post by Denvercoder9 »

ntauthority wrote: post #21
p2t2p wrote: post #16

Earlier quoted context omitted.

We had to stop using alpine because we have to resolve a DNS name that resolved in a 100 hosts. Musl fails to resolve that because it does not support “upgrade to TCP” and the response does not fit into single UDP packet so it gets truncated, so node fails to resolve the name. And not only node, normal Linux tools as well. And the author says it’s a feature, not a bug so for me it is kinda hard to take that thing ser…

Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I thought Node already depended on c-ares, why is it failing on this?

I certainly don't want DNS resolution inside the kernel, and outside the kernel, libc is as "base OS" as "base OS" comes, imo.
Post reply on HN