Nayviler

I'm certainly no expert in this area, but I believe this is configured in the browser itself? https://support.mozilla.org/en-US/kb/firefox-dns-over-https

Perhaps there's another way to do it system-wide, but I wouldn't know it.

Not only will the performance not be any better on amdgpu-pro, the performance will most likely be worse. Even AMD recommends that people who don't need to do machine learning or AI work, use the built-in driver.

Unless they're poorly written, native games will always run better. The GTA IV PC port is fine.

It was a couple months ago that I set this all up, but this is the article I followed IIRC: https://woshub.com/how-to-repair-deleted-efi-partition-in-windows-7/

This is technically only true if you have a single disk. The EFI spec allows for a single EFI partition per disk, so you can definitely have multiple in a system. I know this, because my setup has multiple EFI partitions. Windows doesn't like it, and it will try it's hardest to share a single one with Linux, but if it's on its own disk, you can set it up with its own EFI partition using the command prompt.

Linux Mint is great, Ubuntu is ok, I'd stay away from Manjaro. The Manjaro team is known for selectively delaying updates, which can break systems sometimes.

Teams and VirtualBox both work fine on Linux, though personally I'd recommend just using teams in the browser vs downloading the app from Microsoft.

Most games work great on Linux! A really good resource for seeing if the game you want to play works is ProtonDB. There's a compatibility rating for almost every game on Steam there (even if you didn't buy the game on Steam, ratings for the Steam version should be fairly accurate). For non-steam games, WineHQ AppDB is another good resource, though I've found it can sometimes be a bit out of date when it comes to compatibility (in a good way, it'll say games are broken sometimes when they actually work fine).

For Epic, you can use the Heroic Games Launcher. It's an open-source launcher for Epic and GOG games. It'll automatically handle setting up a wine prefix for you and everything, so all you should need to do is click "install" and then "play" once it's done. Uplay is a bit more difficult, since there's no Linux-native launcher, but it's not impossible. I believe Lutris has an installer for it, you can definitely find instructions on how to do this online.

I'm not gonna lie and say that gaming on Linux is as easy as it is on Windows, especially for a beginner. These games and apps were designed for use on Windows, and if any consideration was given for Linux, it was an afterthought. However, it's completely possible for many people to never have to use Windows for gaming. It's so, sooooo much better than it was just a few years ago, and it's only going to improve from here. You might struggle a bit as a beginner, but with time you'll learn more about how all this stuff works and eventually, if a game doesn't work, in most cases you'll be able to figure out why and fix it.

Personally, I can't remember the last time I just wasn't able to get a game running on Linux at all. There was like, one instance where cutscenes didn't work, that's the worst case I've ever encountered. I mostly stick to single-player games, but still.

Yes, that pop os. As luck would have it, Linus installed it during a very brief period where the steam package in their repo was broken. This is not a common occurrence, and I have never heard of it happening before or since.

If you want to check that a machine you're buying is compatible with Linux, a good place to start is to google how to install drivers for the computer's components on Linux. Check the common problem areas (WiFi, graphics, sound, etc.) and see if you find lots of other people complaining about those components. If you find evidence that a driver is available, or you can't seem to find any info either way, it's probably fine.

I can't really answer the question you had regarding this site you found, but that is my general strategy for checking Linux hardware compatibility.

Also make sure that the retailer you're buying from has a reasonable returns policy, just in case you get it, install Linux (or run it from a live USB, to avoid wiping the disk before you know you're good), and discover something doesn't work.

I don't believe the setup is a fallacy, the AUR is one of the main reasons I use Arch. Sure, other distros may have similar systems in place, but the number of packages available on these systems just doesn't compare. I did a brief amount of research, according to the FreeBSD manual, there are "over 30,000" ports available. In comparison, there are over 90,000 packages available on the AUR, and all of those are in addition to the ~13,000 packages in the official Arch repositories. If I want to obtain a piece of software, even if it isn't in the arch repos, odds are, someone has already gone through the trouble of figuring out how to build/package it, and has added the PKGBUILD to the AUR.

This way of doing things is so much more elegant compared to how things are done on Debian or Red Hat-derived distros, where the solution to the problem of a piece of software not being in the official repos is to either (1) scour the internet and try to find if the developer maintains a repo for your distro, (2) look to see if a third party has packaged the software for your distro, and hope and pray that they maintain it, or (3), compile the package yourself, after manually hunting down all the various libraries the application needs, determining what they're packaged as for your particular distro. The third solution doesn't handle updates at all, unless the application's developer has built-in an update checker into it.

Things are getting better as snaps and flatpaks gain popularity, but both of those systems have lots of issues of their own, and arguably aren't anywhere near as good as a proper native package for your distro. Flatpaks don't really work for CLI tools. Snaps are stupidly slow. Both snaps and flatpaks still struggle with theming. Applications installed with either take up way more space than their natively-packaged equivalents.

Perhaps this is SUSE's time to shine 😄? I believe SUSE Enterprise Linux has a product that allows for binary compatibility with RHEL and CentOS on SLE.