Linux chad way of solving problems

skyrim · 2025-04-18 15:25:37

Hi

How do you people approach solving problems specifically on Linux?
Like at first read the docs and if not works then how do you move forward?

Interested to hear your approach!!

Last edited by skyrim (2025-04-18 15:28:34)

duaner · 2025-04-18 18:32:09

My checklist usually looks like this.

- web search on the error message (~1/3 success rate [SR])
- web search on the problem (~1/4 SR)
- man page (~1/2 SR)
- if the man page is too long and complicated (ffmpeg, mpv, etc.), run up my local LLM and ask it (~1/4 SR)
- wiki.archlinux.org (~1/3 SR)
- wiki.gentoo.org (though arch wiki often links here) (~1/3 SR)
- look for alternative software -- I've even changed distributions at this point before (~1/5 SR)
- dive into the code or roll my own solution (or just give up if it's not a serious problem) (~1/10 SR)

A web search usually covers the wiki's too, but not always. My lowest success rates are with hardware/uefi errors.

I thought about adding a bullet for throwing a tantrum and cursing at the computer, but I'd have to put that between every other bullet.

seth · 2025-04-18 18:49:17

"not" - I solve them like every other problem.
1. isolate the cause (98% of the task)
2. find a solution or workaround (the remaining 2%)

You solve problems - every! problem - by asking the right questions about it.
You can ask google (better than artificial idiocy) but you still need to figure the right questions first.

skyrim · Yesterday 09:07:50

seth wrote:

1. isolate the cause (98% of the task)

Can you elaborate on your approach of isolating the cause?

Head_on_a_Stick · Yesterday 10:09:06

Have you tried turning it off then back on again?

tekstryder · Yesterday 12:06:34

Head_on_a_Stick wrote:

Have you tried turning it off then back on again?

+1

I just recently re-watched the entire series. Still brilliantly hilarious.

OT: what seth said.

ewaller · Yesterday 14:46:38

skyrim wrote:

seth wrote:
1. isolate the cause (98% of the task)
Can you elaborate on your approach of isolating the cause?

Read the output of the program. Start it from a shell to see this.
Read your journal.

ayekat · Yesterday 20:42:19

Make hypotheses, build cases to test your assumption, and if right, you're one step further. If not, you're also one step further.

Head_on_a_Stick · Yesterday 22:17:57

There is always https://wiki.archlinux.org/title/Genera … leshooting, which I have found to be very useful.

seth · Yesterday 22:33:56

ayekat wrote:

Make hypotheses, build cases to test your assumption, and if right, you're one step further. If not, you're also one step further.

Specifcially start wide and then narrow down on the issue.
Eliminate variables as much as you can and try to establish a working baseline.
Don't create moving targets by changing a random set of variables at once - worse than blurring the relevant parameter (what change actually fixed it) is that you can hide a solution by introducing a second problem.

If you're lucky, you can skip this because the journal is yelling the cause at you - then see #2
The challenge here is to "know" which red line in the journal is the bad one - eg. when you see a backtrace, the evil line is typically neiter the first nor last one (often very generic calls) but one between.

Arch Linux

#1 2025-04-18 15:25:37

Linux chad way of solving problems

#2 2025-04-18 18:32:09

Re: Linux chad way of solving problems

#3 2025-04-18 18:49:17

Re: Linux chad way of solving problems

#4 Yesterday 09:07:50

Re: Linux chad way of solving problems

#5 Yesterday 10:09:06

Re: Linux chad way of solving problems

#6 Yesterday 12:06:34

Re: Linux chad way of solving problems

#7 Yesterday 14:46:38

Re: Linux chad way of solving problems

#8 Yesterday 20:42:19

Re: Linux chad way of solving problems

#9 Yesterday 22:17:57

Re: Linux chad way of solving problems

#10 Yesterday 22:33:56

Re: Linux chad way of solving problems

Board footer