Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

ariadne.space

Post reply on HN
Print view View original

171–180 of 204 posts

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

#171

Post by jart »

hibikir wrote: post #93
IshKebab wrote: post #67

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

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.

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

#172

Post by erk__ »

herf wrote: post #167
nonameiguess wrote: post #101

Earlier quoted context omitted.

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.

It could be interesting to see how BSDs compare here

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

#173

Post by temac »

hygh wrote: post #56

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.

> 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?

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

#174

Post by ariadneconill »

eqvinox wrote: post #143
sgerrand wrote: post #122

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

You have a communication issue in that people assume you're providing something Alpine "official". 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.

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.

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

#175

Post by ariadneconill »

fanf2 wrote: post #85
ariadneconill wrote: post #49

Earlier quoted context omitted.

alternatively you could just use a dedicated local resolver

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.

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

#176

Post by ariadneconill »

Karunamon wrote: post #94
faho wrote: post #51

Earlier quoted context omitted.

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

The answer to the first question is an obvious yes, and it's obvious to anyone that uses Docker. No deep knowledge required. If you want Alpine, you do FROM alpine:(version). https://hub.docker.com/_/alpine

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.

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

#177

Post by ariadneconill »

MrStonedOne wrote: post #78
ariadneconill wrote: post #41

Earlier quoted context omitted.

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

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

I'm glad to know that free software maintainers exist to do whatever you want us to do, and that we don't get to set our own boundaries. Cool, cool.

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

#178

Post by int_19h »

rrdharan wrote: post #83
captainmuon wrote: post #7

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

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

This is the standard way of building binary packages for Python that run across many distros. They even provide the "official" containers to build in.

https://www.python.org/dev/peps/pep-0600/

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

#179

Post by int_19h »

wahern wrote: post #165
colejohnson66 wrote: post #77

Earlier quoted context omitted.

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

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…

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.

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

#180

Post by ariadneconill »

d3nj4l wrote: post #59
sascha_sl wrote: post #24

Earlier quoted context omitted.

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.

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

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.

Post reply on HN