What is RISC-V and why it matters to Canonical • Hacker News Board

Re: What is RISC-V and why it matters to Canonical

#41

Post by storus » Fri, Apr 10, 2026, 11:28 PM UTC

hajile wrote: post #33

storus wrote: post #31

Will RISC-V end up with the same (or even worse) platform fragmentation as ARM? Because of absence of any common platform standard we have phones that are only good for landfill once their support lifetime is up, drivers never getting upstreamed to Linux kernel (or upstreaming not even possible due to completely quixotic platforms and boot protocols each manufacturer creates). RISC-V allows even higher fragmentation…

RVA23 is the standard target for compilers now. If you support newer stuff, it’ll take a while before software catches up (just like SVE in ARM or AVX in x86). If you try to make your own extensions, the standard compiler flags won’t be supporting it and it’ll probably be limited to your own software. If it’s actually good, you’ll have to get everyone on board with a shared, open design, then get it added to a future…

Thanks, that however addresses only a part of the problem. ARM is also suffering from no boot/initialization standard where each manufacturer does it their own way instead of what PC had with BIOS or UEFI, making ARM devices incompatible with each other. I believe the same holds with RISC-V.

Re: What is RISC-V and why it matters to Canonical

#42

Post by ddtaylor » Fri, Apr 10, 2026, 11:35 PM UTC

unethical_ban wrote: post #28

ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

Not sure on the timelines, but snap, upstart and Mir were all attempts at evolving Linux ecosystem that lost to RedHat-backed systems. Unity was legit abandoned, and bazaar... Not sure what they were trying to solve there with git and forges already existing.

Wayland was created in 2008. Mir was created in 2013.

Bazaar and Git were created around the exact same time.

Unity was abandoned after a failed attempt to circumvent Gnome 3. I was actually involved with the development of Compiz and they hired Sam to work on Unity, as he was one of the masterminds behind Compiz, but again they just didn't have the vision or execution to make it work.

Re: What is RISC-V and why it matters to Canonical

#43

Post by ThatMedicIsASpy » Fri, Apr 10, 2026, 11:35 PM UTC

IshKebab wrote: post #19

mcdow wrote: post #2

I’m looking forward to using a RISC-V computer in 20 years

I think 10 years is a more realistic estimate. Probably first in servers and Android phones.

They are everywhere already in microcontrollers like ESP32.

Re: What is RISC-V and why it matters to Canonical

#44

Post by hajile » Fri, Apr 10, 2026, 11:40 PM UTC

storus wrote: post #41

hajile wrote: post #33

Earlier quoted context omitted.

RVA23 is the standard target for compilers now. If you support newer stuff, it’ll take a while before software catches up (just like SVE in ARM or AVX in x86). If you try to make your own extensions, the standard compiler flags won’t be supporting it and it’ll probably be limited to your own software. If it’s actually good, you’ll have to get everyone on board with a shared, open design, then get it added to a future…

Thanks, that however addresses only a part of the problem. ARM is also suffering from no boot/initialization standard where each manufacturer does it their own way instead of what PC had with BIOS or UEFI, making ARM devices incompatible with each other. I believe the same holds with RISC-V.

There has been concerted effort to start working on these kinds of standards, but it takes time to develop and reach a consensus.

Some stuff like BRS (Boot and Runtime Services Specification)and SBI (Supervisor Binary Interface) already exist.

Re: What is RISC-V and why it matters to Canonical

#45

Post by mikestorrent » Fri, Apr 10, 2026, 11:41 PM UTC

wk_end wrote: post #36

mikestorrent wrote: post #25

Earlier quoted context omitted.

x86_64 machines are RISC under the hood and have been for ages, I believe; microcode is translating your x64 instructions to risc instructions that run on the real CPU, or something akin to that. RISC never died, CISC did, but is still presented as the front-facing ISA because of compatibility.

That's a common factoid that's bandied about but it's not really accurate, or at least overstated. To start, modern x86 chips are more hard-wired than you might think; certain very complex operations are microcoded, but the bulk of common instructions aren't (they decode to single micro-ops), including ones that are quite CISC-y. Micro-ops also aren't really "RISC" instructions that look anything like most typical RI…

Thanks for the detail, that's very clarifying

Re: What is RISC-V and why it matters to Canonical

#46

Post by Redoubts » Fri, Apr 10, 2026, 11:43 PM UTC

ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

In a way it's really sad how many swings and misses Canonical has taken in its history.

Re: What is RISC-V and why it matters to Canonical

#47

Post by maxloh » Fri, Apr 10, 2026, 11:43 PM UTC

ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

Snap is definitely not abandoned.

Re: What is RISC-V and why it matters to Canonical

#48

Post by sharts » Fri, Apr 10, 2026, 11:43 PM UTC

ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

It’s canonically fucked

Re: What is RISC-V and why it matters to Canonical

#49

Post by Findecanor » Fri, Apr 10, 2026, 11:50 PM UTC

storus wrote: post #41

hajile wrote: post #33

Earlier quoted context omitted.

RVA23 is the standard target for compilers now. If you support newer stuff, it’ll take a while before software catches up (just like SVE in ARM or AVX in x86). If you try to make your own extensions, the standard compiler flags won’t be supporting it and it’ll probably be limited to your own software. If it’s actually good, you’ll have to get everyone on board with a shared, open design, then get it added to a future…

Thanks, that however addresses only a part of the problem. ARM is also suffering from no boot/initialization standard where each manufacturer does it their own way instead of what PC had with BIOS or UEFI, making ARM devices incompatible with each other. I believe the same holds with RISC-V.

There is a RISC-V Server Platform Spec [0] on the way supposed to standardise SBI, UEFI and ACPI for server chips, and it is expected to be ratified next month. (I have not read it myself yet)

[0]: https://github.com/riscv-non-isa/riscv-server-platform

Re: What is RISC-V and why it matters to Canonical

#50

Post by esperent » Fri, Apr 10, 2026, 11:54 PM UTC

maxloh wrote: post #47

ddtaylor wrote: post #23

I stopped listening to what Canonical says. They often get involved in things and disturb the ecosystem then abandon stuff or dig a "not invented here" hole. Unity, Bazaar, Mir, Upstart, Snap, etc. All of them had existing well established projects they attempted to uproot for no purpose other than Canonical wanted more control but they can't actually operate or maintain that control.

Snap is definitely not abandoned.

Sadly