I would rather trust GamingOnLinux here:

While it is not in any way officially supported by Valve, they have now released Windows drivers for the newer Steam Deck OLED model.

(emphasis mine)

I can only speak out of my own experience, which is mostly C++, C#, C and Rust, but I also know a bit of Haskell, Java, Fortran, PHP, Visual Basic, and, to my deepest regret, also JavaScript.

For additional context: I have been working in game development for the last 7 years, my main language is C++ for Unreal, but I've also worked on some Unity projects with C# as main language. Before I switched to game dev I worked in material science, and used C, mostly. I use Rust for my spare time projects, and the game company I work at is planning to introduce it into our Unreal projects some point later this year.

Of all the languages I mentioned above, (Safe) Rust and Haskell are the only ones that have not yet made me scream at my PC, or hit my head against the desk.

So, some of the reasons why I personally love Rust:

• Rust is extremely simple compared to the other languages I mentioned above. If you read the official introduction you know all you need to write Safe Rust code.
• Rust's syntax is elegant. It's not as elegant as Haskell, but it's a lot more elegant than any C-based language.
• Rust is (mostly) type safe. There are (nearly) no implicit conversions.
• Rust is memory-safe, without the runtime overhead that garbage collected languages incur.
  • This is a bit of a neutral point though. The Rust compiler will complain if you make mistakes in memory management. Unlike in managed languages, you still need to do the memory management by hand, and find a working solution for it.
• The memory management model of Rust ("borrow checker") makes data dependencies explicit. This automatically leads to better architecture that reflects dependencies, because if the architecture doesn't match them, development will become an uphill battle against the borrow checker.
• Due to the borrow checker, you can use references extensively, and rely on the referenced object to valid, and also that it is up-to-date (because it cannot be muted or go out of scope as long as you hold the reference).
• Traits are an amazing way to abstract over types. Either at zero-cost (static dispatch), or, in the rare cases where it's needed, using virtual function tables.
• Rust aims to have no undefined behaviour. If it compiles the behaviour of the code is well defined.
  • This, together with the borrow checker, ensures that there are (nearly) no "weird bugs". Where in C++ one quite regularly hits issues that at first glimpse seem impossible, and only can be explained after several days of research on cppreference ("oh, so the C++ standard says that if this piece of code gets compiled on a full moon on a computer with a blue power LED, it's undefined behaviour"), that almost never happens in Rust.
• Macros in Rust are amazing. There are macros-by-example that work by pattern-matching, but there are also procedural macros, which are Rust functions that take Rust code as input, and generate Rust code as output. This gives you amazing power, and one of the most impressive examples is the Serde serialization framework, that allows you to add serialization to your data types simply by adding an attribute.
• Tooling for Rust is pretty good. The Rust compiler is well known for its helpful error messages. The rust-analyzer plugin for Visual Studio Code is great too. (It also works with vim, Qt Creator and others, but the but Visual Studio Code works best imho.)

The points mentioned above mostly apply to Safe Rust though. Unsafe Rust is a different story.

This brings us to the downsides. Rust isn't perfect. Far from it, actually. Here are some of the things that aren't great about Rust.

• No Higher Kinded Types. This is my main issue with Rust. Even C++ has them (as usual for C++ in a horrible un-ergonomic and utterly confusing way). If Rust had Higher Kinded Types, the language could have been simpler still. For instance, there would have been no need for the async keyword in the language itself.
• Unsafe Rust is hard. In my opinion even harder than C++, because of Rust's aliasing rules. Unlike C++, Rust doesn't allow mutable memory aliasing. That's because mutable aliasing can never happen in Safe Rust, and not supporting it improves performance. This means that when writing Unsafe Rust, one has to be careful about aliasing.
  • Luckily one only rarely needs Unsafe Rust, usually only in order to call functions from other languages. Still, it's hard, and I'd generally suggest to use an automated code generator like cxx.rs for interfacing with other languages.
• Interior Mutability. I understand why it exists, but it breaks a lot of the guarantees that make Rust a great language. So, my conclusion is that one should avoid it as much as possible.

However, the upsides clearly outweigh the downsides imho.

tl;dr If a (Safe) Rust program compiles, chances are pretty high that it also works. This makes programming with it quite enjoyable.

Brave? You mean "browser for bigots"?

https://www.standard.co.uk/news/tech/mozilla-boss-brendan-eich-quits-in-row-over-his-opposition-to-gay-marriage-9237701.html

Yes and No.

In the short term the answer is a clear "yes", as it allows players to play nearly all Windows games on Linux without modifications, and game developers to ship their games on Linux without any extra costs.

In the long term it might have a bad effect on the market, as it further helps to cement Microsoft's control over multimedia APIs, since game developers now have little incentive now to target anything other than DirectX...

In this case it's a bit weird though, as the game lists Linux as supported platform, but obviously just ships the Windows build with Proton instead of having a native Linux build that uses open cross-platform APIs.

I am not in the position to decide which tech we use at the studio, however, as a Senior my voice is certainly heard when it comes to tech decisions.

And for Unity I can only say: No tech is worth the risk of dealing with such a shady company.

Takeaway message here: Beko support person does everything they can to recommend not buying from Beko.

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.

They have done that already. It's called Kylin.

Cool! It even has an unintentionally belly-operated off-button!

(Sorry, but this design looks like a UX nightmare. The Sticks feel barely reachable, the buttons on the bottom will be touched unintentionally, the shoulder pads aren't clearly separated, the ABXY buttons are way too small, the speaker seems to be mono,... The list of shortcomings could go on forever...)

I'd strongly recommend to stick to a mainstream distribution like Fedora, Debian, Mint,...

With bigger distributions you have more people working on them (-> more packages well maintained), you get a bigger community, and therefore it's easier to get help if anything breaks.

I'm not sure which distribution to recommend though, as they all have advantages and disadvantages when it comes to gaming. Ten years ago I have switched to Gentoo (which is definitely not a distribution for new Linux users) when I got fed up with Ubuntu's Enshittification, and have stayed there ever since, so I lost a bit track which distributions are good for gaming now and which aren't.

Does anyone know how to report bugs for this? Because the Linux build is linked against libcurl-gnutls, but libcurl-gnutls is not included in the appimage...

I had to unpack the appimage, and manually create a symlink to my system's libcurl to get it to run.

If you are using systemd, there's a tool called coredumpctl.

I am now at the point where I think there are two things happening.

• Actual technological progress.
• Marketing bullshit pushed by dazzlers.

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,...

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.

small performance hit

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.

It is LLM slop: https://www.reddit.com/r/rust/comments/1rz15t3/comment/obiwu24/

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....)

Could be wireless. That would also explain the "battery" mentioned in the poll on shitter.

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?

For $50 I'd get (afaict current prices):

• Hades ($7.49)
• 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)
• One Deck Dungeon ($1.99)
• Slay the Spire ($2.49)
• Wildermyth ($16.24)
• Against the Storm ($8.99)
• Terraformers ($7.99)

This totals now $48.18. If you have an additional dollar to spare, I'd also recommend to get something to scratch that retro-gaming itch:

• The Settlers 2 ($2.73 on GoG - needs DOSBox, for which I've written an install guide)

That's now $50.91 in total.