There’s another launcher that I’m forgetting the name of that will launch Epic and GoG games. Following that proton guide should make NTFS (windows) drives usable for anything in Linux though. I can boot games downloaded from “alternate sites” if I add them to steam as “non steam games” regardless of how the drive is mounted.
There’s still the issue of overhead and such. Like I want to ditch windows forever, but Linux is just not 100% there yet with gaming. It’s very close though.
It is really fantastic. With steam almost all the games i bother playing just works. Deleted the windows partition years ago.
Just have to check the community forum how well it works before buying. Or just get a refund if it does not work.
Not sure if you are joking but Linux gaming is great now. I’ve been gaming for at least the last two years on only Linux. Check out www.protondb.com/explore
There hasn’t been a single game I’ve struggled to run in the last few months on proton. I haven’t had a windows PC in like a year ish or more?
I play games heavily too.
Try it out sometime if your setup isn’t extremely niche and maybe you’ll find it to be accommodating.
The weirdest things I’ve had to do are click a box in steam to enable proton usage and reinstall something in Lutris for Battle.net on world of warcraft.
Highly recommend Pop OS! It’s been very reliable. I haven’t had anything this steady since Mac OS when I was just doing programming. I tried to go from Mac to Alienware for personal computing and it was terrible, windows blue screened almost once a week if not once every four days.
Switched to Pop OS, enabled Proton in steams preferences for gaming, and it was completely steady. Only thing that doesn’t work is the hibernate. Which isn’t a super big deal to me.
I’d actually say everything has been a better experience than windows. Lutris and pop store have a large variety of games and apps. For example lutris supports GOG and probably epic games. It feels like it’s everything I’d want without the shitty user interfaces and lack of crashes.
when the new kernel comes out Linux users will be safe
It’s going to take a lot longer than that for most distros to move to latest upstream. This specific fix might be pulled in as a hotfix if you’re lucky, but it still takes time. The latest Ubuntu LTS is on 5.15, for example, which was released in October 2021. Debian Bookworm, which just released last month, uses 6.1 from December 2022.
This is exactly the kind of thing that gets backported to stable LTS distros tho. The kernel Major.Minor is just the base - it doesn’t tell the whole story.
Critical security fixes are backported. There where a lot of kernels released yesterday that had the fix. For 5.15, 5.15.122 was released with the zenbleed mitigation.
5.15.122 was released with the zen bleed mitigation
But Ubuntu users (for example) won’t get that automatically. Canonical still has to pull the upstream release, run validation, and roll out a patch. It will probably be speedy, but still on the order of several weeks before people see it by default.
So far the word is the microcode fix causes negligible performance impact, but using the MSR fix causes 5-15% loss. In my own testing on EPYC hardware, microcode made no noticable difference to my workloads and benchmarks. Same as random noise in results.
Google has reported that any Intel processor since 1995 with out-of-order execution is potentially vulnerable to the Meltdown vulnerability (this excludes Itanium and pre-2013 Intel Atom CPUs).
It wasn’t branch prediction alone, it was the cache combined with branch prediction. The problem is that even discarded outcomes fill the cache with data. Those older vulnerabilities also had the problem that the access permissions check was done after the branch prediction. It’s probably too expensive to do when it’s not even clear yet whether the branch is going to be taken (that’s just speculation on my part though).
The more steps in the instruction pipeline the more ways there are for there to be an error where some result doesn’t get erased when undoing stuff from the wrong branch. It’s basically like telling someone to move into a new house and get settled then stopping them six hours in and trying to make sure you get all their stuff out.
Updated amd64-microcode for EPYC processors appears available for several distributions which has mitigations available. I went ahead and proactively grabbed the microcode update from Debian unstable (not the best practice) and applied it without issue to my Bullseye/EPYC.
This isn’t exactly condoned as it’s not officially a backport, but I’ll take my chances as this is pretty critical.
Date of the updated microcode should be July 19th.
A CPU performs operations like “read a small bit of thing from the memory into the CPU” and “do a small bit of computation on things inside the CPU” and “put a small bit of thing from the CPU into the memory”.
Doing small bits of computation on things inside the CPU is very fast but moving bits of things from or to the memory is slow in comparison. In order to not be slowed down, CPUs read the code ahead of what is currently being executed, and try to guess what is going to happen and what will need to be moved from the memory into the CPU, so they can do it ahead of time, and have the small bit of thing from the memory already available right there in the CPU when it’s time to do a bit of computation on it. That way, there is no need to wait on slow memory, and the CPU runs much faster overall. That’s a good thing.
In this case, a researcher found a way to make certain CPUs guess what is going to happen with the code wrong, in such a way that the small bits of things that were read from the memory ahead of time do not get properly cleaned up, and can still be found inside the CPU by another program. Those small bits of things might be your password or banking details, so that’s bad.
Add comment