Red Hat developer Marcin Juszkiewicz is working on the RISC-V port of Fedora Linux, and after a few months of working on it, published a blog post about just how incredibly slow RISC-V seems to be. This is a real problem, as in Fedora, build results are only released once all architectures have completed their builds.
There is no point of going for inclusion with slow builders as this will make package maintainers complain. You see, in Fedora build results are released into repositories only when all architectures finish. And we had maintainers complaining about lack of speed of AArch64 builders in the past. Some developers may start excluding RISC-V architecture from their packages to not have to wait.
And any future builders need to be rackable and manageable like any other boring server (put in a rack, connect cables, install, do not touch any more). Because no one will go into a data centre to manually reboot an SBC-based builder.
Without systems fulfilling both requirements, we can not even plan for the RISC-V 64-bit architecture to became one of official, primary architectures in Fedora Linux.
↫ Marcin Juszkiewicz
RISC-V really seems to have hit some sort of ceiling over the past few years, with performance improvements stalling and no real performance-oriented chips and boards becoming available. Everybody seems to want RISC-V to succeed and become an architecture that can stand its own against x86 and Arm, but the way things are going, that just doesn’t seem likely any time soon. There’s always some magical unicorn chip or board just around the corner, but when you actually turn that corner, it’s just another slow SBC only marginally faster than the previous one.
Fedora is not the first distribution struggling with bringing RISC-V online. Chimera Linux faced a similar issue about a year ago, but managed to eventually get by because someone from the Adélie Linux team granted remote access to an unused Milk-V Pioneer, which proved enough for Chimera for now. My hope is still that eventually we’re going to see performant, capable RISC-V machines, because I would absolutely jump for joy if I could have a proper RISC-V workstation.
If I hadn’t done it before, I’d be tempted to suggest that the answer is cross compilation on a faster system. Truly, you’d be astonished just how many packages’ build systems just don’t work at all in cross compilation environment. Almost every package needs to be patched. some quite extensively.
I spent literal days trying to figure out how to cross compile gobject-introspection, so much time that by the time I’d finished I had completely forgotten what package’s dependency I was doing this for.. I can well understand why every distribution just decides that compiling on target is the only sensible course.
That said, it’d be a service to the community if some major distro were to decide that it should be possible to cross compile a complete release and committed to working with upstream maintainers to get everything in working order. It would help keeping modern distros working on other obscure or archaic architectures without necessarily having actual hardware on hand.
Thanks for that insight. Indeed my first thought was why would they not be cross compiling.