IIRC Nvidia needs explicit sync support to work reliably. It’s fairly new and might not have landed in some distros, especially the stable releases.
IIRC Nvidia needs explicit sync support to work reliably. It’s fairly new and might not have landed in some distros, especially the stable releases.
IPv6 has privacy addresses, though. Stuff on my network generates a new random address every day and uses that address for outgoing connections, so you can’t really track individual devices inside my network.
IPv6 has a policy of throwing more address space at stuff to make routing simpler, though.
IPv4 will individually route tiny slices of address space all over the world, IPv6 just assigns a massive chunk of space in the first place and calls it a day.
As a large language model, I don’t have an opinion on this subject.
Well, for starters, unless you’re running a quite old card you should be using amdgpu, not radeon. You seem to have them both loaded.
Post a dmesg?
My point is that gaming could abandon “A/B” in favor of something more like an actual spectrum of Height, Weight, and Gender Presentation instead of just awkwardly renaming the binary? I wouldn’t get so up in arms about gender replacing body type.
Okay, but an in-depth character creation system that lets you pick and adjust individual features is a lot more work than just manually creating two models and asking the player to pick one. Adding that means something else gets cut.
Putting in half a dozen body types and a boob slider shouldn’t be a ton of work, but devs who only offer two player models to choose from in the first place probably aren’t putting that much thought into character creation.
Reports are mixed.
If you want to post logs, I’ll have a look to see if I see any obvious problems: https://github.com/ValveSoftware/Proton/wiki/Proton-FAQ#how-to-enable-proton-logs
I think you only get the VRR setting if the screen does support VRR. No point asking the user if the system can’t do it.
ERROR: […/src/amd/vulkan/radv_physical_device.c:1877] Code 0 : Device ‘/dev/dri/renderD128’ is not using the AMDGPU kernel driver
This is the smoking gun, btw.
I see you’ve got it working, so I’ll just add a bit of explanation.
AMD GPUs used to use a driver called radeon
. It was replaced with the current amdgpu
driver. For a while, you had devices that were supported by both drivers and you could choose between the stable radeon
driver that was missing features like Vulkan and HDMI audio or the brand new amdgpu
driver that had the newest features but was unstable and not well tested.
The kernel has a policy of not unnecessarily breaking things with kernel changes so even though amdgpu
has been well tested in the years since, devices from that era still default to the radeon
driver and need to be forced onto the amdgpu
driver.
I mean, there is, but people have worked hard to set it up so you can just click the button and it all happens.
Slackware just does as it’s told and gets out of the way.
I meant to do this when I built my old system back in 2018, but I found the handful of games I regularly play worked okay on Linux so I never got around to it, and Linux game compatibility has improved leaps and bounds from there.
If it’s a Steam game, for most of them these days you only have to tick a box in Steam’s settings to tell it to use Proton for all games and the game will just work when you click play.
You might give it a try. Or don’t, I’m not your mother.
I’d argue that power is more the issue. All that processor time the antivirus spends scanning and rescanning is a chunk of battery gone.
They also wouldn’t allow the new devs to talk to the old devs, so they had to figure out the old codebase for themselves.
If stuff is designed for big servers that run Linux, it’s easier to get it to run on a desktop PC if the PC runs Linux too because then it’s the same thing except much less powerful.
You’re not supposed to use fc00::/8, so it’s just the fd00::/8 half that’s the new ULA.
That’s what temporary privacy addresses are for. Clients can just keep generating new addresses in your /64, which is it’s own subnet.
Yeah there is: not breaking all your internal traffic when the wan link goes down and you lose your prefix.
Because grabbing a random prefix from the pool is easier than remembering which prefix is assigned to which subscriber account and keeping it static through ISP network changes.
My ISP does ‘sticky’ prefixes, which means they change when they move users between BNGs but otherwise don’t.
The devs have been working hard to hammer out those troublesome edge cases. There’s a lot less of them than there was a year or two ago.