Ralphred

Look up the "Windows AME project". It used to be against the rules to discuss it here because they sidestepped activating windows by supplying an ISO, but they just provide scripts to turn windows into "windows light" now. I can run it in a VM (with GPU pass through) and the overhead of linux and winAME is lower than native windows, and it performs quicker. I don't know what full full experience is like, but it runs my windows only (the very few I have to now) games fine.

Did you alter this file to match your "shared" GPU? What re the outputs of cat /proc/cmdline and lspci -k|grep VGA -A5?

It's worth noting that you can can install drivers "without purpose" with no ill effects in Linux - they will just sit there idle and unused until you plug in the hardware they were written for.

Not really requests, you just seem to be taking a sensible approach with the intention of learning something - your experiences will be able to help others here if well documented.

Please do, and remember to write your thoughts on each distro as you use it, it'll just become a blur of "things I didn't like, but can't remember why" if you don't

A quick read of their page makes it sound like "Matured Fedora". One reference that stuck out was the EAC/GLibc configuration issue, to my mind it means they have their finger at least close to the pulse of the gaming community, but whether the red hat devs (ultimately responsible for their source) are causing their work to be cut out for them is another question. I saw nothing on their page that would make me say "kill it with fire", but from the point of view of an OS "doing what it's told to and nothing more" my guess is that it's footprint **might** be larger than necessary. My advice, try it - if it doesn't tick all your boxes kick it to the curb and move on to something else. Generally i'd say find your 3~4 tops picks, try each of then, assess them "out of the box". If nothing fits the bill install Arch or Gentoo and force it do so...

I 'feel' the same, but we can't have our Linux OS's bending to our every whim AND expect studios to support them the same as a psuedo-static target like windows. Just step back and take the wider view, the Steamdeck and Valve have propelled wine development to the point it's mostly seamless, and there are more gamers using linux now - for those of us who have been doing that for a long time the money from those 'new linux gamers' is feeding development and making our lives much MUCH easier.

Ubuntu used to ship (less so today) many different versions depending on which desktop it supported out of the box. The point of the * is not censorship but to glob, so it means {ubuntu, kubuntu, xubuntu, lubuntu} - Games don't care what DE you use, they are more interested in your core libraries and graphics stack. It's to avoid the "People said to use Ubuntu, but I want KDE/XFCE?" confusion.

I have some of their stuff, and it worked fine at the time of purchase - all credit to them. To be fair, you can't expect them to support every distro devs patch de la jour across all time, there needs to be a static target. The ones that no longer work; I CBA with diagnosing that, ticking the box next to an "era appropriate" proton version is much easier than working out what changed in my OS since 2015...

When you consider the steam-runtime is based off of Ubuntu libraries, *buntu isn't such a bad choice. As far as I know these are the only two distros that let you mix and match stable, testing and alpha quality packages out of the box, but that requirement only seems necessary for the first 6 months of "newborn hardware", after that stable drivers are fine.

If you have no way to elevate privilege then you need to boot using a maintenance disk, chroot into your OS's environment and set/reset the root password for further admin after a normal reboot, or fix your equivalent of sudoers, /etc/group etc before rebooting.

So you changed the way drives are used and presented to the OS by the BIOS, and "maybe" this caused a disk error, really?!?!? The answer you seek is here!

Get a pinout for the chip first and make sure they are in use, they could be redundant.

This is what the "database server" use case is designed for; whilst I understand your hesitancy, it's only really warranted for Access/MYSQLite style databases, and any "auditing" you do needs to recognise that you are working on a snapshot, so "auditing adjustments" should be relative and not absolute.

No, they are "matched pairs", you have to RMA the whole part (i.e. a pair) no just 1/2 of it: There is no way to match 1 stick to it's "other half" without it being present to read it's tolerances - this is how they can sell devices that are "meant to be overclocked". If you look for a "slower part number" it came from the same source, on the same line, it just didn't test as well, so gets sold cheaper as a slower version, mass production of solid state electronics has always been like this: a 1N4006 is just a 1n4007 that failed 1000v testing, but passed 800v testing etc.

Hmm, kinda. If you bought 2x "Corsair Vengeance 2x16GB DDR5 6000MHz CL36" and expect them to work as a "Corsair Vengeance 4x16GB DDR5 6000MHz CL36", well, just don't; the odds are against you.

Nope, sticks are paired; get a new "pair" (i.e. return them both).

Domain management isn't as complicated as people think. For DNS hurricane do free DNS for static IP's, afraid.org do dynamic (and will email you if your dynamic is 'static' for over 12 months (as a way of pruning redundant records)). If you *need* the simplicity offered by Cloudflare, by all means use it, if you don't - please move on. Indeed, SMB/CIFS is one of the most probed for/exploited protocols.

The ones that "do what *you* want" out of the box, without tinkering. If you can't find one that does that - it's Debian, Arch and Gentoo.

Why? What is the criteria for the difference, redundancy, HA or homework? If it's the latter, feel free to go fourth and multiple - alone.

It does what I tell it to, nothing more, nothing less.

XRANDR is the xorg extension that changed (some of) the nomenclature of config files and allows userland alteration beyond pre-defined modelines, it's the backbone of "modern automagical" configurations, which is fine when it works, but as I said a PITA to deal with when it doesn't. output DP-2 mode 3840x1600@143.998Hz can be fixed in xorg.conf (as it should be), but (like I said, again) only people who read man xorg.conf and old school admins know how to do it.

Yep, these "1.2v NiCad" cells were ubiquitous when non-lead acid rechargeable batteries hit the market, and were considered "rechargeable replacements" for standard 1.5v alkaline/acid single use cells. The low internal resistance lead to the revolution of higher current uses, such as your screwdriver. Because of the charge/voltage curves it was common to charge them as "a single unit" (whether in parallel or series) with low current trickle chargers. Searching for "1.2v rechargeable tagged cell" from suppliers like Farnell.com, rswww.com or newark.com should yield a list of results that are suitable NiMH replacements, BUT I'd check with the local "mom & pop" electronic model store first; these cells were extensively used for model cars/boats etc. If you have the original charger it should be fine with NiMH cells, if not you want a current limited and voltage limited trickle charger: Charging time should be around 9~10 hours, so current limit appropriately for the capacity of the cells, and if in series limit to 3v. Personally I'd tap the "middle tags" and create a 2 circuit charger with high initial current burst that tails off into trickle charging after ~1.3v per circuit, as the NiMH cells can handle that. DON'T use a charger for lithium based cells, the charge/voltage curve is different and the best case scenario is shortened battery life/sub-optimally charged cells.

Just post the output of fstab; you need to edit the two drives it's checking for so they actually match yours.

It can be, but they will be mounted purely in "userspace", usually in /run/user[id] somewhere. It may or may not be consistent (regarding naming and mount location), and is probably being run after you login as it needs your valid credentials to do so. TBQH putting the relevant entries in /etc/fstab would probably solve the issue, as local filesystems are mounted early on in the boot process, this will also allow you to create consistant mount points.