There is no such thing as a “glibc based alpine image” • Hacker News Board

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

#101

Post by nonameiguess » Thu, Aug 26, 2021, 2:50 PM UTC

herf wrote: post #82

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…

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.

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

#102

Post by yjftsjthsd-h » Thu, Aug 26, 2021, 2:51 PM UTC

ariadneconill wrote: post #41

akerl_ wrote: post #40

Earlier quoted context omitted.

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

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…

The user already had to go out of their way to install it; I'm not sure adding an extra flag is a huge difference.

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

#103

Post by Spivak » Thu, Aug 26, 2021, 2:54 PM UTC

ntauthority wrote: post #21

p2t2p wrote: post #16

Earlier quoted context omitted.

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

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?

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.

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

#104

Post by Spivak » Thu, Aug 26, 2021, 2:58 PM UTC

Denvercoder9 wrote: post #100

ntauthority wrote: post #21

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

I certainly don't want DNS resolution inside the kernel, and outside the kernel, libc is as "base OS" as "base OS" comes, imo.

The Linux kernel can actually resolve names but it farms out the actual work to userspace using the request-key(8) machinery.

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.

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

#105

Post by geocar » Thu, Aug 26, 2021, 2:58 PM UTC

p2t2p wrote: post #16

Aissen wrote: post #9

Earlier quoted context omitted.

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

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.

What are you doing?

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

#106

Post by dralley » Thu, Aug 26, 2021, 2:59 PM UTC

MrStonedOne wrote: post #88

r1ch wrote: post #70

Earlier quoted context omitted.

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.

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. Welcome to FOSS. xchat solved this with ychat.

> Alpine is free to provide a solution to the problem then.

This entire post is about how there isn't a solution to that problem. It's a fundamentally flawed idea.

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

#107

Post by burnished » Thu, Aug 26, 2021, 2:59 PM UTC

MrStonedOne wrote: post #87

faho wrote: post #11

Earlier quoted context omitted.

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, ". T…

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

There Are No Women On The Internet, so they got corrected. It isn't a bad faith interpretation, more like a gentle correction.

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

#108

Post by lalaithio-glibc » Thu, Aug 26, 2021, 3:00 PM UTC

lalaithion wrote: post #98

ricardobeat wrote: post #65

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.

The only reason to have the "we need to take them down" attitude would be if they are violating your license or glibc's license.

Using the same name can also be considered inapproriate.

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

#109

Post by Spivak » Thu, Aug 26, 2021, 3:02 PM UTC

silon42 wrote: post #23

ntauthority wrote: post #21

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

Typically, on a modern Linux system, DNS queries from libc (and everything else) will always query a local resolver (example: systemd-resolved).

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.

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

#110

Post by gunapologist99 » Thu, Aug 26, 2021, 3:02 PM UTC

colejohnson66 wrote: post #77

captainmuon wrote: post #34

Earlier 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.).

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.