man pages.
How do you search these to find relevant topics?
Example, "audio output"
it is just practise i guess. like we all start searching online, and then eventually keep on learning - oh my mic is clippin, but i turned my volume way down and it is still doing that - why would that be - and then remember that 1 have 2 audio related things in my system - 1 is pipewire for all user facing stuff, and then alsa (alsamixer) for actual hardware - and oh look - i had accidentally given an internal mic boost of 100%. it is not like i got to know that that is a thing in a dream, but over past 2-3 years of looking online, i know what are common culprits, and i also have learnt a bit about my system and how different things are done. when you know that, it is easier to look up a particular manpage or README
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.
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.
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.
Linux
Welcome to c/linux!
Welcome to our thriving Linux community! Whether you're a seasoned Linux enthusiast or just starting your journey, we're excited to have you here. Explore, learn, and collaborate with like-minded individuals who share a passion for open-source software and the endless possibilities it offers. Together, let's dive into the world of Linux and embrace the power of freedom, customization, and innovation. Enjoy your stay and feel free to join the vibrant discussions that await you!
Rules:
-
Stay on topic: Posts and discussions should be related to Linux, open source software, and related technologies.
-
Be respectful: Treat fellow community members with respect and courtesy.
-
Quality over quantity: Share informative and thought-provoking content.
-
No spam or self-promotion: Avoid excessive self-promotion or spamming.
-
No NSFW adult content
-
Follow general lemmy guidelines.