I can only support your decision to switch to Linux. To make your life a little easier, probably just use your iGPU for Linux and use the nVidia GPU for a Windows VM. Unfortunately the state of multi-GPU on Linux(even with just an iGPU and a dedicated GPU) is not that great. While it’s technically possible, unless you want to trouble-shoot for weeks probably stick with a single GPU.
Also keep in mind that when you setup the GPU for pass-through for a VM you can’t use in in Linux without at least a reboot.
On another note, regarding the filesystem(folder structure) you mentioned: It’s actually way more sane that what’s common on Windows.
First thing you need to know, everything is in a folder, including other hard drives, devices, etc.
Second thing to know(coming from Windows) is mount points: In Windows, you have multiple “drive letters” that contain all the data(absolute paths always start with C:\). In Linux, you start with an “root” folder(absolute paths always start with /), and then you can “mount” a filesystem into it: Mounting means making another filesystem available as a “folder”.
So for example, if on Windows you have the drives C:\, D:\, E:\, the equivalent on Linux could be:
/mnt/c_drive, /mnt/d_drive, /mnt/e_drive.
In this case /mnt/ is just a regular folder like any other where by convention other filesystems are mounted to. When /mnt/c_drive is mounted the folder content of /mnt/c_drive/ is your data.
Third thing to know about Linux filesystems is that in Linux files are used for more than data storage:
There are special files and filesystems, for example most device drivers(hdds, serial, gpus, etc.) create special files, typically in the /dev/ folder. For example, writing text to the /dev/ttyS0 file actually writes to the first serial port instead of a file.
The Linux kernel itself also supports special files for controlling(typically in /proc/ for controlling processes, and /sys/ for controlling the kernel).
These filesystems allow you to observe and tune the kernel easily just by writing to a file. For example, /proc/self/ contains all information about the current process, /proc/<pid> contains all information about all processes, /proc/modules lists the currently loaded kernel modules, /proc/mounts lists the currently mounted filesystems and their paths, etc.
Why am I writing all of this? Mostly just to convince you that the way Linux handles filesystems and IO is very flexible and powerful, and once you understand that a file is more than just storage, and a filesystem can be mounted in a folder and can do whatever(including being remote storage or controlling the kernel), it’s not that complicated.
You can read more about the default Linux folder structure, which is based on and mostly the same as the older Unix folder structure
On a side-note to my side-note, learning the CLI is great because once you know it doing it the GUI way is the slower method - If you repeat a task multiple times it is as trivial as typing the commands into a textfile to automate the process(It’s called shell scripting. The beauty of the CLI ecosystem and shells is that everything automatically and easily scriptable - There is really no difference between a shell script and the commands you type on the shell manually).
If you start learning the CLI, the most important command is probably man: You can lookup the manual for most installed programs by simply typing man <program name>.
however vim and systemd alone takes months to get used to…