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

81–90 of 204 posts

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

#81

Post by account42 »

lukeh wrote: post #73
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…

RTLD_LOCAL?

Libraries loaded with RTLD_LOCAL will still have their symbols resolved against those from already loaded libraries as well as the main executable. Looks like there is dlmopen() in glibc since ~2005 though and there is libcapsule [0] which makes it actually usabel - neat.

[0] https://github.com/dezgeg/libcapsule

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

#82

Post by herf »

I think we need more well-maintained "parts" that can be used as alternatives to libc. For instance, string operations can be 5x faster on AVX2, but not every distro provides this code.

I recently upgraded some Centos 6 machines (glibc 2.17) to Debian 10 (glibc 2.28) and system-provided strstr got about 5x faster, which was really important to my binary. I imagine similar differences exist between musl and glibc, due to lack of AVX2 or some other Intel optimizations in musl.

But meanwhile, everyday functions like strstr or memcmp (that don't even allocate memory) are totally glued to the system libc (often with a slow version for your architecture). There is no broken-out "fast intel string ops" library that you can link with to ensure great+consistent performance on your target CPU (though I guess you could roll your own with nasm).

Are big shared libc libraries good for security or other reasons? Maybe. But it does not make performance consistent across distros. It's fine for different distros to be 10% different in speed, but it's really not okay for them to be 500% apart.

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

#83

Post by rrdharan »

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 have trust in it.

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

#84

Post by ekimekim »

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 downsides of debian (see below)

* debian - Very old packages if you're running a supported version. There's a ton of boilerplate to make apt behave itself in a container environment, something like "apt-get update && DEBIAN_FRONTEND=non-interactive apt-get install --assume-yes --no-install-recommends PACKAGE", compare to "apk --update add PACKAGE".

* distroless - More work to create and manage, can't install things ad-hoc in a running container for debugging purposes

As it is, I use debian and put up with the annoyances and need to occasionally install things from source to get a modern version. But there's really no good options. Alpine would be amazing, except I've hit too many problems with musl (though I'm sure it's not actually musl's fault). If someone was advertising "alpine but with glibc" and it actually WAS that (not "alpine with glibc tacked on top"), I'd use it in a heartbeat.

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

#85

Post by fanf2 »

ariadneconill wrote: post #49
mwcampbell wrote: post #47

Earlier quoted context omitted.

Does it matter whose fault it is when one just needs to ship a product and keep it running reliably? I'm conflicted on this. I'm currently running an Alpine-based container in production but am thinking about revisiting the choice of base image. On the one hand, using a smaller base system and (especially) a simpler libc translates to a smaller attack surface, and less noise in static scans for vulnerabilities. So I…

alternatively you could just use a dedicated local resolver

unfortunately that will not solve the problem: DNS RRsets cannot be split up, so if the answer is too big for UDP, it will still be too big when requested via a local resolver

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

#86

Post by WastingMyTime89 »

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?

Historically speaking? Yes.

C and Unix are considerably older than Linux after all.

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

#87

Post by MrStonedOne »

faho wrote: post #11
hhsbz wrote: post #8

Earlier quoted context omitted.

I think it's clear from the website that this is based on Alpine and not part of the project https://hub.docker.com/r/frolvlad/alpine-glibc/ Without context, I think what this guy is pissed off about is that this project enables people to use alpine to run proprietary software.

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…

> > what this guy is pissed off

>Please don't assume everyone is a "guy". In this case, Ariadne is not a "he" (she uses "she"), so a male-coded word like "guy" is ill-fitting.

Please do not mince words, people have a tenancy to refer to their own gender identity when referring to people who's gender identity they do not know. You knew what they meant.

from the hn guidelines:

> Please respond to the strongest plausible interpretation of what someone says, not a weaker one that's easier to criticize. Assume good faith.

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

#88

Post by MrStonedOne »

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.

Alpine is free to provide a solution to the problem then.

Complaining about the problem isn't going to be productive, and until they publicize a way to convey you are a fork of the alpine project they will have this issue.

Welcome to FOSS.

xchat solved this with ychat.

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

#89

Post by minxomat »

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 proposed solution here is to prevent installation of the package, which is a valid solution. You can still set it up if you want, but Alpine isn't going to let you footgun yourself so easily.

Homebrew does the same: https://github.com/Homebrew/brew/blob/3476ca7b8ff889ef61e657...

Exclusions for compatibility and security reasons are not the same as "taking them down". It's linux after all.

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

#90

Post by riwsky »

d3nj4l wrote: post #59
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.

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

That’s a bad analogy. Use of Rails isn’t broken on a technical level; use of glibc on alpine is.
Post reply on HN