There are states which are worse, but don't get as much press coverage. Louisiana is essentially just a a US state controlled by petrochemical companies, so portions of the state have extreme rates of cancer.
Microsoft has the OpenCL, OpenGL, Vulkan compatibility pack. Major issue is that it's just Mesa compiled to a D3D12 GPU backend, so if you have anything but Snapdragon it's basically useless.
Without being hands on, it's difficult to make a direct comparison. There's 2 processors according to CNX [0], and the HP core's instruction set might roughly be comparable to M55.
BC-250 had a standard set of SuperIO and Southbridge, and the PS5 has a duo consisting of a custom NVMe controller and custom SuperIO. If what is true from the PS4 is applicable to the PS5, there had to have been some patches to the kernel in order to add platform support for those custom chips.
It's unfortunately par for the course for something like a console to be like this. Consoles are often subsidized by licensing and publishing costs of games, so preventing you from running your own software is within their best interest.
Judging by how every single TSA agent is horrifically trained and doesn't have a drop of care in the world, abolishing the TSA would be a step up from having it.
Kids are given those for free, so there's no responsibility for them to keep them in good condition. It would take a restructuring of laptops within the school system to kids/families having a joint ownership over the laptop to stop them intentionally destroying them. Even then, there are complications like kids that will absolutely destroy anothers' for fun.
And knowing how laptop makers treat keyboard repairs, the keyboard switches are easy to damage beyond repair and expensive to replace, making them a target for "problem" kids in school districts with a dysfunctional penal system.
My understanding with Mesa is that it has very few dependencies and is ABI stable, so freezing Mesa updates is counterproductive. I'm not sure about Snaps, but Flatpak ships as it's own system managing Mesa versions.
I have to wonder if the Nintendo Switch picking up the Tegra X1 SOC has something to do with it. There's a good chance a lot of components of the (custom microkernel) operating system are derived from Android, and with the Switch receiving active support for so long, I wouldn't be surprised if the work between the Shield TV and Switch are related.
With the Switch being shipped for nearly 10 years, it pales in comparison to the shelf life of most any processor Apple, Google, Samsung, Qualcomm, MediaTek (?) push out.
Though Apple in particular is interesting, as their Apple TV lineup also has the same long legs, with the Apple TV HD/4th Gen releasing in 2015 and receiving the latest OS.
Thing about RISC-V is that there are technically no barriers on doing as you see fit, but there's very clearly defined lines where community support isn't guaranteed, like custom extensions or screwing with already ratified extensions.
We actually don't know a lot about the UR-DP1000 chip, while we do know quite a bit about the 3A6000 because of Chips and Cheese. This makes a thorough analysis of the crimes committed within the core architecture of the UR chip more of speculation than a coherent discussion.
But we do know:
1. The UR-DP1000 does not have any Vector instructions
2. UR only has a 4 way OOO design, while the 3A6k is 6 way OOO
3. The cache architecture of the UR is more complicated, with 4 cores sharing 4MB L3 per cluster (2 clusters total), and a 16MB global L4 where the 3A6k doesn't have this
4. The UR chip doesn't have SMT
Cache issues add another layer here, if it's not the whole issue. Device tree patches for the K3 have 2 clusters of 4 cores with shared 4MB L2 cache per cluster. Core 2 Duo P8400 has 3MB L2 shared between 2 cores, and Sandybridge-Haswell have per core L2 and shared L3.
A TL;DR doesn't explain everything. The Milk-V Titan doesn't have Vector instructions or crypto, while the Pi 5 does. It's very clearly a broken benchmark.
This is why a bunch of RISC-V people won't buy boards without RV Vector instructions.
Something is odd here, the Core 2 Duo only has up to SSE 4.1, while the RVA23 instruction set is analogous to x64-v3. I find it hard to believe that the SpacemiT K3 matched a Core 2 duo single core score while leveraging those new instructions.
To wit the Geekbench 6.5.0 RISC-V preview has 3 files, 'geekbench6', 'geekbench_riscv64', and 'geekbench_rv64gcv', which are presumably the executables for the benchmark in addition to their supported instruction sets. This makes the score an unreliable narrator of performance, as someone could have run the other benchmarks and the posted score would not be genuine. And that's on top of a perennial remark that even the benchmark(s) could just not be optimized for RISC-V.
LoongArch is a weird mix of MIPS and RISC-V. There's not much that would be gained by investing a whole bunch into LoongArch that couldn't also be done to RISC-V, if at all.
KWin/Xorg AFAIK has been on maintanence duty (i.e. fixes mostly come from XWayland) for >5 years now. KDE has expulsed the Xorg codebase of KWin into a seperate repo in preparation of a Wayland only future.
Even if KDE/Xorg is a stable experience is true now, it will not be true in the medium to short term. And a distro like Kubuntu might be 2 years out from merging a "perfect" KDE Plasma experience if it arrived right now.
My 2 cents is that Geely could leverage their existing Volvo and Polestar dealership network much like KIA/Hyundai. Geely Holdings own ~80% of Volvo cars, and a majority share of Polestar. Polestar doesn't own any manufacturing facilities, instead using Geely or Volvo factories.
Geely's entry into the US EV market could/should ultimately be downmarket of Volvo/Polestar, since both of those are luxury vehicle brands.
There's something to be said that mass production is another distinct stage of invention. Karl Benz may have invented the first internal combustion engine car, and plenty more built cars by hand for the rich, but Henry Ford made cars anyone could have for cheap.