This game is phenomenal, I can't stop playing. Intuitive, good UI, tons of fun. Thanks!
Is there a standard way of describing bugs? What resources/standards have people found useful to refer to when reporting one?
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 Linux-using developers fix the problem for me.
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?"
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.
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.
They should drop Linux support and save themselves the hassle.
> 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.
> 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.
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.
1. When I do this
2. Here is what I expect to happen
3. But instead, this happens
> 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].
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.
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.
Pleasantly surprised on all accounts :D
Perhaps other option is using cpp, and having UB that behaves differently in different compilers. But I doubt that as well
- 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!
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.
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.
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.
Why are Amex customers higher value? Is it because they're typically business cards rather than personal?
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.
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.)
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.
When precisely did this happen?
(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."
>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?
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...?
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.
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.
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...
> 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.
Other platforms are infantilized: "Oopsey doodle that crashed :(. Look for problem online? Oh no solution found. Sorry about that. Got it?"
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.
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?
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!
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.
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.
... 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.
Can you imagine anything like that with Windows or Mac OS? We have reports how Apple silences zero day researchers instead.
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.
- 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.)
(The only counter example I can think of at the moment is Samba, and guess what ... it interfaces with Microsoft products!)
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.
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.
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.)
Maybe. On the otherhand I heard similar things about Pulse and Wayland and a decade later they're still problematic.
"If I had asked people what they wanted, they would have told me 'A faster horse!'."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.
Depends on whether you feel selling people stuff they don’t need is ‘not right’.
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.
So I would expect that edge cases might be really relevant to mainstream use because everybody is trying to break the game.
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.
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".
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?
In the case when a user is not technically skilled enough to test for the bug in the latest version themselves they should go to the maintainer whose job it is to be able to do that.
> 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.
What? How is it disrespectful? They're helping their distribution and their distribution should be forwarding the bug onto you if it's not their fault.
In fact, if the distribution is aware of it then the user is more likely to get a hotfix sooner than if they go straight to you.
> 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.
It is actually how most old style open source projects operate. If you're happy to accept direct bug reports which are either already fixed in the latest version or which may be distro specific issues then go ahead. Please don't burden every other project with this kind of noise by making it clear that this is a project specific policy.
That's probably a part of it, but the real answer is because an Amex is a charge card, not a credit card, which means that whatever is spent on it MUST be paid off in full at the next billing cycle. The net effect of this, is that if your customers are shopping with an Amex, they're people who /have/ money, or in the case of business cards they are acting on behalf of an organization that has money. Without writing an expository essay, it seems to be simply true that those who are more affluent also have networks and can bring people by word of mouth if you meet their expectations.
The primary reason Amex customers are more valuable is because most Amex cards carry an annual fee, which only more affluent folks can afford.
The traditional American Express card, though, is a charge card and not-withstanding the new Pay Over Time "feature", requires the entire balance to be paid in full every billing cycle. The entire reason they're popular with businesses is it provides an easy way to effectively do Net 30 payment terms without having to deal with POs and invoicing.
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.
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".
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.
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 and not play find the bug with you.
The vast majority of users would not even be as nice as to email you saying there was a crash. They would just immediately complain on twitter or refund the product if it wasn’t resolved without any interaction.
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.
Summary :
Steps to reproduce :
Expected result :
Actual result :
Build/Version :
And a few more fields about platform, severity, etc. on Jira.Out of curiosity, what does deving for Warner Bros mean? Like working on their internal systems and stuff? Netflix integrations or something? Sounds cool, bet you get to see movies before they come out too!
I was working at their Montreal Studio. It's exclusively a video game studio. I was mostly working in QA on Middle-earth: Shadow of War.
Even if the game is technically developed by Monolith Productions, Warner Bros. Interactive Entertainment (WBIE) helps with their ressources (Artists, QA, Devs).
There's also alot of internal tooling for Builds automation, Automated testing / QA Aids tools, etc that is handled by WBIE as the game editor.
We didn't see movies before they got out but we had access to a 30-50 persons theater room that I was able to "rent" for free outside of business hours to watch movies with friends and show them the non-secure areas of the office. (Cafeteria (Free drinks!), gaming room, etc.))
I'm not really into commics but we had a room with thousands of comic books that we could take and read anytime we wanted (WB owns DC Entertainment).
I worked there 6-8 months when I was out of school before getting my first dev job.
Users tend to rename programs, even give them names of other programs. Our entire finance department can't wrap their heads around the fact that 'Oracle' is not a bookkeeping application. Worse, they are now convinced the new version is called 'fusion'. Oracle financials? Never heard of.
Same people also have a better idea of what might be causing the bug, how to get more information, logs, and so on.
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.
A developer invested time to support linux not necessarily for financial return but social capital returns in the form of more helpful QA feedback.
- Follow Bill Baue and the Reporting 3.0 folks - https://twitter.com/bbaue/status/1342101339120279552 - https://www.r3-0.org/wp-content/uploads/2020/12/r3-0-White-P...
- Joe Brewer on Multicapitalism and producing ecological flow: https://earth-regenerators.mn.co/posts/the-hidden-flow-of-re... skip to 16minutes for this model, references "the atlas of economic complexity" - https://atlas.cid.harvard.edu/ (bias: I sorta collaborate with Brewer on Earth Regenerators)
- Ethan Roland & Gregory Landua on 8 forms of capital : http://www.appleseedpermaculture.com/8-forms-of-capital/
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.
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 and direct feedback are an essential part of the ecosystem. Most OSS has bug tracking and Wikis that describe how to report a bug and quick release cycles (e.g. fast feedback from the user's perspective). Linux users make a conscious decision to use Linux and some level of involvement in the OSS community is often part of that decision.
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 flash drive, boot it, and follow a few prompts.
The software tools are just better for locating, reporting, and communicating these errors are just better on Linux. Not treating your users like morons and giving users actual feedback about why something crashed instead of writing out crash reports to disk that never get sent anywhere is apparently a more effective way of tackling software defects.
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?
I would actually expect that almost all of those people use Windows or MacOS for their local development.
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.
Too many customers run really old versions of code that need older versions of PHP and so on. We can't not provide them without losing the business. We do of course, make newer versions available.
The other fun one we periodically get is customers doing PCI scans or similar and getting warnings for out of date versions of OpenSSL, Apache, etc. Nope; just backporting showing the old version numbers.
And, perhaps other than knowing about permissions, you don't really need any Linux knowledge to use these hosts.
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.
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.
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
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?).
If it's good enough for my colleagues to submit tickets like this, it's good enough for me!
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 benefit would be for your standalone since it supports alsa, jack and pulseaudio clients and can get decent latency.
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`. 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.
As such, we have to link against shared libraries, and you can have conflicts with the host if it is also pulling in those shared libraries. Ardour, on Linux, specifically, in their own packages, pull in a bunch of non-system shared libraries that conflict with the system ones, which breaks our plugin. There are other shenanigans with other hosts.
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.
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.
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.
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.
> What is the value of "is competent enough to copy paste commands from a wiki?".
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.
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
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.
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.
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.
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.
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".
I'm a programmer and this is exactly what I do.
- 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;
Desperate for something to feed my jones, I snaffled my other sister's
abandoned flute. And wow! I was a natural...immediately better with it than
with the guitar I'd been hacking at for months. [...] This was delightful but
mystifying. All I'd had to do was learn to play a scale, and this amazing river
of music poured forth with barely an effort on my part. It seemed almost as
though my hands and lips had always known what to do, had been waiting for me
to pick up the flute. [...] I got these stunning rushes of pure timeless joy,
when my consciousness seemed to expand outwards from the limits of my skin to
fill the universe and I could no longer tell whether I was playing the music or
the music was playing me. Nor were these effects just going on inside my own
head. [...] I was walking home, idly puzzling over this peculiar incident, and
damn near fell over when I finally got it. That girl had been trying to cope
with a theophany; she had looked at me and seen a god. A particular god. And I
knew, suddenly, with utter shattering certainty, which one it was. And that it
probably was not the first time I had inadvertently triggered such an
experience, and would almost certainly not be the last. [...] Not that I took
any of it seriously as a description of the real world. It was an intellectual
chew-toy, perhaps at best a way of understanding the pathologies that prevented
human beings from living the infinitely more desirable life of reason and
science. Until I realized, finally, belatedly, what had been happening to me.
Until the Great God Pan reached out of my hindbrain and thundered "YOU!". And
his gift is music and his chosen instruments the pipes and flutes. And his, too
the power of joy; magic so strong that when it flowed out of me, even before I
knew what I was doing, it amazed people into awe and incoherence and poetry.
[...] (And, oh, yes. The first time I handled a set of pan-pipes I could play
them. Fluently. Effortlessly. And knew I could before I touched them.)
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).
I bet that a vanilla LTS where you only update for security reason is more stable and risk free.
If you have the skills I don't need to directly recommend it to you, you already know it.
If you don't know it you likely don't have the necessary skills.
Through by being opinionated about the choice of packages and way of setup and adding a QA Team, more CI and slightly delayed (non-security) updates (like 1 day or two) you probably could produce a grate experience even for casual users. Hm, but then as a company producing a custom Linux distro is rarely worth it and often special purpose enough to not care about the benefits this approach would bring.
(1): But still indirectly advertise it.
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.
So installing old packages is trivial (iff you had them installed before).
You would at least have to block the AUR on such a distro, there are too many patched kernels/packages there and too many recommendations to install X from the AUR.
Then you have the GUI chnanges in apps, it is too frustrating to make the user learn weekly some new GUI workflow because app X decided to improve stuff.
Arch has a great use case for people that actually need latest stuff and for the people that just really want the latest stuff to satisfy their appetite of checking new features.
I don believe this is true for ANY package(like install an old KDE4 app on your KDE5 system)
Like just a few days, weeks or continue to use a older no longer maintained version of a package because you don't like the new version.
I (now) guess you mean the later in which case, yes it's not trivial as it's not really supported by anyone anywhere. Neither the original software developers (which replaced it with a newer version), the package maintainers/Linux distro (which also moved on as the older version doesn't get updates), other packages interacting with ti (which expect a newer version), etc.
So while it might suck, I would recommend to simply not do so as it's not worth the risk and headaches it brings you. At least not as long as you don't find enough people to do a fork and maintain that fork.
Still undoing you last update is often as simple as just installing the package from the cache, and then you would need to pin it/make pacman ignore it (and then it probably will brake sooner or later depending how much it relies on specific system libraries in specific versions being available).
As an example we are a group of people with some eye disabilities but not completely blind, we use an old application Jovie for KDE, this app was removed from latest KDE and replaced with something with lot less feature. We are compiling this old app from source and at least for this old LTS distros we can get both Qt4/KDE4 and Qt5/KDE5 libs installed. So imagine people with disabilities doing an update one day and poof your must have thing is gone and you can't use your system anymore and some person on the internet will tell you that you are doing it wrong and should not use anythng else then the latest version of stuff because the developers do not support old stuff.