Hopefully this is as far as it goes and not something they will continually restrict each year. This feels similar to the Xiaomi situation which seems to have had the same problems in China, and they have gradually restricted unlocking more and more.

I just think the user should be the one to decide whether they enable it or not. Pre-built PCs and motherboards can enable it by default, but it should be simple to bypass (and it usually is) and no company should be demanding or requiring people enable it.

The same applies for TPM2, which is also useful but shouldn’t be a requirement. If nothing else because of the E-waste this can cause by requiring PCs to support it. And most new PCs will end up enabling it in the long run anyway, so there is no need to force the issue.

I suggest using Beetle mednafen, unless you’re on a very slow system. Or Swanstation, it’s not like that’s going away.

I also don’t see Swanstation going away any time soon, even if it gets no new features. It’s pretty close to feature complete in the ways that matter anyway.

I just overuse parantheses instead, as you noted. You know you’re rambling when you have several layers of them, like I’m writing a conversation in Lisp.

Having a web UI is useful even if you’re not using the extra tools. Not mandatory of course, but nice.

The sandboxing sometimes breaks applications or requires additional configuration. And I don’t like that it’s a separate thing I need to maintain, although some package managers pair main package updates etc together.

And as a NixOS user, I prefer to use nix to handle as much of my system as possible, although flatpak at least is useful as a fallback in a pinch. Of course, this is a niche within a niche and mainstream users, particularly those using immutable distros can and do benefit from flatpak.

I’m guessing it’s the AI agent stuff. Which at the moment is literally just automating browsing through a website.

Apparently there will be APIs to do this in the future. Ironically, AI wouldn’t even be needed for that to be useful.

Valve is one of the main contributors to the RADV Vulkan driver for AMD GPUs, and a bunch of other parts of Mesa and the open driver stack in general.

I should probably add that some of this work is on RDNA3 FSR4 support, which isn’t even supported on Windows. It’s not amazingly fast, but it’s now faster than native and that might be enough to make it worth it (especially in the cases where it improves image quality due to poor TAA implementations).

mpv supports Dolby vision (along with the Jellyfin clients that depend on it), but if you mean with streaming services, that’s unlikely to happen due to DRM.

It’s main benefit is compatibility. As you said fsync is a hack and can cause issues with some games and applications.

The other benefit is more about packaging and the like, in that you won’t have to deal with third party patches. Not an issue if you’re using Proton but can be if you’re using vanilla Wine.

Your kernel must be patched with ntsync patches. If your system does not have /dev/ntsync then your kernel does not have the patches required to use ntsync.

It might also be compiled as a module, but not loaded by default.

sudo modprobe ntsync can be used to test this.

Intel provides solid Linux support, I’d say it’s probably on par with AMD.

I’d say in the long run yes, but they tend to be slower at adding features compared to AMD (which tends to be where all of the experimental stuff happens first). Or rather that AMD cards are often the first target for Mesa developers, which includes the likes of Valve.

This article on the repo is also an interesting read:

Porting LSFG to native Vulkan

A bit of a downside is that the minimum driver requirements are pretty aggressive at the moment, so people could be stuck using WineD3D without realising it. But I suppose crashing isn’t really much better. And people who play games should use a distribution that moves pretty quickly in general.

I don’t have this controller but the Vader 4 pro was updated in the same update, and supports every single extra button + gyro at the same time, provided dinput mode is set.

Full compatibility means native steam input support, which means that gyro + back buttons work together. No need to emulate a specific console controller and lose out on either gyro or back button support.

It looks like mainly a Hyprland fix (and maybe some wlroots based compositors). The old method still works with sway for me, and there’s a another approach using a virtual edid that should work everywhere, but perhaps not with Nvidia cards (see here: https://discuss.kde.org/t/how-to-create-a-virtual-monitor-display/2725/5).

I’m not sure if Plasma or Gnome have any support for headless monitors outside of the EDID method.

Usually it’s fine. To be honest, most new release AAA games have problems on Windows too (and sometimes it’s worse, such as the first part of the FF7 remake).