It should be called atlas-glibc or even himalaya-glibc, not related to alpine at all.
Why? This is a package, not a fork of the project.
There is no such thing as a “glibc based alpine image”
161–170 of 204 posts
Re: There is no such thing as a “glibc based alpine image”
#162Earlier quoted context omitted.
Why is DNS resolution even part of the libc and not, say, the base OS, a service on the base OS, or if need be, an external library like c-ares? In fact, I thought Node already depended on c-ares, why is it failing on this?
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".
GNU formalized a system of tuple definitions for identifying build, host, and target environments, which was popularized by Autotools. See https://autotools.io/autoconf/canonical.html#autoconf.canoni... and https://www.gnu.org/savannah-checkouts/gnu/autoconf/manual/a... Even if you don't use Autotools, this is the canonical way to specify environments in the Unix world, though often a simplified version is employed. (By canonical I mean the one project-agnostic system that everybody at least nominally acknowledges. It's hardly the only system out there. Even Debian has their own alternative: https://wiki.debian.org/Multiarch/Tuples .)
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.
Re: There is no such thing as a “glibc based alpine image”
#163Earlier quoted context omitted.
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 t…
>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.
Re: There is no such thing as a “glibc based alpine image”
#164Earlier quoted context omitted.
Yeah I thought the whole point of Alpine was that it abandoned the insanity of glibc for the relative sanity of musl. My only guess is that they like Alpine but want to run some binary software that links with glibc.
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 lar…
100%
Re: There is no such thing as a “glibc based alpine image”
#165Earlier quoted context omitted.
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…
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 C runtime. 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.
Re: There is no such thing as a “glibc based alpine image”
#166Earlier quoted context omitted.
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.
Gotcha. Sorry your obsolete workaround is being painted as new and borderline malicious. :-\
[deleted]
Re: There is no such thing as a “glibc based alpine image”
#167I 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…
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…
I benchmarked an Alpine's musl doing strstr with a 200-byte "haystack" with a 10-byte "needle" and it's 8x slower than Debian 10's glibc.
Re: There is no such thing as a “glibc based alpine image”
#168Earlier quoted context omitted.
How are they being mistaken? No where do they claim to be the official Alpine image. This is like saying anyone who uploads an Alpine image with a few self-built packages installed is somehow conflating themselves with representing Alpine Linux, when in fact there is nothing the creator of this image has done to indicate that they are in any way considered the official Alpine project. In fact, Docker Hub has a place…
> How are they being mistaken? Because the image is named "alpine-glibc", but the "how" is irrelevant. People are getting confused and that's a problem. > No where do they claim to be the official Alpine image. Doesn't stop people from being mistaken. > If someone is mistaking this package as being supported by Alpine Linux as a whole, then they also the same people that would mistake Google for any app installed fro…
> People are getting confused and that's a problem.
Let's see the data.
Re: There is no such thing as a “glibc based alpine image”
#169It should be called atlas-glibc or even himalaya-glibc, not related to alpine at all.
And if I need glibc for alpine how do I search for it?
Re: There is no such thing as a “glibc based alpine image”
#170> is like trying to run Windows programs on OS/2: both understand .EXE files to some extent, but they are otherwise very different.
But you could run Windows programs on OS/2. They'd even render with the Windows window borders, and not the OS/2 ones.