From: Kei Kebreau <kkebreau@posteo.net>
To: Mark H Weaver <mhw@netris.org>
Cc: guix-devel@gnu.org
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 [thread overview]
Message-ID: <87k1qamy30.fsf@posteo.net> (raw)
In-Reply-To: <871scin5bs.fsf_-_@netris.org> (Mark H. Weaver's message of "Wed, 04 Jul 2018 15:55:51 -0400")
[-- Attachment #1: Type: text/plain, Size: 5023 bytes --]
Mark H Weaver <mhw@netris.org> writes:
> Hi Ludovic,
>
> ludo@gnu.org (Ludovic Courtès) writes:
>
>> Mark H Weaver <mhw@netris.org> 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’re shouting at someone 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 “this community” obviously make no sense. You are
>> a part of “this community” so it cares just as much as you 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’s 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?
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 832 bytes --]
next prev parent reply other threads:[~2018-07-04 22:32 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20180702101757.22792.51026@vcs0.savannah.gnu.org>
[not found] ` <20180702101758.97A6020543@vcs0.savannah.gnu.org>
2018-07-02 17:29 ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Mark H Weaver
2018-07-02 18:06 ` Marius Bakke
2018-07-03 19:20 ` Mark H Weaver
2018-07-04 7:21 ` Ludovic Courtès
2018-07-04 19:55 ` RFC: Portability should be a higher priority for Guix (was Re: 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf.) Mark H Weaver
2018-07-04 22:32 ` Kei Kebreau [this message]
2018-07-05 8:39 ` Ludovic Courtès
2018-07-05 14:15 ` Kei Kebreau
2018-07-05 9:04 ` Jonathan Brielmaier
2018-07-05 19:40 ` Andreas Enge
2018-07-05 6:38 ` Ricardo Wurmus
2018-07-05 8:46 ` Ludovic Courtès
2018-07-05 9:52 ` Andreas Enge
2018-07-05 8:50 ` Ludovic Courtès
2018-07-05 9:01 ` Ludovic Courtès
2018-07-02 18:28 ` 01/01: build-system/meson: Really skip the 'fix-runpath' phase on armhf Marius Bakke
2018-07-03 19:24 ` Mark H Weaver
2018-07-04 7:27 ` Ludovic Courtès
2018-07-04 14:27 ` Marius Bakke
2018-07-03 21:28 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://guix.gnu.org/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87k1qamy30.fsf@posteo.net \
--to=kkebreau@posteo.net \
--cc=guix-devel@gnu.org \
--cc=mhw@netris.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/guix.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).