I remember a gamedev complaining about this on Twitter but the outcome he came to was that he hated that Linux users submitted bug reports, stating the OS itself was broken and he refused to help any of them.
I remember threads like this from back when Valve was pushing Steam Machines. Won’t name names, but there were very successful developers throwing tantrums once the bug reports started to flood in. Many weren’t prepared to actually provide support and spent years regretting it (according to postmortems.) I managed to get a refund on one game after the developer’s Twitter rant went completely off the rails re: Linux being unfit for desktop. Weird that they were 100% fine with Linux when it meant getting my $15, $20, or $30. Makes you think!
Garry from Facepunch was pretty down on Linux from Rust (the game) because of the high bug to purchase ratio and because some stuff just didn’t work on the Linux version of Unity but worked fine on Windows. I mean, fair enough.
Looking in to it a bit more, it looks like they handled this extremely well, admirably even! https://rust.facepunch.com/news/updated-linux-plans
Good devs are good regardless of context, they may have their personal preferences but in the end welcome bug reports and feature requests, especially the helpful ones because it helps the project. Bad devs are dicks regardless of context as well, all they care about is review rate and other numbers appear in the scoreboard
Reflecting on my first year running solely Linux (as opposed to dual-booting), I think that this culture comes from the fact that, on Linux, problems can more often than not be solved. If not solved, then at least understood. When you want to change something on Windows, or something breaks, you have far less room to maneuver.
When I was a Windows user, I’d barely ever submitted a bug report for anything, in spite of being very tech-literate. It felt hopeless, as my entire experience with the OS was that if a fix would come, it’d have to be done by someone else.
Linux treating its users like adults, produces users who are more confident and more willing to contribute.
This is true. I also dont even know how to report actual Android bugs. On Windows its true, its simply a big “f you”
Android bugs go to the maintainers of that specific device or of the custom ROM installed on it.
Using the unaltered version that was installed on the device when you bought it? Reports go to the manufacturer usually.
Unless it’s a carrier branded version, like a Verizon or Tracfone provided phone, in which case bug reports go to them. But frankly, don’t bother, and for the love of all things holy spend a little more money and stop buying carrier branded phones.
For custom ROMs, bug reports go to wherever the maintainers of that ROM ask bug reports be submitted. Usually Git, XDA forums, their website, or their Discord/Telegram channel. And fuck that last one, because hiding bug reports and other information in non-indexed places like Discord is making this more difficult for everyone.
You can do the exact same thing in Windows, just think of the SysInternals Suite and its power. It’s just that people on Linux expect problems, while the overwhelming majority of people on Windows/MacOS is using their device expecting it to work and if it doesn’t they go do something else or buy another device.
Also this completely untrue notion that you cannot fix Windows or play around with its internals is very prevalent, to the point that it’s a meme, so people don’t even try.
But I have to fight the stupid OS to give me useful information. I have to install 3^(rd) party stuff. By default you only get this useless error reporting tool. Even if you report an error your likely to never hear from anyone and the chance of the error being fixed is virtually nonexistent.
On Linux the necessary information is usually readily available. The worst offender in my experience is Steam itself. You can get logs from games fairy easily. But if Steam misbehaves things can get more complicated.
When it comes to closed-source software developed opaquely by for-profit corporations, particularly the huge, monolithic ones like Microsoft, I generally have the attitude that, if I do discover a problem:
- They won’t take my detailed report
- If they do take my report, it goes straight into a shredder bin (or a massive queue where low priority problems go to die, which may as well be the same thing)
- If they do read my report, then it’s likely something they already are aware of
- If they don’t know about it somehow, the issue is probably so low-priority and niche that it wouldn’t escape the backlog anyway
Probably not nearly as bleak as I make it out. But when you can’t see the process, how can you tell?
With open source projects, these things can all still happen, but at least the process is more transparent. You can see exactly where your issue is, and what’s been done to it so far, if anything. Other users can discover and vouch for your problem. And if the dev team takes pull requests, and you are willing, able, and permitted to contribute, you can make the fix yourself.
I found bugs in Windows server products all the time, and there was no way of reporting them. If you opened a ticket (by paying, of course), they would never admit it was a bug. Half the time I got the impression I was the only person in the world that every encountered said issue, and that what I was doing was complete edge-case. Which was bullshit, I would investigate and find dozens of references (which never got resolved) because it was pretty much the only way to use X product feature.
Microsoft QA and support is utter trash. You can get better support in Linux on damn near anything by some rando on IRC or the specific product forum, or, gods forbid, Reddit. There is an almost 100% chance you can fix anything on Linux if you look hard enough, even if you have to go dig through the code. Nothing like that happens in the Windows ecosystem.
Also, the types of information you find are very different. On windows, you’ll find various forum posts about your problem, and some proposed solutions. Usually, nobody seems to know exactly what’s causing the problem, and that’s why the solutions are a bit random. Same goes for iOS related problems too.
On Linux, you might not need forum posts, because sometimes the error messages tells you what’s wrong and how to fix it. If that’s not the case, you’ll find posts about your problem, and usually there’s someone who explains what’s broken and what are the commands to fix it.
There’s none of that guesswork about trying 7 unrelated things to see if any of them magically solve your problem. It’s straight to the point. Your problem is caused by that setting over there, and here’s how to change it.
The Feedback Hub was introduced to fix this gap in user reports for Windows. Microsoft does actively monitor this. They respond when necessary, merge topics, deny or approve bugs/suggestions, etc. For their software, such as Terminal or VS Code, you can use GitHub issues.
Keep in mind, like most companies, Microsoft has guidelines on what employees can say when responding to any user feedback. This is why we typically see a lot of copy and paste. When it is more than that, wording is selective and you may not get more than one or two responses in total.
I know of at least one employee on Reddit who participates every so often. https://www.reddit.com/user/jenmsft/
This went in a different direction than I expected, in a good way.
Interesting take. I wonder if the amount of platform dependent bugs is generally that low for games. I’m a developer, but not a game developer. I would assume that platform dependent stuff comes into play a lot more, when using shiny new tech like direct storage, which is probably used more by AAA titles and less by indie games?
You don’t get many platform-specific bugs if you use cross-platform libraries like SDL2 for OpenGL/Vulkan context creation and human interface.
The difference is money. Vulkan is an incredibly terse spec compared to dx12. You’d think that would make it much more consistent to work with, but really, it’s all it can do to keep up with msft and IHVs who pour money into coaxing AAA devs to use dx12. Then, even when the app gets something wrong and causes issues for end users, the IHV just makes a special case in the driver to correct it, because having a big important dx12 title run correctly on their hw is important to sell units.
Meanwhile, the same IHVs barely bother to support anything beyond the basic vulkan requirements, because it doesn’t gain them anything to do more. If a vulkan game experiences issues, IHVs don’t care because it won’t sell well anyway.
I made games primarily for Windows which we also compiled for Linux. It is mostly input/output stuff, aka hardware issues. That is, audio issues, input issues, storage issues, dependency issues. Modern game engine mostly handle the rest. It wasn’t such a big deal to fix, but most gamedev lacked experience with Linux, and most projects are already over budget and late, so fixing Linux for an extra 2-5% of sales didn’t make much sense at small scale. Proton kind off fixed all of this tho.
If you’re an engine developer, it’s a reasonably common problem.
If you’re a game developer using a cross platform engine, it’s pretty uncommon, as the engine developer has already accounted for most of it.
If you’re somewhere in the middle, it’s probably somewhere in the middle.
It surprises me how many indie devs avoid some of the higher level / more popular engines for this reason alone. But I assume they just must enjoy that sort of stuff much more than I.
It surprises me how many indie devs avoid some of the higher level / more popular engines for this reason alone. But I assume they just must enjoy that sort of stuff much more than I.
The problem with indie devs is purely a lack of knowledge and resources. They don’t feel comfortable testing and packaging binaries for distribution on Linux. A decent number of them are also self-taught and actually have almost no exposure to desktop Linux at all. So it’s actually a much higher hurdle than you think.
All you have to do to help visually impaired people with screen readers is to search for the title on Google (or your privacy friendly engine), click the first result, and add the link to the post.
