I now have run into the issue that I myself cannot play Minecraft on my Linux laptop, which is an ARM machine and the ARM Mali GPU does not support the OpenGL version that Minecraft requires. (It also needs some hackery, as the Java-written Minecraft uses some native code libraries.)

I’m now playing VoxeLibre instead, which runs mostly fine on my laptop.

This. So much this.

The “backlog” is not something to work through, it is a lesson to learn: Do not buy a game unless you have time and are motivated to play it that very moment. If you buy it to play it “later”, or “next week”, you very likely are not going to play it, and it is just wasted money.

(The same is true for books, by the way. And when it comes to books, I refuse to learn this lesson.)

As dumb as this sounds: Playing Ring Fit Adventure on the Nintendo Switch.

I play a custom training routine (or however that’s called in the English version of the game) four days a week that has active time of 17 minutes, and another custom routine that takes about 27 minutes active time plus at least two levels in adventure mode on the other 3 days of the week (what brings the active time on those days up to something around 40 minutes).

The 27 minutes routine is mostly for stamina, so it has relatively light exercises. The other routine is much more demanding, and meant to get my heart rate up and my muscles burning (I won’t go into details, that would be bragging…).

I have lost about 10 kg by doing this, and by no longer eating after 8pm.

However, this weight loss happened in the first couple of months after I started this. My weight has now been constant again for about a year.

What is stopping you from playing Minecraft itself on Linux?

I haven’t played it in a while, but it did work perfectly fine last time I tried it. It is written in Java, after all.

This is so fucking stupid, I can’t even.

For your mental health, have some reasonable arguments about Rust: https://www.heise.de/hintergrund/Entwicklung-Warum-Rust-die-Antwort-auf-miese-Software-und-Programmierfehler-ist-4879795.html

Since it’s in German, here are the key points of the article (written from memory - the article is quite old, so I might misremember - best read the article yourself):

• Software development is stuck in a vicious cycle regarding project budgets.
  • Some competitors don’t know better and just budget the “happy path”, that assumes that everything during development goes right.
    • The author uses a term for this which I like a lot: “Hybris of the programmer”
  • Other competitors know better, but still have to lie in order to remain competitive when it comes to prices
  • Therefore almost all software projects end up with a way too low budget
    • So we get buggy software
• Rust might be a way out of this misery, because
  • it is understood that it takes longer to develop something with Rust
  • but on the flip-side the safety-guarantees rule out a lot of bugs
  • so customers who choose to have their project implemented using Rust are fully aware of the higher costs, but also the higher quality
  • and developers have a well known argument for the higher costs, and also have data that shows how this higher investment will yield a better quality product.

While I am not aware of any way to run custom software on the Steam Deck while it is on standby, you can drastically reduce the power drain if you shut it down fully instead of leaving it on standby. You can either use the “Power” menu after pressing the steam key, or long-press the power button to get the option to do so.

I would not say “lazy”.

There are a lot of bold promises in Unreal Engine 5 advertisements, that get taken up by publishers and producers - and then end up in the game budgets…

And then, near the end of the project, when it turns out that performance isn’t good because the advertisement promises have been a bit too bold, there is no money for optimization left…

Also, if I am allowed to do some absolutely shameless self promotion: Bus Simulator 21 is verified, and 18 is playable.

I need to give two perspectives here. One from my day-job as a gamedev, and one from my hobby as a gamedev.

The main difference is that in my spare time I do not have to suffer working on Windows.

So, first about work: I have switched from an nVidia card to an AMD one in 2022, because my work PC’s nVidia card had too little VRAM to run the editor of Unreal Engine 5. Editor performance was abysmal (due to the nVidia card’s limited VRAM) and running out of VRAM also frequently caused the editor to crash.

After I switched to an AMD card, those crashes were gone and performance of the editor was way better too (because it now had enough VRAM to no longer fall back to system RAM). However, Unreal kept complaining about a driver bug regarding synchronization, that never led to any observable issues other than running into a (continuable) assert on editor startup. I am still using this card, and after some driver update, that warning went away.

The AMD card is working flawlessly for me, and I honestly do not want to switch back.

There is one thing that I need to highlight though: The nVidia rendering debugging tools (most important: nVidia Insights) are locked to nVidia hardware. AMD’s tools are not locked to AMD hardware. So, if you use an nVidia card, you get access to all tools, while on AMD cards you need to make do with the tools you get from AMD (or Intel, or Microsoft).

In my spare time I luckily don’t have to use Windows, and on Linux the AMD drivers are, in my opinion, superior to the nVidia drivers in almost all aspects. The most important thing about them is that they are open source, so you can actually edit the drivers, and mesa (the open source project that contains the OpenGL runtime) has some pretty amazing debugging features.

The AMD Linux drivers also integrate way better with the various desktop environments. With the nVidia drivers you more or less need to use the nVidia Control Center for some settings, what is not the case with the AMD ones.

The one drawback I see on Linux, compared to the nVidia drivers, is that setting up OpenCL is a little bit more involved with the AMD drivers - but since you nowadays can combine the open source drivers with the ROCm OpenCL runtime, that’s not that a big deal any more.

Last, but not least: In my experience the AMD drivers are “more strict” when it comes to using graphics APIs and shader languages correctly. Back when I still used an nVidia card, I caused several bugs that only surfaced on a coworkers’ AMD card. In all of those cases the bugs were actual bugs in my code, that only worked because they accidentally did the right thing on nVidia due to implementation-defined behaviour…

It’s the Windows way. There applications typically also ship all dependencies. Either statically linked, or as a DLL files in their install folder.

It’s not a good solution, but for games that’s imho OK.

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

As a gamedev I never saw this as a big issue. Just run Debian Oldstable on your build server, link whatever you can statically, and you are good.

(However, I am talking on a purely theoretical level here - we only released one Linux game, and that was before I joined the company. I will explain our actual reasons in a separate post.)

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

It isn’t that easy to go indie though, unless you do gamedev as a hobby and have another source of income.

I am working at what was a small studio (about 10 persons) when I joined, and has meanwhile grown to more than 50 employees.

I am a coder, and therefore don’t have direct insight into our finances, so please take everything below with a grain of salt. It is also intentionally vague because I don’t want to violate any NDAs.

Over the years we have started two indie projects, that both were completed and released, but both in the end had a publisher funding a part of the development. So, while they were indie initially, the released products cannot be called indie any more… The reason why we went for publisher contracts for those two projects were manyfold, but an important part was simply that we needed a way to cover our running costs. We are doing gamedev as a day-job, after all, so it needs to pay for our rent, food, etc… (Other important reason for going with a publisher were marketing, customer support,… All the things that we as developers have no experience in.)

Now that we have grown to medium studio size, we are hoping that we can at some point fund an indie project by making enough profit with other, publisher-funded projects. We have several projects running in parallel anyhow, and if 3 of them would yield enough money to pay a 4th project that would be fully our own, we would definitely go for it.

However, the market situation is tough, and we currently cannot afford to do that. Almost all profit we make goes into developing prototypes that we need in order to have a realistic chance to get the next publisher-funded project…

Two years ago it was a lot easier to get publisher contracts. Back then we were quite optimistic about being able to fund a fully independent project, but then the market changed, getting new publisher-funded projects has become a lot more difficult, and right now doing an indie project is (for us) not financially possible…

So, what we are doing now is that we are taking our game ideas and presenting them to publishers. The prottypes I mentioned? Most of them are for our own ideas. Having something the people at the publisher can play goes a long way in convincing them that a game-idea is fun. That’s not indie, but it is as close as we can get to making the games we want to make. While the last year has been tough, with publishers being very, very, very cautious about new ideas, the situation seems to slowly change, and we might eventually get funding for one of our own ideas. Maybe. If we are lucky.

You can’t build a game studio without funding, and that is where the problem lies…

Publishers have become very risk-averse ever since Embracer went downhill. They basically only invest in <literally the same game as some previously successful title>…

I would rather not waste money on a Windows license I am not going to use.

(Not that I would buy an Ally, I already have a SteamDeck.)

I fully second the sentiment that there is no good reason to switch distribution once you have found one that you like.

However, if your goal is to learn something new, and you don’t care about having to nuke the install and start over, then you could go the crazy route and install Linux From Scratch. It is unlikely to yield a maintainable result at first try, but if learning is your goal, this is your best shot at it.

Or you could go the not-that-crazy route and use Gentoo, which is basically Linux From Scratch, but automated. Setting it up is way quicker (couple of hours - except if you configure the kernel by hand), and you will with near certainty get a maintainable system on first try, but it is also far less educational, given that the automation does most of the work for you. (I have switched from Debian to Gentoo 10 years ago, after trying it on my netbook for some time, and I could not be happier. It only does what it should, is rolling release, and only very rarely has issues.)

I would only recommend those two approaches on a second PC though, without immediately switching the main PC over. Linux From Scratch is, as said, unlikely to yield a maintainable installation on first try, so you will likely nuke the install again. Gentoo, while perfectly usable as a daily driver, is certainly not everyone’s beer, and you might simply want to switch away again because you don’t like it.

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

5 GiB is plenty of space for a Linux root filesystem, at least if you move all writeable parts (logs, temporary files, etc.) to different filesystems. Unless you want to install LaTeX, then you probably need 15 GiB or so.

However, CUPS has had a fair share of security issues (for instance https://www.evilsocket.net/2024/09/26/Attacking-UNIX-systems-via-CUPS-Part-I/), so it is probably a good idea to have it disabled by default, unless the user needs printer support.

I guess this was being sarcastic, but just in case it wasn’t:

If you launch the game through Steam that probably won’t matter, because Steam brings along its own libraries for games to use. That collection of libraries is called “Steam Runtime”, and if the game only uses libraries from the Steam Runtime, it will run on any distribution that the Steam Runtime is compatible with (what afaik means basically all distributions).

There are some exceptions though. Graphics drivers for instance are not bundled in the Steam Runtime.

And last, but not least: Even if you don’t run the game through Steam, it’s probably just a bunch of libraries that need to be installed. They only need to be the same or a newer version than those used on the developers’ build server.