NVIDIA has at least 3 abstraction layers such as this and neither NRI or NVRHI seem to have issues with AMD cards. I wouldn't be surprised if one of the libraries or specific versions have problems with AMD cards, it happens during development.
Most engines I've worked do have abstraction layer for gfx APIs, usually you don't have 3 different API specific implementation for all render passes. Abstraction layers (such as NVRHI) do allow taking manual control when needed though.
Last time I checked Guile it was somewhat hard to get working on Windows, build tooling was a classic autotools mess compared to Lua consisting of a few ANSI compatible C files.
Also Guile (and many other embeddable scripting languages) want to initialize global state which I'd prefer not to.
I experienced problems with 5950X as well and nobody (including myself) seemed to believe it was the CPU before I got another 5950X which just worked with the same setup.
The issue wasn't easy to reproduce, all standard checks and torture tests ran just fine but much more random workload crashed the unit when all cores were maxed for few seconds at a time instead (eg. during compiling). Sometimes it happened twice a day sometimes once a week.
It's not exactly a simple task to make safe interpreter for bytecode as some other languages have shown. It's a trade-off which also simplifies the reference implementation.
I wouldn't trust most of these interpreters when it comes to third party code execution, I barely trust my browser even with all the R&D money and attention web browsers receive.
Sandboxed in the sense that things like file i/o or network access can be easily removed and selectively reintroduced, e.g. to give an interpreter which can trash it's own heap but can't do anything to the host.
Bounds checking on instruction opcodes can absolutely be implemented in an interpreter. I suppose it's more complicated than just trusting the integer - but then the thing doesn't fall over on malformed bytecode which seems like a feature.
What a mess. Centos Stream 8 seemed to work at first but then after upgrade to 9 secure boot didn't work at all, I couldn't even boot the 9 install media.
Funny how this just keeps happening in the C++ world. I've seen ten different promise/task frameworks successfully used in production with neat APIs but somehow std::future is still just a toy. Even std::expected was released without the usual map/then.
Good point. I use FreeBSD on a daily driver NUC and I have no need for neither WiFi not Bluetooth. But I know I'm an outlier.
Support on that front could definitely use some improvement. I had to turn off Bluetooth in the bios because it made my box hang on startup. Never bothered to find out why because I don't need it anyway.
IMHO, bluetooth is definitely not a core system for a desktop/laptop. Experience has taught me the bluetooth rune is an ancient symbol that means probably might work. There's no reason I would purchase a bluetooth perhipheral when a wired equivalent is available.
For a mobile phone, it's probably a core system; connecting to a car radio is an important use case. If wired android auto/car play includes hands free calling over usb, then that could be enough, and maybe bluetooth can be relegated to my history bin; but a lot of people like wireless earbuds.
As for WPA3, I dunno? Afaik, I've never needed that either, but my wifi is a bit old.
Most engines I've worked do have abstraction layer for gfx APIs, usually you don't have 3 different API specific implementation for all render passes. Abstraction layers (such as NVRHI) do allow taking manual control when needed though.