Received: from mail-4317.proton.ch (mail-4317.proton.ch [185.70.43.17]) by nld3-dev1.alpinelinux.org (Postfix) with ESMTPS id 28BB57810CE for <~alpine/devel@lists.alpinelinux.org>; Tue, 21 Jun 2022 13:05:44 +0000 (UTC) Date: Tue, 21 Jun 2022 13:05:32 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=panekj.dev; s=protonmail2; t=1655816742; x=1656075942; bh=3+Vbg8Wi3AfbOcFqt53mrdYVelX0cng4wFsBTlKNEMI=; h=Date:To:From:Cc:Reply-To:Subject:Message-ID:In-Reply-To: References:Feedback-ID:From:To:Cc:Date:Subject:Reply-To: Feedback-ID:Message-ID; b=N1B2g5CmEzl2TID0gqPctYCp+N5/znMVqFMUMsUxGvU/ZlSP4yKQ22LTPYa3qHhGy CjddRv9L/i3pUvkuC9WBMuzPLfv+OHoWZI67P87vsvYmVv0SvGSFuMSEvuYrcIRhrr dj4PIY+bVwDD2MdpD0Id5PwInWuQ0yReMsbNR3gE27rUlmzysxegYN39iMPpTycuzc giaLyPSx0STK3e/3iSKHZv6FRy+9XcvKhhq57VMw1Kqs9a8RicF0O5i1+otiz30jkr 2QirUWehD93PBK3DS5J3hbm71nRK7XNdrf4eilK684ycDqy+xNiSTATC98akX9eLty R64HoXohX091g== To: Thomas Lamprecht From: Jakub Panek Cc: Tomas Kolda , ~alpine/devel@lists.alpinelinux.org Reply-To: Jakub Panek Subject: Re: Native Alpine GLibc support (NEW) Message-ID: In-Reply-To: References: <20220621095653.71773d59@ncopa-desktop.lan> <20220621114559.4d38d98e@ncopa-desktop.lan> Feedback-ID: 39296488:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable > IMO, and that really is an outside view, as while I'm dabbling with Alpin= e > Linux and its inner workings on and off since years I'm really not active= in > the community in any form, it feels rather misguided to add glibc into > Alpine Linux itself in general as complete musl alternative, just feels l= ike > going against core characteristics and the reasoning for doing such reall= y > doesn't outweigh Natanael's arguments at all. As a person that dabbles with Alpine and is somewhat active in community, I agree that glibc doesn't feel right with Alpine. It's not a component that you can simply replace in ecosystem as everything has to be rebuilt against it. IMO, libc and package manager are base components which make OS distinct so calling it Alpine with glibc would be a disservice as Alpine focuses on size, simplicity and security, which for glibc I would say neither are a focus. > What do you think about the project? I can share my changes in some > branch or in github. I can also share initial 3.16 binaries to have an > easier bootstrap. It was really a pain. I would be happy to contribute towards apk-tools + glibc OS (option b)) and it's ports as much as I can but would really recommend for it to define itself as separate project from Alpine (e.g. different name). I could also provide some compute and storage for it. Regards, Jakub P.