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

151–160 of 204 posts

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

#151

Post by branneman »

hibikir wrote: post #93
IshKebab wrote: post #67

Earlier quoted context omitted.

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

Yes. Exactly this.

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

#152

Post by kevincox »

zokier wrote: post #62
account42 wrote: post #33

Earlier quoted context omitted.

> It doesn't allow you to install minor versions of the same library at the same time (thats how you end up with all these 1.so, 2.so) Minor versions should be ABI-compatible so you should only need the newer of the two. For ABI-incompatible changes, a different SONAME is appropriate, though the convention would be .so.0 -> .so.1 etc. > So if you want a binary to work across multiple distributions, you can build it o…

> Symbol versioning does not prevent you from updating the implementation of old symbol versions in a compatible way. As I understand the problem is that if application is compatible with both version X and X+1, then there is no way to compile binary that would preferentially use X+1 when available but also work with X. So applications can not reap the benefits of new version without dropping support with old version…

What benefits are you talking about. In general benefits not related to the ABI will be gained when updating glibc. For benefits related to the ABI the gains are probably so small that conditionally using the new ABI is likely not worth it in almost all cases.

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

#153

Post by encryptluks2 »

lolc wrote: post #60
encryptluks2 wrote: post #19

Earlier quoted context omitted.

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.

This is merely a package you install on Alpine so it isn't a fork. Did you not do any independent research and just assume? Want to move the goalposts?

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

#154

Post by nyanpasu64 »

rrdharan wrote: post #83
captainmuon wrote: post #7

A side-note about glibc: I have only ever had problems with glibc versioned symbols. The only thing they more or less do is to pin an old executable to old library versions, and you can supposedly install a newer version of the library. You then save a little bit of disk space. - It doesn't allow you to install minor versions of the same library at the same time (thats how you end up with all these 1.so, 2.so) - So i…

> So if you want a binary to work across multiple distributions, you can build it on a really old CentOS and if you are lucky it will work, but I have no trust in this. For a very long time (decades?) VMware's Linux build system relied on exactly this ability, and managed to ship and support a binary package on many different Linux distributions using this approach. Not sure if it still works this way, but I'd say I…

Is the libstdc++ (whether static or dynamic) ABI stable enough for one C++ binary to run across many Linux distributions?

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

#155

Post by stonemetal12 »

r1ch wrote: post #70
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.

I think this comes from them using "Alpine" in the name for something that is not from the Alpine Linux team nor desired / supported by them. Users could be confused into thinking it's something officially supported and clog up official support channels with unrelated issues.

It uses "glibc" in the name, should we assume it is an official glibc project? Perhaps by using both in the name we should assume it is an official announcement that glibc and alpine Linux have merged and are now one and the same thing!

Or perhaps we should not be dumb and see that it doesn't come from the official channels of either. Therefore we should assume it is some random project that tries to use both, however poor an idea that maybe.

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

#156

Post by tadfisher »

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.

Try nix sometime! When I'm forced to use Docker as a container runtime, nix has made building lightweight images fairly painless without the manual dependency management I see in so many dockerfiles.

https://nix.dev/tutorials/building-and-running-docker-images

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

#157

Post by geocar »

Spivak wrote: post #113
geocar wrote: post #105

Earlier quoted context omitted.

If someone on my team had built an application and put 100 hosts into a DNS server, I would suggest they upload their hosts file to a webserver someplace. 100 hosts just doesn't do anything useful with most applications using gethostbyname() even in glibc, it's going to be slow, and the bug reports you get are going to be really confusing. Custom applications that are prepared to deal with all 100 hosts will be easie…

Service-Discovery-Over-DNS is typically the use-case. It's used as a compatibility layer for software where you either can't or don't want to integrate the native discovery APIs. Consul is a good example of this. You don't actually have to know how to speak Consul to get automatic service discovery, all you have to do is query a DNS name to get the hosts registered for a particular service.

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 you need to write something custom, a www client is better (which consul also supports).

I think if you insist on writing gethostbyname instead of the res_* calls in bind, and robustly handle all results in a sensible way, then that’s silly, and if you have an existing application that works great with ~70 addresses but not 100 I would be curious to know what it is.

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

#158

Post by rkeene2 »

en4bz wrote: post #141
account42 wrote: post #33

Earlier quoted context omitted.

> It doesn't allow you to install minor versions of the same library at the same time (thats how you end up with all these 1.so, 2.so) Minor versions should be ABI-compatible so you should only need the newer of the two. For ABI-incompatible changes, a different SONAME is appropriate, though the convention would be .so.0 -> .so.1 etc. > So if you want a binary to work across multiple distributions, you can build it o…

So `dlmopen`?

I'm always hesitant to use dlmopen() because of the really low limit on number of namespaces your process gets (IIRC, 16).

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

#159

Post by encryptluks2 »

ariadneconill wrote: post #39
sascha_sl wrote: post #37

Earlier quoted context omitted.

It doesn't block it, it requires recompiling musl. https://github.com/docker-library/official-images/pull/10779... This is also a response to inclusion of this broken mess into official docker images, I think alpine putting their foot down is entirely justified here.

correct: we do not want to get stuck with having to deal with angry people who have unstable environments caused by this. and, the conflict option is one of a few options being considered. part of what lead up to this is the fact that we have not taken any public position on mixing glibc and musl runtimes until now. no decision has been made, and won't be made until the TSC meeting next week...

Can it also get brought up there that you come across as a fascist?

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

#160

Post by peter_l_downs »

sgerrand wrote: post #144
pxc wrote: post #140

Earlier quoted context omitted.

j/w: What use cases do you have or have in mind for your glibc package? Do you see it as a temporary step for adding pre-built things to Alpine images during development, before you have time to rebuild them against musl? Do you feel some prod use cases are ‘safe enough’? Or nowadays do you generally prefer the upstream compatibility packages you mentioned?

I don't compile my own software against glibc and run it in Alpine. As mentioned previously, this package was created ~ 6 years ago to run software compiled against glibc (that didn't have the source code available) in Alpine Linux. I don't recommend that anyone uses it over the equivalent Alpine package or compiling your software against musl-c.

And it's been very useful for exactly that purpose -- thank you for providing it (happy user here!)
Post reply on HN