From mboxrd@z Thu Jan 1 00:00:00 1970 From: Kei Kebreau Subject: Re: RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.) Date: Wed, 04 Jul 2018 18:32:19 -0400 Message-ID: <87k1qamy30.fsf@posteo.net> References: <20180702101757.22792.51026@vcs0.savannah.gnu.org> <20180702101758.97A6020543@vcs0.savannah.gnu.org> <8736x1r1g0.fsf@netris.org> <877emdwm0f.fsf@fastmail.com> <87efgknn2v.fsf@netris.org> <87in5veaao.fsf@gnu.org> <871scin5bs.fsf_-_@netris.org> Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:52879) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1faqKK-00021X-4u for guix-devel@gnu.org; Wed, 04 Jul 2018 18:32:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1faqKH-0002CF-Gf for guix-devel@gnu.org; Wed, 04 Jul 2018 18:32:44 -0400 Received: from mout02.posteo.de ([185.67.36.66]:33835) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1faqKH-000242-6m for guix-devel@gnu.org; Wed, 04 Jul 2018 18:32:41 -0400 Received: from submission (posteo.de [89.146.220.130]) by mout02.posteo.de (Postfix) with ESMTPS id 5981D20F1F for ; Thu, 5 Jul 2018 00:32:30 +0200 (CEST) In-Reply-To: <871scin5bs.fsf_-_@netris.org> (Mark H. Weaver's message of "Wed, 04 Jul 2018 15:55:51 -0400") List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: Mark H Weaver Cc: guix-devel@gnu.org --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mark H Weaver writes: > Hi Ludovic, > > ludo@gnu.org (Ludovic Court=C3=A8s) writes: > >> Mark H Weaver skribis: >> >>> The end result is that the wishes of the x86_64-using majority are the >>> only ones that seem to matter in this community, and other users are >>> frequently left in a bad spot. This makes it increasingly unlikely that >>> we'll ever gain a significant number of non-x86_64 users. >> >> This kind of rant is really unhelpful. You=E2=80=99re shouting at someo= ne who >> *is* doing the work of keeping things running. > > I wasn't actually shouting, but in retrospect I can see how it came off > that way. I apologize for any hurt feelings that I caused. > > This is not Marius' fault, and I didn't intend to target him > specifically. I'm grateful for the large amount of important work that > he does on Guix. > > However, I do feel frustrated by the fact that it's considered > acceptable in this community to leave non-x86_64 users with broken > systems in the name of "moving things forward" for x86_64 users. > > Portability is important to the long-term health of the free software > movement. Especially given that fact that Intel has long ago stopped > producing processors that can be used without large amounts of nonfree > software (including the Intel Management Engine), I think we should work > to ensure that Guix works well for users of non-x86_64 systems. > > The origin of this problem is not in the Guix project. Ultimately, it's > due to the fact that x86_64 has far too much market share among > GNU/Linux developers, and therefore the upstream projects upon which > Guix depends are not being sufficiently tested on other platforms. > > However, there is one aspect of Guix that is greatly exacerbating this > problem: our impatience to always have the latest software, even if it > breaks other systems, is a serious problem in my view. > > It means that if I want to ensure that Guix works well for i686 or armhf > users, then I would need to start trying to use Guix on those systems > for real work, which at the present time would entail almost > single-handedly fixing all of the portability bugs in all of the > software that I use, at the full pace of upstream development. I would > need to keep this up for long enough to make Guix appear to be a safe > choice for i686 or armhf users, so that some of them might help work on > these portability issues in the future. > > Another problem is that Guile 2.2's compiler has become so heavy that > it's nearly unbearable to use on slower hardware. Simply running "make" > in my Guix git checkout after updating on my mips-based Yeeloong is so > slow that I'm in the habit of letting it run overnight. > > So again, and I'm saying this calmly but with great concern: given the > current priorities of the project, I could not recommend Guix to users > of non-x86_64 architectures, and I don't see how we can fix that without > attracting more developers who use those architectures. However, I > don't see how we could attract those developers if we continue to > prioritize "moving forward" at full speed for x86_64 users, even when it > breaks other systems. > >> Generalizations about =E2=80=9Cthis community=E2=80=9D obviously make no= sense. You are >> a part of =E2=80=9Cthis community=E2=80=9D so it cares just as much as y= ou do. > > By that reasoning, since I'm part of the community of humans on planet > Earth, the community of humans on planet Earth therefore cares as much > about free software as I do. > > When I suggest that the community would not take certain suggestions > seriously, e.g. the suggestion to block upgrades or merges that would > break non-x86_64 systems, that statement has some meaning. I means that > I expect that most people here would disagree, and that the maintainers > would rule in favor of "moving forward" at full speed, and that it will > be the responsibility of the tiny number of non-x86_64 Guix users to fix > portability bugs as quickly as needed so that the x86_64-using majority > need not suffer any delays. The problem is, we would need a *lot* more > non-x86_64 developers in our community to make that work, and we cannot > attract those developers given the current policies. > >> Please let=E2=80=99s work in a friendly manner towards finding solutions= to the >> problems. > > I'm open to suggestions. Do you see any solution to the problem of how > to attract more non-x86_64 users, given our current policies? > > Thanks, > Mark I am interested in helping with non-x86_64 issues. Particularly, helping with i686-related changes should be just a change in workflow, but I'm interested in obtaining freedom-respecting non-x86 hardware (or at least using a virtual machine as close as possible to real hardware configurations). Any recommendation or links for where I can get a Yeeloong laptop or what freedom-respecting armhf computers are available? --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEg7ZwOtzKO2lLzi2m5qXuPBlGeg0FAls9SvMACgkQ5qXuPBlG eg1aixAAxS63fCCfyZK+nOtf0YdGWS0SGnvjSVFIsLd4Wr9Lw0tbDPzRQqgKtprH jXYa3wNaPQ/CN1+fTDjkEjwUexj776dsnrDgYxWzrqGT+BRtbOgwN2izZwZ75KtG sd87eQOtO+lOxKzKcdBC0eSUmi3tKjEkj8GgKml4BT3R/7xklMi5Kb+zhQEkA6Of MEJAqaiTwIm8rK5QagCQulyORgwVGIoHigBKVCdncig2feCxfoFikYdBUJ5L+KCl +zv+Ae9jra6Cv0OXhLafFU6juvV0g1UfCFzmpn10+XCNtmAYhh5uxmixZRM9rtUd ubM9NI8OE/FIBtG4B5N08aA0rqpoU+hVJrMPlD7x0DarF+JjTU2jQEFSpBIM+x/v CjK0WiXvws12GYyxo6KjvmB1+aAnpOjSv2hYmrq9q6w+FdvsUL1/q5CyzbVcj6hu zrl3wcoJgku4Igf50hSauEEXL3tlCa2lfC7Nd3jZG246Jw0NmmtFtI2A1vbx+tHe mkd0jmO8LuQPw25neOfCnbIJ0Ra5gRydjWyKcPgnCaQyHDh0w7SA0ZWdUySzgvCR kkwRdHxA/ujB+s8tmHjSw29Iv+sPN9B4cduT+9wrGf4skyugOOUM3vVmQUzztkgo 70puUxzINLiL1jVZ5hy3ooLJq2ldr6CHf0cvMOBberEcViMoL/o= =Ml0Y -----END PGP SIGNATURE----- --=-=-=--