I heard that with winbtrfs, you run into permission issues where every time you boot back into Linux, you’d need to chown any files you’d created in Windows, which would be a PITA.
You can set up mappings between windows and linux users so that btrfs will automatically set the correct permissions for files created in windows: https://github.com/maharmstone/btrfs#mappings
As far as I know that’s mostly because there’s much more land in the Northern Hemisphere and the temperature differences (day/night but also summer/winter) are much more pronounced over the land than over the sea: the land heats and cools faster.
Not OP, but: it works similarly to looking at the system in a mirror. The clock’s hands turn, well, clockwise, but if you look at the mirror their movement is anticlockwise. Importantly, if you look at that mirror in another mirror, it will be clockwise again. Add yet another mirror and it’s anticlockwise.
With a single mirror at position x=0 (and YZ plane), you invert “x” position, so (1, 1, 1) becomes (-1, 1, 1). “Inverting” the spatial coordinates ((x,y,z) -> (-x, -y, -z)) is effectively the same as looking at system through 3 mirrors, located at x = 0 (YZ plane), y = 0 (XZ plane) and z = 0 (XY plane), but that is a bit hard to visualize/arrange in practice so usually you would think of it as an equivalent operation of a point reflection around (0, 0, 0). You are right that the point is arbitrary: the important thing is, among others, that clockwise movement becomes anticlockwise.
I made a similar switch half a year ago and thankfully for me it was relatively painless. Some stuff got significantly harder to set up (e.g. getting a nice rust development environment, getting ROCm to work with some torch-based project), but once all that is done I have complete or near-complete setup instructions on how to do it again, so I am hoping the trade-off here will be worth it in the future (or I will drop nixos and move to something else if I get bored, time will tell).
For the beginners, I recommend to go with the flakes setup right from the start, here is a nice guide that you can use as a reference: https://nixos-and-flakes.thiscute.world. I followed it through for the initial setup and I don’t remember having to think about channels, at least initially: I picked the most recent stable one right at the start and only updated it to another - the unstable one - later on when I wanted to get some fresh kernel version. The upgrade was pretty painless, as the channel is just the root input of the flake: change that one line,
nixos-rebuild switchand it’s done. With flakes I occasionally runnix flake update(+ rebuild) to get newer versions of packages (as the flake will be locked to the state of the channel at the time you install/update). If anything (well, most) of the things go wrong, just go back to the previous build while you figure out what’s causing issues (much better than the Arch experience of something going wrong after the update - better read Arch news regularly 🙃).Besides updating my configuration to add/remove packages and doing the same for development environments (btw, for getting compile time dependencies into nix-shell, you need to add them to buildInputs of the shell: https://nixos.wiki/wiki/FAQ/I_installed_a_library_but_my_compiler_is_not_finding_it._Why%3F ), I only ever use
nix profile install nixpkgs#<package>if I want to just run some app without adding it permanently. After these 6 months of use, I have found out I am getting much less software/package cruft building up in my system. If I stop using something (especially a big think like a DE), I can just remove it from the configuration, rebuild and that’s it. With Arch, I probably even forgot about half of the things I installed there over the years.