@MaddieM4@raphus.social It strikes me that software is inherently more expensive than hardware. Herb Sutter already pointed out that C++ keeps getting lumped in with C in most bodies of CWE statistics. They are fundamentally different languages. I keep seeing CVEs for C++ and looking for if they used std::span (like Bjarne Stroustrup already advised everyone to do, even WITHOUT C++ Safety Profiles making the cut) and then seeing they did not. Though it could be fairly stated CHERI has an installed base problem, the "silver bullet language" paradigmatic approach to memory safety some advocate does not strike me as reflecting the underlying economics. How much more expensive is it to ditch existing implementations in the name of memory safety, versus changing things further down in the stack? This is a rhetorical question, of course, but I am not sold on Rust at all for the reasons that it's being sold, but if people want to use it, go ahead... just don't claim it's a silver bullet, or that this approach is even remotely cost effective at scale. If running CWEs vs CVEs in a contrast study strictly by the numbers the way the MSFT folk did (which is where the apparent category error giving rise to the boosting of the "new paradigm" seems to have originated) yields memory safety as the most prominent issue *by the numbers*, do they then argue that the "new paradigm" approach inherently trumps capabilities addressing in hardware, without even showing or examining this in its wider context? Because if they are, I'm missing something. Economics, perhaps. So why force retooling and reskilling when we can add CHERI to ARMv8.1 as already exists, and is specified for x86-64 v2+ already, and as Laurie/Watson have already published, only change <0.05% of a full blown KDE desktop OS distribution? Is there something else to this? I have the usual philosophical razors at the ready as garlic and crucifix to ward off the conspiracy theory. https://www.cl.cam.ac.uk/research/security/ctsrd/pdfs/20210917-capltd-cheri-desktop-report-version1-FINAL.pdf