I'd like to start by thanking everybody who responded to my questions. Your answers have helped a lot when it came to my worries on switching to Linux.
I've taken in a lot of your recommendations:
Fedora, Fedora Kinoite, Nobara, Bazzite Linux, VanillaOS,
I've decided on Fedora Kinoite, as it has everything I want from a distro.
It was very kind of you all to answer my questions but after making that post and reading your answers new questions propped up.
These questions are a little more opinionated than the last ones, and a little better thought out, but please take some time to answer them.
Questions:
Is Wayland worth using? Especially when you consider all the issues that may come from using an NVIDIA card.
Are there any real noticeable advantages/improvements to using Wayland over Xorg.
Does bloat actually matter or is it just a meme?
Does bloat actually have a noticeable negative impact on your system or are people just over reacting/joking.
What are some habits I should practice in order to keep my system organized and manageable?
Any habits or standards that I should abide by in order to save myself headaches in the future?
Any other resources besides the Arch Wiki that I should be aware of?
Self explanatory.
What do you wish you knew when you first started using Linux that would have saved you a headache in the future?
I'm not referring to some skill but instead something pertaining to Linux itself. Feel free to skip this question.
I'll be going to sleep soon, so apologies if I don't reply but please take a moment answer any questions you think you can.
One suggestion I haven't seen addressed: use a filesystem with snapshots such as Btrfs and combine it with Timeshift.
With Timeshift you'll be able to roll back in time on your disk and undo stuff. It can take advantage of the lightning fast snapshots of Btrfs to do that.
On Btrfs, separate your /home into a subvolume @home so that, when you do roll back, your personal files aren't affected.
Configure policies for daily and weekly snapshots on Timeshift. Don't worry about space, they're basically free.
That way you can feel better experimenting with your setup, as long as the system is Bootable.
Heard great things about it. Mint doesn't suggest it as default, but if you choose Btrfs during install, it will configure @home subvolume and snapshots for you, which is nice.
Sure. So a snapshot in itself doesn't consume more than a few KB. The filesystem has a Copy On Write (COW) behavior, meaning it doesn't overwrite edits on files by default. It moves the pointer to the file to a new location and writes the new version there. If there is nothing still pointing to the old data, that space is now considered free and can be overwritten.
A snapshot basically keeps pointers to data in the past. So it's not entirely free, in the sense that older versions of files will remain and therefore not free up disk space as long as that snapshot exists. But it's free in the sense that no data is copied to create a snapshot. Your filesystem is always only writing the difference to the last snapshot.
If you configure snapshots at small intervals and configure them not to be erased, you'll compile the history for all the changes in all your files since ever. And that will definitely cost you space.
Typical scenarios are a daily snapshot that you keep for a week and a weekly snapshot that you keep for a month. That will cost you very little space (again in typical desktop use cases). If you have a streaming folder, a COW filesystem might not be the best idea. Or at least create a subvolume that doesn't get snapshots.
Snapshots don't replace backups and if you need older data that a month, that's what backups are for.
Snapshots on btrfs are at the filesystem level and only really are a list of steps to get back to the old state. They are not a complete backup and you can't move them out of the filesystem.
have a 1G /, 500M for /boot, have partitions for /usr, /usr/local (this isn't used on linux so keep it small), /var, /home, and /tmp if you have little ram. Otherwise use memory-based filesystem (tmpfs), for /tmp I allocate less than 1/4 of my RAM.
Remember to keep /usr/local small on most distro (perhaps I will allocate 5G), and increase /usr, create /opt too to prevent the disaster and allocate it the size for /usr/local. Don't allocate all disk space, a 200G home is enough for most people and leave the rest unallocated. the formatting and fsck would be faster on smaller filesystem.
And if you find other "cache" location, try log out and rm -rf the location, if login doesn't break, I would mount tmpfs on that cache location too.
I actively discourage neophytes from fiddling with multiple partitions. It's a layer of complexity that is unwarranted for them, and most users. Newbies can use a volume for home and another for the rest. Experienced users can split the system volume for the use cases you mentioned. And I don't think having separate fixed size partitions like you suggested is a good idea for anyone on a desktop.
In my opinion newbies should learn what is called sane defaults. It's a pity that almost every installer in the word except OpenBSD's disklabel(8) cannot properly do automatic partitioning.
And I don’t think having separate fixed size partitions like you suggested is a good idea for anyone on a desktop.
UNIX's removable filesystem is a BENEFIT, not a BUG. DOS and then Windows' A: B: C: D: are BUGS.
Why not take advantage of it. Microsoft always wanted a removable filesystem like UNIX. But they simply can't get it.
You can create either logical volume or physical partition, but make sure you have different partition for different mount point: /, /usr, /usr/local (keep small on linux), /var, /opt (if you use), /tmp (if you have little ram or don't want to use memory filesystem).
What do you mean by your comment.
I haven't said something about logical volumes vs physical partitions.