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 Alpine Linux, far from it. The source control repository uses `alpine-pkg-` as a prefix to denote what it's used for—not as a means of assumed official status or such like.
What I find saddening is to see passive aggressive statements like
> I have additionally suggested that the TSC may wish to have the Alpine Council reach out to the alpine-glibc project to find a solution which appropriately communicates that the project is not supported in any way by Alpine.
To the Alpine Linux TSC: please get in contact with me about any and all disclaimers you want to add to this package! I'd love to have these discussions faster and in the open, rather than discovering this disquiet tangentially. Let's get these issues resolved as soon as possible in a way that everyone concerned finds acceptable.
We did not communicate with Sasha because bluntly, we have no objection to the existence of this package itself, but rather third parties distributing the combination to others without disclosing the many caveats about it.
Sasha's package is not the problem, it is the third-party distributors who distribute the final result as an "alpine" image, which leads people to believe that everything is legit about it.
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.
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 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.
> 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 on a really old CentOS and if you are lucky it will work, but I have no trust in this.
As far as glibc or other libraries that take ABI stability seriously go, this does work.
> Forward-compatibility is not really considered, where you update your libraries and your existing app becomes more powerful.
Symbol versioning does not prevent you from updating the implementation of old symbol versions in a compatible way.
> 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.
Having an option to use a separate linking table for specific dlopen calls would be useful, yes.
> 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.
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.
> 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.
You also then can remove the old library file and only have to maintain one for security purposes.
If you have old library versions around, especially in a packaged environment like most Linux distros, then the old code will sit there and potentially no one will be paying attention to it anymore. If you're lucky you'll have some security software (e.g., Nessus, OpenVAS) tell you there's a bug/exploit in it.
If you have only one maintained version of the library installed, with the old symbols embedded, then it's more likely to be paid attention to.
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 if I understand correctly.
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.).
More relevant to the question of libc, the traditional Windows solution was to require applications to distribute or statically compile their own Cruntime. Every release of Visual Studio had its own C runtime. To make matters worse, there was a system C runtime, but most applications didn't link against it, MinGW being a notable exception. AFAIU, this was one of the root culprits for the origin of the notorious DLL Hell. Applications would often crash because libA malloc'd a pointer, which was free'd by libB. That is, there was no shared, global heap. This was a far less obvious pitfall than mixing objects between libA and libB or even libA-v1 and libA-v2. Even if libA-v2 was otherwise backward ABI compatible with libA-v1, if they were built by different versions of Visual Studio you could still end up with heap corruption. Indeed, this could happen if two vendors compiled the exact same source code. If an application install overwrote a library in the shared system folder, boom, applications could begin crashing for no obvious reason.
AFAIU, over the years Windows tried to mitigate this with various hacks for detecting cross-heap pointer freeing. But last time I checked their final approach was to guarantee backward compatibility (including backward heap compatibility) for all future Visual Studio C runtimes; ditto for the system C runtime. IOW, Microsoft committed themselves to maintaining a lot of internal runtime magic to preserve binary compatibility across time, which is functionally what glibc has done using version symbols. Of course, it also became less common on Windows to keep DLLs in shared folders.
The system and the app C runtimes are one and the same in Win10+.
As far as cross-DLL interop: the usual solution was to avoid the C stdlib altogether, and just use the underlying Win32 API functions to manage memory that has to cross the boundary. Or, in the COM land, every object manages its own heap memory, exposing it via the ABI-standard IUnknown::Release.
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.
>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.
They do if they're buildtusing Qt, GTK, WxWidgets, etc. Also shipping DirectX and VC++ runtime libraries, .NET runtimes, etc. was and still is (for whatever reason) still common and stuff just doesn't work without it. Plus whatever else the program needs, like a whole python runtime or something.
>Is it any wonder that no one can ship and maintain a binary app that targets GTK without bundling it?
Distributions have no problem doing it. If you're shipping something outside the distribution why would you ever expect that shipping only half your program would be feasible? There is no OS where that works.
Windows has many solutions to this. It is entirely possible for the apps to use a shared dynamically linked runtime, and the OS provides mechanisms to have several versions installed globally side by side, loading the correct one as needed for each app.
> 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.
The “compile in an old version” thing was IIRC more properly done with linker scripts telling the linker to use an older symbol. I think lsb-gcc does it for you — not that the Linux Standard Base is still widely respected at all.
> 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.
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.
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 endorsed by Alpine Linux.
Yes, there's several of them. The problem isn't your package, but the distribution of "alpine" images that integrate the package. Those images should describe themselves more appropriately.
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.
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.
> Alpine is free to provide a solution to the problem then.
Alpine is also free to _not_ provide a solution to the problem.
Alpine is free to say "This is not an approved use of our name"
As you point out, the way to convey that you are a fork is to change your name in a non-confusing way, and provide attribution to the original in your readme or licenses.
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 roadmap of the Alpine makers, it could be considered a fork of sorts. And given that the package naming is far less confusing than the dockerhub naming, I feel like that's what most people on HN are attributing the confusion to.
Note that the article doesn't mention that it's the container that is the source of confusion until the very last section, where it points out what they want to rename. The package itself is called alpine-pkg-glibc and as the author of that package has pointed out, the reason it is called that is to follow alpine package naming conventions, and they have mentioned on this HN convo that they are completely open to changing that name if asked.
But regarding the docker image, I'm well aware that this isn't technically a full fork; I was mirroring the language used on the parent poster - however, since your clarification does not do justice to the complexity of the situation either and implies that you have less clue about what you're talking about, maybe tone it down a bit. Especially since one possible solution to this situation is indeed for the frolvlad/alpine-glibc authors to produce a full fork of Alpine linux with glibc and call it something else (I wonder if Himilayan Linux is available?)
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... <- That dockerfile, for example, installs curl using the normal Alpine repos, then uses curl to download the signing keys and the packages for the glibc package.
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.
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
It isn't even really a downstream project. This is like saying that third party Deb packages are downstream projects of Debian. They are just third-party packages you can install in Debian.
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.
Maintainer of the Alpine package referenced here. The same name for what? The package name is `glibc`. I think you're confusing/conflating the source control repository's name with the package when they are different things.
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.
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.
We had to stop using alpine because we have to resolve a DNS name that resolved in a 100 hosts. Musl fails to resolve that because it does not support “upgrade to TCP” and the response does not fit into single UDP packet so it gets truncated, so node fails to resolve the name. And not only node, normal Linux tools as well. And the author says it’s a feature, not a bug so for me it is kinda hard to take that thing seriously when parts of standard are unsupported.
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.
It has certainly evolved to be pretty complicated. You have whatever libc chooses to do with getaddrinfo(), nsswitch.conf, resolv.conf, systemd-resolved, various pieces of software (docker, vpns, wsl), and so on, all trying to control the local resolver.
Linux as a system is very ill-defined. I'd argue that GNU/Linux by definition contains glibc even if they are not in the same tree and musl based distributions are a variation which you could call "musl/Linux".
The tuples historically had 3 components--cpu, vendor and operating system. But especially as uclibc and musl became more widespread the last component is commonly split into kernel-libc. (I think this was originally extended for the benefit of Debian GNU/kFreeBSD.) The formal OS identifier for glibc-based Linux systems is "linux-gnu" (e.g. x86_64-pc-linux-gnu), and for musl "linux-musl" (e.g. aarch64-alpine-linux-musl).
Vendor is not very useful these days. It's common to see 3-tuples of cpu-kernel-libc, as opposed to 4-tuples or traditional 3-tuples. Sometimes the system is extended into, e.g., 5-tuples like cpu-vendor-kernel-libc-compiler. Autotools projects commonly have a bit of generated shell code for parsing tuples; it's quite complex owing to ~30 years of accumulated idiosyncrasies.
Because people treat libraries differently today than 30 years ago. We're used to the integration points for things being some form of blocking IPC (like dbus on GNU/Linux, COM, or syscalls) but libc is different.
libc is that service on the base OS. But rather than connecting to an OS service and passing messages back and forth you dlopen and setjmp to do the same thing. On GNU/Linux libc isn't an interface to the NSS service, libc is the NSS service. That fact that you access it via your linker is just an implementation thing.
The kernel itself actually exposes integration points this way too with lib-vdso! The kernel will actually just stick it's own routines in your programs memory space so that you can avoid the syscall overhead for certain calls.
That's up to your distro technically. DNS queries that use glibc (so everything basically) parse /etc/nsswitch.conf and follow the path of NSS modules which can do whatever they want to produce a name.
The resolve module provided by systemd talks to systemd-resolved but the dns module parses /etc/resolv.conf and does the resolution itself.
Ha, I ran into that one at work one time in our custom DNS resolver and had to add TCP upgrade. I was very confused why the tool worked when I shelled out to dig but not when I did the “correct” thing and used a resolver library. I’m very surprised that a project as big as musl would not have support for this.
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 easier to implement using the output from a webserver.
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.
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 getaddrinfo returns a linked list of results so it's not exactly hard to support 100 results. All the actual junk about TCP/UDP is completely abstracted away from the caller.
So sure, while you could use your own DNS client specifically for talking to Consul's DNS server the whole point of the thing is to act as a compatibility layer for software you didn't write and which will 100% of the time use glibc's methods.
> 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.
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 could argue that using Alpine is the responsible choice from a security perspective.
But maybe I'm just rationalizing a desire to pursue the kind of software quality (simplicity, minimization of bloat) that only we developers appreciate and that often has hidden downsides. Then I read about such downsides, like the sibling comment about DNS resolution, and I wonder if the responsible thing to do as a pragmatic product developer (and future manager of such developers) is to banish Alpine from the stack, tolerate the relative bloat of something like Debian, and throw more (and more complex) tools at the problem of the larger attack surface and more noise in vulnerability scans.
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
The `dnsfunnel` resolver has been added to Alpine to solve that issue. Additionally, musl will gain TCP support for situations like DANE where individual records may be very large.
I mean, okay, it's the program's fault. But it is part of the trade-off you make using musl, and one that I, personally, wouldn't decide in its favor.
As the user, you have the choice to use musl and "battle quite a few portability issues" (whether that's the program's fault or not!) or to use glibc and not have to battle. If the benefits of musl outweigh that in your opinion, then go ahead. I don't see it.
For a very long time glibc was the only game in town. so to some extent glibc was Linux. you can forgive people for not testing with other libcs if none was available to test against.
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!
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.
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.
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, ". This makes alpine look bad, because people think it's the alpine project's fault!
> 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.
But do you know if alpine does official docker images namespaced as e.g. alpine/?
Is "alpine-glibc" an official project and someone just helpfully made the image (or an image including an official glibc package)? Or is this a prerelease?
Without a deep knowledge of alpine (or now reading this post) I couldn't answer any of these questions and I'm not sure I wouldn't try to go to alpine for bug reports. I think there's a reasonable potential for confusion, even with the namespace. (but granted, I don't use docker either, so maybe this is a common thing)
And I assume the alpine people (like the author) know that they get bug reports for it and that the issues with it cause bad publicity, and that that's the context for the post and the proposal to block the package.
The problem is the people who use Docker but don't know anything about it. Or don't know that mixing libcs is a problem. They use this glibc package, break their containers and then blame Alpine for the breakage.
>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.
I'm having a hard time here - do you really not see the connection between what I'm saying, what you're saying, and the use of a default masculine pronoun?
I see the connection, what I'm suggesting is that you knew what they meant when they said guy, meaning you did not need to suggest that they thought women didn't exist on the internet, nor did you need to suggest that they were assuming everybody on the internet is a man.
I don't think we're operating under the same impression of bad faith. You seem to be using it to mean "an argument or line of reasoning I don't find compelling", where I am using it to mean "bringing up a line of argument or discussion for some reason other than participating".
So to circle back around on this, some people feel like using male as the default gender is rude and exclusionary. Try assuming people are women, just as an experiment, and see what sort of push back you get. This isn't in any way a bad faith argument.
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.
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.
First, the repo name is alpine-pkg-glibc because it is merely a package you install on Alpine. The container name, created by a different individual is frolvlad/alpine-glibc, and they make it clear that it is based off Alpine with the glibc package installed. In fact, you can even look at the source code. This is ridiculous, and if Alpine starts going after people for using alpine in the container image name or tag then I now know what distro to avoid entirely.
Those names are clearly packages based on a distrop
So why not:
glibc-alpine
This would avoid confusion.
> they make it clear that it is based off Alpine with the glibc package installed
Well, seeing the number of issues opened on the official Alpine bug tracker regarding this package, it seems it's not that clear.
> if Alpine starts going after people for using alpine in the container image name or tag then I now know what distro to avoid entirely.
Alpine starts going after people for misusing the name and impacting their reputation. This is completely normal and understandable.
Marketing and communication is an important part of every projects, even open source projects, this is not exclusive to businesses. If you want people to support your project, you need to protect your image.
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?
It does not. They use Alpine in the name so people can find the image. Searching for Alpine on Docker Hub has 49,530 results. This image doesn't even show up on the first page of results. I think whoever wrote this needs to rethink how ridiculous they are being.
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.
> 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)
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 large images is more annoying, everything else being equal. But alpine and, say, ubuntu, aren't always equal. Those people then find one of the ugliest differences, often related to musl, or something they are using relying on glibc-like behavior, and then get to choose between a hack like this, or much larger images.
As an example my organization was moving everything to alpine, but as part of the switch we found out that some computationally heavy tasks were getting significantly worse performance under alpine than with a glibc-based distro, mainly due to the relatively well documented issues with memory allocation performance. It'd not be surprising that someone finding themselves in this kind of situation ends up just adding glibc to alpine, instead of switching back, or figuring out how to tweak the memory allocator.
This is one of the reasons why I've been building Cosmopolitan Libc. https://github.com/jart/cosmopolitan Alpine and Musl aren't radical enough on the bloat-free angle (since they don't fix root problem which is dynamic shared objects) and their definition of portability is supporting architectures like sega saturn but do nothing to support intel/amd microarchitectural dispatching, which is likely why you encountered performance issues. It's like, I love Musl so much, but I just didn't see the value in being able to port my apps to Sega Saturn if my C Library only runs on Linux and has suboptimal performance on x86.
[side note] I seem to recall there being something about the the way the musl header files are written that basically throws a wrench into any scientific computing code that's compiled with it. Might have something to do with security like those checks intended to prevent people from overlapping memcpy so someone should totally fix that.
musl is definitely more developer-friendly than glibc, which may lead to a brighter future for it, but right now at this time there's significant downsides to choosing musl.
Performance in real world applications is worse on musl vs glibc, at a level that can result in higher latencies and needing to spend more on compute resources to serve a given level of load.
I don't get it. There's a docker image called alpine-ruby. I presume that isn't supported by the alpine team either, but, honestly speaking, I'm doubtful that's causing enough of a support load on them. If it is, I would assume the reasonable solution to that is to close any support requests with "We are not responsible for that image" or something of that variant, or even requesting the creator of the image to mention that in the docs, but preventing users from installing ruby on alpine (!!!), not just images?
> Frankly you can name a dockerhub entry anything you like as long as it's not taken.
Yeah, definitely, just like you can name a library like Vue vue.js. Does that mean Vue is an official project of the JS Committee? No, of course not! It's bizarre to think otherwise, and that doesn't mean Vue should avoid using js in its name because somebody could get confused. Putting something like ".js" or "rb" (like in "dry-rb") in a name is a signal for a target, and not always trademark infringement.
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.
I don’t think anybody is arguing that shoving glibc into an Alpine image is a great idea.
But if I decided to make an “alpine-goofy” image where I started with “FROM alpine” and then renamed all the binaries so cp was rm and rm was ls and so on, it would be a stupid idea but not trademark infringement.
Could this project do everybody a favor by adding a banner saying “Hey y’all just FYSA we are not affiliated w/ Alpine upstream, please don’t send them glibc support requests”? Totally. But I’m shocked that Alpine’s approach here is to start by trying to implement a technical blocker for what I can install on my Alpine image, with an offhand remark that maybe they could try talking to the image owner first.
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 support burden.
the only thing the proposed change does is encode something that is already factual: if you install that glibc package, you have a high likelihood of breaking your system.
it's not like we are blocking it in apk-tools, and you can roll your own musl package with the conflict removed by simply building it with the `ALLOW_GLIBC_PKG` option.
It feels like you’re splitting hairs. No, you’re not blocking it in apk-tools, and yes, a user can work around the change you’re making to continue doing what they want. But your post directly says “I have also proposed an update to Alpine which will block the installation of the glibc packages produced by the alpine-glibc project”. So I’m not sure how describing it as “blocking this downstream project” could possibly be inaccurate.
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 before continuing, that would also solve the issue as far as I am concerned, but it does not have such an option at this time, and we need to put our foot down sooner rather than later.
Edit: besides, nothing has been implemented. This is just one proposal, the point of having a conversation is to determine what the best option for solving this issue is.
As visible upthread, I think starting w/ the block in code is a bad move, and am sad that reaching out to the maintainer of alpine-glibc seems like an afterthought.
That said, there is not a universal mandate for how an open source project “must behave”, other than that the terms of the license (which the authors of the code are able to choose). There isn’t a single cohesive “entire fucking point” of open source. The things proposed in the blog post are permissible under the license, are able to be bypassed by the user, and are not some earthshattering affront to human decency.
We should be able to disagree about the best course of action without falling into incendiary accusations.
> 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.
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...
I was not aware that publicly setting boundaries on what is a supportable configuration and what wasn't one was somehow equivalent to white nationalist syndicalism, but thanks for letting me know.
When your first reaction in all this was to figure out a way to try to block a third-party package from being installed, and then you make comments like... "we feel it appropriate to signal our position more
forcefully." And then you lock comments on GitLab from people commenting..
You could have, before even writing the blog post, posted an issue on their GitHub to try seeing if they can post a more noticeable disclaimer... although it doesn't really even need one and is pretty inherent, just like all the other Docker Hub images using Alpine in their name to indicate the underlying distro.
The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes.
The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You also assume that this is our first reaction.
Our first reaction was 6 years ago when it first came out: meh.
No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
It is unfortunate that we have waited this long to put our foot down, honestly!
We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Stop assuming this is our "first" reaction. It isn't. I even said it wasn't to begin with -- a "first" reaction cannot logically be an escalation from a previous position, it must be an initial one.
> The issue is not the package. Obviously Sasha is allowed to publish whatever packages he wishes.
> The problem is that third parties take his package and then describe the combination of Alpine with his package in such a way that people are led to believe is totally stock Alpine.
You were specifically trying to block the package from being installed without recompiling musl.
> This then causes many people to complain in Alpine support channels, or on websites like this one, that Alpine is "buggy" in ways that cannot be reproduced on real Alpine.
You're putting too much pressure on yourself. This is simple... if someone isn't using the official Alpine image (alpine) then they should ask for support from the image creator, as there are thousands of things that can go wrong outside of you control.
> No, this is our first reaction to a large company trying to pass off their hackjob images combining Alpine, glibc and a glibc JDK as a certified JDK that is running on stock Alpine.
Labeling other developers work as hackjob images is condescending. Your whole post was condescending. Just because someone has alpine in an image tag doesn't mean that they are trying to indicate that it uses stock Alpine as the base image, but instead that it uses Alpine as the underlying distro. Who knows what software or changes they've added to it that may cause issues outside of Alpine's control.
> It is unfortunate that we have waited this long to put our foot down, honestly!
> We need to support our friends in the Docker community who manage the Docker Library who also get to deal with the fallout of these hackjob images.
> The person who makes the hackjob rarely faces the consequences of it breaking, that basically has always fallen on us, or on the Docker Library team, or on some other team in the ecosystem that has to deal with somebody who is mad because their application has failed due to some shoddy work done by somebody 2 years ago.
Seriously, these comments only show that this is more about control for you than anything. I can't say for sure, but I have a feeling that eventually other people in the community will either leave or ask you to leave for toxic behavior like this.
The only reason I took any position at all on this issue is because other partners in the Alpine / Cloud Native ecosystem requested that we clarify our position on mixing musl and glibc runtimes.
You ignore the point I am making: people are already fighting this issue for years, and Alpine has not taken a position on it until now.
We should have done so sooner, but unfortunately we did not, so a more theatric approach is sometimes needed to make a point.
We want to discourage bad practices in the creation of alpine-based images, so that our partners (such as the Docker library team) do not have to deal with user complaints with images, or feel like companies are bullying them into accepting images they know are built with bad practices.
If you call taking action to provide assistance requested by our ecosystem partners (who have been thrilled that we are putting our foot down by the way) toxic behavior I wouldn’t want to know what your idea of a party is to be blunt.
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?
> 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 ActiveSupport, and they get frustrated and angry when the thing they've copied from elsewhere doesn't work as they expect. Whether that's good or not is another matter, but that doesn't mean Ruby should prevent people from running Rails! You really shouldn't be obsessed with people liking your project to the point where you prevent anybody from doing anything with it that you haven't personally authorized.
Not the same argument. Combining musl and glibc runtimes into a single system is known to result in instability.
Whether it gets documented as part of a "don't do weird things" system or this update gets accepted, it needs to be addressed, as people have erroneously expected this configuration to have the same stability guarantees as stock Alpine.
There’s a solution to all of these problems, tried and tested, and older than the concept of package registry namespacing called “registering a trademark and sending a cease and desist letter”. Works great.
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.
Some things like this do exist. Some programs or even entire customized distros will LD_PRELOAD jemalloc for size or hardened malloc for security (I'm sure there's a performance-optimized version out there I don't know about). There's nothing at all stopping developers from providing optimized subsets of libc intended for more specific use cases than the fully-general system-wide libc.
Note that when you're comparing Centos 6 to Debian 10, you're comparing a system released in 2011 that went end of life last November to a system released in 2019. I don't think it's that surprising that 8 years of development brought a 500% performance increase. Presumably, Centos 8 (released 17 days after Debian 10) would have had the newer glibc.
I've not used this particular image myself but I have installed glibc in an alpine image, then compiled some code and copied that over to run on the scratch image as part of a multi-stage build.
Super useful as alpine is a small image and with none of the drawbacks mentioned in the blog post.
Semi off-topic: While I like the idea of symbolic versioning in theory, in practice it has only ever caused me pain and never shown any benefit whatsoever: I really don’t care that cosf changed ever so slightly in 2.xx! Just use the cosf I have!
At the very least, a simple, non-hacky way to force that linkage would be great but I have found no such thing. Anyone here had any better luck?
I think this is a perfect example of why the Open Source Definition has "Integrity of The Author's Source Code" If they care about being associated with other people's projects, then they should add a bit to the license that they have to change the name of the project when modifying.
I think the majority of people resort to this hack because security folks in their infinite wisdom require to use alpine and nothing else. Unfortunately, a lot of libraries don't support musl and have no plans to support it in the future, so you have to be creative.
musl's thread stack size is too low (128K), so many open source test suites segfault.
I do not understand why musl doesn't move to at least 512K like OSX.
The generous 8192K glibc thread stack size isn't actually used on Linux with overallocation, so I fail to see why musl chose that small default in the first place.
maybe, musl by design, is for resource limited embedded boxes. multiple threads with large stack size will eat up RAM. If you need larger thread stack I believe you can set it in the code.
"Since 1.1.21, musl supports increasing the default thread stack size via the PT_GNU_STACK program header, which can be set at link time via -Wl,-z,stack-size=N." Of course you can always use pthread_attr_setstacksize
> The generous 8192K glibc thread stack size isn't actually used on Linux with overallocation
Is it even (over)committed? The main reason for having a max stack size is multithreading, but I'm not sure why it should be committed at all. Surely, an unbounded single thread stack is not precommitted to infinity?
I would like to point out the GitHub linked to in the article says “glibc alpine based image” as in based on the alpine-glibc image. It seems adriadne has misread it as glibc based alpine?
> 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 for official images. 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.
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.
Just checked out the GitHub repo. Apparently the author can't even be bothered with posting an issue seeing if there may be a more appropriate name for the GH repo, although I personally see nothing wrong with the name as it is merely a package that you have to manually install.
But the problem is, as much as I want to like it and use it, there have always been rough edges to it. By and far, the biggest beef I kept on returning to with Alpine is the whole musl libc thing.
Not because that's what they ship with, because well, "my house my rules" as the saying goes.
But because the maintainers insisted on building various packages where the original external code developers stated quite clearly in their build guides that they didn't support anything other than glibc .... and yet Alpine would build and ship packages built against musl. Bit of a dangerous game to play if you ask me !
This was not random small external code bases either, we're talking about some quite well known open source projects here.
I'm not sure if they still have the same "musl or bust" package building policy these days as its been a few years since I quit using Alpine for good. Hopefully they've changed their ways since then.
This is seriously the saddest and dumbest post I've seen in a long time. Someone decides to build an Alpine package without ever claiming it is part of the official Alpine distro, you can't even install it using the default Alpine repos, and then they created a Docker image with it already installed... and somehow someone wants to complain and threaten to block the package from even being installed. This is like Microsoft levels of bad for FOSS, maybe even worse. No where are they claiming to represent the official Alpine image. I have plenty of Docker images that use Alpine as a base image. Am I somehow representing that they represent the official Alpine image? No. I wonder if this person is just bored, or mad in general and wanted to find something pointless to complain about.
What I find saddening is to see passive aggressive statements like
> I have additionally suggested that the TSC may wish to have the Alpine Council reach out to the alpine-glibc project to find a solution which appropriately communicates that the project is not supported in any way by Alpine.
To the Alpine Linux TSC: please get in contact with me about any and all disclaimers you want to add to this package! I'd love to have these discussions faster and in the open, rather than discovering this disquiet tangentially. Let's get these issues resolved as soon as possible in a way that everyone concerned finds acceptable.