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

21–30 of 204 posts

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

#21

Post by ntauthority »

p2t2p wrote: post #16
Aissen wrote: post #9

Earlier quoted context omitted.

I've had to battle quite a few portability issues, but everytime it was a program incorrectly assuming some sort of behaviour from glibc and not really musl's fault.

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?

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

#22

Post by [deleted] »

encryptluks2 wrote: post #18
diegocg wrote: post #5

Earlier quoted context omitted.

It makes it look like an "official" project. Just give it a different name and explain that it's Alpine with glibc somewhere

It does not. They use Alpine in the name so people can find the image. Searching for Alpine on Docker Hub has 49,530 results. This image doesn't even show up on the first page of results. I think whoever wrote this needs to rethink how ridiculous they are being.

[deleted]

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

#23

Post by silon42 »

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?

Typically, on a modern Linux system, DNS queries from libc (and everything else) will always query a local resolver (example: systemd-resolved).

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

#24

Post by sascha_sl »

d3nj4l wrote: post #13

I don't get it. There's a docker image called alpine-ruby. I presume that isn't supported by the alpine team either, but, honestly speaking, I'm doubtful that's causing enough of a support load on them. If it is, I would assume the reasonable solution to that is to close any support requests with "We are not responsible for that image" or something of that variant, or even requesting the creator of the image to menti…

This is inherently broken, and its brokenness is not obvious or clearly attributable to the hacky glibc.

Imagine debugging an app on this (and possibly not even knowing it's based on an unofficial base image) not knowing this very specific behavior for hours with no results, you'd probably have a very bad impression of alpine.

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

#25

Post by op00to »

encryptluks2 wrote: post #18
diegocg wrote: post #5

Earlier quoted context omitted.

It makes it look like an "official" project. Just give it a different name and explain that it's Alpine with glibc somewhere

It does not. They use Alpine in the name so people can find the image. Searching for Alpine on Docker Hub has 49,530 results. This image doesn't even show up on the first page of results. I think whoever wrote this needs to rethink how ridiculous they are being.

I assumed it did.

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

#26

Post by akerl_ »

sascha_sl wrote: post #24
d3nj4l wrote: post #13

I don't get it. There's a docker image called alpine-ruby. I presume that isn't supported by the alpine team either, but, honestly speaking, I'm doubtful that's causing enough of a support load on them. If it is, I would assume the reasonable solution to that is to close any support requests with "We are not responsible for that image" or something of that variant, or even requesting the creator of the image to menti…

This is inherently broken, and its brokenness is not obvious or clearly attributable to the hacky glibc. Imagine debugging an app on this (and possibly not even knowing it's based on an unofficial base image) not knowing this very specific behavior for hours with no results, you'd probably have a very bad impression of alpine.

I don’t think anybody is arguing that shoving glibc into an Alpine image is a great idea.

But if I decided to make an “alpine-goofy” image where I started with “FROM alpine” and then renamed all the binaries so cp was rm and rm was ls and so on, it would be a stupid idea but not trademark infringement.

Could this project do everybody a favor by adding a banner saying “Hey y’all just FYSA we are not affiliated w/ Alpine upstream, please don’t send them glibc support requests”? Totally. But I’m shocked that Alpine’s approach here is to start by trying to implement a technical blocker for what I can install on my Alpine image, with an offhand remark that maybe they could try talking to the image owner first.

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

#27

Post by faho »

Aissen wrote: post #9
dbt00 wrote: post #2

I've definitely had my share of annoyances with musl-libc and would probably consider building my base images around distroless if that were something I were dealing with right now. In the meantime, it's kinda shitty of someone to casually squat on the alpine linux namespace. If you want to make a small distribution that also ships glibc, then it's not alpine. Don't call it that.

I've had to battle quite a few portability issues, but everytime it was a program incorrectly assuming some sort of behaviour from glibc and not really musl's fault.

I mean, okay, it's the program's fault. But it is part of the trade-off you make using musl, and one that I, personally, wouldn't decide in its favor.

As the user, you have the choice to use musl and "battle quite a few portability issues" (whether that's the program's fault or not!) or to use glibc and not have to battle. If the benefits of musl outweigh that in your opinion, then go ahead. I don't see it.

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

#28

Post by p2t2p »

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?

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.

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

#29

Post by jcelerier »

faho wrote: post #4
hhsbz wrote: post #3

Earlier quoted context omitted.

If it's alpine with glibc I don't see what's wrong with calling it that

What's wrong with that is the reason trademarks exist: Confusion. If something is called "alpine-glibc", it's reasonable to expect that it's by the alpine people and supported like alpine. This, as we see here, annoys the alpine people because they now get bug reports and support requests from people using it, and have to direct people elsewhere. And when it doesn't work, they get the hit to their image even tho they…

It's the old Iceweasel story all over again. Sadly open-source is ill-equipped to handle naming issues.

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

#30

Post by sascha_sl »

akerl_ wrote: post #26
sascha_sl wrote: post #24

Earlier quoted context omitted.

This is inherently broken, and its brokenness is not obvious or clearly attributable to the hacky glibc. Imagine debugging an app on this (and possibly not even knowing it's based on an unofficial base image) not knowing this very specific behavior for hours with no results, you'd probably have a very bad impression of alpine.

I don’t think anybody is arguing that shoving glibc into an Alpine image is a great idea. But if I decided to make an “alpine-goofy” image where I started with “FROM alpine” and then renamed all the binaries so cp was rm and rm was ls and so on, it would be a stupid idea but not trademark infringement. Could this project do everybody a favor by adding a banner saying “Hey y’all just FYSA we are not affiliated w/ Alpi…

These are completely different situations. Wanting glibc compat on Alpine is not an unusual requirement, unlike your "alpine-goofy" image, and the bugs it introduces are subtle and may not show up at all in some use-cases.

Believe it or not, a lot of developers aren't aware we have different libc implementations at all, the "exec format error" or "file not found" errors alpine spits out already create a lot of support burden.

Post reply on HN