I’m on Arch, with Hyprland as my Window Manager. I use an RTX 3070.

For Wayland specifically, the driver was next to unusable for a while. I jumped ship from Windows in Sept. 2023. Beginning with driver 560 iirc, it got a lot better, plus their engineers pushed a lot of changes across the Wayland ecosystem to implement explicit sync support (a net positive, but before this, Nvidia was too stubborn to implement implicit sync, so bad screen tearing was unavoidable). Also there’s been a slow migration to using the GSP processor on newer cards. They claim it can improve performance, which may be true, but I also recently learned it helps them keep some more parts of their code closed-source, which is likely why it’s required to use the open source kernel modules.

At this point, though, it does feel very smooth and I can play games like The Finals at competitive framerates!

But relative to my performance under Windows, it’s still worse, mainly in average framerate. Like others have said, DX12 games seem to be hit hardest. I sometimes have to run lower settings to compensate. Also, if my VRAM gets filled, Xwayland apps all break, so I have to be very careful with higher quality texture quality especially.

Anyways, to answer your question, I think an average gamer doesn’t notice the degraded performance, without benchmarking or comparing framerates back to back— it still runs pretty smooth and framerates are still pretty high. If they aren’t happy with it, they’ll drop quality settings or resolution, just like they’d do under Windows.

Sick! That makes me want to use grindstones in building more, those look clean!

I read in the comments of your previous snapshot post that the Wayland default had some issues with cursor theming… perhaps that’s why it’s reverted? Odd either way.

You’re strawmanning their comment— I’d imagine they’d have the same, if not more, issues with snap.

Flatpak doesn’t integrate well with all systems. For me personally, on Arch, I have to update and store Flatpak versions of some dependencies, like proprietary Nvidia drivers, separately from the rest of my system and its package management system. And it does take up some space to store the runtime too.

Also Flatpaks may require some extra set up and/or workarounds due to their sandboxed environment. That’s not inherently bad and has some big security upsides, but it’s a consideration.

Also I don’t know how well it plays with immutable distros, but I’d imagine there may be similar integration issues there, too.

It’s still probably a lot easier for devs to have a consistent distribution format though, and they are typically more secure, so I’m not saying there’s not merits to only providing a Flatpak. Just pointing out that your reply here was misguided, imo.

Sorry for the late reply. Also @Cricket’s response is great and actually references a source!

Anecdotally though, as a user, I’ve noticed that some things require extra permissions. Usually there’s a prompt from the operating system that’ll ask for permission capture the desktop, which lets me specify which window or monitor to share. It uses the “XDG Desktop Portal”, which was already what allowed Flatpaks to securely access OS resources, and it has a whole bunch of different requests for resources and permissions. It’s similar to a web browser, where it’ll prompt you for privileges when an app wants them.

The hardest pain point for me has been that an app cannot detect keyboard input if it isn’t focused. This could prevent key loggers, but it also makes global shortcuts not work. There is a protocol that allows an app to request a key be forwarded to it, but it’s not widely implemented in apps (discord, for example) and I’ve had to rely on workarounds.

All good! You’re still totally right; outside of the context, Linux has quite the user base with servers, embedded devices, and even phones, if we count Android. I think that’s relevant because it means we can’t rely on “security by obscurity”.

I haven’t heard of any such cases, but it is a smaller pool of users. Also, many desktop Linux users know more about using a computer than other operating system users, since it’s less common for Linux to come preinstalled. So that may affect it, too.

I imagine vulnerabilities with the Linux kernel or common utilities do apply to desktop users as well, which is a good reminder why staying up-to-date is important. But to my understanding, exploiting remotely would need a way of sending data to the target. And most desktop computers won’t have ports open to the internet for anyone like servers will.

I know that Wayland’s design does make it more difficult for a user-mode program to act maliciously, like as key-loggers or reading the clipboard.

I’m sorry to hear you’re having trouble!

Regarding the vainfo thing, at least on Arch, the Nvidia vaapi driver is a separate package. I’m not sure what the equivalent is on bazzite, but that’s likely why vainfo doesn’t show anything. And you should still be able to use nvenc anyways, which sunshine will choose before vaapi.

Is moonlight able to see the computer on your network? And in sunshine’s web interface under the “troubleshoot” tab, there’s a log. Does it say anything that might help?

I’ve played a small amount with it— I didn’t go far because I only have one graphics card. But my understanding is that you can set up the virtual machine to “capture” the graphics card when it is booted up, and “release” it when it’s done. That’s how some people can use a single graphics card, they just can’t see the Linux desktop while the vm is in use.

For switching games, make sure the drive the game is on is supported by both Windows and Linux. I imagine you’d need to unmount it on the host while the vm is open. I do this for some games with dual booting. Also, install the Windows version and force proton, otherwise you’ll have to install it twice.

For microphone, I assume there’s a solution like network: a way of forwarding the data to the VM in addition to being available on the host. I haven’t tinkered with this though.

For monitors, I’d look into Looking Glass. My understanding is that it can make a window to display the vm output. If you don’t mind the monitor being “tethered” to the gpu, though, I’d imagine any monitors attached on the gpu you pass would display the vm’s contents, while any on the host card will remain the same.

Best of luck!

That’s fair— I’ve had to go looking for rabbits and breed them on each world I’ve gotten bundles in.

They’re great for early game— I’ve used them through the experimental feature to hold mob drops and other small-count loot. And I like being able to access them right from the inventory, though it is a bit tricky to get the preferred item out.

That’s all my praise. Shulker boxes hold lots more total and are way better post-dragon. And they could add the inventory access mechanic to shulker boxes.

Colored bundles are a huge W!

I’m a bit bummed that they don’t use rabbit hides in the recipe anymore… it makes it more accessible, but they’re an almost useless item. And Minecraft has a lot of those.

Idk where you heard that— I know there was difficulty implementing them with certain control schemes, so I think that’s where the delay came from.

Thanks for sharing this, it’s super awesome! I agree that subtle stuff like this adds up to make a fresh, polished experience!

I currently use and love bluetuith! I hope you are able to secure funding and contributors, as this sounds like it could be a great development.

Got home, it’s working really well. Like, I’m super pleased!

VRR still needs testing on my system. I know that there’s yet to be a fix for multi-monitor VRR. I still need to test with a single monitor, though.

YOOO!!

I can’t wait to get home for this! I’m going to try to use VRR again too, see how it plays with that.

Developers of Doom, Wolfenstein and Quake