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

61–70 of 204 posts

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

#61

Post by wyldfire »

Aissen wrote: post #9
dbt00 wrote: post #2

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.

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.

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

#62

Post by zokier »

account42 wrote: post #33
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…

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

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

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

#64

Post by synergy20 »

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.

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

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

#65

Post by ricardobeat »

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.

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

#66

Post by throw0101a »

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…

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

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

#67

Post by IshKebab »

WesolyKubeczek wrote: post #63

If you want glibc, why use Alpine? Mainstream distributions are for glibc. Alpine exists specifically as a musl-based thing.

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.

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

#68

Post by WJW »

p2t2p wrote: post #28
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?

Adding to the other responder. 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.

If the outlier has >100x as much market share as the rest of the other unixes combined, is Linux really still the outlier?

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

#69

Post by eckesicle »

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.

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

#70

Post by r1ch »

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.

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.
Post reply on HN