Linux is a nightmare – only 0.8% of sales – over 50% of reported tech issues (2019)
sh.reddit.com
sh.reddit.com
1: https://www.neowin.net/news/linux-gamers-are-way-better-at-f...
Even if a bug is platform-independent, the report may well be platform-specific and difficult to reproduce. The real nature of the bug only becomes clear after analysis, and getting the right platform for the analysis may be so much work that the whole thing is impractical.
"May be" doesn't mean "very rarely" either. It's sad, really. You may sit in front of your keyboard with an intuition that this bug affects lots of people and know that you can't really work on it, so how to you respond? Sad.
Trying to reproduce a bug by doing something different than what the customer did is a good way to waste time, in my experience.
One of my first really nasty bugs of this kind was platform-independent, in the sense that the fix affected all platforms. Once I had found the buggy code it was easy to reproduce it on my development workstation by constructing a more efficient reproducer.
But it did not affect all platforms equally. With the hardware on my desk it led to a slow memory leak and would crash after very long time, on a particular customer's hardware it leaked all memory in an hour, and the customer had more memory than I. I don't remember why, maybe the different CPUs changed whether a race was lost/won? Anyway, I restarted often and could have gone a year without noticing the bug in my office, but even on the same platform as I personally used, customers would have infrequent crashes.
So. Platform-dependent or not? It's hard to classify in those terms, don't you agree? And that's typical in my experience.
Depends on the type of software. I feel like PC games are on the extreme end of having lots of minor bugs and one very dominant platform.
Last week I had to set up a new debian with a combination of one really old package and one really new in order to work on a bug. Setting that up took more time than the bug itself. (The bug itself wasn't at all related to those packages or versions, BTW.)
Spoiler: 38% of bug reports from Linux users, 400 in total, but only 3(!) are actually Linux specific.
It doesn't directly figure into the reporting rate, but Linux users also file better bug reports, likely due to the communal education and technical support that is so central to contemporary, personal Linux usage. Any newbie asking questions on a Linux forum, IRC, Matrix, or Discourse is bound to learn strong norms about including diagnostic info and other context in issue reports, as well as what asking useful questions looks like.
Linux users end up helping to identify a hugely disproportionate number of the bugs that affect Windows users because of this.
Past HN discussion of another indie dev's experience with this can be found here: https://news.ycombinator.com/item?id=28978086
This might be bad for you if your company over relies on metrics about the number of reported or open bugs in an unhelpful way. But in itself it's a decidedly good thing for your software quality and the experience of your users to include Linux users in your user community.
But still, this is why you target Proton. It seems "anti linux" and suboptimal, but its actually quite practical.
Whenever I do game on linux, I always use the proton versions anyway because they perform better than the native linux version, with the only exception so far being Minecraft.
And these are game ticks, so it actually affects the rate you play the game rather than just FPS.
Most of the issues users have with Starfield are the product of having a set incompatible software. Nvidia users often fail to run the game when their driver is too new. AMD users often fail to run the game when their driver is too old.
There's a broad range of issues like this in Linux land that are very difficult to track and understand. Users seem to understand that its a package management issue but have no clue how to fix it. So they end up reiterating pointless "rolling release bad" or "stable release bad" rhetoric.
And DIY maintenance on Arch Linux is part of the pitch (especially when running Nvidia drivers).
Distros that pitch themselves as gaming distros (like Fedora Nobara, Garuda, CachyOS) tend to offer a far superior out-of-the-box experience. Windows is in that category too, as Microsoft rather explicitly targets gaming more than, say, base Ubuntu or Fedora.
If you need to run new things, you are not the target audience for LTS releases and shouldn’t be using them. Don’t expect time-travel compatibility from the backported bugfixes that an LTS calls “updates”.
That doesn’t make Ubuntu LTS bad. If you have a box that you intend to set up in a closet and forget for three years, but still don’t want to turn into a glaring security hole in six months, Ubuntu LTS with updates applied automatically or over SSH is a good choice. (Granted, I happen to think Debian is a better choice, but reasonable people can disagree here.) Just don’t expect the latest shinies from it.
I think they should though!
Targeting native linux is very difficult. Simply testing the game on Proton would be orders of magnitude easier for the developer.
With regards to sales, on the one hand, I expect that the number of players on Linux has spiked by at least an order of magnitude. On the other hand, I expect that the majority of people buying a steam deck are “hardcore” PC gamers who also have a windows desktop somewhere, so it’s hard to attribute game sales to Linux/Steam deck.
In terms of support tickets, somebody mentioned that a developer countered that the tickets they saw were mostly non-Linux specific, and likely the result of a savvier crowd who’s more proactive at reporting bugs. I kind of expect the number of issues per player to go down, both because of the qualitative change in user base and because the deck represents a console-like static target. On the other hand, I expect those support tickets to be a lot less actionable (because they’re coming from less technical users)
Also worth noting, the landscape of Linux packaging is much different than it was 4 years ago:
- Flatpak/AppImage allows you to statically-link all dependencies to avoid undefined behavior
- Steam and others can provide basic runtimes with necessary libraries (eg. Steam Linux Runtime)
- Proton, WINE and DXVK work together to map Windows APIs to your specific setup, regardless of your x11/Wayland/PulseAudio/Pipewire configuration
Indeed shipping a native Linux title is no cakewalk, but products like the Steam Deck kinda refute these outdated complaints. You could target Windows-native and probably get 'free' Linux support if you're using a popular engine.
That being said, I run a "nightmare stack" of sorts on my main Linux gaming PC: Alder Lake CPU, Nvidia GPU. NixOS on root and Steam installed natively. For a while, it was Unsupported Driver city - Population: Me.
...that being said, games have "just worked" for as long as I have Vulkan drivers installed. Steam might complain about software acceleration, but Cyberpunk runs with DLSS and Raytracing like a charm. The underlying stack is incredible, and I think it proves that you can make Linux a reliable delivery platform if you put in the work.
That's just my experience, but look at the rest of the industry: Apple publishing Game Porting Toolkit based on DXVK code, Raspberry Pi GPUs playing Fallout: New Vegas, RISC-V getting Box86 support, the list goes on. Hardware diversity is great right now, the Steam Deck just pulls a lot of that technology to center-stage.
It's probably not a use case people think of when they think of NixOS, but it's popular with users and contributors nonetheless, and thus also fairly well-supported.
It's also generally a nice way to cope with proprietary NVIDIA drivers (although the new open-source ones are already available in Nixpkgs as well!).
And for games with heavy anticheat, it gets a lot harder.
I think they very clearly draw the line there, nowhere has Valve claimed responsibility for fixing other developer's issues. They ship a runtime that works very similar to Windows, they don't write patches and hack jobs for bad developers.
Studios shouldn't care, exactly like OS/2 runs Windows apps better than Windows.
On the graphics side, I believe that Vulkan is better supported than Direct X.
- Launch options! They help everyone, but are specifically great for stuff that breaks often like fullscreen settings, DirectX versions and game launchers.
- Simpler stacks work better. You can run a browser-scale runtime if necessary, but a thin implementation around Win32 might run better for everyone. YMMV.
- Multiplayer stacks are a bit of a pickle, but there are a few options. Some games (eg. Overwatch 2 or Dark Souls) will queue you up as a normal PC player. Others (Destiny 2, Rainbow Six Siege) won't let you play online at all. A smaller-yet selection of games uses anti-cheat patched into WINE (eg. Apex Legends) and that seems to work great. Again, YMMV and it will depend a lot on the game you ship.
The super-low-level stuff is a mystery to me, though. Hopefully someone more qualified has tips on it written somewhere :p
I understand that it isn't linux's fault per se , but I would never understand running your personal desktop on Linux for non-ideological reasons.
WSL and WS-Android both exist. They have allowed me to selectively ignore the worst of windows and touch Linux on a needs basis.
I used to root every android device and apply balance mods before starting any game. Now, I just wanna do the thing.
Since VMWare exists and hardware has been fast enough, that the only physical device running GNU/Linux has been my netbook, from the netbook golden age.
As for Android, it is great that it isn't really yet another UNIX clone, rather its own thing, with a managed userspace, we need to move away from a fossilized OS designed for PDP11s.
Also did they specify which distro(s) they support? Dedicated enough QA? Differences are typically not that hard to paper over, mostly a bunch of if-dir-exists, do this, else do that. XDG_* env vars help as well. Proton, flatpak, etc.
Thanks to legions of developers leaving GNU/Linux behind, adopting OS X, Microsoft realized the mistake to not offer proper POSIX support on the Windows NT OS linage.
Aside from being an incorrect use of jargon, it hurts the project. Emulators have a reputation of not being able to handle the latest games. Proton is very good at playing many modern games. It plays some games better than Windows natively on the same hardware.
Edit: Actually their dev docs even agree with the characterization as a "Windows Emulator": https://wiki.winehq.org/Wine_Developer%27s_Guide/Architectur...