I am now at the point where I think there are two things happening.
Examples for the first one would be new battery tech for electric vehicles, new ways to harvest renewable energy, new tools that allow to make software more stable,... Examples for the second would be NTFs, Crypto-Currencies, "AI", e-Fuels,...
They have done that already. It's called Kylin.
ARM based Deck would be a huge improvement to battery life. Don't get your hopes up too high. You will need an emulation layer like FEX of Box64, and unlike WINE those do have quite a substantial overhead.
It is impressive how far those emulators have come, especially since they got the option to use native libraries instead of emulated ones, but the game logic itself will always need emulation...
This doesn't mean it can't be done, it just means that the ARM CPU needs to be pretty fast to counter the emulation overhead, and that's why I have my doubts about the energy efficiency...
(Btw: I have tried running several AMD64 games on my A311D powered MNT Reform laptop with Box64. It's impressive how well the emulation runs, and how many games are actually playable already. However, I also encountered a lot of games that don't reach enjoyable FPS on that hardware. With a faster ARM chip though....)
No. Or rather, not yet. Valve has not released SteamOS 3 for anything other than the Steam Deck, but is planning to do so at some point in the future.
I honestly wouldn't recommend SteamOS for anything other than a dedicated gaming device though. It excels at its use case of launching games via Steam, but for everything else it is quite cumbersome... I would much rather install a general purpose Linux distribution and run Steam on it.
First things first: This hasn't happened to me in ages. I even stopped looking at ProtonDB. Stuff just runs.
However, if a game I buy really wouldn't run on Linux, I would just refund it (if possible) and play something else. I have a pile of shame that could fill a hundred lifetimes, I really don't need to play this one particular game.
If you are using systemd, there's a tool called coredumpctl.
A geh, is doch iagendwie liab, oda?
Übahaupt, jetzt wo si Hochdeutsch imma mea duachsetzt, und vü junge Leit übahaupt nimma richtig östareichisch^1^ redn leanan, missn ma doch schaun, dass unsa Sproch net oafoch ausstiabt, oda?
Mia hom a a longe Tradition, wonns um Mundoatdichtung geht. Da Dichta von da obaöstareichischn Hymne zum Beispü, da Stelzhamer Franz, hot gonz vü in Mundoat gschribn.
Und weis ma grod eifoit: Es gibt a a eigene Wikipedia in unsam Dialekt: https://bar.wikipedia.org/ Oba do dua i ma söm schwah, dass i des vasteh. De is scho in da äagstn von de oagn Mundoatn gschribm.
(So, jetzt woas i net, wöcha Sproch i im Dropdown do untn auswöhn soid... Wei wirklich Deitsch is des jo net...)
[^1^] I am fully aware that the dialect I'm writing in is not called "Austrian". The two big dialects spoken in Austria are "Alemannic" and "Bavarian", and the one I'm writing is the Bavarian dialect. I'm only using the word "östareichisch" here, because that's what I expect most people to use in spoken conversation.
From the official rules:
Once you provide the required information and submit the form you will receive one (1) entry into the Sweepstakes. After you submit the form you will have the opportunity to earn up to three (3) additional entries. [snip]
a) Create a Steam account. [snip]
Okay, that's doable, I guess most people have one already
b) Click the ‘follow’ button to follow @summergamefest on X. [snip]
Suuuuure. Who in their right mind would willingly go on X?
c) Click the ‘follow’ button to follow @thegameawards on X. [snip]
Again X? How much did Elon pay them?
If you want your module to contain submodules, it needs to go into a folder. That folder needs to be named like the module.
It's explained pretty well in the book, imho: https://doc.rust-lang.org/stable/book/ch07-02-defining-modules-to-control-scope-and-privacy.html
So, for your example, the file structure could for instance be
src/main.rs
src/separate_file1.rs
src/separate_file1/separate_file2.rs
An alternative layout that I think is more common would be
src/main.rs
src/separate_file1/mod.rs
src/separate_file1/separate_file2.rs
Or, if you think separate_file2 could contain submodules at some point, maybe
src/main.rs
src/separate_file1/mod.rs
src/separate_file1/separate_file2/mod.rs
Some games, like the Pathfinder games by Owlcat, use that initial input to determine if you are playing with mouse/keyboard or a gamepad. Depending on that, you get presented with a different UI in the main menu.
Another reason for such a screen could also be Xbox support. Nowadays it's no longer necessary, because user-handling has been vastly improved with the GDK, but before the GDK was released a splash screen was the most user-friendly way to do user-handling in a single-player or online-multiplayer game on Xbox.
I'd also suggest a Steam Deck, but for a different reason. My experiences with switchable graphics (both, nVidia and AMD) have been extremely disappointing. It's quite frustrating to spend €1500 on a gaming laptop, and then constantly facing driver issues, tearing,...
If I were to buy a laptop, I'd therefore also go with an AMD integrated graphics unit, and no switchable graphics. Performance would be comparably bad, but at least an integrated (non-switchable) card works... And now we are at the point of having a dedicated gaming device like the Deck, which lets you have both: A performant enough gaming device, and a laptop that isn't burdened by the price and issues of switchable graphics.
I'll give you my point of view as game developer.
Disclaimer first: I work as a coder, everything I say about publisher interaction is second-hand knowledge.
We have made one Linux game. It was the first one of our two "indie" titles (quotation marks, because both of them ended up being partially funded by a publisher, so they weren't really indie in the end), where we had promised a Linux build on Kickstarter, long before a publisher got involved.
The main reason why we did not do native Linux in our publisher-funded games is quite simple: Our publishers didn't pay us for it.
There are actually some publishers who are very keen on getting native Linux versions for their games, but we sadly have not released a game with any of them yet...
The publishers we released games with did not agree to the buget that we think is needed to do a Linux port of sufficient quality. If we would lower the price for doing a Linux port to the point where our publishers would agree to it, we would take on a lot of financial risk ourselves, so this is sadly not an option.
If everything worked as it is advertised by engine developers, making a Linux version would be quite cheap: Just click a few buttons and ship it. This is, sadly, not the case in real-life, as there are always platform specific bugs in game-engines. Our one Linux game was made with Unity, and we had quite a few Linux-only bugs that we forwarded to the Unity devs (we didn't have engine source code access), and had to wait for them to fix... For the engine we mainly use nowadays, Unreal, we have a rule-of-thumb: "Engine features that are used by Fortnite are usually well maintained." There is no native Linux version of Fortnite... (We did try Unreal's Vulkan RHI in Unreal 4.26 for Steam Deck support in one of our games. Let me put it this way: The game in question still uses Direct3D on Steam Deck.)
So, from experience we expect that the chance that we would have to find and fix Linux-specific engine bugs is quite high. Therefore we have to budget for this, what makes offering a native Linux version relatively costly compared to the platform's market share. Costly enough to make our publishers say "no".
This, by the way, also answers the question why publishers are willing to pay for the way more expensive console ports. There are also way more console players, and therefore potential customers out there...
(I can only guess, but I would expect publishers to be even more reluctant to pay for native Linux, now that WINE works so well that getting a game running on Linux needs typically zero extra work.)