Linux

1. Learn FreeBSD.

2. Learn Linux.

/s

And how did you, advanced Linux user, get to the stage your at now?

Incrementally over time by reading the documentation and/or manuals of the commands I need to run and looking up how others solve the problems that I need to get other ideas about things (even, periodically, for things that I already know how to do to see if anyone has found a better way to do it or if a new tool has come out that helps). And trying things out/experimenting with different ways of doing things to find out what works well or not.

See if your library has "How Linux Works" - https://www.amazon.com.au/How-Linux-Works-Brian-Ward/dp/1718500408

https://programming.dev/c/linuxupskillchallenge

I guess my end goal is to be able to comfortably install and use arch Linux with my own customization’s and be able to fix it when things go wrong.

Why? I have been using Linux for nearly two decades and I am perfectly content with a low-config distro and desktop environment. You don’t have to use Arch but if you insist get a Steam Deck.

Work at the tip of your "paygrade" and try to make immersion as fun as possible. Maybe consider using a different disk for Linux, since mistakes are the best way to learn. (Don't reinstall just because something broke).

Here are some fantastic ways to make mistakes:

1. Install a more involved, but typical, CLI-centric, DIY-friendly distro -- from today's order of difficulty, that's EndeavourOS, (install is easy, then you can learn one package at a time), Arch Linux (install is hard iff you have trouble with understanding wiki structure, and you'll want familiarity with what packages you need), and Gentoo (the installation guide is incredible).
2. Try out new CLI software. The terminal is your friend! Are you gonna back up videos with yt-dlp? Perhaps make a shell script for something? Maybe search the AUR for something cool to try out (underrated function of the AUR: test-driving!). With a terminal, who needs file explorer?
3. Play a game. Linux games exist... they're called CTFs ;). Bandit is pretty fun for beginners (try to keep notes! Maybe use Git?): https://overthewire.org/wargames/bandit/
4. Make unnecessary customizations ("rices"). Your shell can be made sexy (ohmyzsh?). Your lockscreen can be made sexy. Your windows can be made sexy. (And if you break something, don't reinstall :3). Remember: if you build something pretty and see it every day... absolute epic.
5. And of course, flex your hands, get your apron on, have fun popping the engine and fixing! How does one ask questions, put in due diligence, Google, read logs (like journalctl or dmesg or --verbose or whatever)? This is a skill you don't lose -- and we'll be happy to answer a good question.

Of course all of this depends on where you are (the tip of your paygrade). For pasting commands specifically, as you said... do 'em one at a time -- and understand each one.
Like, what is piping |? Why is xargs after it? Why can one stop ping with CTRL+C? What does man curl say about this weird curl command? How does one even read a manpage well, anyway (and is curl cheat.sh/SOME_COMMAND better)? Why is there so much gpg?

And at the end of the day... remember how fun this shit is. The engine is open; we're allowed to look inside. Woohoo!

When you are doing stuff in the terminal write it down somewhere else also, on a piece of real life paper or in a simple text document or whatever works for you.

In general I found taking notes while trying to do things in the terminal helped me learn.

Another book rec: https://pragprog.com/titles/bhcldev/small-sharp-software-tools/

Switch to rolling distro, it will break so many things with each update you'll learn stuff by fixing it. Also you can check https://overthewire.org/wargames/bandit/

I have sort of had enough of copy and pasting commands I find on the internet without having a good understanding of how they actually work.

One thing you could do is start trying to understand those commands.

Read the man pages or the documentation to figure out what the commands are actually doing. Once you have the "what" , you can dig deeper to get to the "why" if it isn't obvious by that point.

After enough of that, you'll go to copy/paste and already understand what it's doing without needing to look it up again.

Then from there, it's a matter of building the instinct to be able to say "I need to do X, so I'll use commands Y and Z."

This course by the Linux Foundation goes over the basics and I thought it was pretty good. I was a long time user of Linux when I came across this and wanted to see how much I really knew. It's very easy to follow and well structured

https://training.linuxfoundation.org/training/introduction-to-linux/

I'd recommend reading man pages. They're a great way to understand the programs that are on your system. The Arch Wiki and the Gentoo Wiki both provide additional information that may be of use to you.

"I take full responsibility for my Arch system."

Here is a bunch of random tips to become more comfortable with the terminal.

Do absolutely everything that you can on the terminal.

When you install something, enable the verbose if possible and snoop around the logs to see what is happening.

If an app or an install fails, look at the logs to see what is the issue, and try to fix it by actually resolving the error itself first instead of finding the commands on the internet to fix your issue.

Instead of googling for your command options, use the help menu from the application and try to figure out how to use the command from there.

on the tailend of a convo in in a discord recently I added a command to the "customize chatgpt" section to allow chatgpt to have a custom "man" like command similar to linux, but that works for all code or commands.

This makes chatgpt give me a Linux command or code snippet formated in a table explaining what each piece of the command does.

when a prompt is givin beginning with the word man followed by code or commands please respond with a table following these rules and nothing else: skip title row, No backticks around command components, No unnecessary rows, column 1 should contain the command component, column 2 should contain a brief command description

Using tldr to learn commands. It gives you the information you are probably looking for in the man page but it's not buried among lines and lines and lines of arcane stuff and it's formatted in a readable way with helpful examples. Saved my sanity more than once.

I'm not saying "don't read the man pages", they are great way to get a deeper understanding of commands. But when you are just wondering what a command does and how it's commonly used, then a two lines summary + example is much more helpful than an essay going in minute details over everything.

Since it takes a lot less time than hunting the same info in the man page, you can run it before every command you are not familiar with, without too much hassle. Then if you want more info you can check the man page.

I will be using your example of Arch as a great stepping off point, because honestly imo the best way to learn is by having a project to work on

1. RTFM - Read The Fucking Manual. Read the docs, read the code comments if need be. In the case of installing an OS, use the installation guide as a starting point; Arch's is on their wiki, and links to several other sections that go more in-depth about what each step does and why it does it.

2. DuckDuck it - if you don't understand what something is or why you're doing it, search it. If you understand it completely, search it anyway and check the docs because no you don't, you just don't know how little you know. If you know why we do something and what function it fulfills, but not how... Then you're a power user.

Using your example of commands from the internet, break the command down into as many parts as you can, and figure out what each part does. If there's punctuation marks, don't assume you know what those are doing. man [command's name] is your friend.

3. Do all of the above as often as possible, no matter how slow it makes progress feel. Learning these things the proper way now will save you from days, weeks and months of troubleshooting in the future. I mean it, literally at every step of the process.

4. secondary sources are invaluable, but for this it might help to get into the best way to self-educate. The only gospel are the docs and/or manual that were written by the code/OS maintainers - primary sources - everything else is opinion.

Here's a source i agree with on the best way to self-educate, but keep in mind even Artem is still just a secondary source.

That being said, here's a few secondary sources that helped me understand how OSes work and why:

nand2tetris: build an operating system starting with logic gates and working your way up from there. It has a offshoot site that's slowly being rolled out, that implements it all in a gamified interface: nandgame

os-tutorial: build an OS from scratch

Linux From Scratch: Learn everything about Linux by building your own distro from the kernel up.

Unfortunately everything that taught about the behind-the-scenes aspects of OSes in general—and Linux in specific—were either projects like the above, or just seeing what came up in a DuckDuckGo, Youtube, forum, or wiki etc. search. Below are just resources that teach you about the "power user" level of knowledge, not "super user" but not your average user either.

Fireships' 100+ Linux Things you Need to Know: it's not particularly good on its own, but it does introduce a lot of concepts and vocab for you to then look up elsewhere

freeCodeCamp.org offers a lot of courses that will go over using Linux. None go too in-depth on the fundamentals of Operating Systems, but they will still introduce most of what you need to know for day-to-day use. I don't want to link them all, but just search for linux freecodecamp on youtube and find one that piques your interest. The longer, the more in-depth—you don't have to watch it all in one sitting.

5. And of course, when all else fails: just ask. Participate in the community, don't be afraid of looking stupid. The only people that get no respect are the ones who refuse to accept others' help because they know better than those they're asking to help them. (ignore the gatekeepers who want to project their own need for an identity onto you)

Arch Linux Handbook on internet Archive

I learned a lot by using a less common distro (solus). When I would have a problem, the solutions I could find on forums or arch wiki wouldn't apply to my distro directly, and I would have to look into the solution for long enough to understand what needed to change in order for the solution to work.

You can probably do this on any distro, just by not using commands you find online until you understand what they're doing and why that might fix your problem. Arch wiki is a great resource for any distro, even though it won't always be accurate for the distro you're on.