RISC-V is better for Linux due to driver support. Vendors making hardware are more likely to use RISK-V for their controllers due to the costs. Modern computers are putting more functions under control of kernels that run on proprietary compute. (There exists a chart showing how little the Linux kernel directly controls.) As more of those devices run RISC-V, they will become more discoverable.
Also, those that can design or program tge devices will have more transferrable skills. Leading to the best designs spreading, and all designs improving.

Places in a computer with compute (non-exhaustive, not all candidates for RISC-V):
BMC
Soundcard (or subsystem on mainboard)
Video card (GPU and the controller for the GPU)
Storage drives
Networking
Drive interface controlling card
Mainboard (not BMC)
Keyboard
Mouse
Monitor
UPS
Printer

Will it be perfect? Nope.
A lot of the vendors will lock things up as well.

Better for Linux? I’m not sure I would say it is. Better for the world in general? When you compare things like power consumption, you can definitely see that in some use cases (the average user), ARM is superior. But for Linux? Maybe by default owing to the fact that it’s more modern. As for RISC-V, the core is open source and “all” the extensions are proprietary, so it’s not as open source as it pretends to be. But it’s definitely better than what we’re currently accustomed to as mainstream.

Shortest answer is that RISC-V is Open Source and ARM is proprietary but what does that mean?

First, it means “freedom” for chip makers. They can do what they want, not what they are licensed to do. There are a lot of implications to this so I will not get into all of them but it is a big deal. There is even a standard way of adding ISA extensions. It makes RISC-V an interesting choice for custom chip makers trying to position themselves as a platform ( think high-end, specialty products ).

If you are a country or an economy that is being hit with trade restrictions from the Western world ( eg. China ), then the “freedom” of RISC-V also provides you away around potentially being denied access to ARM.

For chip makers, the second big benefit is that RISC-V is “free” as in beer—no licenses. For chips in laptops or servers, the ISA license is a small part of the expense per unit. But for really high-volume, low-cost use cases, it matters.

In the ARM universe, middle of the market chip makers license their designs off of ARM ( not just the ISA ). This is why you can buy “Cortex” CPUs from multiple suppliers. Nobody else can really occupy this space other than ARM. In the RISC-V universe, you can compete with ARM not just selling chips but by licensing cores to others. So, you get players like StarV and MilkV that again want to be platforms.

So, RISC-V is positioned well across the spectrum—somewhat uniquely so. This makes it an excellent bet for building software and / or expertise.

It is only the ISA that is Open Source though. Unlike some of the other answers here imply, any given RISC-V chip is not required to be any more open than ARM. The chip design itself can be completely proprietary. The drivers can be proprietary. There is no requirement for Linux support, etc. That said, the “culture” of RISC-V is shaping up to be more open than ARM.

Perhaps because they want to be platforms, or perhaps because RISC-V is the underdog, RISC-V companies are putting more work into the software for example. RISC-V chip makers seem more likely to provide a working Linux disto for example and to be working on getting hardware support into the mainline kernel. There is a lot of support in the RISC-V world for standards for things like firmware and booting.

With the exception of RaspberryPi, the ARM world is a lot more fractured than RISC-V. You see this in the non-Pi SBC world for example. That said, if we do consider just RaspberryPi, things are more unified there than in RISC-V.

Overall, RISC-V may be maturing more quickly than ARM did but it is still less mature overall. This is most evident in performance. Nobody is going to be challenging Apple Silicon or Qualcomm X Elite with their RISC-V chips just yet. Not even the Pi is really at risk.

Eventually, we will also just get completely Open Souce designs that anybody can implement. These could be University research. They could be state funded. They could be corporately donated designs ( older generations maybe ). Once that starts to happen, all the magical things that happened for Open Source software will happen for RISC V as well.

Open Source puts a real wind at RISC-V’s back though. And no other platform makes as much sense from the very big to the very small.

Actually, I think RISC-V is even worse than ARM. With ARM, at least you have a quite reliable instruction set on the CPU. With RISC-V, most vendors have their own extensions of the instruction set, which opens a big can of worms: Either you compile all your stuff for your own CPU, or you have a set of executables for each and every vendors flavor of RISC-V commands, or you exclusively use the RISC-V core commands. The first would be only for hardcore geeks, the second would be a nightmare to maintain, and the third would be not really efficient. Either way, it sucks.

Yes. Less blobs than ARM. I’m not even sure if some RISC-V have any blobs – someone correct me if I’m wrong.

Also getting cockblocked by proprietaryisms is bullshit. HDMI is a Circle Jerk of capitalism controlling competition and the market for self preservation.

I don’t think there has been huge issues with incompatible ISAs on ARM. If you’d use NEON extensions, for example, you might have a C-implementation that does the same if the extensions are not available. Most people don’t handwrite such code, but those that do usually go the extra mile. ARM SoCs usually have closed source drivers that cause headaches. As well as no standardized way of booting.

I haven’t delved super-deep into RISC-V just yet, but as I understand these systems will do UEFI, solving the bootloader headache. And yes, there are optional extensions and you can even make your own. But the architecture takes height for implementing an those extensions in software. If you don’t have the gates for your fancy vector instruction, you can provide instructions to replicate the same. It’ll be slower on your hardware, but it’ll be compatible if done right.

i’ve had the same thought lately. the common arm design approach around the bootloader seems to turn old Android phones and tablets into e-waste sooner than necessary, in theory they could all run Linux and be useful for another ten years. but it’s hard enough to port mainline Linux to Android devices, and almost impossible to get all the included hardware working properly

deleted by creator