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

51–60 of 204 posts

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

#51

Post by faho »

im3w1l wrote: post #50
faho wrote: post #11

Earlier quoted context omitted.

It doesn't outright state anywhere that it's not an official alpine product, and I don't know if everyone reads the site - many people will just copy the "FROM frolvlad/alpine-glibc" from elsewhere. In any case, the Alpine people would know, and they apparently think it's a problem. >Without context, But you have context here! It has issues with symbol versioning! There is "strange behavior and possible crashes, ". T…

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's a reasonable potential for confusion, even with the namespace. (but granted, I don't use docker either, so maybe this is a common thing)

And I assume the alpine people (like the author) know that they get bug reports for it and that the issues with it cause bad publicity, and that that's the context for the post and the proposal to block the package.

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

#52

Post by wyager »

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…

Ha, I ran into that one at work one time in our custom DNS resolver and had to add TCP upgrade. I was very confused why the tool worked when I shelled out to dig but not when I did the “correct” thing and used a resolver library. I’m very surprised that a project as big as musl would not have support for this.

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

#53

Post by cormacrelf »

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…

There’s a solution to all of these problems, tried and tested, and older than the concept of package registry namespacing called “registering a trademark and sending a cease and desist letter”. Works great.

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

#54

Post by throwthere »

tyingq wrote: post #38
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…

https://twitter.com/RichFelker/status/994629795551031296 Yikes.

Oh wow. There's a big contrast between Linus screaming "don't break userspace," and that sort of crusade against the spec.

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

#55

Post by Aissen »

throwthere wrote: post #54
tyingq wrote: post #38

Earlier quoted context omitted.

https://twitter.com/RichFelker/status/994629795551031296 Yikes.

Oh wow. There's a big contrast between Linus screaming "don't break userspace," and that sort of crusade against the spec.

It's not the same because this is not an ABI, but an API needing a recompilation. It's actually explained in the article why it is not an ABI.

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

#56

Post by hygh »

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.

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

#57

Post by d3nj4l »

dijit wrote: post #36
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…

> There's a docker image called alpine-ruby. There may be, but that seems dangerous. Frankly you can name a dockerhub entry anything you like as long as it's not taken. But you probably wanted ruby:alpine anyway.

> Frankly you can name a dockerhub entry anything you like as long as it's not taken.

Yeah, definitely, just like you can name a library like Vue vue.js. Does that mean Vue is an official project of the JS Committee? No, of course not! It's bizarre to think otherwise, and that doesn't mean Vue should avoid using js in its name because somebody could get confused. Putting something like ".js" or "rb" (like in "dry-rb") in a name is a signal for a target, and not always trademark infringement.

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

#58

Post by devit »

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?

Someone added it to libc and now it needs to be provided forever for compatibility.

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

#59

Post by d3nj4l »

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.

> 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.

That's fine! I've seen this happen with Rails all the time: newbies do something in Rails behaves differently in Rails than in vanilla Ruby, because Rails redefines core Ruby classes in ActiveSupport, and they get frustrated and angry when the thing they've copied from elsewhere doesn't work as they expect. Whether that's good or not is another matter, but that doesn't mean Ruby should prevent people from running Rails! You really shouldn't be obsessed with people liking your project to the point where you prevent anybody from doing anything with it that you haven't personally authorized.

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

#60

Post by lolc »

encryptluks2 wrote: post #19
creshal wrote: post #6

Earlier quoted context omitted.

Except it's not, as it mixes glibc with musl in ways that induce undefined behaviour you don't expect. If it was recompiling all packages to use glibc, the name would be more appropriate… but also still a trademark violation.

So, of the 49,530 images that show up with several using Alpine somewhere in the name or description... you think this is a trademark violation how? Alpine is synonymous with lightweight images. Several people and vendors use it in their image names.

I do expect images with "alpine" in the name to be based on the Alpine distro. And not some weird bastard of Alpine. And I see no problem with them asserting their trademark here.
Post reply on HN