I can tell you how I learned linux. be prepared to cringe.

1. I installed Linux before going to school, I figured that if I used Linux as my main OS I would be less tempted to dick around and play games

2. I eventually found a coop part time job as a dev. I used my own Linux machine, and being the star eyed young person I was I used arch.

this is the cringe part:

3. I did dev work on arch Linux without fully understanding how it works and ran into multiple issues (none of which was because of arch). for instance my USB wifi driver was the dogshit broadcom ones so the "drivers" for it were kind of messed and I had to hack several things into get it to work.

I learned systemd, Linux kernel modules, dkpg, obviously more familiarity with bash and shell stuff

4. I ran into issues with grub because FUCK grub. so I had to learn about boot loaders, fixing your install with chroot on a live usb, I also wrote step by step guides to untuck my particular problem just in case I run into it again

so moral of the story is.. dive in?

Start running servers if you haven't already. Use an old computer, or an SBC or VPS and setup some Linux servers. There's lots of different ways to do it, so mess around and break shit over and over. You can't help but learn that way, though I would highly suggest you take notes/documentation. This is a habit I'm trying to develop after too long :)

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)

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!

I'm late to the party but have you seen Linux Journey? https://linuxjourney.com/

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.

Install TLDR pages from your package manager to get easy access to the most useful information

https://tldr.sh/

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

1. Learn FreeBSD.

2. Learn Linux.

/s

If you're in the position to take certificates then that's a another way of learning a lot. At least it has worked for me. I've over the last half year taken RHCSA and RHCE from RedHat - though paid by work. Theses in specific are expensive, but I'm sure there are other ones that are cheaper. This would also allow you to 'show off' your skills in an official way should you need to, for applying for certain jobs etc..

I at least find this way to be helpful as you have to motivate yourself to learn and pass an exam to get the certificate. It might not be for everyone though.

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

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.

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.

My advice would be look up The Missing Semester it’s a free online MIT course on how to use the terminal and it will govern you a better understanding of how to use it and Linux more generally. Really helpful to find your way around and give you an intuitive sense of what you’re trying to achieve.

Then beyond that installing arch is easy with archinstall but it’s probably more helpful to learn about the components of desktop Linux and what they do so that you actually know what you’re doing.

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

https://programming.dev/c/linuxupskillchallenge

Attempt an Arch install entirely from memory. You might want to try this in a VM, in case something goes wrong, but just do it. If you can't quite remember what to do, man and ls /bin are your friends.

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

For getting better at terminal I would suggest looking into alternative shells. Bash is fine, but it’s not exactly user friendly by default. Something with more robust auto completion like zsh or saner defaults like fish could make the learning experience easier. You can always come back to bash later.

For understanding how the OS works I would start by reading about the file system layout, then look into the init process.

I got to the point I am at through a series of projects of increasing complexity. First I ran a web server on my machine to copy files over the network. Then I used a spare PC to make a simple SMB server. Later I made it into a HTPC pirate box, for streaming stuff downloaded off Usenet to my Xbox. At some point I ran a minecraft server (before docker came along and trivialized this), and got into a bunch of sysadmin and programming stuff and that’s pretty much it.