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 kids have (insanely shitty) chromebooks from school and we are absolutely responsible for the cost if they break. We have to sign a release at the beginning of the year. Whether or not they’d be able to collect from the vast majority of families is a different question, granted. But the responsibility is there.
In practice, there's a huge difference in responsibility between buying and sending your kid with a laptop and signing a paper that says you're responsible if it breaks. I'd also guess it depends on where you go to school.
My child's school provided Chromebook was broken from the beginning, so clearly they're not paying that much attention.
> Kids are given those for free, so there's no responsibility for them to keep them in good condition.
Very often they aren't (the school devices are in-school resources that aren't given to the kids any more than their desks are) and anything the kids have out of school is bought by the parents (and even if they are given the computers by the school, usually the replacement costs is on the parents if there is damage). But, either way, grade school kids are, on average, irresponsible as a matter of cognitive development (its a big part of why children are treated differently than adults legally.)
> school districts with a dysfunctional penal system.
A school district that can be described as having a “penal system” is, ipso facto, dysfunctional.
Who pays for the laptop when the school bully pours water on a kid's backpack? Or a kid has their bag in a seat and someone sits on it accidentally?
What happens when a kid's laptop is broken, regardless of the reason, and the family is unable to afford to repair it? Are we going to run into a similar situation that we had when kids couldn't pay for school lunch? Do teachers write "pay for a new laptop" in sharpie on the kid's arm for the parent?
A child's educational environment is a lot more chaotic, violent, and uncontrolled compared to an office environment. If you're issuing my child a $600 laptop and making me responsible for any damages, guess what's going to be kept at home in a secure location?
Making a child responsible for securing a laptop in an insecure environment isn't accountability, it's just a form of imprisonment.
What happens when a backpack full of paper books is destroyed? When I was a kid, we were charged between $50-100 for a book that was written in or destroyed. I bet these days it would be $200 each. Yeah we were running around with $500-600 of books in our backpacks all the time.
Back in the day it was also our (kids/parents) responsibility to provide book covers. We always used paper grocery bags, but you could buy some that were purpose built.
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.
> My understanding with Mesa is that it has very few dependencies
Some of the shader compilers require LLVM which is a giant dependency to say the least. But with Valve's ACO for RADV I think that could technically be omitted.
> Flatpak ships as it's own system managing Mesa versions.
Mixing and matching the kernel and userspace mesa components is subject to limitations. However it will transparently fall back to software rendering so you might not notice if you aren't doing anything intensive.
Related, being a container flatpak has no choice but to ship the mesa userspace component. If it didn't nothing would work.
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.
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.
If it's anything like the k1, I wouldn't be surprised if Core 2 performance was on the table. The released specs are are ~Sandybridge-Haswell like, but those were architectures made by (at the time) the top CPU manufacturer and were carefully balanced architectures to maximize performance while minimizing transistors. SpaceMIT is playing on easy mode (they are making a chip on a ~2-4x smaller process node and aren't pioneering bleeding edge techniques), but balancing an out of order CPU is still tough, and it's totally possible to lose 50% of theoretical ipc if you don't have the memory bandwith, cache hierarchy, scheuling etc.
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.
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.
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
