It's worse than that -- there is not a single piece of hardware that implements RVA23 available to be bought on the market today.
There are SoCs on the market that implement RVV (Vector extensions), and SoCs on the market that implement H (Hypervisor extensions).
There are no SoCs on the market that implement both at the same time. And both are mandatory for RVA23.
I'd love to be proven wrong on the hardware availability. If there's hardware to be bought in western countries that implements both RVV and H, please let me know.
Most of the low-level pieces are in Rust, the TUI is written in Python and most of the remaining pieces are getting lowered down to the Rust libraries over time.
(It was all Python up until ~6 months ago)
EDIT: Oh, and you can buy the Grayskull cards online now, without contacting anyone.
Firmware can sometimes get a bit complicated due to third party IP used and whether that can be opensourced, but within those constraints this is the ambition.
I.e things like memory controller setup and link training is often constrained by the IP vendors on whether you can share it in source form.
Good news in general though -- there isn't a lot of firmware on these cards in the path of the workloads, most of it is around system management and thermals/power.
Terminology-wise some of pieces in the code base are called firmware, but are loaded at runtime and built as part of the usual build process. It's more of a linked-with-the-workload libraries than resident FW. (There's some of both though).
Zero work? I guess memory fades quickly sometimes.
Apple rented out DTK systems for $500 for developers to get their hands on ARM hardware and port their applications. Hardly zero work. You couldn't even keep the hardware, you had to send it back (and originally you wouldn't even get $500 in credit to buy a production system with, luckily they fixed that after the easily predictable uproar).
Google is providing software emulators instead, much easier to work with and doesn't require complicated device logistics. Not only that, but the only audience that really needs to do work to get ready, are either those producing NDK applications, or those working on hardware support for RISC-V.
Java/Kotlin applications would not need any porting. Sounds like zero work to me!
But my immediate conclusion isn't "Signals are dangerous and let's go deep on the complexity thereof". Instead, my primary conclusion really is "Someone forgot to write a testcase to make sure log rotation behavior is covered, so of course it might regress".
It's sad how the ND-100/500 (and 5000+) families have almost completely disappeared, including online material about them.
The IT department at my university was involved in NDIX development (BSD for ND-5000), I believe. This was a few years before my time so I didn't get first-hand exposure to that.
I do regret not holding on to one of the Compact ND-100/110s that we had around in the late 90s, nor any of the Tandberg terminals that we had huge numbers of.
Be careful about diving in and doing too much work yourself as a developer. If you do, sure, your team now has 11 engineers instead of 10. 10% bump!
What can you, as their manager, do to instead increase their productivity by 10%? Likely many things, and this is a lot more sustainable, because otherwise the team gets neglected from a manager support perspective while you're busy working with them.
Of course, find things to do technically to help the team if you want, that's a great idea. But don't assume that the best thing you can do for them is always to do what they are doing.