Linux

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.

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.

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

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.

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!

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

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.

If you do something long enough, it then becomes second nature.

Program -h or --help

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

For something easier than man, check out tldr

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.

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.

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.

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.

Read the doc, like suggested: man pages, online doc. A book, even. Then, trial and error.
It's ok to fail trying to fix something, it's not to not even try, at least I think so ;)

First always take notes of the steps you took to do something. If you were throwing shit at the wall then try and do it again using only the correct steps. I have saved my own ass by taking down notes. Include the commands (obviously), what they do, why you're using them, the expected output, and errors you came across with their solutions.

Since you said you wanted man pages to be easier to parse, I'll give you some advice on how to approach these, admittly, intimidating blocks of text. One skill I have learned is how to read those intimidating technical documents and actually get the information I need from them. A good practice is take a tool, a programming language, data format, etc. that you already know and look at the technical specifications. Since you already know how it works you should be able to understand the information in there, and learn how to parse out that data. RFC 2119 also gives some guidance on some of the word usage in those documents (it's very limited), and is a nice short one to get used to reading stuff like that.

Another thing is I just try shit out to see what happens. Would probably be a good idea to do this on a machine you don't care about reimaging, or make a backup of all the data you care about losing. I'm a very learn by doing kind of person and have learned a lot this way

Finally if you have the time and knowledge looking at source code can really give you an understanding of how a tool works. This is my absolute last resort, so don't think you have to do this.

Edit: I wrote this assuming you're ok with getting into the nitty gritty of Linux. Otherwise I would recommend switching to a more user friendly OS. It looks like you're trying to set it up for gaming, this is a guess and I could be wrong. I have been using Bazzite for about 6 months now, and the only times I have issues with it is when I try to do power user stuff that isn't gaming related (e.g. trying to install a build tool to build something from source code).

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.

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

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.

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.

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.

Same way you started anywhere: practice.

Most people who use Windows cant, and don't, need to fix a thing. Same thing in Linux.

The goal is to make the OS as compatible with as many machines as possible, to make sure that user intervention isn't really needed, so you don't really get that reflexive sort of knowledge unless you're doing it for work and being exposed to it at a MUCH larger scale. Even then, you forget the things you don't use frequently.

There tons of learning simulators out there for the basics. Just found this one. Give it a go: https://itsfoss.gitlab.io/post/test-your-bash-skills-by-playing-command-line-games/