Notably, of those bug reports, fewer than 1% (only 3 bugs) were specific to the Linux version of the game. That is, over 99% of the bugs reported by Linux gamers also affected players in other platforms. Moreover (quoting from the OP):
> The report quality [from Linux users] is stellar. I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed. And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.
Indeed, although my kneejerk reaction to the subject line was to expect another sad article about how it's not worth it to support Linux, this author seems very happy with the decision to do so.
> Worth it? Oh, yes - at least for me. Not for the extra sales - although it’s nice. It’s worth it to get the massive feedback boost and free, hundred-people strong QA team on your side. An invaluable asset for an independent game studio.
This is the case with people selling business software, meaning bugs would mean wrong accounting or worse outcomes for the customers. Yet all layers in the company would treat these reports as an annoyance.
Are there any good articles on writing helpful bug reports? Whenever I submit a bug I try to give as much detail and be as specific as possible but I always imagine some dev somewhere reading it rolling their eyes at the unnecessary paragraphs I’ve submitted.
bug reports and communication in general: If you've got a good summary/abstract more detail is always better. I don't know if I've ever had to talk to someone on my team about how they "over communicated" (not the same as TMI!). Make the receiver responsible for saying "OK, that's enough, got it!"
Usually sending just "help" and no other data is preferred. Don't send screenshots, don't make use of the ingame reporting tools (pressing F11), don't send steps to replicate.
I’ve often thought that game developers, esp indy studios, would benefit from doing first beta releases on Linux exclusively - wringing out a bunch of bugs, then doing a wider release.
>"we have all seen bug reports like: “it crashes for me after a few hours"
Here is a gem from my collection of user "bug reports". The email with this exact words and nothing else - "something is wrong, what do I do?". I was biting my fingers trying not to reply with the first thing that came into my head.
Or have proper analytics. If a user emails you and says "It crashes after a few hours" rather than feeling bad for them, you ask them what their steam/game id is and you look them up in the crash reporter system and see exactly what happens rather than relying on a few programmer consumers doing the work for you.
Possibly, but how many of the bugs are rare edge cases (i.e., attempting to break the game) versus problems players actually face in normal gameplay? Without knowing what priority or severity these bugs take, it is difficult to say how useful the increased volume of feedback is.
Yep, it’s a great point to raise in support of releasing software for Linux. Adept users who can produce high quality bug reports and help solve bugs across all platforms provide a lot of value, perhaps enough to justify “only” a ~5% market share.
Just from the title, I went in expecting that percentage to be much higher, but still expected I'd get a chance to complain how report quality was not taken into account (I expected Linux users to submit better reports)!
Sometimes I forget my detailed bug reports with steps I took, even if I can't reproduce it--since it might provide a hint to someone with insight into the programs internals--, are a weird outlier.
I am not sure why would one expect more linux bugs in a game made using a game engine (I couldn't find any info and I am assuming this game is one, correct me if I am wrong). If it is not working in linux, then it must be an engine bug, not a game one. If I am wrong then props to devs for having such a consistent game engine
Perhaps other option is using cpp, and having UB that behaves differently in different compilers. But I doubt that as well
OP was not saying that 38% of the bugs are Linux-specific, he was saying that Linux users report many more bugs per capita than windows users (and he sees that as a good thing).
Yep we find a variant of this with our python open source data science users who normal businesses would hate:
- Across all Python envs (Jupyter, streamlit/plotly, flask/Django, ...), they report way more bugs, and often from our free tiers, which sounds low ROI.. but our community caught all but ~2 significant bugs we fixed this year that our internal automated testing missed and would have otherwise gone to our Enterprise and gov users . They are happy to exchange a tiny bit of GPU or viz burps for new features faster, as long as we are responsive to their reports! That also pushed us to a better dev cadence which wouldn't have worked for our Enterprise users. More subtle, we have more confidence for deploying wider features/APIs which would otherwise be too underused + risky for the same reason.
- they are often doing innovative new things with our stack, which originally meant feature requests for non-repeatable sales.. but ended up stretching our flexibility into wider applicability, and they can clearly tell us areas to advance the visual, analytic, etc sides of our R&D and package it up for the rest of their internal analysts. Almost like a multiplier for conversations with our more operationally focused no-code/low-code users, and helps us see around the corner for them in the AI+API+customization sides!
- most of our technical partnership discussions now go through our OSS client repos. Rather than PowerPoints with BD people that don't have staff to do things, a product dev or sales engineer/architect or devrel blogger will think, "oh our customers would benefit from better interactive visuals on our data, let me whip something up quick with that package" and we help them take it from there
- open source data users like PyData developers and data scientists, compared to say the # of SMBs out there or general enterprise employees, is small and almost by definition doesn't pay for most software... but they end up being attached to projects that do, and influence much of their organization that definitely does!
We're just used contributing bug reports and pull requests, sort of our thing. It's not as prevalent with Windows or MacOS users, just not part of that culture.
Great article, though he's benefitting from a specific slice of Linux users that are great to work with.
On the other end of the spectrum, try releasing a php plugin for Wordpress, OpenCart, Magento, etc. I released a mildly popular, open-source, free add on in this space. The Linux users there are decidedly less technical, but still doing it themselves.
What I got for "bug reports" was mostly terrible, few details/logs/etc. And a weird entitlement thing where people had really high support expectations over something that was open source and free. Even a few expletive-laden emails. I did receive a few really helpful reports, pull-requests, and thank you emails...but they were very much the exception.
With a game that supports Linux, you get people who have chosen to run Linux instead of Windows because they prefer it. They have also worked enough with their system to get their Linux system capable of running games well, which may not be trivial for the given distro.
With a Wordpress plugin or whatever, you get people who are running Linux because they "have" to. Trying not to sound "true Scottsman"y here, but most of the time these are not actually Linux users, these are Windows users who are further confounded by having to use an unfamiliar platform.
For similar reason, I think the level of experience is probably different. Meaning those could be the same person and time is the important variable. After they’re used to developing, they better understand what useful feedback looks like.
In addition, in my experience maintaining a developer tool, an outsized source of bug reports is Linux users reporting already fixed issues in their outdated distro packages, or even problems introduced by their packager (e.g. flatpak/snap permission problems). And they typically won’t identify the version despite clear instructions in the issue template asking for the debug output containing everything I need, including the version.
If you support distro packaging of your software (which you should, since it should ideally reduce the load on you when it comes to triaging bugs) and users are coming to you with distro specific bugs then you should:
- Immediately close issues where the user has indicated that they did not test against the latest version or where the user has not answered the question "did you reproduce this issue with the current version of the software built from source?" (You should just automate this)
- If users continue pestering you and they seem to come from a specific distribution: complain to the maintainers of the distribution and ask that they inform their users of the proper bug reporting channels.
New users are coming to linux on a regular basis and they're coming in with a windows mindset. It is important for the smooth functioning of both linux distributions and software projects to make users aware that the proper channels for reporting bugs they experience when using software which was packaged for their distribution is the distribution's maintainers.
Users need to be made aware that unless they're compiling directly from source and using a supported version then they have no business going to upstream with their bug reports.
You may think this is harsh but if you get backlash, distributions should have your back on this (they usually do have information somewhere to inform users that bug reports should go to them first). I recommend any open source project take this stance when it comes to bug reports. If someone finds a real bug and they are certain it's not one caused by their distribution then they can easily build your project and reproduce the bug there.
(Aside: If you are providing a library then an appropriate level of API stability is a must have if you want people to be able to actually test bugs in a newer library version.)
Don't blame the user here - your bug reporting template should have users declare what package version they're using so that you can easily tell them they're on an outdated package. Flatpak is usually a boon in this regard since you can ensure your users are all on the latest packages, though you're making the tradeoff of having to deal with any Flatpak-specific bugs (which I'd say is a decent tradeoff for solo maintainers).
That's interesting. Most of the WP devs I encountered are deploying on old-school shared Linux hosting, like BlueHost, GoDaddy, etc. Maybe some use Windows for local dev stuff, but I doubt many deploy their "prod" there.
Glad to see that it was a positive view of the Linux bug reporters, rather than "Bah, I spend all my time fixing packaging issues from entitled Linux users who scream at me that the game doesn't work with their obscure, home-spun distro."
In a similar vein, I think the biggest value-add that Arch has over other distros is that it turns out having the filter of "can follow well written instructions through mildly tricky commands well enough to result in a bootable system" results in a community with a base level of competence, care, and patience that puts it at least two standard deviations above the other distros and at least four (I know how small the percentile is now) above just the general wash of garbage that you get when you Google for Windows issues.
It creates similar effects to the different credit card companies. Why would anyone accept Amex and its higher fees? Because they bring you higher value customers, sometimes dramatically higher value.
>In a similar vein, I think the biggest value-add that Arch has over other distros is that it turns out having the filter of "can follow well written instructions through mildly tricky commands
What is the value of "is competent enough to copy paste commands from a wiki?". Honestly I think the best bug reports might be because some Linux users probably understand C/C++ and can understand crash reports and error messages because they understand the system.
WSL is somewhat similar in that installing it was harder than installing most other things on Windows. They've made it easier in Windows 11, and will probably continue that direction. I wonder if MS knows where that leads for them.
TBH, as a non-ubuntu (gentoo) user, i'm pretty sure, that all the packaging isues (for non-gentoo packages) are something that I, personally have to deal with, and not bother the original developer with.
On the other hand, a Windows user is trained not to report bugs, especially in games. There's rarely a channel for reporting things & simple bugs go unfixed unless the community can work out some hack to do it for themselves. Games are abandonware monoliths on day one.
Secondly, if a program crashes in Windows and you try to force kill it, you get blocked waiting for the 'report' to be sent do Microsoft. Users are trained to click off this, so the OS will finally do what you asked it to.
Do you think this has something to do with how many Windows programs (not just games) handle errors and crashes? Even Windows still uses the "Error code: <bunch of meaningless numbers>" scheme. I can't even think of the last time I even attempted to get crash logs for a Windows program; however, on Linux I can usually find where logs got dumped and debug without as much of a headache.
... and if you search for that meaningless number and manage to find a proper support page, you are usually left with as much information as you started with. I don't understand why open source developers are so much better in this respect, but the diagnostics usually leave me feeling as though I could solve the problem even when I don't have the technical skills to do so. Being able to comb through the logs to pinpoint the problem is a major contributor in this respect.
(The only counter example I can think of at the moment is Samba, and guess what ... it interfaces with Microsoft products!)
I've noticed this too, compare any forum thread for a AAA Windows game and a Linux game, the Windows game thread is going to look like a bunch of chickens running with their heads cut off wondering why the 0x00423 error is causing the game to crash. Head over to a Linux thread and it's a usually a much more productive conversation because the errors are just clearer.
And when you can find a bug reporting channel the issue gets answered by an ‘MVP’, usually with some sort of inapplicable canned response, and then closed as ‘fixed’, without actually addressing the problem.
> On the other hand, a Windows user is trained not to report bugs
Decades of dealing with open source projects hasn't been much better in my experience. I don't usually bother to submit bug reports because my experience is that they'll be ignored for a few years and then closed unceremoniously.
That depends. I've dealt with open source products where I've submitted a bug report, submitted a bit of code, had the developer say that the patch wouldn't work for a good reason, then push out a proper fix nearly immediately. On the other hand, I have heard many stories that reflect yours. I suspect the size of the user base is a major contributor. Popular projects have many people submitting "bugs" that are little more than low priority (to the developer) feature requests.
For an audio app that I work on, it's similar, but different: around 1% of the users are on Linux, and around a third of the bugs / complaints come from Linux, but they're virtually all Linux specific.
We're having to seriously consider dropping Linux support because the support / maintenance load is so high. (This comes significantly from the libraries we're using having worse Linux support, and a lot from the Linux audio ecosystem in general not being very mature; and then a whole bunch of it is people wanting packages for dozens of different systems.)
I would think you can deal with platform-specific issues by saying "we support Ubuntu [or whatever you're willing to do]; anything else you're on your own" up front. But yeah, audio is a general weak spot.
I won't buy closed source programs with "Linux ports" anymore for this reason: it seems to always mean "some dev got it working on one Ubuntu version once". The last bug of this form I hit was a program trying to read a hardcoded path that apparently exists on Ubuntu and blissfully segfaulting if it didn't exist...
We do that. In bold. Still doesn't stop people from writing to us at least once a week asking for something else or reporting that the Ubuntu package doesn't work on their distro.
With Pipewire and containerized distribution (eg. AppImage or god forbid, Flatpak), distributing Linux software can really be as complicated as you want it to be. Granted, audio software is still a bit confusing compared to Windows or MacOS, but with the advent of PipeWire I think most people are ready to put those days behind them.
Another alternative is to drop Linux support and let your users make a Wine installer if they really care about your software. Most VST plugins and audio software works boringly well through Wine, even scaling up to be a viable route for supporting games.
Yes, it is a VST plugin (and standalone), and amusingly probably works better in Wine than Native, aside from the fonts being craptastic. Containerized distribution doesn't really work for plug-ins.
This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement. (I didn't see if that's among its goals, but such would seem reasonable.)
Linux audio support is generally a pain. Have you considered officially supporting one audio library and just saying YMMV if you use something else? For example, only support ALSA.
Which is why I've stopped reporting LibreOffice bugs. I have had literally hundreds of bugs filed, with test files and reproducibility instructions. Then they changed bug trackers - twice - and all that is lost.
With KDE and Mozilla, I'm still seeing bugs fixed a decade after I stopped reporting them. So I might be inclined to file egregious bugs to those two projects, if I feel inclined at the moment to wait a decade for a resolution.
I saw recently twitter complaint about emacs bug filed almost 15 years ago finally getting a wontfix responce(bug was about undo history loss or something). And then they write articles about their new and shiny bug closing process[1].
[1] https://lars.ingebrigtsen.no/2021/08/14/10x10/
Knowing a bug will be investigated would be enough, never mind fixed. Sadly I would assert that the vast majority of open source projects do not bother to respond to reports or even patches. The result of being ignored enough times is that I have become much less motivated to report bugs on projects that might actually care, unless there is clear and present evidence (openly available) that their issue tracker is sufficiently active. If I have to wait more than a week for a reply, you have lost me for good. If I can’t see evidence of the process working, I will not waste my time.
I had much better results with one-man projects, than with projects which have a small army of volunteers and/or of paid employees. In the later case, it feels exactly the same as when I try to get in touch with the various administrations in my area, meaning that I can achieve a similar result by printing my missive, setting it on fire and dancing around it naked.
I've reported bugs to FF and Chrome several times because they were in things I cared about. Developers tend to care more, know that there will be a place to report bugs, know how to do it and so forth. Obviously Linux gets more bug reports.
(I use mac, the m1 is just great, but I would never go through the effort of reporting a bug to mac [unless serious security hole] because I don't care about them, and because I have the impression from having tried at one time some years ago that mac bug reporting sucks.)
"Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone - the thing is, the Linux community is exceptionally well trained in reporting bugs."
The whole thread was interesting but this comment had me cracking up:
>Same experience here. Linux folks not only are our most frequent bug reporters, but they're also the best at documenting their issues and sometimes just... give us code for UI improvements?
It's worth noting that this game uses Godot engine, which is open source and built with Linux in mind, and most platform compatibility complexity was shifted to engine. Experience is quite different for big game developers that have their own engines and can't offload complexity to another layer of abstraction, supporting a lot of hardware/software combinations on Linux for them is quite hard. I presume that's why there are games that didn't get PC Linux releases while technically having Linux port(Cyberpunk 2077 would be prime example).
> Experience is quite different for big game developers that have their own engines and can't offload complexity to another layer of abstraction, supporting a lot of hardware/software combinations on Linux for them is quite hard.
Oh but they can offload that complexity to e.g. SDL [0]
As for why games like Cyberpunk 2077 are not on Linux, we can only speculate. Remember however that for a profit-focused publisher/developer the Linux port not only has to be profitable to make sense, it has to be more profitable than other things they could spend their time on.
We know for a fact that Stadia runs on Linux. We have leaked documents from CDPR hack earlier this year with details of Google's deal with CDPR. From these documents we know that Vulkan renderer exists and even how much Google paid for that.
I'm talking about native Linux ports, not Proton compatibility. There is Linux port of Cyberpunk 2077 and we know it because there is Stadia version of game. And Linux versions of Hitman 3, Control, more than a dozen of Ubisoft games(they basically have Linux versions of all their major engines), two latest Doom games. And Denuvo DRM(which is basically only game in town right now) doesn't affect compatibility with Linux that much, DRMed games like RDR2 work just fine. Anticheats are bigger problem, but they are being dealt with. Biggest anticheat providers are now Proton compatible.
I think Windows users are used to live with bugs and work around them.
Linux users prefer to adapt a system to their needs, Windows users adapt to the system.
Or maybe it's much simpler than that: Linux attracts people who are more tech savvy and like to get involved. Windows users are often incapable of understanding even basic OS concepts.
There's often no need to go any deeper than that. Same with Mac users: there's a considerable demographic to whom an OS is simply just an app launcher (which IMHO is fine), maybe even just the browser.
Negative feedback is insanely valuable. I write about that here:[0].
Here's what I wrote:
> It can be mighty unpleasant to read negative reviews and comments about our work, but it’s worth it to do so, as long as we’re doing it to improve said work. I often say that positive affirmations feel good, but negative feedback is required to improve a product. Negative feedback, even if it’s uncouth diatribes from unpleasant people, is far more valuable than the most glowing praise (unless said “glowing praise” comes from Consumer Reports).
Simply put, negative feedback is a goldmine. DON’T WASTE IT. Steel yourself. Take a belt of absinthe, if you need, and open the “Comments” section. Read everything. It sucks, doesn’t it? Is that even physically possible? Don’t you wish you were in good enough shape to do it? Do you remember your mother ever saying anything that could indicate this were true? Wait. What was that they said about the communication error report alert?
There's another piece of advice I've heard along these lines.
> Listen to the users complaining. Users are very good at identifying problems that you missed or can't see because you're too close to the project. But be careful listening to users about solutions to the problems. They can't see the whole picture.
I think this is good advice. You should want to make the best product you can. Some users have good ideas and can see things you can't. But it is hard to get the signal out of the noise and this can be very frustrating.
>even if it’s uncouth diatribes from unpleasant people
HUGE Caveat: negative feedback is not always constructive feedback. I imagine the kind of feedback devs fear isn't
>There's this weird clipping problem with the character on this level that can rarely cause you to get stuck in the floor
it's
>OMG why can't I even move in this game, did the dev even playtest this shit?
Even if they are technically saying the same thing, the latter makes me want to discord the "feedback" as some dramatic user. Even if I ignore the language, there's not much action I can take to address the issue, whereas non-diatribe negative feedback user gave me an exact level at the bare minimum to start off at.
And it's the internet. It may not be the most common feedback, but in this day of "likes", people sure do like to hoist the latter kind of comment up for devs to see first.
Wine's crash handler provides a lot more details and diagnostic information if you know what you're looking at. "Oh RAX was 0 and de-referenced. That looks like a trivial memory error in SomeComponent.dll+0x302223."
Other platforms are infantilized: "Oopsey doodle that crashed :(. Look for problem online? Oh no solution found. Sorry about that. Got it?"
That's not platform specific at all. If your program spits out proper crash logs (which most games do), it's a matter of locating and examining the log file.
The "if you know what you're looking at"-part is pretty much nonsense as you're basically saying "if you are an experienced programmer with intimate knowledge of both the system and the hardware architecture".
This is not something a regular user should be expected to know. A good program should simply provide a proper feedback-channel and collect and send the appropriate information if the user choses to do so.
>The "if you know what you're looking at"-part is pretty much nonsense as you're basically saying "if you are an experienced programmer with intimate knowledge of both the system and the hardware architecture".
Same thing.
> This is not something a regular user should be expected to know. A good program should simply provide a proper feedback-channel and collect and send the appropriate information if the user choses to do so.
Then why do all these bugs fall through the cracks on other platforms?
> the thing is, the Linux community is exceptionally well trained in reporting bugs
I don't have any stats to back up my claim but I believe a good chunk of those Linux users are tech folks - well, we submit bugs all day long at work, of course we are trained to do so!
Kudos to them. I remember reading a report from a game dev a few years ago that said basically the same thing and came to the conclusion, "... and that's why we're ending our Linux support," which utterly baffled me.
I'm reminded of Valve talking about supporting Linux for their half-life2 engine. Their experience was that they were able to find some fabulous engine speed up improvements that they then backported to the windows version.
The common thread with supporting Linux seems to be that it's not necessarily worth it from a revenue/market size point of view, but there are all kinds of intangibles that you only get by doing cross platform development.
At the coprorate level, intangibles don't help you move up the chain, unforuntately. I imaigne there are many well-intentioned devs that lack the choice to keep working on these things, or have to make other choices in the grand scheme of things.
Looking at the numbers, and the fact that most of the bugs affect all OS's playing the games, the title should probably something more like "Linux users file more reliable bug reports"
That's basically what's being said here, but you just know flag wavers are going to take the title to mean that Linux is more buggy.
> Most Windows users don't even know what a bug report is.
... or a telemetry.
To be fair, given a well-known application (paid especially), users may be more inclined to try to complain about some annoying/unexpected behavior. Just too often it goes onto a forum, so noone knows if this results in a bugreport somewhere.
It's a sci-fi 2D space mining simulator. It's already going to attract the type of user who files detailed and specific bug reports. If the author made a Call of Duty clone for Linux, would they get as many great bug reports? I don't think so.
Microsoft/Appple don't have nightlies. For systems as complex as that, it can take days just to land it in some dev feature branch, let alone get into into a production branch scheduled by product managers to deploy whenever.
A good trick for removing unintelligent content from google search results on any general computing issue is to prefix the search terms with "linux". And I'm a Mac user :)
As an Ubuntu and RHEL user, I tend to prefix my searches with "arch", for the same reason (although if you have a subscription, and your issue is with a RHEL system, RHEL is worth searching first, as they often have a bug report with resolution for your exact issue).
This is great. By the way, one of the things that has often discouraged me from filing bugs is not really knowing how to do so. Sometimes, looking at issues on github, I find people provide super structured and clean descriptions of bugs. Then there are the other kind, that the author describes: “it crashes.”
Is there a standard way of describing bugs? What resources/standards have people found useful to refer to when reporting one?
The Mac and Windows using developers at work never know how to file a bug report. I have to play 20 Questions to get them to give me the information I need to isolate the problem and fix it.
The Linux-using developers fix the problem for me.
This article does and doesn't mirror my experience.
When the pandemic hit, I helped my now 15 year-old godson build a video game add-on as a way to stay close since we couldn't travel. For the last two years we've had a blast working on this together. The add-on has grown in popularity, and has a few dozen thousand users.
Where I agree with the article, many of the complaints do come from Linux users.
Almost without exception though, the bugs they reported were Linux-specific, or related to old-versions of the add-on that we no longer supported.
A lot of times the Linux users were a release version or more behind because the emulation software they were running hadn't been updated to run the latest version of the game. They'd update the add-on, before updating the game, and then be upset when it didn't work on the slightly less than new version. Building a work around for this was a valuable lesson for my godson, in that we had to plan for the imperfect-path and make sure the add-on had a lot of edge cases baked in.
Some other things I've noticed...
Linux users do tend to report more bugs, but mostly because Linux users tend to be quick to anger. Customer support for Linux users... it was never pleasant. Someone would say something like, "Don't you test your shit?!" and like keep in mind this is a free add-on for a video game... and they'd be irate that we hadn't tested it on every system imaginable before releasing it.
Linux users don't accept reality. Often they're aren't running the "real" instance of the game, they are running some hacked together thing running on some emulator... it's not going to be perfect. Or they were running the game on unsupported hardware that they rigged a work around for. A lot of times they'd swear the bug only came about due to our add-on, but countless hours wasted trying to appease folks like this and 99% of the time it was a bug on their end. We'd probably have had 20% more "real" dev time if we didn't ever engage with those people in the first place.
Linux users tend to be more European, and there was certainly a language barrier at times. Made supporting the add-on for them worse because bug reports would come in bad-English, or German run through Google Translate to English... or just in German. There seemed to be a large number of mid-30s Germans playing a game that I'd say was aimed more for teenagers... Without sugar coating it, bug reports form those people always felt like, "Doesn't this loser have anything better to do?"
Linux users do tend to be more technical, and often they have suggestions for improvement in mind. But rarely do any of them take the time to crate a PR. It was infuriating. We'd have one guy complain every week on an open ticket... we'd say, "Hey mate, we're backed up... we'll get to this when there's time. Feel free to submit a PR!" and instead he'd just paste 80% the code he wanted updated in the GitHub ticket, and then nag us every week to fix the bug. It would have been an easy enough fix, except it required us to install Linux to verify the fix. Oof.
Broad ways I wish every community was better?
Don't be a dick. So many of the complaints came from these man-children and every other word was a profanity. Especially on open-source projects, just understand how nice you are directly correlates to how fast your issue gets worked on.
If you can fix something, don't bitch about it... just push a PR.
If you push a PR, test it first. Don't assume it's on someone else to do more testing than you'd care to do. "Oh man, that would require me to do X, Y, Z... that would take hours!" Yeah, it would require anyone testing to do X, Y, Z... if you want it fixed, the fix includes testing on X, Y, Z... not just writing the code. Way more testers are needed for all open source projects, but most end users -- even the ones who can't code -- don't really want to help the project by volunteering testing time. If there's a project you like, and you can't code, you should still reach out to the creator and say, "Hey, how can I help test?"
That sounds a lot like badly managed support TBH. Complaint about having to install Linux to check fix indicates that you weren't even trying to run build on Linux before releasing it, I'm not sure why were you supporting Linux at all with that kind of attitude. And I presume that vanilla game doesn't have common way to install mods and Linux version is non-existent.
>I'm not sure why were you supporting Linux at all with that kind of attitude.
it's a free add-on made alongside a 15 year old for bonding purposes. For all we know, it wasn't. And I don't think they have a duty to provide any labor that goes beyond their bonding to ensure this, let alone be yelled at for it.
>Someone would say something like, "Don't you test your shit?!" and like keep in mind this is a free add-on for a video game.
that's always the worst. If they paid some money for this, then I can understand some anger in their investment. Here, it's literally goodwill providing this tool the complainer chose not to make themselves and they instead throw a fit like the world owes them this free labor.
I don't like using this retort, but this is exactly what the "why don't you make your own steak" sorts of replies are for.
It has to pick up a few things from the surrounding environment, but steam entirely standardizes the vast majority of it, and the rest of it is really really similar between every linux-running OS.
Does whatever work on Android too? Because that's technically Linux, that's what I believe GP was referring to. I believe Android actually has a totally different graphics stack.
The point is that people who choose an OS other than Windows or Mac tend to choose something based on Linux, and are usually technically skilled and submit much higher quality bug reports, more often.
Linux users just care more about the experience of using a computer, otherwise most wouldn't have jumped ship.
Also, technical skill aside, Linux users are used to dev <-> consumer relationship being more symmetrical and more of a "two way street". The few non-coder Linux users I know prefer it for this aspect --- similar to why people might shop at a local neighborhood co-op instead of Walmart/Target/Microsoft/Apple
Notably, of those bug reports, fewer than 1% (only 3 bugs) were specific to the Linux version of the game. That is, over 99% of the bugs reported by Linux gamers also affected players in other platforms. Moreover (quoting from the OP):
> The report quality [from Linux users] is stellar. I mean we have all seen bug reports like: “it crashes for me after a few hours”. Do you know what a developer can do with such a report? Feel sorry at best. You can’t really fix any bug unless you can replicate it, see it with your own eyes, peek inside and finally see that it’s fixed. And with bug reports from Linux players is just something else. You get all the software/os versions, all the logs, you get core dumps and you get replication steps. Sometimes I got with the player over discord and we quickly iterated a few versions with progressive fixes to isolate the problem. You just don’t get that kind of engagement from anyone else.
Indeed, although my kneejerk reaction to the subject line was to expect another sad article about how it's not worth it to support Linux, this author seems very happy with the decision to do so.
> Worth it? Oh, yes - at least for me. Not for the extra sales - although it’s nice. It’s worth it to get the massive feedback boost and free, hundred-people strong QA team on your side. An invaluable asset for an independent game studio.
Maybe there's a better term to throw at this. "Even though just 5.8% of userbase, Linux users contribute 55% of helpful QA feedback"
10 replies →
The worst part? I've seen developers and companies actually complain about this. Just 6% of sales yet look at the huge amount of work they cause us!
This is the case with people selling business software, meaning bugs would mean wrong accounting or worse outcomes for the customers. Yet all layers in the company would treat these reports as an annoyance.
Huge amount of work they do for us
3 replies →
Are there any good articles on writing helpful bug reports? Whenever I submit a bug I try to give as much detail and be as specific as possible but I always imagine some dev somewhere reading it rolling their eyes at the unnecessary paragraphs I’ve submitted.
I can recommend https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
13 replies →
As a dev, I think
STEPS TO REPRODUCE Open foo click bar
EXPECTED RESULT saves bar
ACTUAL RESULT crashes with error x912344
MISC <any other logs, details here>
is the best. It gives just the right amount of detail to get started, in a good, actionable format.
5 replies →
Use this template:
1. When I do this
2. Here is what I expect to happen
3. But instead, this happens
5 replies →
From "Post-surgical deaths in Scotland drop by a third, attributed to a checklist" > GitHub and GitLab support task checklists in Markdown and also project boards [...]
> GitHub and GitLab support (multiple) Issue and Pull Request templates:
> Default: /.github/ISSUE_TEMPLATE.md || Configure in web interface
> /.github/ISSUE_TEMPLATE/Name.md || /.gitlab/issue_templates/Name.md
> Default: /.github/PULL_REQUEST_TEMPLATE.md || Configure in web interface
> /.github/PULL_REQUEST_TEMPLATE/Name.md || /.gitlab/merge_request_templates/Name.md
> There are template templates in awesome-github-templates [1] and checklist template templates in github-issue-templates [2].
> [1] https://github.com/devspace/awesome-github-templates
> [2]ognarb
5 years ago
skeeter2020
5 years ago
dylan604
5 years ago
WalterBright
5 years ago
blackearl
5 years ago
https://community.kde.org/Get_Involved/Issue_Reporting This one is pretty good
bug reports and communication in general: If you've got a good summary/abstract more detail is always better. I don't know if I've ever had to talk to someone on my team about how they "over communicated" (not the same as TMI!). Make the receiver responsible for saying "OK, that's enough, got it!"
3 replies →
Think about what you would want to know if someone was reporting the bug to you. Provide at least that much information.
"Just the facts, Ma'am"
https://www.youtube.com/watch?v=v4LPkmGO5Cc
Usually sending just "help" and no other data is preferred. Don't send screenshots, don't make use of the ingame reporting tools (pressing F11), don't send steps to replicate.
I’ve often thought that game developers, esp indy studios, would benefit from doing first beta releases on Linux exclusively - wringing out a bunch of bugs, then doing a wider release.
Well that might be one way to _accelerate_ your dev process.
maybe alpha, beta level you gotta be on all platforms.
>"we have all seen bug reports like: “it crashes for me after a few hours"
Here is a gem from my collection of user "bug reports". The email with this exact words and nothing else - "something is wrong, what do I do?". I was biting my fingers trying not to reply with the first thing that came into my head.
"We are sorry to read that. Please clearly describe your problem to us so we can help you. Feel free to call us on this phone number: XXX-XXX-XXX"
People don't always understand our perspective, we should guide them into doing the right thing and everybody will be happy.
Save your generic answer so you don't waste your time doing so, but being pedagogical should be part of our work in my opinion.
2 replies →
Interpreted literally it’s a reasonable question: “What process should I follow when I encounter a problem?”
1 reply →
I don't hold myself and frankly answer that my crystal ball is on scheduled maintenance today.
2 replies →
Conclusion: want good testing and bug reports of your game? Support linux.
Or have proper analytics. If a user emails you and says "It crashes after a few hours" rather than feeling bad for them, you ask them what their steam/game id is and you look them up in the crash reporter system and see exactly what happens rather than relying on a few programmer consumers doing the work for you.
6 replies →
Possibly, but how many of the bugs are rare edge cases (i.e., attempting to break the game) versus problems players actually face in normal gameplay? Without knowing what priority or severity these bugs take, it is difficult to say how useful the increased volume of feedback is.
4 replies →
Yep, it’s a great point to raise in support of releasing software for Linux. Adept users who can produce high quality bug reports and help solve bugs across all platforms provide a lot of value, perhaps enough to justify “only” a ~5% market share.
Just from the title, I went in expecting that percentage to be much higher, but still expected I'd get a chance to complain how report quality was not taken into account (I expected Linux users to submit better reports)!
Pleasantly surprised on all accounts :D
Sometimes I forget my detailed bug reports with steps I took, even if I can't reproduce it--since it might provide a hint to someone with insight into the programs internals--, are a weird outlier.
This was my hunch, and I just wanted it to be true. I'm very pleased it turned out to be that way.
more likely s/linux/developers, which i suspect represents the majority of linux users
God damnit... Clickbating is ruining any shred of useful information...
I am not sure why would one expect more linux bugs in a game made using a game engine (I couldn't find any info and I am assuming this game is one, correct me if I am wrong). If it is not working in linux, then it must be an engine bug, not a game one. If I am wrong then props to devs for having such a consistent game engine
Perhaps other option is using cpp, and having UB that behaves differently in different compilers. But I doubt that as well
OP was not saying that 38% of the bugs are Linux-specific, he was saying that Linux users report many more bugs per capita than windows users (and he sees that as a good thing).
Yep we find a variant of this with our python open source data science users who normal businesses would hate:
- Across all Python envs (Jupyter, streamlit/plotly, flask/Django, ...), they report way more bugs, and often from our free tiers, which sounds low ROI.. but our community caught all but ~2 significant bugs we fixed this year that our internal automated testing missed and would have otherwise gone to our Enterprise and gov users . They are happy to exchange a tiny bit of GPU or viz burps for new features faster, as long as we are responsive to their reports! That also pushed us to a better dev cadence which wouldn't have worked for our Enterprise users. More subtle, we have more confidence for deploying wider features/APIs which would otherwise be too underused + risky for the same reason.
- they are often doing innovative new things with our stack, which originally meant feature requests for non-repeatable sales.. but ended up stretching our flexibility into wider applicability, and they can clearly tell us areas to advance the visual, analytic, etc sides of our R&D and package it up for the rest of their internal analysts. Almost like a multiplier for conversations with our more operationally focused no-code/low-code users, and helps us see around the corner for them in the AI+API+customization sides!
- most of our technical partnership discussions now go through our OSS client repos. Rather than PowerPoints with BD people that don't have staff to do things, a product dev or sales engineer/architect or devrel blogger will think, "oh our customers would benefit from better interactive visuals on our data, let me whip something up quick with that package" and we help them take it from there
- open source data users like PyData developers and data scientists, compared to say the # of SMBs out there or general enterprise employees, is small and almost by definition doesn't pay for most software... but they end up being attached to projects that do, and influence much of their organization that definitely does!
We're just used contributing bug reports and pull requests, sort of our thing. It's not as prevalent with Windows or MacOS users, just not part of that culture.
Great article, though he's benefitting from a specific slice of Linux users that are great to work with.
On the other end of the spectrum, try releasing a php plugin for Wordpress, OpenCart, Magento, etc. I released a mildly popular, open-source, free add on in this space. The Linux users there are decidedly less technical, but still doing it themselves.
What I got for "bug reports" was mostly terrible, few details/logs/etc. And a weird entitlement thing where people had really high support expectations over something that was open source and free. Even a few expletive-laden emails. I did receive a few really helpful reports, pull-requests, and thank you emails...but they were very much the exception.
I think the difference is:
With a game that supports Linux, you get people who have chosen to run Linux instead of Windows because they prefer it. They have also worked enough with their system to get their Linux system capable of running games well, which may not be trivial for the given distro.
With a Wordpress plugin or whatever, you get people who are running Linux because they "have" to. Trying not to sound "true Scottsman"y here, but most of the time these are not actually Linux users, these are Windows users who are further confounded by having to use an unfamiliar platform.
There are even a few php users trying to run windows server...
Yes, you get users who have linux as their 'daily driver', as opposed to those to dabble in it a bit on the side :)
For similar reason, I think the level of experience is probably different. Meaning those could be the same person and time is the important variable. After they’re used to developing, they better understand what useful feedback looks like.
1 reply →
In addition, in my experience maintaining a developer tool, an outsized source of bug reports is Linux users reporting already fixed issues in their outdated distro packages, or even problems introduced by their packager (e.g. flatpak/snap permission problems). And they typically won’t identify the version despite clear instructions in the issue template asking for the debug output containing everything I need, including the version.
If you support distro packaging of your software (which you should, since it should ideally reduce the load on you when it comes to triaging bugs) and users are coming to you with distro specific bugs then you should:
- Immediately close issues where the user has indicated that they did not test against the latest version or where the user has not answered the question "did you reproduce this issue with the current version of the software built from source?" (You should just automate this)
- If users continue pestering you and they seem to come from a specific distribution: complain to the maintainers of the distribution and ask that they inform their users of the proper bug reporting channels.
New users are coming to linux on a regular basis and they're coming in with a windows mindset. It is important for the smooth functioning of both linux distributions and software projects to make users aware that the proper channels for reporting bugs they experience when using software which was packaged for their distribution is the distribution's maintainers.
Users need to be made aware that unless they're compiling directly from source and using a supported version then they have no business going to upstream with their bug reports.
You may think this is harsh but if you get backlash, distributions should have your back on this (they usually do have information somewhere to inform users that bug reports should go to them first). I recommend any open source project take this stance when it comes to bug reports. If someone finds a real bug and they are certain it's not one caused by their distribution then they can easily build your project and reproduce the bug there.
(Aside: If you are providing a library then an appropriate level of API stability is a must have if you want people to be able to actually test bugs in a newer library version.)
2 replies →
Don't blame the user here - your bug reporting template should have users declare what package version they're using so that you can easily tell them they're on an outdated package. Flatpak is usually a boon in this regard since you can ensure your users are all on the latest packages, though you're making the tradeoff of having to deal with any Flatpak-specific bugs (which I'd say is a decent tradeoff for solo maintainers).
5 replies →
Most of the Wordpress developers I know are Windows users. (I don't know too many of them, but still.)
That's interesting. Most of the WP devs I encountered are deploying on old-school shared Linux hosting, like BlueHost, GoDaddy, etc. Maybe some use Windows for local dev stuff, but I doubt many deploy their "prod" there.
7 replies →
Glad to see that it was a positive view of the Linux bug reporters, rather than "Bah, I spend all my time fixing packaging issues from entitled Linux users who scream at me that the game doesn't work with their obscure, home-spun distro."
In a similar vein, I think the biggest value-add that Arch has over other distros is that it turns out having the filter of "can follow well written instructions through mildly tricky commands well enough to result in a bootable system" results in a community with a base level of competence, care, and patience that puts it at least two standard deviations above the other distros and at least four (I know how small the percentile is now) above just the general wash of garbage that you get when you Google for Windows issues.
It creates similar effects to the different credit card companies. Why would anyone accept Amex and its higher fees? Because they bring you higher value customers, sometimes dramatically higher value.
>In a similar vein, I think the biggest value-add that Arch has over other distros is that it turns out having the filter of "can follow well written instructions through mildly tricky commands
What is the value of "is competent enough to copy paste commands from a wiki?". Honestly I think the best bug reports might be because some Linux users probably understand C/C++ and can understand crash reports and error messages because they understand the system.
32 replies →
> Why would anyone accept Amex and its higher fees? Because they bring you higher value customers, sometimes dramatically higher value.
Why are Amex customers higher value? Is it because they're typically business cards rather than personal?
3 replies →
WSL is somewhat similar in that installing it was harder than installing most other things on Windows. They've made it easier in Windows 11, and will probably continue that direction. I wonder if MS knows where that leads for them.
2 replies →
TBH, as a non-ubuntu (gentoo) user, i'm pretty sure, that all the packaging isues (for non-gentoo packages) are something that I, personally have to deal with, and not bother the original developer with.
On the other hand, a Windows user is trained not to report bugs, especially in games. There's rarely a channel for reporting things & simple bugs go unfixed unless the community can work out some hack to do it for themselves. Games are abandonware monoliths on day one.
Secondly, if a program crashes in Windows and you try to force kill it, you get blocked waiting for the 'report' to be sent do Microsoft. Users are trained to click off this, so the OS will finally do what you asked it to.
Do you think this has something to do with how many Windows programs (not just games) handle errors and crashes? Even Windows still uses the "Error code: <bunch of meaningless numbers>" scheme. I can't even think of the last time I even attempted to get crash logs for a Windows program; however, on Linux I can usually find where logs got dumped and debug without as much of a headache.
... and if you search for that meaningless number and manage to find a proper support page, you are usually left with as much information as you started with. I don't understand why open source developers are so much better in this respect, but the diagnostics usually leave me feeling as though I could solve the problem even when I don't have the technical skills to do so. Being able to comb through the logs to pinpoint the problem is a major contributor in this respect.
(The only counter example I can think of at the moment is Samba, and guess what ... it interfaces with Microsoft products!)
I've noticed this too, compare any forum thread for a AAA Windows game and a Linux game, the Windows game thread is going to look like a bunch of chickens running with their heads cut off wondering why the 0x00423 error is causing the game to crash. Head over to a Linux thread and it's a usually a much more productive conversation because the errors are just clearer.
And when you can find a bug reporting channel the issue gets answered by an ‘MVP’, usually with some sort of inapplicable canned response, and then closed as ‘fixed’, without actually addressing the problem.
> On the other hand, a Windows user is trained not to report bugs
Decades of dealing with open source projects hasn't been much better in my experience. I don't usually bother to submit bug reports because my experience is that they'll be ignored for a few years and then closed unceremoniously.
That depends. I've dealt with open source products where I've submitted a bug report, submitted a bit of code, had the developer say that the patch wouldn't work for a good reason, then push out a proper fix nearly immediately. On the other hand, I have heard many stories that reflect yours. I suspect the size of the user base is a major contributor. Popular projects have many people submitting "bugs" that are little more than low priority (to the developer) feature requests.
For an audio app that I work on, it's similar, but different: around 1% of the users are on Linux, and around a third of the bugs / complaints come from Linux, but they're virtually all Linux specific.
We're having to seriously consider dropping Linux support because the support / maintenance load is so high. (This comes significantly from the libraries we're using having worse Linux support, and a lot from the Linux audio ecosystem in general not being very mature; and then a whole bunch of it is people wanting packages for dozens of different systems.)
I would think you can deal with platform-specific issues by saying "we support Ubuntu [or whatever you're willing to do]; anything else you're on your own" up front. But yeah, audio is a general weak spot.
I won't buy closed source programs with "Linux ports" anymore for this reason: it seems to always mean "some dev got it working on one Ubuntu version once". The last bug of this form I hit was a program trying to read a hardcoded path that apparently exists on Ubuntu and blissfully segfaulting if it didn't exist...
4 replies →
We do that. In bold. Still doesn't stop people from writing to us at least once a week asking for something else or reporting that the Ubuntu package doesn't work on their distro.
1 reply →
With Pipewire and containerized distribution (eg. AppImage or god forbid, Flatpak), distributing Linux software can really be as complicated as you want it to be. Granted, audio software is still a bit confusing compared to Windows or MacOS, but with the advent of PipeWire I think most people are ready to put those days behind them.
Another alternative is to drop Linux support and let your users make a Wine installer if they really care about your software. Most VST plugins and audio software works boringly well through Wine, even scaling up to be a viable route for supporting games.
Yes, it is a VST plugin (and standalone), and amusingly probably works better in Wine than Native, aside from the fonts being craptastic. Containerized distribution doesn't really work for plug-ins.
This is the first time I'm reading of Pipewire, and it sounds promising, but will need to have host support before it becomes a reasonable VST / LADSPA replacement. (I didn't see if that's among its goals, but such would seem reasonable.)
4 replies →
> but with the advent of PipeWire I think most people are ready to put those days behind them
Maybe. On the otherhand I heard similar things about Pulse and Wayland and a decade later they're still problematic.
Linux audio support is generally a pain. Have you considered officially supporting one audio library and just saying YMMV if you use something else? For example, only support ALSA.
Packages aren't supposed to be submitted and maintained by the developers themselves. The distribution maintainers and community is supposed to do it.
That only works for open source packages.
1 reply →
I don't know about you - you might be insane for all I know - but I'm MUCH more likely to report a bug if I think there's any chance of it being fixed
Which is why I've stopped reporting LibreOffice bugs. I have had literally hundreds of bugs filed, with test files and reproducibility instructions. Then they changed bug trackers - twice - and all that is lost.
With KDE and Mozilla, I'm still seeing bugs fixed a decade after I stopped reporting them. So I might be inclined to file egregious bugs to those two projects, if I feel inclined at the moment to wait a decade for a resolution.
I saw recently twitter complaint about emacs bug filed almost 15 years ago finally getting a wontfix responce(bug was about undo history loss or something). And then they write articles about their new and shiny bug closing process[1]. [1] https://lars.ingebrigtsen.no/2021/08/14/10x10/
2 replies →
> Then they changed bug trackers - twice - and all that is lost.
When precisely did this happen?
1 reply →
Knowing a bug will be investigated would be enough, never mind fixed. Sadly I would assert that the vast majority of open source projects do not bother to respond to reports or even patches. The result of being ignored enough times is that I have become much less motivated to report bugs on projects that might actually care, unless there is clear and present evidence (openly available) that their issue tracker is sufficiently active. If I have to wait more than a week for a reply, you have lost me for good. If I can’t see evidence of the process working, I will not waste my time.
I had much better results with one-man projects, than with projects which have a small army of volunteers and/or of paid employees. In the later case, it feels exactly the same as when I try to get in touch with the various administrations in my area, meaning that I can achieve a similar result by printing my missive, setting it on fire and dancing around it naked.
I've reported bugs to FF and Chrome several times because they were in things I cared about. Developers tend to care more, know that there will be a place to report bugs, know how to do it and so forth. Obviously Linux gets more bug reports.
(I use mac, the m1 is just great, but I would never go through the effort of reporting a bug to mac [unless serious security hole] because I don't care about them, and because I have the impression from having tried at one time some years ago that mac bug reporting sucks.)
FTA:
"Do you know how many of these 400 bug reports were actually platform-specific? 3. Literally only 3 things were problems that came out just on Linux. The rest of them were affecting everyone - the thing is, the Linux community is exceptionally well trained in reporting bugs."
That indicates that Linux it's very far away from being mainstream
The whole thread was interesting but this comment had me cracking up:
>Same experience here. Linux folks not only are our most frequent bug reporters, but they're also the best at documenting their issues and sometimes just... give us code for UI improvements?
Another example of "they'll never tell you": https://pointersgonewild.com/2019/11/02/they-might-never-tel...
One thought: if merely 'being a Linux user' can enrich bug report rates by a factor of 6.5x, how many bugs are still not being reported...?
It's worth noting that this game uses Godot engine, which is open source and built with Linux in mind, and most platform compatibility complexity was shifted to engine. Experience is quite different for big game developers that have their own engines and can't offload complexity to another layer of abstraction, supporting a lot of hardware/software combinations on Linux for them is quite hard. I presume that's why there are games that didn't get PC Linux releases while technically having Linux port(Cyberpunk 2077 would be prime example).
> Experience is quite different for big game developers that have their own engines and can't offload complexity to another layer of abstraction, supporting a lot of hardware/software combinations on Linux for them is quite hard.
Oh but they can offload that complexity to e.g. SDL [0]
As for why games like Cyberpunk 2077 are not on Linux, we can only speculate. Remember however that for a profit-focused publisher/developer the Linux port not only has to be profitable to make sense, it has to be more profitable than other things they could spend their time on.
[0] http://libsdl.org/
We know for a fact that Stadia runs on Linux. We have leaked documents from CDPR hack earlier this year with details of Google's deal with CDPR. From these documents we know that Vulkan renderer exists and even how much Google paid for that.
For most AAA titles the reason is simply 3rd-party DRM and/or Anti-Cheat not working on Linux.
I'm talking about native Linux ports, not Proton compatibility. There is Linux port of Cyberpunk 2077 and we know it because there is Stadia version of game. And Linux versions of Hitman 3, Control, more than a dozen of Ubisoft games(they basically have Linux versions of all their major engines), two latest Doom games. And Denuvo DRM(which is basically only game in town right now) doesn't affect compatibility with Linux that much, DRMed games like RDR2 work just fine. Anticheats are bigger problem, but they are being dealt with. Biggest anticheat providers are now Proton compatible.
I think Windows users are used to live with bugs and work around them. Linux users prefer to adapt a system to their needs, Windows users adapt to the system.
Or maybe it's much simpler than that: Linux attracts people who are more tech savvy and like to get involved. Windows users are often incapable of understanding even basic OS concepts.
There's often no need to go any deeper than that. Same with Mac users: there's a considerable demographic to whom an OS is simply just an app launcher (which IMHO is fine), maybe even just the browser.
There's a reason ChromeOS has been so successful.
Negative feedback is insanely valuable. I write about that here:[0].
Here's what I wrote:
> It can be mighty unpleasant to read negative reviews and comments about our work, but it’s worth it to do so, as long as we’re doing it to improve said work. I often say that positive affirmations feel good, but negative feedback is required to improve a product. Negative feedback, even if it’s uncouth diatribes from unpleasant people, is far more valuable than the most glowing praise (unless said “glowing praise” comes from Consumer Reports).
Simply put, negative feedback is a goldmine. DON’T WASTE IT. Steel yourself. Take a belt of absinthe, if you need, and open the “Comments” section. Read everything. It sucks, doesn’t it? Is that even physically possible? Don’t you wish you were in good enough shape to do it? Do you remember your mother ever saying anything that could indicate this were true? Wait. What was that they said about the communication error report alert?
[0] https://littlegreenviper.com/miscellany/the-road-most-travel...
There's another piece of advice I've heard along these lines.
> Listen to the users complaining. Users are very good at identifying problems that you missed or can't see because you're too close to the project. But be careful listening to users about solutions to the problems. They can't see the whole picture.
I think this is good advice. You should want to make the best product you can. Some users have good ideas and can see things you can't. But it is hard to get the signal out of the noise and this can be very frustrating.
Agreed. Like Henry Ford is quoted as saying:
1 reply →
>even if it’s uncouth diatribes from unpleasant people
HUGE Caveat: negative feedback is not always constructive feedback. I imagine the kind of feedback devs fear isn't
>There's this weird clipping problem with the character on this level that can rarely cause you to get stuck in the floor
it's
>OMG why can't I even move in this game, did the dev even playtest this shit?
Even if they are technically saying the same thing, the latter makes me want to discord the "feedback" as some dramatic user. Even if I ignore the language, there's not much action I can take to address the issue, whereas non-diatribe negative feedback user gave me an exact level at the bare minimum to start off at.
And it's the internet. It may not be the most common feedback, but in this day of "likes", people sure do like to hoist the latter kind of comment up for devs to see first.
Wine's crash handler provides a lot more details and diagnostic information if you know what you're looking at. "Oh RAX was 0 and de-referenced. That looks like a trivial memory error in SomeComponent.dll+0x302223."
Other platforms are infantilized: "Oopsey doodle that crashed :(. Look for problem online? Oh no solution found. Sorry about that. Got it?"
That's not platform specific at all. If your program spits out proper crash logs (which most games do), it's a matter of locating and examining the log file.
The "if you know what you're looking at"-part is pretty much nonsense as you're basically saying "if you are an experienced programmer with intimate knowledge of both the system and the hardware architecture".
This is not something a regular user should be expected to know. A good program should simply provide a proper feedback-channel and collect and send the appropriate information if the user choses to do so.
>The "if you know what you're looking at"-part is pretty much nonsense as you're basically saying "if you are an experienced programmer with intimate knowledge of both the system and the hardware architecture".
Same thing.
> This is not something a regular user should be expected to know. A good program should simply provide a proper feedback-channel and collect and send the appropriate information if the user choses to do so.
Then why do all these bugs fall through the cracks on other platforms?
3 replies →
> the thing is, the Linux community is exceptionally well trained in reporting bugs
I don't have any stats to back up my claim but I believe a good chunk of those Linux users are tech folks - well, we submit bugs all day long at work, of course we are trained to do so!
Interview with the author, mostly touching the Linux development of the game: https://www.gamingonlinux.com/2021/05/an-interview-with-kode...
Kudos to them. I remember reading a report from a game dev a few years ago that said basically the same thing and came to the conclusion, "... and that's why we're ending our Linux support," which utterly baffled me.
Appreciate the old reddit url, so much more readable imo.
I am more impressed by 5.8% of sales being from Linux, it was less than a percent in my experience
I'm reminded of Valve talking about supporting Linux for their half-life2 engine. Their experience was that they were able to find some fabulous engine speed up improvements that they then backported to the windows version.
The common thread with supporting Linux seems to be that it's not necessarily worth it from a revenue/market size point of view, but there are all kinds of intangibles that you only get by doing cross platform development.
At the coprorate level, intangibles don't help you move up the chain, unforuntately. I imaigne there are many well-intentioned devs that lack the choice to keep working on these things, or have to make other choices in the grand scheme of things.
Looking at the numbers, and the fact that most of the bugs affect all OS's playing the games, the title should probably something more like "Linux users file more reliable bug reports"
That's basically what's being said here, but you just know flag wavers are going to take the title to mean that Linux is more buggy.
Most Windows users don't even know what a bug report is.
> Most Windows users don't even know what a bug report is.
... or a telemetry.
To be fair, given a well-known application (paid especially), users may be more inclined to try to complain about some annoying/unexpected behavior. Just too often it goes onto a forum, so noone knows if this results in a bugreport somewhere.
Yep, sampling bias.
It's a sci-fi 2D space mining simulator. It's already going to attract the type of user who files detailed and specific bug reports. If the author made a Call of Duty clone for Linux, would they get as many great bug reports? I don't think so.
When I submitted a bug to Linux distro Pop OS, it was fixed and deployed within days to all users.
Can you imagine anything like that with Windows or Mac OS? We have reports how Apple silences zero day researchers instead.
Microsoft/Appple don't have nightlies. For systems as complex as that, it can take days just to land it in some dev feature branch, let alone get into into a production branch scheduled by product managers to deploy whenever.
A good trick for removing unintelligent content from google search results on any general computing issue is to prefix the search terms with "linux". And I'm a Mac user :)
As an Ubuntu and RHEL user, I tend to prefix my searches with "arch", for the same reason (although if you have a subscription, and your issue is with a RHEL system, RHEL is worth searching first, as they often have a bug report with resolution for your exact issue).
I bought this game because I appreciate good devs and want to encourage linux support in gaming.
This game is phenomenal, I can't stop playing. Intuitive, good UI, tons of fun. Thanks!
This is great. By the way, one of the things that has often discouraged me from filing bugs is not really knowing how to do so. Sometimes, looking at issues on github, I find people provide super structured and clean descriptions of bugs. Then there are the other kind, that the author describes: “it crashes.”
Is there a standard way of describing bugs? What resources/standards have people found useful to refer to when reporting one?
There are a bunch of open source projects on github with issue templates. Have a look at a couple of those and pick one that suits you.
I wonder how many people will read just the headline, think, "I knew it!" and move on without actually reading this insightful article.
It just means that Linux users are more technically savvy I would say.
If you've installed and use Linux then 90% your interests are in IT / software / hardware design.
So you know concept of a bug. And it is a good chance you've produced and fixed those by your own too.
The best person to report a bug is a programmer really.
the titled should be updated to say "the Linux community" at the end, as on the original page
The original title was too long
The Mac and Windows using developers at work never know how to file a bug report. I have to play 20 Questions to get them to give me the information I need to isolate the problem and fix it.
The Linux-using developers fix the problem for me.
This article does and doesn't mirror my experience.
When the pandemic hit, I helped my now 15 year-old godson build a video game add-on as a way to stay close since we couldn't travel. For the last two years we've had a blast working on this together. The add-on has grown in popularity, and has a few dozen thousand users.
Where I agree with the article, many of the complaints do come from Linux users.
Almost without exception though, the bugs they reported were Linux-specific, or related to old-versions of the add-on that we no longer supported.
A lot of times the Linux users were a release version or more behind because the emulation software they were running hadn't been updated to run the latest version of the game. They'd update the add-on, before updating the game, and then be upset when it didn't work on the slightly less than new version. Building a work around for this was a valuable lesson for my godson, in that we had to plan for the imperfect-path and make sure the add-on had a lot of edge cases baked in.
Some other things I've noticed...
Linux users do tend to report more bugs, but mostly because Linux users tend to be quick to anger. Customer support for Linux users... it was never pleasant. Someone would say something like, "Don't you test your shit?!" and like keep in mind this is a free add-on for a video game... and they'd be irate that we hadn't tested it on every system imaginable before releasing it.
Linux users don't accept reality. Often they're aren't running the "real" instance of the game, they are running some hacked together thing running on some emulator... it's not going to be perfect. Or they were running the game on unsupported hardware that they rigged a work around for. A lot of times they'd swear the bug only came about due to our add-on, but countless hours wasted trying to appease folks like this and 99% of the time it was a bug on their end. We'd probably have had 20% more "real" dev time if we didn't ever engage with those people in the first place.
Linux users tend to be more European, and there was certainly a language barrier at times. Made supporting the add-on for them worse because bug reports would come in bad-English, or German run through Google Translate to English... or just in German. There seemed to be a large number of mid-30s Germans playing a game that I'd say was aimed more for teenagers... Without sugar coating it, bug reports form those people always felt like, "Doesn't this loser have anything better to do?"
Linux users do tend to be more technical, and often they have suggestions for improvement in mind. But rarely do any of them take the time to crate a PR. It was infuriating. We'd have one guy complain every week on an open ticket... we'd say, "Hey mate, we're backed up... we'll get to this when there's time. Feel free to submit a PR!" and instead he'd just paste 80% the code he wanted updated in the GitHub ticket, and then nag us every week to fix the bug. It would have been an easy enough fix, except it required us to install Linux to verify the fix. Oof.
Broad ways I wish every community was better?
Don't be a dick. So many of the complaints came from these man-children and every other word was a profanity. Especially on open-source projects, just understand how nice you are directly correlates to how fast your issue gets worked on.
If you can fix something, don't bitch about it... just push a PR.
If you push a PR, test it first. Don't assume it's on someone else to do more testing than you'd care to do. "Oh man, that would require me to do X, Y, Z... that would take hours!" Yeah, it would require anyone testing to do X, Y, Z... if you want it fixed, the fix includes testing on X, Y, Z... not just writing the code. Way more testers are needed for all open source projects, but most end users -- even the ones who can't code -- don't really want to help the project by volunteering testing time. If there's a project you like, and you can't code, you should still reach out to the creator and say, "Hey, how can I help test?"
That sounds a lot like badly managed support TBH. Complaint about having to install Linux to check fix indicates that you weren't even trying to run build on Linux before releasing it, I'm not sure why were you supporting Linux at all with that kind of attitude. And I presume that vanilla game doesn't have common way to install mods and Linux version is non-existent.
>I'm not sure why were you supporting Linux at all with that kind of attitude.
it's a free add-on made alongside a 15 year old for bonding purposes. For all we know, it wasn't. And I don't think they have a duty to provide any labor that goes beyond their bonding to ensure this, let alone be yelled at for it.
1 reply →
>Someone would say something like, "Don't you test your shit?!" and like keep in mind this is a free add-on for a video game.
that's always the worst. If they paid some money for this, then I can understand some anger in their investment. Here, it's literally goodwill providing this tool the complainer chose not to make themselves and they instead throw a fit like the world owes them this free labor.
I don't like using this retort, but this is exactly what the "why don't you make your own steak" sorts of replies are for.
I love that this links to the legacy reddit ui.
Just for kidding but... do you think windows users are able to make/know what is it a bug report?
Hrmmm. This appears to be a trend. Moving averages suggest in some short time 13% of those sales may account for 50% of the bugs.
They should drop Linux support and save themselves the hassle.
Despite being 13% of the userbase
TL;DR: reason number one million why you should be using Free software whenever you can: you don't feel helpless about bugs.
There is no such OS as Linux, Linux is the kernel. Support Linux-based OSs you want to support and no other OSs you don't support.
There is for all practical purposes a singluar linux.
Why? Because you can bundle your own "userspace" to support your game, and that's what steam does for you with it's runtime: https://github.com/ValveSoftware/steam-runtime
It has to pick up a few things from the surrounding environment, but steam entirely standardizes the vast majority of it, and the rest of it is really really similar between every linux-running OS.
TBH this runtime can be replaced, and Arch ships a package which makes it very easy to do
https://wiki.archlinux.org/title/Steam/Troubleshooting#Steam...
Sometimes it works better than what Valve ships. It saved me a couple of times.
4 replies →
Does whatever work on Android too? Because that's technically Linux, that's what I believe GP was referring to. I believe Android actually has a totally different graphics stack.
The point is that people who choose an OS other than Windows or Mac tend to choose something based on Linux, and are usually technically skilled and submit much higher quality bug reports, more often. Linux users just care more about the experience of using a computer, otherwise most wouldn't have jumped ship.
Also, technical skill aside, Linux users are used to dev <-> consumer relationship being more symmetrical and more of a "two way street". The few non-coder Linux users I know prefer it for this aspect --- similar to why people might shop at a local neighborhood co-op instead of Walmart/Target/Microsoft/Apple
talk about missing the forest for the trees! _goddamn_