arch wiki. some of their documentation is better then most apps give

This is why suggesting distros like CachyOS to beginners is dumb. I know everyone wants to promote their own favourite, but then this is what happens.

Stick to the big names, having large userbases helps them stomp out these bugs.

• https://www.learnlinux.tv/ - i started with this guy’s bash scripting series. learning bash will definitely give you at least a vague idea of what these forum commands are doing

• i promote Codecademy every chance I get because they’ve got some really good free courses, and i actually subscribe to unlock the quizzes and projects. I went through the CompTIA Linux+ certification path last year and it covers a lot.

• the most important part: take notes. like you said, there’s too much to remember. you gotta have a reference, even a place where you store other references. I use Obsidian, so i use that to search for a topic i may already have notes on already. each topic has links back to references (so many itsFOSS and GeeksForGeeks.org articles, but also youtube videos).

finally, a friendly warning: anytime a linux user uses the word “just” as in “just do this…” Ignore them. It’s never “just” something. this means they have lost the ability to put themselves in the shoes of a new user.

For something easier than man, check out tldr

First and foremost, get the suggestions from good sources.

Then read the suggested command and learn what it does. Look up what each part is. Then look up that command’s documentation (via manpages - man command). Do that enough times and you learn enough bits and pieces to build a good picture of the system.

This is how I learned. Took me about 5 years to get enough knowledge to feel fairly comfortable in the OS.

The other way to do it is to learn the basics in a structured way, like a course, tutoring, a book. These days I teach my knowledge of Ubuntu to colleagues at work who come to our project, which requires it. I sit them down for several 1:1 study sessions, 4-8 hours total. They come out fairly proficient afterwards and more importantly - able to reliably expand their knowledge.

man pages.

For new Linux users it’s best to stick with well established and supported distributions. Then it’s easier to find solutions for common problems.

It’s good practice to look up what the commands do, you enter when you find a solution. Read the man page or other documentation of the command you’re entering. It doesn’t need to be everything, just enough to get an idea what it does.

Also: take notes when you find a problem and how you fixed it. You can go back to them later.

sound and screen dimming

You can’t give a general answer to this. There are several different software stacks for sound on Linux. A typical one goes like this, but can look different.

Kernel - driver - ALSA - PipeWire - desktop environment - application - user

There might be an error at each of these levels.

In the simplest case, it’s a bad configuration, where the volume is set to 0 or mute somewhere in this stack. So try different applications first to play sound, also try playing sound from the terminal. Change volume sliders in different places.

Then go down the stack. Try playing sound with ALSA directly using aplay and speaker-test.

Finally go down to the driver and see if the hardware is detected. Depending if the soundcard is connected via USB or PCI use lsusb or lspci.

Find out the type snd chipset of your soundcard and then search if there’s a driver for Linux already. If you have new or unpopular hardware, it can take a while (a year or two) for a driver to be written, tested, and accepted into the kernel. Then it has to go downstream to the distributions until you get it. So for new hardware you might have to do some additional steps like finding a driver and compiling a kernel yourself.

It’s also worth checking the log files of the audio stack (ALSA, pipewire, or whatever your distro uses).

screen dimming

The stack looks like this:

Kernel - driver - X11/XOrg or Wayland - compositor - Desktop Environment (KDE, Gnome, etc.)

The error might be the keystroke not registering, the desktop not sending the right command, the display driver not supporting dimming, a bad or missing configuration. Again work through the stack. Find out what your distro uses.

Try setting the brightness through the terminal for example.

I, for one, find it frustrating to use Windows when there are problems that you can’t just fix via their control panel, because you’d be left with nearly no tools aside from hoping someone knows the magic registers to tweak.

That said, a lot of how to “fix” a computer issue comes just from how well do you know your system, or just systems in general.

Let’s use your sound issue example. If it’s a sound issue, well, for starters, what program are we using to control sound? Pipewire? Pulseaudio? Or straight ALSA? Then let’s look at how to configure it. How do know about them? I look up what sound servers are commonly used, and try to see if my system uses any of them? But how did I know about sound servers? Cause I tried installing Arch cause it’s a good way to learn about how Linux distros are put together, and I ended up learning about the pieces in the puzzle that makes up a daily-drivable desktop system.

So there’s a bit of curiosity and discovery process that helped me in setting up my knowledge to help situate and isolate problems in the system.

If it’s some other distro, where I don’t know how they’ve put the system together, I would definitely be a bit lost, but because of how transferrable a lot of skills and knowledge is in the Linux side of the world, I can probably find my way and figure out what needs to be done. Is it a lot of reading though? Absolutely!

It’s both a curse and a blessing that we have many options on building up a system in the Linux ecosystem, cause we have a lot more options, but it does mean we don’t have a central authoritative source or manual to things.

And this is sort of an aside, but use the Arch wiki even if you’re not using Archlinux. It’s one of the most fantastic resource for figuring out how to fix something in Linux, and to learn about various pieces that make up the whole puzzle. Give the Installation Guide a read even if you don’t care about installing Arch.

Program -h or --help

Or just look for help outright online. No one’s holding a gun against your head.

Its mind boggling how one can visit a forum and there’s people saying “oh yeah just run -c xhhkrk ()<>[] bbbhjl and that will fix your sound issue”

Saw your first sed command, I see. It’s ok, I’ve been using Linux for 20+ years and still don’t understand that one.

I study solutions given for some hours. If I can’t get their logic, I put them aside and go back in a few days, often after seeing something unrelated that helps understanding the topic I was stuck at. That I dunno if has a name, but I like to call it “additive learning”.

Also sudying =/= applying the solution

Really it boils down to having a basic understanding of what commands can do and why you’d want to use them in specific instances. There are general books and resources out there that can at least raise baseline knowledge, for example Introduction to Linux. Or one of my favorite The Linux Documentation Project. As experienced people forget what it’s like to be new at something, you won’t immediately find anything super readable out the gate; though occasionally you do run into easy to understand things just randomly on the web. Secondly reading the documentation of the distro you are using (as sometimes you’ll find some useful stuff in there) like what they use as a basis to create their distro. That can aid one’s troubleshooting because you know where you can look in order to achieve the result you crave. Or help you ask targeted questions that can boost your ability to learn about things.

Another is not using an Arch-based distro when you’ve only used Mint as your first distro, that is a difficulty spike that you aren’t ready for. Ubuntu is probably the easiest to get your toes wet with, after Mint, as you have graphical ways of solving problems and terminal based solutions. A great hybrid for learning the basics, as most command related solutions are similar (but do have different structure based on the distro). As Ubuntu’s documentation is fairly solid and can mostly be parsed once you understand the basics. Linux is a different animal in a lot of respects, it’s meant for people that are ready to learn and Linux can be learned over time. To really understand, it will take time and effort to parse documents, think, and apply the fruits of those mental labors. However, as Linux is a community, you can reach out to others. There really isn’t an easy way to do this, is my point. We all start out fresh, but because humans have brains, you can figure Linux out.

From my experience, it’s something that only came with time spent diagnosing things, and then building up instincts for things like that, or just poking around with things and understanding how things work under the hood. Even then, there are usually things I have to look up every now and then.

Though I must admit, my knowledge basically tripled since installing arch and figuring things out myself with only the help of man pages, and trying to correct the behaviour of just looking things up and blindly applying fixes. Each time I need to fix something complicated, I fight the urge to just “look it up” and stop, take a breath, and think. It seems obvious but sometimes I forget to do that. I try to fix it myself, and then occasionally when shit hits the fan, I look it up, but try to understand why the fix works. But as I said, you will likely only reach that level of experience with time, or alternatively throwing yourself into the deep end of a difficult distro with no hand holding to understand not only how something is done, but why.

Not sure if any of that made sense, or I’m just rambling… Eh…

There’s nothing wrong with looking things up, and it teaches future you what to do/how things work.

That said, troubleshooting is a skill that can be applied to anything. It’s mostly just eliminating variables and patience sometimes, but even professionals still look stuff up regularly. All that reading and research helps you build a foundation to help inform your troubleshooting though.

Also, +1 for man! If you need to know more about a command in the terminal, just type “man” (short for manual) then whatever the command is and you’ll be presented with documentation regarding the command!

2 things: Experience Repetition

First of all, continue to look up how to fix things, there’s no problem with that. HOWEVER, make sure you understand what the commands you are entering do. Same thing applies to Windows as well, I’ve seen plenty of troubleshooting posts that and with “paste these 3 lines into power shell”

The more you do this, you’ll get a feel for how everything is organized. You might not know HOW to fix your issue at this point, but you will at least know where to look for logs and where to find the config files relevant to your issue. Once you’ve fixed enough problems, you’ll start to be able to figure it out on your own. You can also help out with bug reports better now too.

You also need to do this often enough that you remember these things. I’ve got a bunch of Linux installations (3 desktops, 1 laptop, 4 small servers) so I get plenty of practice changing things. When I only had the 1 computer running Linux, it was a lot harder to remember everything.