I feel like there’s also the point that on Mac OS a lot of stuff “just works” because everything else just doesn’t work at all. I have a number of things that just aren’t going to work at all on Mac. Linux is obviously much more permissive, which leads to a lot more kinda working stuff that just wouldn’t work at all on Mac.

The compositors are the ones doing a lot of the protocol development. They want to have WIP versions so they can see what issues crop up, they’ve been making versions all doing. Now, I agree that it is slowing things down, but it’s more of just an additional thing that needs to get done, not so much a chicken and egg problem.

Wine and Proton have actually put a ton of work into Wayland support, it’s very far along. I wouldn’t be surprised for Proton to have a native Wayland version soon.

Also XWayland has many limitations as X11 does.

If an app has only ever supported X11, then it probably doesn’t care about those limitations (the apps that do care probably already have a Wayland version). And if an app doesn’t care about the extra stuff Wayland has to offer, then there’s not really a reason to add the extra support burden of Wayland. As long as they work fine in XWayland, I think a lot of apps won’t switch over until X11 support starts dropping from their toolkit, and they’ll just go straight to Wayland-only.

Programming languages is way too broad a category. There’s a lot of variation in both power and difficulty.

The last commit was two days ago and the last update was two months ago (at least for me on Android).

No shame in having to switch back after giving it a try and running into a lot of issues. Having to reboot a lot is definitely unusual, there’s probably something wrong with your setup, but who knows where the issue is or how long it would take you to fix. Hopefully you can give it another try in a few years and those issues have been resolved.

While this is still a massive problem, it does require a public fork at some point. So if you have a private repo that has never had a public fork, you should be safe.

From my own looking into this it looks like more of a suggestion than a request (for now at least), just a “this might be a good idea, we should look into it”.

The deleting most emails is very interesting. In my personal email, I’ve been saved quite a few times by finding emails multiple years old. But I can definitely see how things would be quite different in a work email, and I may consider trying that myself.

The issue is one of licensing, not technology. There’s all kinds of patents in the space, and using free codecs could still infringe them. DirectX doesn’t have the same patent protection. I believe in theory you could make a fully open source Linux native version of DirectX.

For more info from someone who knows more than me, see here.

Well, sometimes Windows games depend on propietary codecs, and until Valve can get the devs to make adjustments so the codecs aren’t needed, the games aren’t going to work properly in regular Proton.

If GE received a Cease and Desist, that would be frustrating, but linux gaming would go on. If Proton got a Cease and Desist, that could be catastrophic to linux gaming. Valve could even theoretically get banned from working on linux gaming (like the Yuzu devs got banned from working on emulation). It’s just not worth the risk for compatibility/performance for a smaller proportion of games.

I need some advice on what to throw on this laptop - and some suggestions on how to squeeze the best performance out of this (Optimus vs. Proprietary NVIDIA vs. Open source drivers).

One thing here, the open source Nvidia drivers still have a lot of performance issues. It’s only fairly recently that NVIDIA has opened their drivers up enough to allow any kind of reasonable performance from open source drivers, and getting them up to par is still a work in progress. So stick with the propietary drivers for now, but keep an eye on the new open source driver, NVK.

(As far as distro recs go, I recently started using OpenSUSE Tumbleweed and am really liking it, but I don’t have enough experience with it yet to make an informed recommendation)

Nvidia already opened their driver, at least to the same extent as AMD, which is why NVK is able to exist.

I’m not sure about the latter

I believe it was Xwayland 24.1 that recently released that brought explicit sync support, so you’ll need that.

Seems like a good redesign.

Yep, this is what I had to do.

Nvidia users will also need a DE update, but yeah, we’re finally almost there.

will not solve issues with compositors not having it

Many compositors already have patches for explicit sync which should get merged fairly quickly.

graphical libraries not having it

Both Vulkan and OpenGL have support for explicit sync

apps not supporting it

Apps don’t need to support it, they just need to use Vulkan and OpenGL, and they will handle it.

Wayland doesn’t implement sync of any kind, they probably meant to say “the Wayland stack”

Wayland has a protocol specifically for explicit sync, it’s as much a part of Wayland as pretty much anything else that’s part of Wayland.

Nvidia is not the only driver that needs to implement explicit sync.

Mesa has already merged explicit sync support.