4 ms·

I think this can still be thought of as a "nightmare" for some developers. The mindset may be that the developers don't want users reporting bugs. They'd rather

I think this can still be thought of as a "nightmare" for some developers. The mindset may be that the developers don't want users reporting bugs. They'd rather the users passively tolerate the bugs. This way the developers don't need to put in the effort to fix them! These developers may prefer not to support Linux because they simply do not want to deal with sophisticated users.

mixmastamyk 3y ago
Eliminating your main source of paid work sounds like a bad idea, if you like to eat that is.
nightpool 3y ago
Obviously when you frame it like this it sounds insane, but the fact of the matter is that responding to support tickets and triaging bugs have a real, hard cost in $$$ spent. If supporting Linux platforms doubles your time spent responding to support requests and triaging tickets—even if you never fix an additional bug, it could very well be enough to entirely tank the profitability of adding Linux support, well above the value that any additional minor bugs they find might bring.
- hot_gril 3y ago
  They can deprioritize bugs coming from Linux users if they find the triaging by itself so hard, but at that point I doubt they have the bandwidth to fix Windows-reported bugs either. The original post seems more like the approach of managers who are disconnected from reality and gauge everything from some metrics. Bugs = bad, reduce bugs by any means necessary.
  - hot_gril 3y ago
    (Either that or the bugs really are Linux-specific, which is quite possible)
    - Arnt 3y ago
      I've worked on platform-independent code. Even if a bug is platform-independent, the report may well be platform-specific and difficult to reproduce. The real nature of the bug only becomes clear after analysis, and getting the right platform for the analysis may be so much work that the whole thing is impractical. "May be" doesn't mean "very rarely" either. It's sad, really. You may sit in front of your keyboard with an intuition that this bug affects lots of people and know that you can't really work on it, so how to you respond? Sad.
      - hot_gril 3y ago
        Having little experience with this, my question is, why not simply try to reproduce the ingame bug using Windows and throw it out if it can't be reproduced? Because at that point, I would categorize the bug itself as platform-specific.
        Arnt 3y ago
        Sometimes the reproduction instructions look as if they can be followed on another platform. I've done that. "Let me just try that quickly on my…" and bingo. But speaking generally, if a bug is that easy to reproduce on your usual development platform, you find it before shipping anyway. Trying to reproduce a bug by doing something different than what the customer did is a good way to waste time, in my experience.
        Arnt 3y ago
        Perhaps I should elaborate. One of my first really nasty bugs of this kind was platform-independent, in the sense that the fix affected all platforms. Once I had found the buggy code it was easy to reproduce it on my development workstation by constructing a more efficient reproducer. But it did not affect all platforms equally. With the hardware on my desk it led to a slow memory leak and would crash after very long time, on a particular customer's hardware it leaked all memory in an hour, and the customer had more memory than I. I don't remember why, maybe the different CPUs changed whether a race was lost/won? Anyway, I restarted often and could have gone a year without noticing the bug in my office, but even on the same platform as I personally used, customers would have infrequent crashes. So. Platform-dependent or not? It's hard to classify in those terms, don't you agree? And that's typical in my experience.
ThrowawayR2 3y ago
Linux is a "nightmare" for some games developers since its fans will rush to ascribe malicious motives to them for the slightest suggestion that there are problems with supporting it; case in point.
- Arnt 3y ago
  It's not linux that's a nightmare. It's setting up a platform that matches the user's well enough to reproduce and analyse the reported bug. Last week I had to set up a new debian with a combination of one really old package and one really new in order to work on a bug. Setting that up took more time than the bug itself. (The bug itself wasn't at all related to those packages or versions, BTW.)

mixmastamyk 3y ago

Eliminating your main source of paid work sounds like a bad idea, if you like to eat that is.

nightpool 3y ago

Obviously when you frame it like this it sounds insane, but the fact of the matter is that responding to support tickets and triaging bugs have a real, hard cost in $$$ spent. If supporting Linux platforms doubles your time spent responding to support requests and triaging tickets—even if you never fix an additional bug, it could very well be enough to entirely tank the profitability of adding Linux support, well above the value that any additional minor bugs they find might bring.

hot_gril 3y ago
They can deprioritize bugs coming from Linux users if they find the triaging by itself so hard, but at that point I doubt they have the bandwidth to fix Windows-reported bugs either. The original post seems more like the approach of managers who are disconnected from reality and gauge everything from some metrics. Bugs = bad, reduce bugs by any means necessary.
- hot_gril 3y ago
  (Either that or the bugs really are Linux-specific, which is quite possible)
  - Arnt 3y ago
    I've worked on platform-independent code. Even if a bug is platform-independent, the report may well be platform-specific and difficult to reproduce. The real nature of the bug only becomes clear after analysis, and getting the right platform for the analysis may be so much work that the whole thing is impractical. "May be" doesn't mean "very rarely" either. It's sad, really. You may sit in front of your keyboard with an intuition that this bug affects lots of people and know that you can't really work on it, so how to you respond? Sad.
    - hot_gril 3y ago
      Having little experience with this, my question is, why not simply try to reproduce the ingame bug using Windows and throw it out if it can't be reproduced? Because at that point, I would categorize the bug itself as platform-specific.
      - Arnt 3y ago
        Sometimes the reproduction instructions look as if they can be followed on another platform. I've done that. "Let me just try that quickly on my…" and bingo. But speaking generally, if a bug is that easy to reproduce on your usual development platform, you find it before shipping anyway. Trying to reproduce a bug by doing something different than what the customer did is a good way to waste time, in my experience.
        Arnt 3y ago
        Perhaps I should elaborate. One of my first really nasty bugs of this kind was platform-independent, in the sense that the fix affected all platforms. Once I had found the buggy code it was easy to reproduce it on my development workstation by constructing a more efficient reproducer. But it did not affect all platforms equally. With the hardware on my desk it led to a slow memory leak and would crash after very long time, on a particular customer's hardware it leaked all memory in an hour, and the customer had more memory than I. I don't remember why, maybe the different CPUs changed whether a race was lost/won? Anyway, I restarted often and could have gone a year without noticing the bug in my office, but even on the same platform as I personally used, customers would have infrequent crashes. So. Platform-dependent or not? It's hard to classify in those terms, don't you agree? And that's typical in my experience.

ThrowawayR2 3y ago

Linux is a "nightmare" for some games developers since its fans will rush to ascribe malicious motives to them for the slightest suggestion that there are problems with supporting it; case in point.

Arnt 3y ago
It's not linux that's a nightmare. It's setting up a platform that matches the user's well enough to reproduce and analyse the reported bug. Last week I had to set up a new debian with a combination of one really old package and one really new in order to work on a bug. Setting that up took more time than the bug itself. (The bug itself wasn't at all related to those packages or versions, BTW.)