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”

#131

Post by deadbunny » Thu, Aug 26, 2021, 4:07 PM UTC

sgerrand wrote: post #128

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.

Maintainer of the Alpine package referenced here. It's called `glibc`, makes no claims on Alpine Linux and certainly isn't a Linux distribution. You install the package in Alpine Linux, nothing else.

Most people's experience with alpin is through containers. Given you provide `alpine-glibc` containers is likely where the confusion comes from. If you don't know the backstory one would easily assume this is an Alpine endorsed container.

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

#132

Post by MrStonedOne » Thu, Aug 26, 2021, 4:13 PM UTC

deadbunny wrote: post #130

MrStonedOne wrote: post #114

Earlier quoted context omitted.

The solution is to seperate the branding from the idea. There is no way for somebody to suggest in the name of their product that they are a downstream of alpine without using the word alpine. alpine linux can fix this by creating and providing a generic word for their flawed-opinionated-mini-linux whatever

> alpine linux can fix this by creating and providing a generic word for their flawed-opinionated-mini-linux whatever Why is it on the Alpine Devs to name a downstream project? Would you ask the Debian devs to name Ubuntu?

they are the ones who have an issue with alpine-glibc's name

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

#133

Post by ludocode » Thu, Aug 26, 2021, 4:15 PM UTC

gunapologist99 wrote: post #110

colejohnson66 wrote: post #77

Earlier quoted context omitted.

That’s not so much glibc’s fault, but the Unix philosophy of /lib, right? Windows’ “solution” to this is to basically require applications to provide their own runtime (such as Qt, GTK, etc.).

Disk space is cheap, particularly when we're talking about libs that consume a few hundred kb each. On the other hand, software distributions should continue to rely on shared libraries, for their own software , but third-party compiled apps that are intended to be cross-distro/cross-arch should try to bundle as much as possible. This is why I prefer /opt over /usr/local for third-party compiled apps.

Maybe. Apps wouldn't have to bundle their own versions of libraries if those libraries actually cared about backwards compatibility. Bundling is just an unfortunate workaround for libraries continually breaking their ABI.

Windows 10 can run virtually all apps compiled against Windows 2000 just fine, and those apps did not have to bundle their own graphical toolkits. Windows has gone through several new toolkits but they always preserve the old ones so that old programs continue to work.

By contrast GTK has regularly broken things between even minor version updates. Distributions also drop the old major versions of toolkits much more quickly. GTK3 was first released in 2011, but by 2018 most distributions no longer provided GTK2 pre-installed.

Is it any wonder that no one can ship and maintain a binary app that targets GTK without bundling it? Of course bundling sure looks like an attractive solution in this environment, but it's the environment that's the problem.

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

#134

Post by puffyvolvo » Thu, Aug 26, 2021, 4:18 PM UTC

MrStonedOne wrote: post #78

ariadneconill wrote: post #41

Earlier quoted context omitted.

I am proposing that we encode something that is already factually accurate: glibc and musl generally do not mix in any way that results in a stable system. Do you not think that distributions should make even a little bit of effort to introduce friction toward scenarios known to break systems? If apk-tools had a soft conflict option, where it printed a warning and required the user to acknowledge that warning somehow…

alpine exists in the open source space and must behave like an open source project. You don't get to tell your users how to use your project. That is the entire fucking point of open source software.

> You don't get to tell your users how to use your project.

Sure I guess but "don't footgun yourself" is pretty different. But I guess some people just like using linux for the novelty of breaking shit and feeling smart about fixing it.

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

#135

Post by dwheeler » Thu, Aug 26, 2021, 4:21 PM UTC

captainmuon wrote: post #34

sambe wrote: post #14

Earlier quoted context omitted.

Would you not just have more subtle, harder to debug problems if it were not for versioned symbols?

I'm not at all against versioning , but found glibc's implementation a source of frustration. It would be great if you could install Qt 5.9, 5.12, 1.14 in parallel and have apps use the latest version (except for that one app that triggers a bug where you fix it to 5.9). This is an actual problem that occurred at work, I had to statically compile Qt in that case. Glibc's idea of lib versions doesn't help here at all…

> It would be great if you could install Qt 5.9, 5.12, 1.14 in parallel and have apps use the latest version (except for that one app that triggers a bug where you fix it to 5.9).

The underlying library-loading system on Linux handles this just fine, and has for decades (look up "soname" for details).

The problem is that system package managers want to load "just the latest" & maintainers have to take extra steps to enable loading of multiple versions.

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

#136

Post by puffyvolvo » Thu, Aug 26, 2021, 4:23 PM UTC

akerl_ wrote: post #32

sascha_sl wrote: post #30

Earlier quoted context omitted.

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

The fact that a downstream image is popular doesn’t make it sane for upstream to want to literally block its existence via code changes.

It does when it's causing excessive load on upstream from users who think what is effectively an outright broken configuration is supported. Preventing footguns and providing users the ability to continue using it if they really really want to seems like a sane option?

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

#137

Post by sgerrand » Thu, Aug 26, 2021, 4:24 PM UTC

deadbunny wrote: post #131

sgerrand wrote: post #128

Earlier quoted context omitted.

Maintainer of the Alpine package referenced here. It's called `glibc`, makes no claims on Alpine Linux and certainly isn't a Linux distribution. You install the package in Alpine Linux, nothing else.

Most people's experience with alpin is through containers. Given you provide `alpine-glibc` containers is likely where the confusion comes from. If you don't know the backstory one would easily assume this is an Alpine endorsed container.

I don't provide "alpine-glibc" Docker images or containers, so I don't really know what you're referencing here. I maintain an Alpine package called `glibc`. Please enlighten me!

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

#138

Post by sgerrand » Thu, Aug 26, 2021, 4:27 PM UTC

gnud wrote: post #127

sgerrand wrote: post #123

Earlier quoted context omitted.

Maintainer of the Alpine package you referenced here. I'm not a "them". ;) I don't see where "Alpine" is used in the package name, unless you're referring to the source repository name. In case it isn't clear, `alpine-pkg-` is a prefix which denotes that the repository contains an Alpine Linux package manifest and configuration. There's nothing in the repo itself which states that this package is published and/or end…

I think they're talking about things like https://hub.docker.com/r/frolvlad/alpine-glibc or https://hub.docker.com/r/jeanblanchard/alpine-glibc

Ah, thanks for the pointer. The blog post referenced the Alpine package I maintain but was obviously implicitly referencing those Docker images.

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

#139

Post by Sohcahtoa82 » Thu, Aug 26, 2021, 4:31 PM UTC

encryptluks2 wrote: post #15

jsiepkes wrote: post #12

Earlier quoted context omitted.

> Foss shouldn't be about us going out on our way to block others. Sure, but this is about the Alpine project getting tired of being mistaken for the maintainers of a fork of their project. How would you feel if the power company would call you every week because they think your someone else and you had to explain the same thing every week?

How are they being mistaken? No where do they claim to be the official Alpine image. This is like saying anyone who uploads an Alpine image with a few self-built packages installed is somehow conflating themselves with representing Alpine Linux, when in fact there is nothing the creator of this image has done to indicate that they are in any way considered the official Alpine project. In fact, Docker Hub has a place…

> How are they being mistaken?

Because the image is named "alpine-glibc", but the "how" is irrelevant. People are getting confused and that's a problem.

> No where do they claim to be the official Alpine image.

Doesn't stop people from being mistaken.

> If someone is mistaking this package as being supported by Alpine Linux as a whole, then they also the same people that would mistake Google for any app installed from the Google Play Store.

Agreed.

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

#140

Post by pxc » Thu, Aug 26, 2021, 4:33 PM UTC

sgerrand wrote: post #122

Maintainer of the Alpine glibc package referenced here. For some background context, this package was originally created to solve a specific problem long before Alpine provided glibc compatibility packages like `libc6-compat` and others. I agree that this package shouldn't be considered "blessed" or an official Alpine package or a default solution for running programs originally compiled against the GNU C library on…

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?