There is no such thing as a “glibc based alpine image”
ariadne.space
ariadne.space
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.
Or nowadays do you generally prefer the upstream compatibility packages you mentioned?
They have a communication issue in this escalation (TSC/Council) before trying to simply talk to you.
I'm not gonna blame either of you.
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.
- 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 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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
This entire post is about how there isn't a solution to that problem. It's a fundamentally flawed idea.
Why is it on the Alpine Devs to name a downstream project? Would you ask the Debian devs to name Ubuntu?
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.
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?)
> 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.
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.
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.
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.
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 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.
Without context, I think what this guy is pissed off about is that this project enables people to use alpine to run proprietary software.
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.
FROM frolvlad/alpine-glibc
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.
If you want Alpine, you do FROM alpine:(version).
>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.
Both of those statements are bad faith.
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.
Just give it a different name and explain that it's Alpine with glibc somewhere
One stands for: "we use alpine" (not a trademark violation)
The other one stands for "this is alpine" (a trademark violation)
debian-stable
debian-buster
debian-slim
python:3.10-debian
python:3.10-alpine
So why not:
glibc-alpine
> 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.
In fact, I thought Node already depended on c-ares, why is it failing on this?
The resolve module provided by systemd talks to systemd-resolved but the dns module parses /etc/resolv.conf and does the resolution itself.
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.
C and Unix are considerably older than Linux after all.
Alpine or Debian including libC is more equivalent to the BSDs including it.
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.
https://github.com/dank101/4.2BSD/blob/master/include/netdb....
I personally it should be renamed because it's just a generic way for the kernel to ask for data from userspace, not just keys but still.
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.
What are you doing?
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.
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.
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.
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.
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.
https://nix.dev/tutorials/building-and-running-docker-images
My only guess is that they like Alpine but want to run some binary software that links with glibc.
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.
[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.
There's also gcompat for that, although I don't know how comprehensive that is
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.
* 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.
Was it chromium?
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.
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.
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.
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.
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.
You don't get to tell your users how to use your project.
That is the entire fucking point of open source software.
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.
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.
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.
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...
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.
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 may be, but that seems dangerous. Frankly you can name a dockerhub entry anything you like as long as it's not taken.
But you probably wanted ruby:alpine anyway.
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.
But you could run Windows programs on OS/2. They'd even render with the Windows window borders, and not the OS/2 ones.
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.
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.
Debian 10 release date: 6 July 2019
Centos 6 release date: 10 July 2011
This is hardly an apples-to-apples comparison.
Super useful as alpine is a small image and with none of the drawbacks mentioned in the blog post.
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?
Similar to devuan being free of systemd. How do you argue a systemd package for devuan should he handled?
If you need a minimal distro, which supports musl and glibc as alternative use void.
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.
"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
It won’t really: that’s vmem, it’ll only need a bit of memory for the accounting of the mappings in the kernel.
No you can't, not with std::thread, which makes std::thread nearly unusable with musl.
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?
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?
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.
Let's see the data.
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.