Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Despite having just 5.8% sales, over 38% of bug reports come from Linux

old.reddit.com

Post reply on HN
Print view View original

251–260 of 267 posts

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#251

Post by account42 »

bentcorner wrote: post #146
drdrey wrote: post #38

Earlier quoted context omitted.

Use this template: 1. When I do this 2. Here is what I expect to happen 3. But instead, this happens

One more tidbit: In the "When I do this", I find it useful to omit stuff that isn't interesting. Does the thing fail if I do something immediately? Or does it only occur if the application has been dormant for a few minutes? Does it only occur using the mouse, or can I use the keyboard? Get a good set of steps for reproducing the problem, but wander a little off those steps to see what is actually necessary. I've bee…

It's probably better to err on the side of having too many steps rather than missing cruicial steps to reproduce the problem.

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#252

Post by account42 »

Gigachad wrote: post #223
saagarjha wrote: post #218

Earlier quoted context omitted.

It's not really that hard to do this: ask bug reporters to attach their logs. Don't just take them preemptively "just in case".

If I asked users to attach a bug report file, most of them would complain and tell me to stop waisting their time and get the problem fixed. I have many times explained to users that I found their issue in our reporting and have not ever got a negative response. The average user does not give two shits that you can see exactly what line of code their instance of your game crashed at. They want to play a video game an…

The average user also has no idea what/how much information is contained in those automated reports. If you are just sending a build ID and a stack trace, sure. If you are sending memory dumps (even partial) or associating those stack dumps with identifying information (e.g. steam IDs) then you really should be asking for informed consent before you do that. And no, it being a common practice to just collect as much information as you can does not make it an OK practice.

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#253

Post by account42 »

Arch-TK wrote: post #159
oefrha wrote: post #31

Earlier quoted context omitted.

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, inclu…

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 v…

I strongly disagree - I'd rather all my users filed their bugs directly on the upstream issue tracker for my projects so that I can get a proper view of what bugs are being encountered. If there are steps to reproduce then most of the time it will be a lot easier for you as the developer to just check if the bug still happens with the latest version than having the user or packager build it themselves. Don't expect users just have a build environment laying around or can quickly set one up. Don't expect that building the latest version is always easy on every distribution.

If its not easy to reproduce or if there are no reproduction steps then sure, ask for more information. It's also OK to refer to a distribution bug tracker if the user is not able to produce a useful report or if you suspect there is a packaging issue, but doing that for all reports of problemsx with distro builds, especially when using automation, is disrespectful of the time the user has spent on reporting the bug. So sure, you can do that (you don't owe users anything after all) but I think its rude and will only turn potental future contributors away. I'm definitely glad that that is not how most projects handle user reports.

If you are being overwhelmed by user reports then maybe you can find some dedicated people from your userbase that would be willing to help with bug triage?

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#254

Post by qayxc »

ok123456 wrote: post #240
qayxc wrote: post #232

Earlier quoted context omitted.

> Then why do all these bugs fall through the cracks on other platforms? Two main reasons: 1) Other platforms are primarily used by non-technical individuals who simply don't care about the OS and who more often than not are unable to tell the difference between bad software ergonomics, user error, and software bugs in the first place. 2) The Linux platform is built around the concept of OSS, where user participation…

It's not just the community mentality of the users. Just by raw numbers there are going to be more "technical users" running on other platforms because the number of Linux users is so vanishingly small. Most of the people trying to game on Linux are "non-technical" with regards to being able to debug random errors in some random binary. You can only really assume they have enough skill to put an Ubuntu image on to a…

> Just by raw numbers there are going to be more "technical users" running on other platforms

Observation bias. The vast majority of desktop users in 2021 are found in a professional setting (offices, etc.). Those users don't use computers at home, whereas the vast majority of Linux users do.

> You can only really assume they have enough skill to put an Ubuntu image on to a flash drive, boot it, and follow a few prompts.

I'd like to see some statistics on that. Gaming has shifted to consoles and gaming on PC has been the domain of MS Windows for decades. Survey¹ says that >96% of users are on Windows and the few Linux gamers (~1%) are just as likely to run Arch as Ubuntu (0.26% vs 0.29%).

The choice of using Arch over Ubuntu is a strong indicator in- and of itself that the user made an informed decision (e.g. is tech savvy as opposed to "insert media and click 'next' a few times).

> Not treating your users like morons and giving users actual feedback about why something crashed [...]

As I mentioned that's not up to the OS but to the software in question. Also you're contradicting yourself here: on the one hand you argue that users aren't morons and have technical knowledge, while on the other hand you assume they're basically trained monkeys that can flash an image and follow prompts.

Which is it?

1. https://store.steampowered.com/hwsurvey

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#255

Post by deeberl »

LongTimeAnon wrote: post #203

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

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#256

Post by efreak »

oefrha wrote: post #83
tyingq wrote: post #76

Earlier quoted context omitted.

Bug templates help, of course. But people do still just dump the wrong stuff in until the report is accepted. Like some kind of OS version in the App version field, for example. Or some ambiguous thing like "latest". Or copy/paste from an existing bug report from some other person. You can see this on many public repos.

> Like some kind of OS version in the App version field, for example. Oh, I would be grateful for even that. Often enough, the bug template is simply deleted, the last line of the error in non-debugging mode is pasted in along with a "doesn't work"; or just "doesn't work".

While I don't do this intentionally, I do use a native Android app (fasthub) to submit issues. So far as I know, there isn't any GitHub app that has support for issue templates. Occasionally I'll submit an issue without remembering to check for a template first, though I usually remember before actually submitting.

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#257

Post by account42 »

simion314 wrote: post #47
dotancohen wrote: post #37

Earlier quoted context omitted.

> What is the value of "is competent enough to copy paste commands from a wiki?". Because without that filter you are getting feedback from, at best, people who cannot even copy paste commands from a wiki.

That is still a pathetic filter , "I know to read and I know to copy paste", I still believer that the good reports are not from the copy-paste ,I run Arch to be cool group but from technical people that run Linux(any distro).

Being able to read and follow instructions is the main skill required to be a good bug reporter.

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#258

Post by account42 »

wheels wrote: post #243
thefr0g wrote: post #233

Earlier quoted context omitted.

> Yes, it is a VST plugin Shouldn't that be the easiest way to distribute audio software for linux? It's just a static shared library and maybe some data. > 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'm pretty sure they didn't mention pipewire as a replacement for vst or lv2 (or ladspa lol). It's…

> It's just a static shared library [...] No. First, "static shared library" is self-contradicting: libraries are either shared or static, not both. The longer answer is that plugins have to be compiled with the `-fPIC` flag to be loadable. The `-fPIC` flag basically says that it has relocatable symbols. You can't link against system-provided static libraries because they're never (by design) compiled with `-fPIC`. I…

> It might be possible for us to configure our build system to recompile every library we depend on as static and relocatable, but that'd be quite a bit of effort to set up.

Sounds like you already know the solution to your problems. Link all your dependencies into your plugin, hide all symbols except the plugin interface and base system ones and you can make your plugin distro-agnostic. If you depend on external shared libraries then yes, your interface to the system becomes a lot more complex and thereby brittle.

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#259

Post by account42 »

terafo wrote: post #121

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 th…

> 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/

Re: Despite having just 5.8% sales, over 38% of bug reports come from Linux

#260

Post by account42 »

mariusor wrote: post #158
5e92cb50239222b wrote: post #11

Earlier quoted context omitted.

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.

The value of the steam runtime is not in how well it runs for users, but that it provides a singular target for game developers. I'm not sure if you witnessed any discussions around why most game developers are not willing to port their games to linux. From what I've seen the main complaint is that linux is too fragmented and nobody wants to package a binary for X versions of glibc, Y versions of sound libraries, and…

> nobody wants to package a binary for X versions of glibc

You only need to build against the oldest glibc version you want to support - and the runtime does nothing to change that since you can't bunle your own libc (if you want any dynamic linking at all, which you need fro e.g. OpenGL/Vulkan).

> Y versions of sound libraries

The steam runtime makes sure that there is a libasount/libpulse* present so that your program can start if it links against those, but it does not provide anything for compatibility between them - that can be achieved by e.g. SDL or OpenAL Soft (which load them dynamically which means there is no problem if the libraries are missing and you won't even need the runtime). It's also ok to only support one audio system then then have users figure out the compatibility on their system (e.g. PipeWire supports the ALSA and Pulse ABIs).

> Z versions of graphic APIs

Same, the runtime ensures that a vulkan loader is present but does not actually do anything for compatibility. Both OpenGL and Vulkan also provide backwards compatiblity so you again just need to decide on a minimum version.

What the steam runtime mainly does is provide a bunch of libraries that are present on Ubuntu that games might link against so that everyone has them. Nothing stopping the games from shipping those libraries themselves though.

Post reply on HN