Linux

Microsoft store apps don’t work in wine.

Guild wars used to work in Linux, idk about two but it seems to.

What you might consider, since you have the time, is using Linux as a main os and run windows in a vm inside it with gpu passthrough.

The idea is that you boot Linux all the time and when you need windows you “turn on” the virtual machine running it which gets direct control over a video card connected to a monitor.

It’s like having two computers with two monitors right next to each other except with only one computer.

The big benefit is that you get damn near 100% compatibility with even games that have windows only anti-cheat because… you’re running windows. It’s also nice to not make a choice to “switch” because windows is always right there when you need it!

The cons are that it takes a little time and learning to set up and you need to make sure your hardware works with it and that you have enough of it to make such a setup work (both onboard and discrete video cards, two monitors or a kvm switch, etc.).

But for a certifried gamer it’s a good move.

wine is not a distribution. It is a program that allows running windows applications on Linux, and is available on most distributions.

There's a standard. /usr was often a different partition.

/bin - system binaries
/sbin - system binaries that need superuser privileges
/usr/bin - Normal binaries
/usr/sbin - normal binaries that require superuser privileges
/usr/local/bin - for executables that aren't 'packaged' - i.e., installed by you or some other program system-wide

To summarize: the major difference is that Arch Linux gives you the latest versions of all programs and packages. You can update anytime, and you'll get the latest versions every time for all programs

Debian follows a stable release model. Suppose you install debian 12 (bookworm). The software versions there are locked, and they're usually not the latest versions. For example, the Linux kernel there is version 6.1, whereas the latest is like 6,9 or something. Neovim is version 0.7, whereas the latest is 0.9. Those versions will remain this way, unless you update to, say, debian 13 whenever it comes out. But if you do your regular system updates, it will only do security updates (which do not change the behavior of a program).

You might wonder, why is the debian approach good? Stability. Software updates = changes. Changes could mean your setup that was previously working, suddenly isn't, because now the program changed behavior. Debian tries to avoid that by locking all versions, and making sure they are fully compatible. It also ensures that by doing this, you don't miss out on security updates.

The practical difference is the package manager; Debian-based systems use dpkg/APT with the .deb package format, Arch uses Pacman with .pkg packages.

Debian-based distros use a stable release cycle, so there are version numbers. The ecosystem is maintained for each version for an extended period of time, so if you have a workflow that requires a specific era of software, you can stick with an older version of the OS to maintain compatibility. This does not necessarily mean the software remains unpatched; security or stability patches are applied, this tends to mean the system is stable. Arch-based distros use a rolling release, basically what they said they were going to do with Windows 10 being the "last" version of Windows and they'd just keep updating it. Upside: Newest versions of packages all the time. Downside: Newest versions of packages all the time. You get the latest features, and the latest bugs.

Debian-based distros don't have a unified method of distributing software beyond the standard repositories. Ubuntu tried with PPAs, which kind of sucked. Arch has the Arch User Repository, or AUR.

Arch itself is designed to be an a la carte operating system. It starts out as a fairly minimal environment and the user will install the components they want and only the components they want, though many Arch-based distros like Manjaro and EndeavorOS offer pre-configured images. Debian was one of the earliest distros shipped ready to go as a complete OS; I know of no system that offers the "here's a shell and a package manager, install it yourself" experience on the Debian family tree.

But given an installed and configured Debian and Arch machine, what can one do that the other can't? As in, can it run [application]? Very little.

You can do pretty much the same things on either. The difference is one is a rolling release with fresh fairly untested packages and the other is a fixed stable system with no major changes happening.

You can “do” the same thing in Debian as you can arch, the main difference is packaging philosophy, Debian packages are older and more stable, while in Arch world you typically have the newest version of software packages as late as a few weeks from their release (the caveat being breakage is a bit more likely), Arch also has user repositories where the community can contribute unofficial packages