>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.
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.
>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
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).
Tbh. I would never directly(1) recommend arch to anyone for a simple reason, it requires some linux/unix skills to be worth it.
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.
I don't think a rolling release will ever work for casual users, there are too many configurations of hardware and things you might not know people are using, some package update could affect someone printer and you cost this person a job opportunity.
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’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.
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.
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).
I disagree, when you release a new version of something distros like Debian or Ubuntu will backport the security fixes but not backport the new features and the new bugs.
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.
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).
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.
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.
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;
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.
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.
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.
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.
> 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.
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.
> 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.
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".
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.