Worth noting that just because a CPU uses the RISC-V instruction set does not make it open hardware; it just makes it possible for it to be open hardware, but it’s still up to the copyright holder to release the source files and design as open source.
That’s true, but open source software is generally written in high level, portable languages that can be compiled to multiple CPU architectures without changing the code, so proprietary software is really what would have any problems running, and even then, there are x86 emulators like Box86/64 and FEX out there and can even work transparently using systemd-binfmt.
In a small way, yes, in that the software ecosystem built around it would work on future open hardware, but the hardware could absolutely still be fully, 100% proprietary.
Good. Pump that up. I want to be able to run my favorite open OS on open hardware.
Worth noting that just because a CPU uses the RISC-V instruction set does not make it open hardware; it just makes it possible for it to be open hardware, but it’s still up to the copyright holder to release the source files and design as open source.
Fair, but it means devs will write software that can one day run on open hardware.
That’s true, but open source software is generally written in high level, portable languages that can be compiled to multiple CPU architectures without changing the code, so proprietary software is really what would have any problems running, and even then, there are x86 emulators like Box86/64 and FEX out there and can even work transparently using systemd-binfmt.
At the application level? Yes. At the OS / package level? It’s still a work in progress. And you need the latter to use the former.
Still, better than fully proprietary hardware.
In a small way, yes, in that the software ecosystem built around it would work on future open hardware, but the hardware could absolutely still be fully, 100% proprietary.