MIME-Version: 1.0
References: <CAGFcrM=KPg5AZie-ux055SVAZu08EmSJ3s-Q_Map5j5CmGaaKA@mail.gmail.com>
 <20220621095653.71773d59@ncopa-desktop.lan> <CAGFcrMmniJdjO54SHR+Js=5pyuB70A_M0Ge92=pFpxjbBHYC9w@mail.gmail.com>
 <20220621114559.4d38d98e@ncopa-desktop.lan> <CAGFcrMmddidhEknrSUtydvocghN2pm30pUQ8eGsuqEd9eNpLSg@mail.gmail.com>
 <e5703d3f-4953-6797-2a93-324ea72810b9@lamprecht.org> <vTcnWREDRbSp_m2UXDa_2LCTqGU6XH8o9aBAPLeCyJv0MqPQF5dQ2GNQ-tVLrqiuRCrVsuJRTTz1F6RuKHry-bCvRHyMW3GSOTgjutxKURI=@panekj.dev>
 <CAGFcrMmYUyfuUzBr32CwHtZf-+n-mHBBXvpArUcuNzVCCNRynQ@mail.gmail.com>
 <CKVUTPCNCCJ5.MRXA8K04UO72@sumire> <CAGFcrMk_4-WALsR88e4Xi5DAf8y5-a=kT=2413C1rHspXH_Gfw@mail.gmail.com>
 <emdea05cbc-c1e3-405b-a5ba-f75b4eaedcee@95047c56.com>
In-Reply-To: <emdea05cbc-c1e3-405b-a5ba-f75b4eaedcee@95047c56.com>
From: Tomas Kolda <koldat@gmail.com>
Date: Wed, 22 Jun 2022 14:12:26 +0200
Message-ID: <CAGFcrMmFtO2xS-LUmyXA4R7u+cVx8kTwo+O-KWV_+EBth_YzKw@mail.gmail.com>
Subject: Re: Native Alpine GLibc support (NEW)
To: Laurent Bercot <ska-devel@skarnet.org>
Cc: ~alpine/devel@lists.alpinelinux.org
Content-Type: text/plain; charset="UTF-8"

>   No, it has to be Alpine, whose defining characteristic is to be a
> musl-based distribution, which is the main reason why it's small and
> efficient and has the success it has, that needs to grow glibc support,
> i.e. diluting its meager resources away from its central vision and
> into something *every other distro under the sun* already does, which
> means decreasing its value in the software ecosystem.
>
You are right. Alpine can definitely pick their way. I do not want to
create yet another distro. I was asking for cooperation that was
outlined by Oliver as well. And maybe after some time Alpine will see
market for this change. There is a good reason main distros are using
glibc. I am trying to be pragmatic and not just say MUSL is great.
There are so many variables in the world. And maybe that is why we see
this type of request time to time.
>
>   I would prefer more energy to be spent in understanding why the
> musl pthread thing is so inefficient for your use case, and having a
> discussion in musl about how to improve it, and whether the use case
> is common enough to be worth trade-offs, if necessary.
>   I would prefer technical issues to be solved rather than translated
> into organizational burden and vision dilution put onto projects.
>
Yes I would like that as well. This would potentially solve this one
particular issue (time frame is questionable). It does not solve the
others.