This article is an updated version of a reddit post with a similar title written by u/zendeavor.
Have you tried asking for Arch related help and found that the community was "unfriendly" and "unhelpful"? Only telling you to "RTFM: Read the Friendly Manual"? Then this article may be helpful to you.
So after seeing some cool screenshots in /r/unixporn you got interested in Arch? Then welcome! Arch is the perfect distribution for giving full control of your system and customizing it exactly as you want.
Is it your first time using linux? If yes, then you've chosen a fantastic user-centric distribution from which to build a strong foundation of knowledge and experience. That was my case when I started.
If you've already used linux, was it Ubuntu or Ubuntu-based? If yes, be ready to relearn from scratch how computing works in a linux environment.
But before you start customizing your system into a hand tailored environment for your needs, there's a couple of things you need to know:
Whereas many GNU/Linux distributions attempt to be more user-friendly, Arch Linux has always been, and shall always remain user-centric. The distribution is intended to fill the needs of those contributing to it, rather than trying to appeal to as many users as possible. It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems.
Arch is a community project. It exists because of the package maintainers, support staff, and everyone else who contributes to the project.
[…] Arch's developers are volunteers and active contributors will often find themselves becoming part of that team. Archers can freely contribute packages to the Arch User Repository, improve the ArchWiki documentation, provide technical assistance to others or just exchange opinions in the forums, mailing lists, or IRC channels.[…]
If participating in such a community and embracing the Arch Linux Principles is something you're excited about, then Arch is the right distribution for you. Otherwise, don't be surprised if members of the community make you feel unwelcome.
Proactively seek to give of yourself and to bring only benefit to your peers and community.
Be sure to check our Code of Conduct before interacting with the community.
But exactly because our community is filled with people with awesome techinical skills and are doing this job in their spare time and for free, we have our own principles for respecting each others time.
If you've been told to RTFM: Read the Friendly Manual when asking for help, it's not necessarily because the person who told you that didn't want to help you, it's because we have an awesome wiki and very well kept manuals.
Similarly as it is with Arch, most of the linux eco system is built upon open source software, most notably, the linux kernel itself. And most of that software is maintained by volunteers. Because those volunteers do this in their spare time, choosing a documentation method should be done with those constraints in mind.
Text based documentation is easy to do and easy to update. Ideally we'd have video tutorials and detailed blog posts with screenshots for every tool in the main repositories. But it's not hard to see how that would be unfeasible to maintain for developers.
Tip
When reading the whole manual is too much, use tldr. It gives you quick examples on how to use the tool in question
Using text based documentation also allows us to centralize our information. Giving personalized help for everyone, when most problems users have with a specific tool tend to be very similar, would be a very inneficient use of our time. Instead, we keep our documentation updated with information relevant to those issues.
Note
If one day while trying to troubleshoot an isse you see something missing in the documentation of the tool, be a good citizen and try to improve it. Be the change you want to see in the world :D
So be respectful with the time of others and Read the Friendly Manuals when you need help. Don't be a Help Vampire.
If even then you still don't know how to solve your issue, the next part will help you.
So you've encountered an erroneous application in your system; congratulations, you're one step closer to becoming a full-fledged Archer!
Here's how to solve your problem in the Arch Way:
If its graphical, run the application from your terminal. All linux applications, even graphical ones, have a standard output and error stream. This means that if you run that application from a terminal, you get access to way more information than running it normally from your application launcher.
If yes, search for the errors and warnings exactly as the were printed on the screen. If that doesn't produce any uself results, widen your search by removing references to your specific machine from those error's; this includes absolute paths, process ids, timestamps, and a variety of other things that you will easily spot. Keep widening your search by removing details until you find something that can help you.
If no useful information was printed, it's time to RTFM. Specifically, we're
looking for two specific words: debug and verbose. Generally, you can assume
that -v == verbosity and multiple occurrences of -v, such as -vvv, or -v -v -v
will be higher levels of verbosity. The higher the verbosity, the more
information will be outputed.
But sometimes -v its a synonym for --version. The -d flag takes on
multiple different meanings, such as daemonize(run the program in the
background, almost like apending & to the command), debug, or even
detach[ed](in tmux, -d is a common flag used for starting a window or session
without immediately focusing it). So for simplicity's sake, just check the
manpage. Once you've done that, try searching online in the way we discussed.
Another trick that can help you is searching for the symptoms you are
experiencing and the application name "in quotes", e.g. "myapp" crash when opening text file. This makes your search engine filter the results to only
show those that contain the exact word between quotes. Use your search engine
tools, such as filter for time, and maybe add "archlinux" or the brand of your
gpu or any uncommon hardware you have that may be related.
Now you ask yourself this: Has this problem started ocurring recently? More specifically, did it start after an update to the package/software/system?
Warning
Don't start downgrading packages yet!
First, open the pacman log with a pager:
less /var/log/pacman.logAnd then hit G (capital g). It will drop you to end of the log. Use j and
k to navigate down and up, respectively. Use / or ? to search for a term
forwards or backwards, respectively. See what packages were upgraded lately and
determine their relationship with the problem you're having. Then and only
then is it okay to try downgrading.
Note
This type of navigation is callen vim-motions. You'll see it a lot in commonly used linux tools. It comes from an awesome editor that a lot of Arch users use: vim (and it's successor, neovim).
To dowgrade a package use:
pacman -U /var/cache/pacman/pkg/{package}-{version}.{architecture}.pkg.tar.xzWhere:
{package}is the name of the package{version}is the version previously installed that pacman has in cache{architecture}will be x86_64 if you haven't enabled multilib
Use your terminal auto complete to find the package you want or cd and ls
the directory to find it.
If downgrading the package fixed it, be sure to report it at bugs.archlinux.org.
If the issue still occurs, and you're reasonably sure that it was caused after the update, you can try downgrading the libraries or orthers dependencies of the application in question and further pinpoint the problem. But doing this will often get you into a rabbit hole tht ends in depdendency hell.
Pacman often spits out information regarding the packages you update if some
manual intervention is desirable or necessary. This should be in the pacman log
as well, but if it's not you can check the post_install() function from the
$pkg.install script(this is easiest to find by using the abs). alternatively,
you can just install the package again and pacman will print it neatly to your
console. Verify that you have taken any necessary steps outlined there.
The next step is to check your configurations. Did you change any settings recently? Change them back and see if the problem still occurs. Then, take care of your pacnews and try the program again.
If you did all of the troubleshooting and still couldn't find solution, it's time to ask for help.
But because you followed this guide, you now have all the information needed to follow basic litany for reporting a problem.
Post your symptoms, logs, hardware, and anything you discovered or supect about your problem while troubleshooting it. If you want the person that knows how to solve your problem to spend time helping you, make it as convenient as possible for them.
Good places to ask for help:
This guide is meant as a starting point with general directions. For more specific information, head first to the general troubleshooting page and the specific page for the tool you're having issues with. Looking at issues in the repository of the application can also help you find information about currently knows bugs.
Troubleshoot yourself to the best of your abilities.
Tip
An easy way to pastebin output from the command line is to [pipe your output via
curl to 0x0.st: command | curl -F 'file=@-' 0x0.st
After (hopefully) reading all this, you may think "Is this all really necessary?". The answer is yes.
If reading logs, searching around and learning how your tools work (and don't) is not something that you're interested in, then Arch linux isn't the right distribution for you. So don't be surprised if someone isn't welcoming with you.
Or maybe it is the right distribution for you, but you may not to gain more confidence first. Use a more user-friendly distribution first, get comfortable with the terminal, and tinker with something that you feel comfortable with. Then one day, when you feel more adventurous, try Arch again. And maybe it still won't be for you, which is fine. Arch is about using your computer the way it suits you, and maybe Arch doesnt suit you.
As The Primeagen says:
Gatekeeping is not inherently wrong, you just need good gates to keep.
I've seen a lot of people complain about how Arch users are unhelpful and unfriendly, and, with a couple of rare exceptions, my experience so far has been the complete opposite. Because since day one I tried to trouleshoot things on my own as far as my skills allowed me and gave the information I gathered when asking, every time that I needed help, other users were really helpful.
As times goes on you'll realize that doing things this way is actually a lot faster. If I have an issue in my system, I don't want to have go ask somewhere; wait for someone to reply; keep talking to them back and forth as we troubleshoot and only then be able to solve my issue. If I have a task to do and a tool isn't working as expected, I want to quickly read the documentation, find what want, fix it, and go on with my day. As you get experienced and know what to loook for, this is way easier and faster than asking for help.
After following this guide and solving your first problem, with or without help, you're full fledged Arch user, btw. Install a tiling windows manager, set your wallpaper as an anime girl, configure your neovim and post some cool screenshots online.
If this guide was helpful and/or informative, star it.
If you think there's something missing that could help a begginer or some edit that would make this article better, leave a comment bellow (sadly, there's no pull requests fors gists at the time of writing this article).
Thanks for reading!
I wrote this mostly to test drive OXY2DEV's markview plugin (which is awesome, btw). But hopefully it ends up being helpful.
I've been an Archer for over a year now and I want to start contributing to the community from now on (when uni lets me).