It is increasingly rare for EDK2 (A modern, feature-rich, cross-platform firmware development environment for the UEFI and PI specifications from www.uefi.org: https://github.com/tianocore/edk2) to not be used as the basis for a secure boot load plus runtime firmware services stack).
Vendor veerage from vanilla upstream edk2 does occur of course but it does so also with legacy BIOS’. There’s no getting around it in the real world with very very few exceptions.
UEFI evolved to solve standardized boot and firmware at scale and the internet as it stands today would struggle without a standard like it. RISC-V taking a different approach would be swimming against the tide backwards to irrelevance.
Crystal lang deserves a look given the article writer’s preferred language attributes. It has OO paradigms, elegant composability, efficient codegen etc.
This. It is somewhat disheartening to hear the whole interop-with-C with Rust being an insurmountable problem. Keeping the whole “it’s funded by the Government/Google etc” nonsense aside: I personally wish that at least a feeble attempt would be made to actually use the FFI capabilities that Rust and its ecosystem has before folks form an opinion. Personally - and I’m not ashamed to state that I’m an early adopter of the language - it’s very good. Please consider that the Linux kernel project, Google, Microsoft etc went down the Rust path not on a whim but after careful analysis of the pros and cons. The pros won out.
My perception is that the designers have taken their rough experience onboard and have now settled on a reasonable development model with an emphasis on achievable feature additions. The language server is astonishingly good, the feature set as it stands very much batteries included and the reaction time to highlighted discrepancies and a reasonable resolution very commendable. I’m an embedded dev so my opinions are biased accordingly but I do see some pretty awesome additions with vls, veb, vui etc. Of course, please conduct your own experiments and research but I’m incrementally optimistic.
You’re right. But consider that in order to be useful when not fused off, the design would need to have a bunch of additional logic (interconnect ports, power control machinery etc) at the periphery of the to-eventually-be-fused-off area that would likely remain even when things were fused off. That may impact power.
Apart from that there’s the other usual angles: The very fact that there’s additional logic in the compute path (eventually fused off) means additional design and verification complexity. The additional area, although dark, eats into the silicon yield at the fab.
An ISO standard is hard to gepolitically regulate, I would think.
It also cements the fact that the technology being standardized is simply too fundamental and likely ubiquitous for folks to worry about it being turned into a strategic weapon.
Taking the previously mentioned ethernet example (not a perfect one I should accentuate again): why bother with blocking it's uptake when it is too fundamentally useful and enabling for a whole bunch of other innovation that builds on top.
A large motivation for this move is likely to ensure that attempts by some incumbent ISAs to lobby the US government to curb the uptake of RISC-V are stymied.
There appears to be an undercurrent of this sort underway where the soaring popularity of RISC-V in markets such as China is politically ripe for some incumbent ISAs to turn US government opinion against RISC-V, from a general uptake PoV or from the PoV of introducing laborious procedural delays in the uptake.
Turning the ISA into an ISO standard helps curb such attempts.
Ethernet, although not directly relevant, is a similar example. You can't lobby the US government to outright ban or generally slow the adoption of Ethernet because it's so much of a universal phenomenon by virtue of it being a standard.