You have Debian experience? Then stick to it. It may be boring, but boring is good. That means it doesn't need much maintenance, and that it just works.

Können wir das bitte umbenennen? Also von "Cryptowars" in "himmelschreiend inkompetente Politiker"?

I haven't looked at the schematics, so I am not certain which connection exactly would be needed. I only know that the Reform Mainboard and the Reform CM4 adapter don't expose any way of writing to the eMMC other than booting the system first. The problem here is that the Banana Pi CM4 boot process first looks for a bootloader in eMMC, and only if it cannot find one there, tries the SD card. So, if one flashes a bootloader that gets recognized by the firmware, but that later fails to boot, one is stuck...

The I/O board on the other hand allows to connect to the CM4 via USB, and there is a weird, but supposedly working, procedure to erase the data in eMMC.

In any case, I now have a spare CM4 I/O board lying around, and if I ever choose to upgrade my Reform to the Rockchip SoM (or something even faster), I can then still use the CM4 as a small standalone PC.

At least in my case, the default OS came on an SD Card, and both, the M.2 SSD (which I had ordered together with the laptop) and the eMMC were empty. The manual contains a section about moving the OS to eMMC, so I guess that's their default setup.

(In my case there's an additional thing though: For the Banana Pi CM4 SoM the installation of u-boot into eMMC is officially not supported, as one would need a CM4 I/O board to erase it again, if anything goes wrong. I installed it there anyhow, and it's working for me, but I did buy the I/O board beforehand as a precaution.)

I am curious how much work it will be to modify that Ubuntu image to fully work on the Reform. The audio chip and some other peripherals are on the mainboard, and need to be included in the device tree for the kernel to pick them up, so I would expect that at least some modifications of the image are needed.

It might already be enough to grab the device tree from the MNT gitlab, compile it, and put it in the boot partition for stuff to work. (You will likely also want to install the reform-tools - either from their gitlab or from their repository. They include a kernel module that is needed to get battery readout and to power off the laptop on shutdown.)

What helped me a lot while setting up the system was that I kept the SD card with the official (Debian Unstable) image around - every time something didn't work, I could boot it up and check how the official image does it.

I own one, and am really happy with it. There is some jank to expect though:

• The official system image is based on Debian Unstable. This means that you frequently get broken updates (for instance, currently waybar is broken, and just a few days ago, boot got broken by a buggy initramfs).
  • At least for some SoMs there are also Debian Stable images available, which are, well, stable.
  • I am running Gentoo on my Reform, and once one gets past the initial setup (kernel config is a challenge) it works pretty well. I have written a blog post about installing Gentoo on the Reform.
• DPMS off might not work reliably (depending on SoM). I got it working well on my BananaPi CM4 SoM by changing sway config though.
• Suspend-to-disk (hibernate) does currently not work. Last time I tried it, the system continued just fine, but froze a few seconds later.
  • No clue if standby works. I don't use standby.
• Some other issues exist with the Banana Pi CM4, but there are workarounds: https://community.mnt.re/t/tracking-known-issues-and-solutions-with-the-bpi-a311d-upgrade
• There are probably more issues that I cannot remember right now.

That said: Now that I have Gentoo running on it, and found workarounds for the most annoying issues (except for the suspend-to-disk issue), I am loving the laptop and would not trade it for anything else.

Yep, innoextract just unpacks the files, and I then place them into a folder in the home dir. Before I knew about innoextract I also just used WINE to run the installers, and then copied the installed files around. (btw, the apple pkg installers can also be unpacked by a combination of 7z and cpio - in case you just want to unpack one of the many GoG Dosbox games and don't have innoextract or WINE available)

I have a folder named ~/Games - and the individual games in subfolders there. In Steam's "add non-steam game" dialogue there's a "browse" button, and in that one I then select the .exe file of the game. That adds it to the library, and allows selecting Proton as compatibility tool in the preferences.

I am pretty sure the Steam Client reports which games you play to Steam's "presence" service, such that your Steam Friends can see what you are playing. I don't know if Valve gathers that data for other purposes (but would assume they do unless told otherwise). Also, some games that ship with Steam integration in their GoG installer (e.g. Loop Hero) will even track as you playing the Steam version - even if you don't own it there.

And yeah, there is no GoG Galaxy emulation in Steam of course, but I honestly don't care much about achievements. The lack of cloud support in non-Steam games is annoying though, as I also have a Steam Deck and those saves don't automatically synch...

I usually just download the installers from their website. It's not like I would need to install or update games on a day to day basis...

If the installer is only available for Windows (or if I am using my ARM laptop) I use innoextract to extract the files without needing to run the installer.

For Windows games I found that the easiest way to deal with them is to add them to the Steam Library as a non-steam-game, and to force Proton on them...

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.

Yep. With Kingmaker it was extra annoying, because the game has Steam Deck Verified rating, and the Steam Deck defaults to the Linux build.

Thing is, you can play through the whole first chapter of the game with a gamepad without issues... However, once you unlock the Kingdom Management screen, you run into the bug, which is a soft-lock once you open said screen. The UI doesn't properly initialize, all text fields remain at their default value, and you cannot make any inputs any more. Luckily the ESC-Menu still works, so you can save your progress...

If it weren't for the Steam Deck, I guess very few people would have run into this bug, if any at all. Kingmaker has a different UI if played with a gamepad, and even though Kingmaker's gamepad-UI is done really well, it is clear that it is meant for playing the game on a TV screen (think: consoles). If you are sitting right in front of your screen (PC), the UI you see when playing with mouse and keyboard is superior in each and every aspect.

My top answers are of course Kerbal Space Program, Dwarf Fortress and Stellaris.

However, all those have been mentioned already, so, to add something new to the list: Pathfinder: Kingmaker. It is currently my favourite cRPG.

Edit: Since you mentioned "Great Linux ports": Kingmaker has a game-breaking bug in the Linux version regarding Gamepad input. However, as long as you play it with mouse and keyboard (as the gods intended - insert PC Master Race meme), the Linux version is working perfectly fine. However, if you plan on playing it on the Steam Deck, you might want to play the Windows build.

This. I had written a similar last paragraph in my answer below, but decided to delete it before submitting.

I have to suffer Windows at work. No way on earth this sad excuse for an operating system gets anywhere near my gaming PC. I want my gaming PC to be for fun stuff, not use it to torture myself.

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.

Mesa has its own OpenCL implementations for AMD GPUs too: Clover and RustiCL. However, Clover is not really developed any more (afaik) and lacks some important extensions, such that many programs can't use it. RustiCL is rather new, and I don't know how well it works.

It's not a dumb question at all, and there is no "agreed upon" definition.

For me the most important characteristics of a "Mainstream Distribution" would be the size of their maintainer team - though that is also inaccurate if we are talking about distributions that are built on top of other distributions - as in your example.

Another indication is to check who is sponsoring a distribution's development. If there are plenty of commercial sponsors, then chances are that the distribution is well maintained. Similarly, if the distribution is created by a commercial company (Intel, Canonical, RedHat,...), as those companies also have an interest in keeping their product in a good state.

Age of the distribution might be another indicator. If a distribution has been around for a long time, chances are it isn't bad either.

However, I am lazy and would not actually check any of this by hand. Instead, the thing I would actually do is to just go to https://distrowatch.com/dwres.php?resource=major and read through their list. 😉

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.

Quake II RTX is fully raytraced though. I'm not sure how well performance measurements done with it apply to other games that do a mix of raytracing and rasterizing.

I did mention ML, of which OCaml is a dialect. Afaik Elm doesn't have type classes (aka Traits) - a property I would consider necessary to call it "similar to Rust".

Haskell.

I'm not joking. If you want something that's very similar to Rust, but doesn't have the restriction of being a systems language, then Haskell might be the right thing for you. Unlike Rust, Haskell is Pure Functional though, so it forces you to have an even cleaner architecture.

If Pure Functional isn't your beer, then you could also check out the language that inspired Rust: ML. If I remember correctly, Rust was started as "something similar to ML, but suitable for systems programming". So, it only feels natural to take an ML dialect if you want "something similar to Rust, but without the restriction of it being suitable for systems programming".

A popular ML dialect would for instance be F#, which is built on top of the .Net runtime and is therefore compatible with C# and the likes. On the other hand, in order to make it compatible with C# and the likes, there are some weird compromises in F#...

Or, if you (like me) dislike the idea of having a Garbage Collector, you could go for Lean4. That's what I'm learning currently, and it feels a bit like a bastard child of Haskell and ML.

Controversial opinion: There are only 2 kinds of people that think Rust will not become a widely used language:

• Those who don't bother to learn it, and only argue about it without any hands-on experience, and
• those who don't understand which niche Rust tries to fill.

For me it was funny, btw. I started out as basically a Rust fanboy, back when the "First Edition of The Rust Book" was still just called "The Book"...

Then I learned a bit of Haskell, and was immediately disappointed that Rust doesn't offer the same convenience when it comes to working with Traits (cough Higher Kinded Types cough). So, while I never considered myself part of the first group, I definitely was part of the second for some time.

However, the more I've been trying to abuse Rust for stuff that would be better done in a higher level language (like Haskell), the better I understood why Rust doesn't offer those abstractions: They often can't be zero-cost, and using them in a language that tries to be very explicit about performance costs becomes very verbose... In other words, I learned the hard way what "systems programming" means in the case of Rust, and which languages it competes with, and which it doesn't.