Time. And experience.

I compare this with other skills like growing plants… “keep watering them” is not good advice for cacti…

A lot of Windows users have to search for solutions which you probably know. And there’s still advice out there to “open regedit…” (do you understand the difference between HKLM and HKCU?)

Windows is like Linux, but someone’s taken away all choice: 1 desktop GUI, 1 filesystem (mostly), etc. so there’s usually only 1 answer.

Pressing the volume key should work as it’s been the same for decades. Yet, why can’t I move the taskbar to the top of the screen in Win11 now?

You’ll get there with Mint Cinnamon, but someone else on Mint Xfce will have to do something different, and learn different things yet you’ll still both learn about apt even if you try to only use the gui to update your systems.

Over time the venn diagram of advice becomes clearer and you find what advice works for you (ie cli vs gui) and you learn why some plants need water and others don’t.

Learning resources are common. Good ones that go beyond ‘sudo yourmom’ are rare.

More approachable man pages sounds like a cool idea. Superman pages. It could not only have a list of flags but nested explanations of what those things mean. Maybe some wikipedia style markdown to connect it all. Simple English wikipedia writing style. Someone get on it. I don’t have time for any more projects.

Log files, dmesg, journalctl and systemctl status are good starting points to get clues for where to start troubleshooting problems, then you can hit the man pages or internet. Watch a video about the typical Linux system file structure means and what directories have important config, log, device, or process files and then go look at those files with cat or nano or ls -la.

You start to become familiar with how things go together and the usual suspects for problems, but also get better at searching the internet or a wiki for troubleshooting your problem.

man pages.

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.

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.

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.

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.

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.

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

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.

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.

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

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

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!