[HN Gopher] Despite having just 5.8% sales, over 38% of bug repo...
___________________________________________________________________
Despite having just 5.8% sales, over 38% of bug reports come from
Linux
Author : otreblan
Score : 925 points
Date : 2021-10-24 14:14 UTC (8 hours ago)
(HTM) web link (old.reddit.com)
(TXT) w3m dump (old.reddit.com)
| [deleted]
| dopu wrote:
| 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?
| [deleted]
| tyingq wrote:
| 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.
| oefrha wrote:
| 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.
| Arch-TK wrote:
| 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.)
| ajvs wrote:
| 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).
| oblio wrote:
| Congratulations for acting exactly like his bad bug
| reporters.
| tyingq wrote:
| 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.
| oefrha wrote:
| > 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".
| oefrha wrote:
| > 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
|
| Of course I do that, and I said so. I do everything I can
| to make it trivial for users to give me all the information
| I need. They just don't give a shit. Some people won't
| read.
|
| (And the extra irony here is that my original comment
| already mentioned issue template asking for everything, yet
| you didn't read it and jumped in to tell me "don't blame
| the user".)
|
| Edit: I should also mention that this is FOSS work. I'm
| doing free support for these users who supposedly shouldn't
| be blamed for wasting my time.
| chias wrote:
| 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.
| Moru wrote:
| There are even a few php users trying to run windows
| server...
| 5e92cb50239222b wrote:
| Most of the Wordpress developers I know are Windows users. (I
| don't know too many of them, but still.)
| tyingq wrote:
| 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.
| mAritz wrote:
| I think that's the issue though: You're seeing "Linux
| users" that only use Linux on their servers because they
| are somewhat forced to do so.
|
| I would actually expect that almost all of those people use
| Windows or MacOS for their local development.
| lixtra wrote:
| Keep in mind that WP has a vast installation base, so
| your local sample is not necessarily representative. I
| only know WP admins that a fairly comfortable with Linux
| and use it on a daily basis.
| grawprog wrote:
| And those hosts often are not using up to date packages
| and don't even have up to date security fixes at times.
|
| I recently moved a wordpress site I was working on from a
| local dev setup onto a live bluehost server and was
| immediately hit with a bunch of out of date package
| warnings. As the customer was using some cheap shared
| hosting service, there wasn't much I could really do
| about it.
| tyingq wrote:
| That's sort of funny, as one of the remaining few value
| pitches for something like Bluehost (versus a $5/month
| vps) is _" somebody else does apt-get update && apt-get
| upgrade for you"_.
| donatzsky wrote:
| Not a lot of Windows in the shared hosting space. And what
| little there is tends to be more expensive, from what I
| have seen.
|
| And, perhaps other than knowing about permissions, you
| don't really need any Linux knowledge to use these hosts.
| midasuni wrote:
| Back in 1996 I had a website running on a shared unix of
| some sort. I could barely upload files in the correct
| binary/ascii mode, or copy and paste a "chmod" command.
|
| My 1996 self would be the exact nightmare wordpress user
| today, although I guess I wanted to learn even though I
| didn't know what I was doing, which is different to many
| comments I've seen on places like GitHub.
| dbg31415 wrote:
| 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?"
| terafo wrote:
| 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.
| Timpy wrote:
| 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?
| AdmiralAsshat wrote:
| 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."
| ajsnigrutin wrote:
| 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.
| atomicnumber3 wrote:
| 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.
| tyingq wrote:
| 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.
| rubyist5eva wrote:
| You can literally just do `wsl.exe --install` on the newest
| builds of Windows 10 and it enables the hypervisor feature
| and downloads Ubuntu in one command. AFAIK it's the same in
| Windows 11 (I'm still on 10 and don't plan on upgrading for
| a few years at least).
| tyingq wrote:
| Yes, as I mentioned, they made it easier only very
| recently. 09/27/2021, actually. And you still have to
| open cmd.exe or powershell with "run as admin". It is not
| as easy as installing, say, GitBash.
|
| Also, some things are still under documented, or hard to
| do. Like that "wslg.exe" can be used to make Windows
| shortcuts to launch graphical programs. Or how to make
| various systemd things work (pid 1 is not systemd), and
| so on. Or how to add all the Windows fonts to the Linux
| distro. I'm saying they will likely improve all this over
| time.
| simion314 wrote:
| >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.
| Noughmad wrote:
| > What is the value of "is competent enough to copy paste
| commands from a wiki?"
|
| Very high actually. You can tell them things like "please
| run in debug mode" or "please run with this command line
| flag" or even "please change this setting and retry". Even
| more basic, you can tell them to restart the game/program,
| or to reboot their computer, and then you can trust that
| they actually did it.
|
| When dealing with a regular computer user, you can't assume
| any of these things.
| simion314 wrote:
| From my real world experience on making desktop apps you
| want to get all the bug reports from all users, so you
| need to make it "1 click", This means add a menu /button
| to submit a bug report, then you popup a form where user
| fills stuff, you also send the log file where you
| collected info live OS version and other useful stuff
| plus the crash logs).
|
| Same if you need to have the user run in debug mode you
| make it 1 click to enable/disable debug mode, usually
| though developers don't work directly with customers so
| then they don't put the effort to streamline the
| collection of quality bug reports.
| dathinab wrote:
| There is a even simpler reason:
|
| A lot of people gaming of Linux are either software
| developers or system administrators.
|
| People buying a "Linux gaming system" are the rare
| exception, instead it's often "buy a powerful computer for
| use case X, and hey why not go for a slightly
| better/tweaked spec and also also game on it".
| matheusmoreira wrote:
| > buy a powerful computer for use case X, and hey why not
| go for a slightly better/tweaked spec and also also game
| on it
|
| I'm a programmer and this is exactly what I do.
| pxc wrote:
| > What is the value of "is competent enough to copy paste
| commands from a wiki?".
|
| For a while, NixOS had examples throughout its manual, in
| the installation section, which did not together form a
| usable installation script, or even snippets within one. If
| you read the prose in the manual and used the examples _as
| examples_ in the context of the prose, you 'd be fine. But
| if you blindly copied and pasted all of the example
| snippets, the install would not complete.
|
| You can watch someone 'get filtered' here:
| https://www.youtube.com/watch?v=QujRHErFG4w
|
| The documentation has since been revised to make the
| examples copy-paste safe, which is a change I endorse
| because I see NixOS is a tool whose adoption I want to see
| grow and whose community I want to welcome and educate
| people rather than function as a super duper cool kids club
| whose that makes me feel special inside. But it does show
| how you could up the ante from the Arch case, if you really
| think exclusionary obscurantism is the way forward for
| projects you care about.
| dotancohen wrote:
| > 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.
| dathinab wrote:
| You might be surprised how many people are out there
| which can't even read a wiki close enough to follow
| instructions in it.
|
| Plus in my experience a lot of Arch users don't just
| "copy past instructions" they also somewhat understand
| why this instructions are needed, the Arch Wiki is grate
| as a resource for setting up things when you understand
| what you do, but it's often terrible when you just want a
| step by step guide.
|
| Any way the main benefit of Arch is that it's close to
| stable upstream repose, instead of sometimes lacking not
| just month but even years behind wrt. the version of
| libraries they ship.
| simion314 wrote:
| >Any way the main benefit of Arch is that it's close to
| stable upstream repose, instead of sometimes lacking not
| just month but even years behind wrt. the version of
| libraries they ship.
|
| There is a downside that most Arch users omit
| intentionally, when you get latest GNOME/App with the
| cool new bug fixes and cool new features you also get the
| new not cool bugs and the new redesign/feature removal.
| This can cause the system not to boot if the
| kernel/graphics driver is updated in incompatible ways.
|
| LTS distros with years behind features is in many casea a
| feature many appreciate. 2
| heywire wrote:
| I've been using the Arch Linux Archive as a way to stick
| with a known stable system for a few weeks until I have
| time to dedicate to a system upgrade and correcting any
| issues that arise.
| simion314 wrote:
| How do you undo an app or subsystem after an update you
| don't like?
|
| For example I upgrade my IDE but not in place, I keep
| previous version just in case the new one is buggy or
| they again moved shit around. For my main system I am on
| LTS and I upgrade if there is a need and not to get high
| on version numbers. For example I tested new versions of
| kernels and video drivers and end up on what feels right
| for me and stopped there. Sometimes the new video driver
| is more unstable then the older ones so I would never do
| a driver update without having a good reason and time to
| evaluate it.
| dathinab wrote:
| Arch keeps a package cache of old packages, if you want
| to forever.
|
| So installing old packages is trivial (iff you had them
| installed before).
| dathinab wrote:
| I've been using Arch since ~8 years and at least for me
| updates breaking stuff is rare, and every time it happens
| there was a simple easy work around the problem (like
| downgrading for a day or two at which point the bug was
| fixed).
|
| Through without question a major reason why the (few)
| problems I did ran into haven't been a problem was due to
| my understanding of Linux.
|
| The is the misconception that Arch is bleeding edge, it's
| not. It's the latest _stable_ releases of the software it
| composed of. And at least for my use cast the amount of
| headache it reduces by doing so far outweighs the amount
| of problems I ran into (which are in my experience few,
| and _iff_ you have the necessary skills normally easy to
| work around).
| def_true_false wrote:
| Arch probably has a lower share of GNOME users than your
| average distro.
| NullPrefix wrote:
| Arch Wiki is so great enough that even users of distros
| other than Arch read it.
| simion314 wrote:
| 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).
| rpmisms wrote:
| I'm assuming you don't generally do front-end work,
| because many many users are complete [insert PC word for
| zero capacity for rational thought].
| simion314 wrote:
| I do interact with customers, but I would rather get a
| bug report from a Kubuntu users that knows the difference
| between a compiler and a linker then from a 12 years old
| that managed to copy paste instructions into a command
| prompt.
| yjftsjthsd-h wrote:
| The bar can be as low as it wants to if it effectively
| filters people out. It's like how fizzbuzz is a terrible
| stupid test until you realize the shocking number of
| people who claim to be developers but can't pass it.
| simion314 wrote:
| We would need to do a rigorous test though to see if this
| low bar is significant, you would have 4 groups of people
|
| - Windows tech people(c/c++ developers) - Linux tech
| people(c/c++ devs and sys admins) - Arch non tech people
| that copy pasted instructions - any other OS or distro
| non tech people
|
| then see if the Arch copy paste-rs are closer to non tech
| people or closer to tech people. The assumption is that
| since they can read instructions would create better bug
| reports, but is also possible they would be over
| -confident elitist-ic dudes that use weird packages and
| broke the program with their copy pasting of commands and
| installing garbage from AUR;
| [deleted]
| matheusmoreira wrote:
| > I know to read and I know to copy paste
|
| You'd be surprised. I've _seen_ many arrogant users try
| to install Arch and fail because they were literally
| incapable of reading and understanding the simple
| instructions written on the Arch Wiki. Even technical
| users of other distributions. Sometimes they use an
| installer and manage to get a working system with no
| effort... Only for it to stop working because they failed
| to read the news and some update required manual
| intervention. If I remember correctly, users are required
| to provide pacman output as a form of CAPTCHA in order to
| create an Arch Wiki account. They must prove they
| installed Arch in order to edit the wiki.
|
| A certain degree of elitism is great, no matter the
| community. Arch Linux users are expected to be
| responsible for their own systems, it's expected that
| they will take care of it and maintain it. People who
| can't or won't do this are better off using something
| else.
| yeetaccount wrote:
| For someone to find the wiki, read it and then attempt to
| solve their problem in a rudimentary fashion gets you
| towards the tail end of the bell curve. They might even
| follow up with you if you have questions.
| simion314 wrote:
| Nah, is super easy to find the Arch wiki and the install
| instructions, Arch users will push you hard to it so is
| impossible not to find it, maybe you might find some
| honest person though to explain the downsides too.
| terafo wrote:
| Yet, something like 95% of all desktop users can't do
| that. You, presumably, disproportionally interact with
| tech people. Typical office worker might encounter
| problem that requires terminal once in a year at which
| point sysadmin is called. And it`s not only about reading
| and copy pasting it's about ability to devote pretty
| large amount of attention to a task.
| [deleted]
| swalls wrote:
| 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.
| giuliomagnifico wrote:
| Just for kidding but... do you think windows users are able to
| make/know what is it a bug report?
| terafo wrote:
| 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).
| qayxc wrote:
| For most AAA titles the reason is simply 3rd-party DRM and/or
| Anti-Cheat not working on Linux.
| milesvp wrote:
| 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.
| da39a3ee wrote:
| 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 :)
| gizmo686 wrote:
| 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).
| rpmisms wrote:
| 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!
| lmeyerov wrote:
| 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!
| wheels wrote:
| 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.)
| rpmisms wrote:
| 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.
| yjftsjthsd-h wrote:
| 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.
| wheels wrote:
| 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.
| yjftsjthsd-h wrote:
| That is unfortunate; it sucks that the cost of WONTFIXing a
| ticket isn't zero:\
| edflsafoiewq wrote:
| 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...
| yjftsjthsd-h wrote:
| I mean, "Linux" isn't enough to target, and in all
| fairness, if they say it's for Ubuntu then that's what they
| support. One would hope that they do _say_ they 're
| targeting Ubuntu, of course.
| wheels wrote:
| What you may be missing is that that comes from necessity
| -- again, for an app like ours, 1% of our users are on
| Linux. Producing packages for Ubuntu along takes about as
| much time as producing for Windows and macOS, where almost
| all of our users are.
|
| Testing and packaging for, say, the top 5 distros would get
| the effort-per-user to an even crazier extreme -- we'd
| literally be at the point that supporting a user on Linux
| takes 200 times more effort than supporting a user on
| Windows. You either need a very large number of users, or a
| very large value per use for that to make sense.
|
| For non-OSS projects, most of the time the smart decision
| is just not to support Linux. I've worked at other pro-
| audio companies, and they had Linux versions internally
| that they didn't release because of the support costs.
| emersion wrote:
| Packages aren't supposed to be submitted and maintained by the
| developers themselves. The distribution maintainers and
| community is supposed to do it.
| wheels wrote:
| That only works for open source packages.
| oblio wrote:
| Ah, I know that one!
|
| Easy! Just make it open source and get rid of your
| livelihood. Make it open core so people will hate you just
| as much (bonus points if your software can be ripped off by
| a hyperscaler) or go Red Hat and be 100% open source and
| basically turn into a consultancy which is not what a lot
| of people want to do with their lives.
|
| I'm just being sarcastic, in case anyone was wondering.
| smoldesu wrote:
| 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.
| wheels wrote:
| 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.)
| AnIdiotOnTheNet wrote:
| > 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.
| hdjjhhvvhga wrote:
| I wonder how many people will read just the headline, think, "I
| knew it!" and move on without actually reading this insightful
| article.
| ChrisMarshallNY wrote:
| 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...
| godelski wrote:
| 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.
| ChrisMarshallNY wrote:
| Agreed. Like Henry Ford is quoted as saying:
| "If I had asked people what they wanted, they would have told
| me 'A faster horse!'."
| godelski wrote:
| Yeah and it takes skill to distill what they actually want
| out of that comment. People don't want a faster horse, they
| want a faster method of transportation. This is easy to
| miss, especially the more technical jargon people use when
| explaining what they want.
| gwern wrote:
| 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...?
| shultays wrote:
| I am more impressed by 5.8% of sales being from Linux, it was
| less than a percent in my experience
| wly_cdgr wrote:
| 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
| dotancohen wrote:
| 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.
| davidgerard wrote:
| > Then they changed bug trackers - twice - and all that is
| lost.
|
| When precisely did this happen?
| terafo wrote:
| 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/
| oblio wrote:
| https://www.jwz.org/doc/cadt.html
|
| Copy paste the link. Or:
|
| > I'm so totally impressed at this Way New Development
| Paradigm. Let's call it the "Cascade of Attention-Deficit
| Teenagers" model, or "CADT" for short.
|
| > It hardly seems worth even having a bug system if the
| frequency of from-scratch rewrites always outstrips the
| pace of bug fixing. Why not be honest and resign yourself
| to the fact that version 0.8 is followed by version 0.8,
| which is then followed by version 0.8?
|
| > But that's what happens when there is no incentive for
| people to do the parts of programming that aren't fun.
| Fixing bugs isn't fun; going through the bug list isn't
| fun; but rewriting everything from scratch is fun (because
| "this time it will be done right", ha ha) and so that's
| what happens, over and over again.
|
| In your case, replace version "0.8" by "new bug tracker" or
| "new bug handling process".
| [deleted]
| voakbasda wrote:
| 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.
| wott wrote:
| 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.
| reginold wrote:
| 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.
| croes wrote:
| 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.
| qayxc wrote:
| 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.
| thrwyoilarticle wrote:
| 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.
| AnIdiotOnTheNet wrote:
| > 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.
| wildrhythms wrote:
| 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.
| cs702 wrote:
| 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._
| necovek wrote:
| 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
| matheusmoreira wrote:
| 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!
| whateveracct wrote:
| Huge amount of work they _do for us_
| dylan604 wrote:
| Marketing/PR depts never see it that way. They open up new
| tickets, and that's the metric they care about. Not
| justifying it, but marketing depts rarely get it right.
| ghostwriter wrote:
| Marketing of Facebook was of no use when Facebook was
| laying flat not so long ago. It shows which department
| should really have a definitive voice in product metrics.
| woolion wrote:
| 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.
| [deleted]
| programmarchy wrote:
| 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.
| marcodiego wrote:
| Conclusion: want good testing and bug reports of your game?
| Support linux.
| css wrote:
| 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.
| bluepizza wrote:
| Even if someone is not attempting to break the game, they
| might accidentaly hit those rare edge cases.
|
| Of course, you could infer the usefulness of the increased
| volume of feedback from the fact that a game author is
| extremely happy about it.
|
| Overall, I don't see any particular problems with having
| reported issues. We definitely don't pay cloud storage per
| open issue or anything like that. Initial assessment of a
| bug report is not particularly difficult either.
|
| I'm not sure if your concerns translate to actual negative
| impact.
| perl4ever wrote:
| I'm not a gamer, but from what I've read, the whole
| industry has been transformed by the incredible lengths
| people go to, to cheat.
|
| So I would expect that edge cases might be really relevant
| to mainstream use because everybody _is_ trying to break
| the game.
| freedomben wrote:
| FTA it sounds like basically all of them were normal
| gameplay that affected all platforms. only 3 were linux
| specific.
| pixl97 wrote:
| Depending on what kind of game you have, those exotic edge
| cases can come to be the dominant behavior in games,
| particularly multi-player where slight advantages can lead
| to some players dominating every one else.
| Gigachad wrote:
| 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.
| octorian wrote:
| But not analytics that are too good, or certain people will
| write a lot of inflammatory articles about how your
| software is nothing but evil spyware.
|
| Seriously, though, having a robust and automatic crash
| reporting system very much helps track down bugs you're
| never going to get a good report on or be able to directly
| reproduce.
| b0rsuk wrote:
| This was my hunch, and I just _wanted_ it to be true. I 'm very
| pleased it turned out to be that way.
| JeremyNT wrote:
| 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._
| reginold wrote:
| 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"
| lordnacho wrote:
| Makes total sense. You're unlikely to use Linux if you're
| not something of a power user, at least. I would guess
| there's a lot more developer type people who use Linux, and
| they are the people who appreciate a good bug report.
|
| Same people also have a better idea of what might be
| causing the bug, how to get more information, logs, and so
| on.
| atomicnumber3 wrote:
| They're also probably more used to the development
| process. With proprietary software, if you don't pay for
| a support contract, you basically can't submit a bug
| report - not really. You just ignore the bug and hope
| it's fixed in later versions.
|
| This applies to big AAA games too, so games aren't
| necessarily special.
|
| But indie games are in a weird spot where:
|
| 1. They're clearly artists. Nobody who want to make tons
| of cash becomes an indie game developer. If you have the
| aptitude to grind through the docs and make a game, you
| have the aptitude to grind leetcode and get a comfortable
| job somewhere that pays benefits and cash. And since
| they're artists, and they're making games, people
| empathize deeply with them.
|
| 2. They get a bit of a pass on the whole free software
| zealotry thing. I'm sure some people are still hard-line
| about it, but like, if I had to rank software in terms of
| freedom-threat-if-proprietary, something like Office or a
| compiler and towards the top, and Valheim is rather
| closer to the bottom.
|
| 3. They really have to listen to their players to
| survive, so they end up operating a lot more in the open.
|
| So they end up looking a lot more like an Open/Free
| project than you would expect.
| leeoniya wrote:
| more likely s/linux/developers, which i suspect represents the
| majority of linux users
| Kye wrote:
| 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.
| FpUser wrote:
| >"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.
| aendruk wrote:
| Interpreted literally it's a reasonable question: "What
| process should I follow when I encounter a problem?"
| Andrew_nenakhov wrote:
| I don't hold myself and frankly answer that my crystal ball
| is on scheduled maintenance today.
| andi999 wrote:
| So when will your crystal ball be ready, could you then
| asap adress the issue? Also keeping spare crystal balls
| would be really helpful.
| Andrew_nenakhov wrote:
| We are a small company supporting a free opensource
| product, we can't afford spare crystal balls. Even the
| one we have was bought on a secondary market, warranty
| expired in late 14th century.
| jraph wrote:
| "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.
| justicezyx wrote:
| God damnit... Clickbating is ruining any shred of useful
| information...
| shultays wrote:
| 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
| freedomben wrote:
| 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).
| dv_dt wrote:
| 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.
| stjohnswarts wrote:
| maybe alpha, beta level you gotta be on all platforms.
| godelski wrote:
| Well that might be one way to _accelerate_ your dev process.
| elliekelly wrote:
| 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.
| bedobi wrote:
| 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.
| rnotaro wrote:
| Yeah, that was basically most of the bug template we were
| filling when I used to work QA at Warner Bros. Games.
| Summary : Steps to reproduce : Expected
| result : Actual result : Build/Version :
| And a few more fields about platform, severity, etc. on
| Jira.
| skeeter2020 wrote:
| 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!"
| edflsafoiewq wrote:
| Conversely I think you should generally write the smallest
| amount of text you can. It maximizes the chance someone
| else will actually read it.
| codetrotter wrote:
| I sometimes try to follow the journalistic reporting way
| of writing. (Not the clickbait style mind you.)
|
| So I start it off with a few brief paragraphs of text
| explaining what I did, what happened and what I expected
| to happen. Each paragraph only a couple of sentences
| long.
|
| Then below that I fill in with more details.
|
| Of course this still means that if you glance at it you
| still see a lot of text and may not bother reading. But
| my hope is that if by chance the recipient does read the
| first few paragraphs then it will provide the necessary
| motivation to either read on or to begin investigating on
| their own.
| stjohnswarts wrote:
| It's best to do something like
|
| 1. config and versions
|
| 2. the bug (failure to see expected results
|
| 3. how to reproduce in as simple terms as possible
|
| 4. any data such as screen shots, core dumps, logs, etc
| blackearl wrote:
| 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.
| ognarb wrote:
| https://community.kde.org/Get_Involved/Issue_Reporting This
| one is pretty good
| ArloL wrote:
| I can recommend
| https://www.chiark.greenend.org.uk/~sgtatham/bugs.html
| [deleted]
| kens wrote:
| It's interesting to compare that guide "How to report bugs
| effectively with ESR's "How to ask questions the smart way"
| [1]. They both cover similar material, but the styles are
| extremely different. The latter is rather hostile to the
| reader: "If ... then _you_ are one of the idiots we are
| talking about. " "If you decide to come to us for help, you
| don't want to be one of the losers." It's also heavy on "us
| vs them", how _we_ are experts and you need to treat us
| properly.
|
| You know, it just occurred to me that the "How to ask
| questions" document is targeted as much at hackers and how
| they should maintain their "standards" than at users who
| are asking questions. For example, the document has
| approving examples of "logically impeccable but dismissive"
| hacker answers; these make more sense as instructions on
| how a hacker should respond than as something relevant to a
| user.
|
| I guess my point is that I had read the "How to ask
| questions" document for decades and viewed it as an
| objective document, not realizing how arrogant and
| "gatekeeping" it is.
|
| [1] http://www.catb.org/~esr/faqs/smart-questions.html
| _dain_ wrote:
| I agree, that "how to ask questions the smart way"
| article always left a bad taste in my mouth. Perhaps
| there should be a "how to answer questions" companion
| piece.
| LambdaComplex wrote:
| esr seems to have a pretty big ego, just based on his
| writings. (e.g. at one point he declared that he can tell
| if someone is smart or not just by looking at them)
| B1FF_PSUVM wrote:
| Strange, he's old enough to have watched the first TV run
| of Lt. Columbo ...
| fao_ wrote:
| He actually at one point wrote that he was a
| reincarnation of the god Pan, so he has/had a very
| literal god complex, too. It's such a shame that he was
| the person to interpret hacker culture for those of us in
| the future, because he's hardly a good lens
| elliekelly wrote:
| Thank you! I'm definitely guilty of mongoose-ing and
| diagnosing in my bug reports so this is very helpful!
| jraph wrote:
| > diagnosing in my bug reports
|
| It's probably fine, if you put it in a separate section,
| clearing indicating that you are guessing.
|
| At work we have an optional "diagnostic" section in our
| ticket template, mainly intended for the team, but I'd be
| happy to see a user try to fill it. At worse it's
| harmless, at best it gives the actual reason, somewhere
| in the middle it can give ideas even if it is wrong.
| krisoft wrote:
| > At worse it's harmless
|
| I wish. It happens very often that such speculation
| derails the whole investigation. It really shouldn't, but
| people are people. If the title of the bug report says
| that the foobar is broken it might take weeks until
| someone realises that they were wrong and actually the
| problem is in the frobnicator which feeds the foobar.
|
| Especially when because of this we assing the
| investigation to the wrong team. The foobar people don't
| want to appear as if they don't take the bug seriously,
| but all they check everything looks normal on their side.
| WalterBright wrote:
| "Just the facts, Ma'am"
|
| https://www.youtube.com/watch?v=v4LPkmGO5Cc
| westurner wrote:
| From "Post-surgical deaths in Scotland drop by a third,
| attributed to a checklist"
| https://westurner.github.io/hnlog/#comment-19684376
| https://news.ycombinator.com/item?id=19686470 :
|
| > _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]https://github.com/stevemao/github-issue-templates _
| drdrey wrote:
| Use this template:
|
| 1. When I do this
|
| 2. Here is what I expect to happen
|
| 3. But instead, this happens
| bentcorner wrote:
| 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 been surprised more than once when
| something that I thought was incredibly complex only
| required a few steps. And also been surprised when a
| complex repro was actually complex (e.g., if I drag quickly
| it works, but if I drag slowly it doesn't? what?).
| toomanybeersies wrote:
| Ugh no thanks, I'll just send them a screenshot and say
| "it's broken, please fix this!"
|
| If it's good enough for my colleagues to submit tickets
| like this, it's good enough for me!
| dotancohen wrote:
| ...4. And this is my software version and Linux distro.
| input_sh wrote:
| Also useful to run the app from the terminal, replicate
| the bug, and see if any logs pop up.
| dylan604 wrote:
| Think about what you would want to know if someone was
| reporting the bug to you. Provide at least that much
| information.
| brtknr wrote:
| Appreciate the old reddit url, so much more readable imo.
| cromka wrote:
| Interview with the author, mostly touching the Linux development
| of the game: https://www.gamingonlinux.com/2021/05/an-interview-
| with-kode...
| bryanrasmussen wrote:
| 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.)
| WalterGR wrote:
| 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."
| roofwellhams wrote:
| That indicates that Linux it's very far away from being
| mainstream
| noisy_boy wrote:
| > 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!
| Procedural wrote:
| 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.
| FastEatSlow wrote:
| 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.
| michaelpb wrote:
| 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
| gpm wrote:
| 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.
| 5e92cb50239222b wrote:
| 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.
| mariusor wrote:
| 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 Z versions of graphic APIs. Having the
| steam runtime to target solves all of these issues, even if
| it doesn't represent _the best_ that a user can run on
| their individual configuration.
| mrRandomGuy wrote:
| talk about missing the forest for the trees! _goddamn_
| baybal2 wrote:
| Most Windows users don't even know what a bug report is.
| guscost wrote:
| Yep, sampling bias.
| zoomablemind wrote:
| > 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.
| peey wrote:
| the titled should be updated to say "the Linux community" at the
| end, as on the original page
| otreblan wrote:
| The original title was too long
| ok123456 wrote:
| 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?"
| qayxc wrote:
| 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.
___________________________________________________________________
(page generated 2021-10-24 23:00 UTC)