Date: Tue, 21 Jun 2022 11:07:44 -0500 (CDT)
From: Ariadne Conill <ariadne@dereferenced.org>
To: Laurent Bercot <ska-devel@skarnet.org>
cc: Tomas Kolda <koldat@gmail.com>, ~alpine/devel@lists.alpinelinux.org
Subject: Re: Native Alpine GLibc support (NEW)
In-Reply-To: <emdea05cbc-c1e3-405b-a5ba-f75b4eaedcee@95047c56.com>
Message-ID: <6ead6b41-72b3-969a-51cd-ebc102b215c@dereferenced.org>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed

Hi,

On Tue, 21 Jun 2022, Laurent Bercot wrote:

>
> I find it interesting that when thinking about such things (making
> a distro supporting two libcs, or supporting two init systems, or
> patching some software to work with the better-known alternative, or...)
> the frame of reference is always "adding the support of $biggerthing
> to a project that has $smallthing as a characteristic", and never the
> opposite.
>
> It always ends up meaning more burden for the project that typically
> has fewer resources, less manpower, and that is only kept afloat by
> the superhuman good will and effort of its maintainers.
>
> Why does nobody ever say "ohey, let's add musl support to Fedora!" ?
>
> 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.
>
> I see this pattern happening over, and over, and over.
> I don't get it.
> That's a lie. I kinda get it, but I really don't like it.
>
> 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.

+1.  The solution is to add support for lock elision to musl, as glibc 
have done.  Or to use a newer version of the JDK which adds lock elision 
at the language level.

But the problem with lock elision in libc is that it is very difficult to 
prove that an implementation is correct.  When it is implemented at the 
language level, it is easy to prove.  This is why it has not happened in 
musl yet, in my opinion.

Ariadne