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.

  > 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

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.

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.

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).

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.

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.

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

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.

Why are Amex customers higher value? Is it because they're typically business cards rather than personal?

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.

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.