Received: from nc-smtp1.sdv.fr (nc-smtp1.sdv.fr [212.95.69.91]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 56B3E781244 for <~alpine/devel@lists.alpinelinux.org>; Tue, 21 Jun 2022 15:50:46 +0000 (UTC) Received: from skarnet.org (140.156.124.78.rev.sfr.net [78.124.156.140]) by nc-smtp1.sdv.fr (Postfix) with SMTP id 91CA120186 for <~alpine/devel@lists.alpinelinux.org>; Tue, 21 Jun 2022 17:50:45 +0200 (CEST) Received: (qmail 17905 invoked from network); 21 Jun 2022 17:51:12 +0200 Received: from unknown (HELO ?192.168.0.237?) () by sinay.internal.skarnet.org. with SMTP; 21 Jun 2022 17:51:12 +0200 From: "Laurent Bercot" To: "Tomas Kolda" Subject: Re: Native Alpine GLibc support (NEW) Cc: ~alpine/devel@lists.alpinelinux.org Date: Tue, 21 Jun 2022 15:50:45 +0000 Message-Id: In-Reply-To: References: <20220621095653.71773d59@ncopa-desktop.lan> <20220621114559.4d38d98e@ncopa-desktop.lan> Reply-To: "Laurent Bercot" User-Agent: eM_Client/9.0.1708.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable 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. I would prefer technical issues to be solved rather than translated into organizational burden and vision dilution put onto projects. -- Laurent