There is no such thing as a “glibc based alpine image” • Hacker News Board

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

#201

Post by geocar » Fri, Aug 27, 2021, 5:53 PM UTC

Spivak wrote: post #200

geocar wrote: post #157

Earlier quoted context omitted.

That doesn’t answer my question at all, unless you mean that people make bad engineering decisions because they like using cute things. dig is not affected by alpine’s decision here because dig does not use gethostbybame. No DNS client would be. This affects gethostbyname which very few programs in my experience even support robustly, so any “use-case” where someone is using 100 results would surprise me. It seems if…

I'm not really sure what you mean by "support gethostbyname robustly" or that "dns clients aren't affected." Because on a GNU/Linux system the only correct method of resolving DNS is by using gethostbyname (or nowadays getaddrinfo) and friends. If you do anything else things will be broken because you aren't following the distro's/system integrator's/sysadmin's/user's configured NSS modules for name resolution. And g…

> on a GNU/Linux system the only correct method of resolving DNS is by using gethostbyname

I don't think that's right.

gethostbyname() doesn't query DNS, it queries names, which includes /etc/hosts, and possibly NIS, active directory, and other possible things. Most applications would never be expecting 100 results from one of these queries and many will not tolerate it well.

Specialised users of gethostbyname() can certainly do better, but what I doubt is the wisdom of such specialisation: It certainly has nothing to do with the application -- it is literally under the control of the network administrator as you are well aware. Specialisation can occur in your application, but it can just as easily specialise another way.

On the other hand, if your application really wants to specially speak to Consul's DNS (as opposed to whatever the network administrator is doing) it can definitely use res_query()

> so it's not exactly hard to support 100 results

Maybe we mean different things by "support": What do you do with them?

> I'm not really sure what you mean by "support gethostbyname robustly"

When most applications connect to a host they get from gethostbyname they often connect to the first, and give up if the connection opens and resets: This is exceptionally common with load balancers and address translation. To those applications, what is the point of giving them multiple results in this situation?

A few applications try to handle the result robustly: connect to a random member of the list, or connect to several in parallel and try the request in parallel. Some applications do really wild stuff here to make a good user-experience.

Most do not.

When someone types `ping google.com` (for example) you only ever get one result. If that name doesn't ping, it doesn't try another.

Most are like that.

Hopefully that makes what I mean by "robustly" clearer.

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

#202

Post by encryptluks2 » Sat, Aug 28, 2021, 10:45 PM UTC

undecisive wrote: post #199

encryptluks2 wrote: post #149

Earlier quoted context omitted.

This isn't a fork. I seriously wonder how many people here are commenting without having any clue as to what they are talking about. It is simply a package that you install with apk in Alpine.

Thanks for your "clarification", however I don't think you've fully grokked the situation yourself. I think the thing that was referred to as a "fork" was the docker image, which uses the package you mention, and afaik is the primary way that people are receiving that package and believing it to be blessed by the Alpine gods. In the sense that the container is a distribution in its own right that deviates from the ro…

So, let's say I create a Docker Hub image with alpine as the base, then I install a package from the Alpine repo.. let's say Chromium. So now you're telling me, that is a fork of Alpine and I should be forced to recompile Alpine entirely anytime I want to install a package and create a Docker Hub image? I guess that is one way to ensure no one uses Alpine for container images ever again.

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

#203

Post by rurban » Mon, Aug 30, 2021, 5:16 AM UTC

croes wrote: post #169

rurban wrote: post #99

It should be called atlas-glibc or even himalaya-glibc, not related to alpine at all.

And if I need glibc for alpine how do I search for it?

There is no such thing as glibc on alpine. Alpine us by definition free of glibc bloat.

Similar to devuan being free of systemd. How do you argue a systemd package for devuan should he handled?

If you need a minimal distro, which supports musl and glibc as alternative use void.

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

#204

Post by undecisive » Tue, Aug 31, 2021, 8:30 AM UTC

encryptluks2 wrote: post #202

undecisive wrote: post #199

Earlier quoted context omitted.

Thanks for your "clarification", however I don't think you've fully grokked the situation yourself. I think the thing that was referred to as a "fork" was the docker image, which uses the package you mention, and afaik is the primary way that people are receiving that package and believing it to be blessed by the Alpine gods. In the sense that the container is a distribution in its own right that deviates from the ro…

So, let's say I create a Docker Hub image with alpine as the base, then I install a package from the Alpine repo.. let's say Chromium. So now you're telling me, that is a fork of Alpine and I should be forced to recompile Alpine entirely anytime I want to install a package and create a Docker Hub image? I guess that is one way to ensure no one uses Alpine for container images ever again.

I'll be boring and ignore the straw man if you don't mind, and continue to focus on the theme of "people here are commenting without having any clue as to what they are talking about"

> then I install a package from the Alpine repo

You might want to do some research - from the readme: "The current installation method for these packages is to pull them in using wget or curl and install the local file with apk" - https://github.com/jeanblanchard/docker-alpine-glibc/blob/ma... But yes, if someone builds a chrome package that completely screws up other packages in alpine, to the point that the Alpine maintainers are being inundated with bogus support requests then yes, ONE SOLUTION is to recompile the project in a way that means that the package is no longer a problem. You have solved the problem with a fork.

The other solution is to make it very very clear in your naming and documentation that this is not a supported alpine image, and that bug reports should go to the maintainer of the image, not Alpine themselves.

However, either way, you could be argued to have created a new "distribution" of software that is no longer truly Alpine linux, but is based on Alpine linux. Including Alpine in the name is not necessary, and in this case it seems, not desirable.

Even if your codebase is not a fork, you have "forked off" from the original distribution.