This. There is very little need for third-party tools, as long as you don’t want to install a whole lot of games. After all, the installation process only happens once per game, and also without tools it doesn’t take very long.

As a step-by-step guide:

• Download the games from the GoG website. You can find them if you hover the site’s header bar, where your user-name is displayed. There’s a “Games” button which brings you to the list of games, where you can download the installers directly. The downloads are listed under “Download Offline Backup Game Installers”.
• Unpack the game installer.
  • Innoextract is your friend here. No need to run the installer, just unpack the files. Works with both, Windows and Linux games.
  • Alternatively, if it’s a native Linux game, you can just run the installer directly on the Steam Deck.
    • For Windows games you can theoretically also use Proton directly on the deck. However, the process is annoying, so I won’t go into details.
  • Alternatively, you can run the installer on your desktop PC and copy the files to the Deck via sftp.
• Add the game to Steam Library. This can be done in Desktop Mode. There’s a menu entry in Steam’s “Games” menu for that.
  • In the File Browser, you need to disable the file filter, as it (iirc) only shows .desktop files by default. You’ll want the game’s executable though.
• If it’s a Windows game, go to the game’s properties page in Steam, and force a specific compatibility tool for it, namely some recent version of Proton.
  • For native Linux games this step is usually not needed, but some very old games need to set the Steam Linux Runtime here.
  • For DOS games, check out my blog post about DOSBox on the Deck.
    • I don’t know how well it works on the Deck (never tried it, as I don’t feel it’s necessary), but there would also be boxtron.
• Last, but not least, use sgdboop to set some artwork.

I would be very surprised if they wouldn’t fix all 50 filesystems.

In all projects I have worked on (which does not include the Linux kernel) submitting a merge request with changes that don’t compile is an absolute no-go. What happens there is, that the CI pipeline runs, fails, and instead of a code review the person submitting the MR gets a note that their CI run failed, and they should fix it before re-opening the MR.

That’s a very good point. I hadn’t considered potential lack of domain knowledge at all. In that case Rust might even help, because it’s easier to write interfaces that can’t be used wrong - so that even someone without the needed domain knowledge might be able to fix compile issues without breakage.

Behind all the negative tone there is a valid concern though.

If you don’t know Rust, and you want to change internal interfaces on the C side, then you have a problem. If you only change the C code, the Rust code will no longer build.

This now brings an interesting challenge to maintainers: How should they handle such merge requests? Should they accept breakage of the Rust code? If yes, who is then responsible for fixing it?

I personally would just decline such merge requests, but I can see how this might be perceived as a barrier - quite a big barrier if you add the learning cliff of Rust.

I only use my Steam Deck while I am away from my gaming (Linux-)PC. The reasons for this are that for me a big screen wins compared to the small (and relatively low-res) display of the Steam Deck, and also the games I usually play play way better with mouse and keyboard than with gamepad input… Also, the Steam Deck is relatively heavy, so gaming in bed or stuff like that also isn’t that enjoyable…

That said, the Steam Deck absolutely shines in situations where I cannot access my gaming PC. I usually take it with me when I go for a longer train ride, and also brought it along for vacation.

Compatibility wise I am in the situation that all the games I ever tried are working on the Steam Deck, but that’s mostly because I have been using Linux exclusively for decades, and have made it a habit to check if a game is going to work before buying it. Though, in recent years that habit slightly changed, thanks to the work Valve has put into WINE development. While back when I switched to Linux most Windows games would not run via WINE, nowadays one can expect that almost all games do. It is still a good idea to check protondb first, of course. Also, there are still a few games that need tinkering to get them to run, and protondb usually has some info on how to do that.

One negative point I have to mention is battery runtime. It strongly depends on what one is playing, but very demanding 3D games can drain the battery in 1.5 hours. However, I am talking about the old LCD model here, the newer OLED models run longer with one charge (though I don’t know how long actually).

Another negative is the display resolution. Most games don’t mind running on 1280x800, but some do. This can lead to illegible text, broken UI, or, as is the case with Stellaris, a different UI that is less convenient to use.

And last, but not least, performance. The Steam Deck GPU is just enough for the built-in display’s resolution, and also only under the assumption that games are reasonably optimized. I have not yet been in the situation that I would have gotten unplayable FPS, but I have heard a lot about games only running with 20 FPS, and needing upscaling… So, basically don’t expect it to run Crysis (yes, I know that joke is old, and that the Steam Deck can run Crysis just fine).

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.

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)

Points that I would gladly agree upon - but it seems the Wikipedia authors don’t.

I am not knowledgeable enough to draw a definite line what counts as functional and what doesn’t - so I chose to go with whatever Wikipedia says… Even though I dislike it.

I know, from a mathematics standpoint it does not make sense, but from how the term is used nowadays in programming it does: Those languages allow to compose functions, pass functions as parameters, return functions, etc.

Truth has been spoken.

Except that Kotlin is functional (just like Rust, C++, Visual Basic, JavaScript,…). It is, however, not Pure Functional (like Haskell or Lean4 would be - if you haven’t checked out Lean4, I can recommend it, great fun).

(Sauce: https://en.wikipedia.org/wiki/List_of_programming_languages_by_type#Functional_languages)

And for it to be a worthwhile saving in low memory or storage situations, further constraints need to be met too. For instance, you would need to compile your own standard library, or go fully no-std…

To answer your question: I use an Xbox Series X gamepad. However I cannot recommend this cheaply built piece of junk.

I also tried to use the DualShock 4, but with that I had the problem that it interfered with my WIFI connection. I’m not sure if this is a general problem, or only happens with my WIFI base station though. Also, the DualShock controller has a severe drawback, and that is its short battery runtime, compared with the issue that you cannot easily switch batteries…

So, my recommendation: An Xbox One gamepad. While I don’t own one, I am using them regularly at work, and they basically have all the advantages of the Xbox Series X gamepads, and have a way better build quality.

I would also recommend Xbox 360 gamepads, but they need a dedicated base station, which is very expensive.

And their gamepads for Xbox were pretty good too. Past tense, because those of the Xbox Series X suck (including the “Elite”).

and adding it to Game Mode

Wait, waaaaaat? Lutris can do that? Okay, time to download it on my Steam Deck, like, right now. (Okay, not actually right now, I am at work, but today in the evening.)

Just to add this: Star Control 2 is not only free (as in free beer), it is free (as in free speech). The open source project is hosted on SourceForge (yes, that still exists), and has a website that is worth checking out: https://sc2.sf.net/

I have been using Linux for more than 15 years and would consider myself a semi-advanced user, but that thing in the screenshot - it scares me.

Android has become such an unusable mess otherwise…

I mean, you can’t even find the option to allow sideloading on my Android TV box without first enabling developer mode…

It really depends on what you are doing with your system…

On my main PC I want the full Linux Desktop experience, including some Gnome tools that require webkit - and since I am running Gentoo, installing/updating webkit takes a lot of RAM - I would recommend 32 GiB at least.

My laptop on the other hand is an MNT Reform, powered by a Banana Pi CM4 with merely 4 GiB of memory. There I am putting in some effort to keep the system lightweight, and that seems to work well for me up to now. As long as I can avoid installing webkit or compiling the Rust compiler from source, I am perfectly happy with 4 GiB. So happy actually, that I currently don’t feel the need to upgrade the Reform to the newly released RK3588 processor module, despite it being a lot faster and it having 32 GiB of memory.

Oh, and last, but not least, my work PC… I’m doing Unreal game development at work, and there the 64 GiB main memory and 8 GiB VRAM I have are the absolute bare minimum. If it were an option, I would prefer to have 128 GiB of RAM, and 16 GiB of VRAM, to prevent swapping and to prevent spilling of VRAM into main memory…

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.