On Sat, Apr 15, 2023 at 7:08 AM Jeff Law <jeffreyalaw@xxxxxxxxx> wrote: > > > > 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. Fedora != CentOS Stream or/and RHEL. Well, I have different opinions on what CentOS and RHEL should be/support in AArch64 days. CentOS Stream or/and RHEL is a different story, and shouldn't impact Fedora in exactly the same way. I am gonna repeat myself. I doubt there will be a need to support anything below RVA23 in CentOS Stream. That of course would mean that existing (or near future, yet to be announced) SBCs wouldn't be able to run it. > > > > > 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. Brings high-performance (and yet cheap) SBCs that it's fully compliant is too expensive today (i.e. you would lose money doing it [personal opinion]). It's going to happen, it's most likely coming from the Chinese market [personal opinion]. > > > > > > 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. The first distributions to support RISCV were Debian and Fedora. I even would say we worked together while building things out, or hunting firmware/silicon bugs. I am still on the Debian IRC channel, and some Debian folks are still on Fedora IRC channel. I could say that Ubuntu is the dominating distribution for RISCV SBCs. Canonical engineering resources and willingness to support pretty much every SBC (but with vendor kernel or/and firmware) is really hard to compete with. If you want to get the best out-of-the-box experience on your RISCV SBCs definitely Ubuntu is #1 suggestion, but that wasn't the case for many years. Ubuntu came to RISCV land very late (I would say somewhat recently), but now should be dominating (no way to confirm). Nice work by the Ubuntu community and Canonical engineers. They truly want to support every piece of hardware available out there. Cheers, david > > > > > > 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 _______________________________________________ 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
