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”

#141

Post by en4bz » Thu, Aug 26, 2021, 4:41 PM UTC

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…

So `dlmopen`?

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

#142

Post by glb100 » Thu, Aug 26, 2021, 4:42 PM UTC

synergy20 wrote: post #64

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

> Of course you can always use pthread_attr_setstacksize.

No you can't, not with std::thread, which makes std::thread nearly unusable with musl.

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

#143

Post by eqvinox » Thu, Aug 26, 2021, 4:44 PM UTC

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.

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

#144

Post by sgerrand » Thu, Aug 26, 2021, 5:15 PM UTC

pxc wrote: post #140

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…

j/w: What use cases do you have or have in mind for your glibc package? Do you see it as a temporary step for adding pre-built things to Alpine images during development, before you have time to rebuild them against musl? Do you feel some prod use cases are ‘safe enough’? Or nowadays do you generally prefer the upstream compatibility packages you mentioned?

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.

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

#145

Post by MrStonedOne » Thu, Aug 26, 2021, 5:25 PM UTC

burnished wrote: post #119

MrStonedOne wrote: post #111

Earlier quoted context omitted.

"somebody using a generic is really suggesting that women don't exist on the internet" sounds exactly like a bad faith interpretation.

I'm having a hard time here - do you really not see the connection between what I'm saying, what you're saying, and the use of a default masculine pronoun?

I see the connection, what I'm suggesting is that you knew what they meant when they said guy, meaning you did not need to suggest that they thought women didn't exist on the internet, nor did you need to suggest that they were assuming everybody on the internet is a man.

Both of those statements are bad faith.

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

#146

Post by elzbardico » Thu, Aug 26, 2021, 5:32 PM UTC

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…

What a load of bs! If they have any issue with your project why not just open an issue?

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

#147

Post by traceroute66 » Thu, Aug 26, 2021, 5:41 PM UTC

Conceptually there is a lot to like about Alpine.

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.

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

#148

Post by pxc » Thu, Aug 26, 2021, 5:50 PM UTC

sgerrand wrote: post #144

pxc wrote: post #140

Earlier quoted context omitted.

j/w: What use cases do you have or have in mind for your glibc package? Do you see it as a temporary step for adding pre-built things to Alpine images during development, before you have time to rebuild them against musl? Do you feel some prod use cases are ‘safe enough’? Or nowadays do you generally prefer the upstream compatibility packages you mentioned?

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

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

#149

Post by encryptluks2 » Thu, Aug 26, 2021, 5:54 PM UTC

undecisive wrote: post #115

MrStonedOne wrote: post #88

Earlier quoted context omitted.

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

This isn't a fork. I seriously wonder how many people here are commenting without having any clue as to what they are talking about. It is simply a package that you install with apk in Alpine.

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

#150

Post by encryptluks2 » Thu, Aug 26, 2021, 5:56 PM UTC

deadbunny wrote: post #130

MrStonedOne wrote: post #114

Earlier quoted context omitted.

The solution is to seperate the branding from the idea. There is no way for somebody to suggest in the name of their product that they are a downstream of alpine without using the word alpine. alpine linux can fix this by creating and providing a generic word for their flawed-opinionated-mini-linux whatever

> alpine linux can fix this by creating and providing a generic word for their flawed-opinionated-mini-linux whatever Why is it on the Alpine Devs to name a downstream project? Would you ask the Debian devs to name Ubuntu?

It isn't even really a downstream project. This is like saying that third party Deb packages are downstream projects of Debian. They are just third-party packages you can install in Debian.