Received: from out0.migadu.com (out0.migadu.com [94.23.1.103]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 0A2FB781355 for <~alpine/devel@lists.alpinelinux.org>; Wed, 22 Jun 2022 16:57:14 +0000 (UTC) MIME-Version: 1.0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ayaya.dev; s=key1; t=1655917033; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=KIIQ2ngD2A4CF+/iKhz2F6bQ7Gg63f/98boimj8nWlY=; b=jxGKIokI0p2L/zR02UGGVcrbafoI60eyPvLqbQG+8/g/sF8on2I3wwdGZjzotVSrO7pj2H HTrd0wfUAksxXHa1RqiyDeE4pjx8qy+D/Pvm9RV85j7AsiJWHVheSCKDYzXzs3C57AzeTr n1jms/WMLC9b9swGTjVN54GxaKigXkA= Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=UTF-8 Date: Wed, 22 Jun 2022 18:57:12 +0200 Message-Id: Cc: <~alpine/devel@lists.alpinelinux.org> Subject: Re: Native Alpine GLibc support (NEW) X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: "alice" To: "Tomas Kolda" , "Laurent Bercot" References: <20220621095653.71773d59@ncopa-desktop.lan> <20220621114559.4d38d98e@ncopa-desktop.lan> In-Reply-To: X-Migadu-Flow: FLOW_OUT X-Migadu-Auth-User: ayaya.dev On Wed Jun 22, 2022 at 2:12 PM CEST, Tomas Kolda wrote: > > 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. you don't want to make another distro incorporating $hugesetofchanges, so you just want others to work on it for free incorporating them instead? > And maybe after some time Alpine will see > market for this change. last i checked nobody working on alpine was working for 'a market' to make money out of (with alpine)- personally i do it for free, but maybe we are all supposed to be getting paid? certainly, if someone was throwing free money my way maybe this would be an actual interesting project to work towards. > There is a good reason main distros are using > glibc. I am trying to be pragmatic and not just say MUSL is great. then use a glibc distro? i don't get it, again, as Laurent has said, nothing whatsoever is forcing you to use musl or alpine. i understand you believe you are not asking for much, just a 'small' set of compatibility patches to easily allow someone else to 'build alpine but with glibc'.. but if they are as easy as you have demonstrated and claim, then.. you're done? you successfully made all the changes, and can now build your forked+patched aports whenever you wish with glibc, and can keep it that way. sounds like you already found the solution, and can keep working on it there, as your own project. sadly though, this is indeed 'an entire other distro'.. though you are basically already done making it. > 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. a very easy solution (for all the others): use literally any other glibc-based distribution.