There is no such thing as a “glibc based alpine image”
1–10 of 204 posts
Re: There is no such thing as a “glibc based alpine image”
#2I'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.
Re: There is no such thing as a “glibc based alpine image”
#3I'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.
If it's alpine with glibc I don't see what's wrong with calling it that
Re: There is no such thing as a “glibc based alpine image”
#4I'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.
If it's alpine with glibc I don't see what's wrong with calling it that
What's wrong with that is the reason trademarks exist: Confusion.
If something is called "alpine-glibc", it's reasonable to expect that it's by the alpine people and supported like alpine.
This, as we see here, annoys the alpine people because they now get bug reports and support requests from people using it, and have to direct people elsewhere. And when it doesn't work, they get the hit to their image even tho they've had nothing to do with it.
Re: There is no such thing as a “glibc based alpine image”
#5I'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.
If it's alpine with glibc I don't see what's wrong with calling it that
It makes it look like an "official" project.
Just give it a different name and explain that it's Alpine with glibc somewhere
Re: There is no such thing as a “glibc based alpine image”
#6I'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.
If it's alpine with glibc I don't see what's wrong with calling it that
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.
Re: There is no such thing as a “glibc based alpine image”
#7A 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 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.
- Forward-compatibility is not really considered, where you update your libraries and your existing app becomes more powerful.
- The dynamic linker doesn't allow you to load two different library versions at the same time (without a lot of contortions). You would think you could do `dlopen` and `dlsym` on two different `.so` files, and then just have separate function pointers to each version's functions. But the linker loves to load all the symbols into a global namespace for some reason.
I'm sure there are ways to overcome all of this, but I feel too young to understand how it got this way and to old to learn it propertly :-P. If I were to design a new system today, I'd probably do something like .NET's global assembly cache: Just dump all library versions in /lib, and have the linker pick the best one at runtime. And make it easy to detect and react to a missing lib at runtime.
Re: There is no such thing as a “glibc based alpine image”
#8Earlier quoted context omitted.
If it's alpine with glibc I don't see what's wrong with calling it that
What's wrong with that is the reason trademarks exist: Confusion. If something is called "alpine-glibc", it's reasonable to expect that it's by the alpine people and supported like alpine. This, as we see here, annoys the alpine people because they now get bug reports and support requests from people using it, and have to direct people elsewhere. And when it doesn't work, they get the hit to their image even tho they…
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.
Re: There is no such thing as a “glibc based alpine image”
#9I'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.
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.
Re: There is no such thing as a “glibc based alpine image”
#10"I don't like you exercising your right to foss, so we are going to make using foss harder for you".
Foss shouldn't be about us going out on our way to block others.