The next time you encountered a problem, and found the command to fix that problem, call in sick for a week, drill all the way down to the source code level, find out what the root cause was, and what that command does. You can only fix things if you know how it is supposed to work.

Interesting.

I kind of have the opposite impression. I really enjoy being able to look things up like you mentioned. I have really enjoyed being on Linux in general for about two years or so now and I wish I’d switched much sooner. I really appreciate the willingness to help from the community and usually any issue I run into is a quick and easy fix. I don’t think there’s been a single thing I’ve asked about that was super difficult or I was unable to be helped with. Even if I don’t understand the technical aspects, it’s nice to have a collective resource essentially. Nobody’s ever been mean or talked down to me over any of it. Positive experiences all around.

You guys are awesome, truly.

When you don’t even know where to begin:

• Arch Wiki search
• Docs and wiki for your distro
• StackExchange search
• Sometimes other distro wikis like Gentoo and Debian have some pointers
• Forum search (distros, lemmy, reddit, project issues and discussions)

That should give you one or more possible solutions involving commands. Don’t just run them right away. If they’re new packages you need to install, you can check some basic package metadata like website URL either via your distros web interface or package manager itself:

pacman -Si packagename  
apt-cache show packagename  

Once installed, hopefully you have man page showing up for man command. If not, they or some other reference docs should be available on the web. Try to find the official resources instead of clickmill tutorial blogs and LLM ramblings like deepwiki. Many but not all commands will give you some usage explanation by passing --help. Any flags/parameters you found in solutions should be explained here. Try to understand the solution/example you were given and what you should expect it to do. Maybe you want to change, add, or remove some arguments for your scenario.

If any files are mentioned, you can open and read them in a text editor. If the command is expected to change anything, or you need to edit config files, you can back those up before you go to town.

Basic cli utilities I use all the time that will help you a lot to be comfortable with: cat less grep diff sudo tee tree head tail curl wget dmesg. If you are ambitious then sed awk jq. If your system uses systemd then systemctl journalctl. No need to remember every single flag but bit by bit you pick up what’s relevant for you. And any terminal text editor (nano, (neo)vim, emacs, helix) for sudo edits.

When you want to recall what you did before, you should be able to search your shell history with Ctrl+R. You can put searchable reminders for your future self with comments: brightnessctl s '-10%' # dim monitor decrease screen brightness.

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.

man pages.

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.

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.

For something easier than man, check out tldr

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

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

Program -h or --help

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

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.