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]

Hi Ludovic,

address@hidden (Ludovic Courtès) writes:

> Mark H Weaver <address@hidden> 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