How big the performance hit is depends on the game. If the game logic itself is CPU-heavy, the performance hit will be big. If the game spends most of the CPU time in system-supplied libraries or isn't CPU-heavy to begin with, it's gonna be small.
The good news is that many VR titles aren't CPU-heavy.
For 2) I'd also suggest to check out SDL. There are excellent SDL bindings for Rust, and it's way less involved than dragging in a fully-featured game engine.
Pathfinder: Kingmaker ($2.99) (make sure to force-enable the Windows build on the Steam Deck, the Linux build has issues with gamepad input on the kingdom management screen)
I'm willing to bet that it's AI. It soft-contradicts itself quite often, emphasising that C++ is "Performance First", but then also claiming stuff like "Rust achieves memory safety with zero runtime overhead".
Edit: What I am trying to say is that I have seen text like this in LLM output quite often, if the LLM is mixing text from different sources in its training data.
Also, there is just wrong stuff in the text itself, not only in the conclusion. For instance the claim that Rust's type system makes data races impossible. They are easier to avoid, but there is nothing stopping you from writing data races...
Here, for instance, have a data race in safe Rust...
There are several small differences between the Xbox 360 and the Xbox Series X gamepad. No single point by itself would be a very big difference, but overall it sums up. I have both gamepads in front of me, and will try to make a comparison:
The material of the Xbox 360 gamepad feels "better". I can't exactly say why, but I think it's because of its smooth material on the bottom.
The Xbox 360 gamepad has bigger analogue sticks, with stronger springs.
Similarly, the triggers of the Xbox Series X gamepad are "weaker" than of the Xbox 360 gamepad.
I would have sworn that the Xbox Series X controller is a lot lighter too, but turns out, after weighing them both, that the Xbox 360 controller is slightly lighter. It does not feel this way though, with the Xbox 360 gamepad feeling way sturdier and heavier (but, as said, it's actually lighter?!?).
The buttons on the Xbox 360 gamepad feel a lot smoother. They don't make a "cheap, broken device" noise when being pressed.
This also applies to the D-Pad.
I think the last point - the feeling when using the buttons and especially the D-Pad - is the most important one for me. On the Xbox 360 gamepad the buttons feel like actual buttons. On the Xbox Series X gamepad they sound and feel like a fidget toy. Using the D-Pad on the Xbox Series X gamepad is really annoying, because of the noise it makes.
What annoys me is that previous generations of Xbox controllers had quite good build quality. The Xbox 360 controller was amazing in that regard, and the Xbox One controller was pretty decent too. The Xbox Series X controllers (and I am explicitly not excluding the "Elite" model) feel like cheap trash in comparison.
Configure the Display Manager to use that session for their users (In GDM, for instance, it's enough to manually select it once on login - GDM remembers the last-used session per user)
Gamedev here:
For non-indie projects it's not up to the devs to decide which platforms get a native build. That decision is made by the publisher, and usually depends strongly on the estimated amount of extra work needed to make a native version. I agree with your statement, that if devs use ARM development PCs, they get a strong argument to convince publishers to pay for a native version, because porting costs will drop to near-zero.
However (there always is a "however"):
Many devs cannot switch away from Windows. If one develops for PC only, it's possible. If one targets other platforms too (think: game consoles), one is stuck with whatever development environment the manufacturers of those platforms support - what is typically Windows and Visual Studio. It is kind of a chicken-and-egg problem. Platform SDKs will be made available for other operating systems or processor architectures once enough gamedevs are using those. Gamedevs cannot yet use those because platform SDKs aren't available for them...
It's, to be honest, a frustrating experience...
I personally would switch away from MSVC and Windows the moment I get an opportunity to. However, there never was an opportunity up to now... Our previous tech-director was pushing for Linux on dev machines - or rather: "let the devs use whatever they want, as long as it works" - but there never was an opportunity to switch, due to our games' target platforms allowing only Windows for development...
I've never used Heroic, so I can't say what to expect, but I've never had any issues downloading games via the GoG website.
Have you tried that? Maybe it's faster?
Though, honestly, I think i might just be some outage on GoGs side. If the downloads via the website are slow too, it might be worth talking to their support.
For a typical desktop Linux 12 GiB should be fine.
It depends on what you do with the system, of course. If you regularly compile big and template-heavy C++ codebases, work with Blender,... then 12 GiB won't be enough.
(What really surprised me was how much can still be done with just 4 GiB of memory. My laptop is currently limited to 4 GiB, and with some effort to set up a minimalist system it's working surprisingly well. I barely ever hit the memory limit - actually only when compiling big template-heavy C++ codebases 😉.)
If you count DOSBox as emulation (what it definitely is - unlike WINE it actually emulates an x86 PC and peripherals):
The Settlers 2: This is a timeless classic. The graphics are 2D, but they still look OK today.
Albion: A Science Fiction and Fantasy RPG (yes, it has both, and that'a a key point of the story). The gameplay itself isn't that great, but the lore, story and the graphics are amazing.
I've played both on the Deck, and they both work great.
(Btw: I did not use Settlers 2 as an example for my DOSBox setup guide by chance. I picked it because it is an amazing game and still fun nowadays.)
Thanks, gonna do that first before I start my next print. This sounds like a really plausible cause!