On 4/14/23 20:14, Neal Gompa wrote:
We should not screw up with RISC-V in Fedora like RHEL did with ARM.
Yes, I'm saying RHEL's ARM strategy was a mistake, and still is, to
some degree. We see aspects of this being walked back now as the
ecosystem didn't go the way RHEL ARM folks hoped, and breaking further
into that ecosystem requires reversing some of those choices. We
should learn from that for Fedora RISC-V.
Well, the RHEL direction was essentially mandated by the markets vendors
were chasing. Plain and simple. You may say RHEL's ARM strategy was a
mistake, but I'd disagree strongly.
Like ARM, RISC-V risks (pun intended!) total stratification between
low/mid range SBCs and unobtanium servers. Given the current path of the
groups working in RISC-V, this is certain to happen. Thus, if Fedora
RISC-V cannot run well on RISC-V SBCs, then we effectively have no
useful RISC-V port, since nobody can use it.
That's already happened. Stratification was inevitable given the RISC-V
model. The only questions in my mind are viability in the server space
and whether or not that could one day lead to offerings between server
class and the SBC systems.
We already have similar problems with POWER (ppc64le) and Z (s390x),
but the former was built in an era when there were computers of
reasonable performance across all price points. The latter is
basically funded by IBM development and nobody can really do anything
with it.
The era where POWER was a viable platform outside the server space has
been gone for a long time. x86 just killed the market and it's not
clear there's space for anyone else in that market. Apple may prove me
wrong in that space, but the investment they've made is enormous.
For the first time in a long time, Fedora has the opportunity to have
a first-mover advantage and become the default platform for hobbyist,
professional, and high-end systems of an architecture. Let's not
squander it on myopic views of datacenter class hardware that don't
exist yet leveraging specifications that nobody is implementing in
currently available hardware.
First mover advantage is already lost to Ubuntu. Sad but true in my
mind. Fedora has zero presence in the spaces that matter.
Insofar as subarches go, let's just define them in RPM like we have
for 32-bit x86 and more recently 64-bit x86. If we know what kind of
ISA profiles are out there, we should just incorporate them into RPM
and set up the compatibility detection logic for them to work.
The current and future crop of SBCs just aren't going to have the oomph
to be a viable platform in my mind. I can take a 10+ year old xeon run
qemu on top of it and get dramatically better risc-v performance than
the SBCs out there
Creating subarch around something like rv20, go ahead. But it's going
to be worse than the armv7 situation was.
jeff
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
