People who've never used Rust or only used it once and couldn't grok it like to meme that Rust is bad to cope.

Linux is broad and deep so it would help if you gave some examples of tasks you are failing to do.

Edit: I guess I can give some fundamental topics for your search, but I don't have many resources at the ready.

For starters, many topics will apply to all of Unix, not just Linux. So make sure you understand the difference, and learn about the Unix philosophy.

Also, I think the most useful piece of documentation is the Arch Wiki. I'd always check here first. The table of contents should give you a good idea of the scope of information.

1. Filesystems. In Unix, everything is a "file". Explore the directory layout. Maybe learn about the FHS (filesystem hierarchy standard) and XDG. Learn how file permissions and ownership work. Learn about disk encryption with LUKS. Learn about GPT partitioning and EFI boot partitions. If you want to manage a filesystem spanning many storage devices, I highly recommend looking into ZFS. You might also want to set up some kind of file service like NFS or something with a web client like copyparty or dufs. Try out the dust and duf tools for checking space usage.
2. Networking. I don't know how deep you need to go here, but Linux networking is highly customizable. I think most distros use systemd's built-in DHCP client in systemd-networkd. Have a look at nftables if you want to mess with firewalls. Wireguard for VPN. Learn to use the ip tool.
3. Remote Access. Especially for a desktop, it's very useful to set up an SSH service on your PC so you can access it remotely from e.g. a laptop. You can even SSH over the public Internet using a VPN.
4. Monitoring. Install BTop to get a quick overview of system activity and resource utilization. I also like the procs tool as an alternative to ps.
5. Shells. As part of your Bash journey, I'd also check out shells like fish, zsh, and nushell.
6. Package Management. I'm not very familiar with Bazzite's package manager. It's an immutable distro, so that will make a difference. Read the bazzite docs for this I guess. You'll probably need to learn about flatpaks. I'd recommend checking out Nix if you want to try something different. I also quite enjoyed Arch's pacman if you're willing to try a new distro like CachyOS or EndeavourOS.
7. Dotfile management. I recommend learning some basic Git or Jujutsu (jj) and managing your configuration files in a git repository. You can also do this with Nix via Home Manager.
8. Desktop Environment. I don't know which variant of Bazzite you chose, but it's probably a complete DE out of the box. Just know that you can customize your DE quite a bit. I personally enjoy tiling window managers; you might want to check those out.

ICE just needs to scan his face with the Racistron 2000 app and it overrides his birth certificate, haven't you heard?

Japan's copyright law is very similar to the US, so I'm not sure what you're referring to.

https://en.wikipedia.org/wiki/Berne_Convention

You don't mess with the Zohran.

I think "AI slop" is the de facto nomenclature.

Anyone that thinks they're "coding on the go" with something of this form factor is kidding themselves.

It's such a good investment that it's why insurance was invented.

You are never guaranteed to be able to do anything during a crash. You are better off handling these kinds of edge cases in a recovery phase during the start of your app.

Wireguard is p2p.

EDIT: I guess the point is it's doing peer discovery without static public IPs or DNS. Pretty cool!

Did y'all know that microwaves aren't magic and you need to mix your food?

That a "working" prototype with no tests is just as good as a carefully-designed and well-tested feature. I see this happen so often that a coder puts a prototype in front of a product manager or exec and they are like, "this is exactly what we need, now! Ship that!" And then misery ensues for all of the engineers that need to maintain this piece of garbage. As managers pressure the engineers to build new features on top, they inevitably break fundamental parts of it, and without a confident leader to demand that tech debt is paid off, that product will consume the souls of many desperate coders.

In contrast, if you do it right the first time, there will be significant parts of code that never need to change, and the parts that do need to change will be much easier, because it will be obvious if it breaks the tests.