FreeCAD definitely has a steeper learning curve and a few rough edges, but to me it was absolutely worth it to learn. I really don't like my files subject to the whims of Autodesk.

This is why Google has been using their browser monopoly to push their "Web Integrity API". If that gets adopted, they can fully control the client side and prevent all ad blocking.

They almost certainly won't. Every so often they make a big show of these raids and then quietly drop it later. Check out some of Jim Browning's videos to see how the raids work out.

Arch Wiki for more general info. Official docs/man pages of whatever thing you are working with for details.

Honestly, I think his communication here is fine. He's probably going to offend some people at NIST, but it seems like he's already tried the cooperative route and is now willing to burn some bridges to bring things to light.

It reads like he's playing mathematics and not politics, which is exactly what you want from a cryptography researcher.

I think they already have. I held off on Wayland on my main machine for a long time due to Nvidia issues. For example, I was getting rendering issues where some windows/popups would be totally invisible until I moused over them. Those issues are now gone, and I've been running Wayland for the last few months with no problems at all.

The system will be secure for personal use as before.

I wouldn't be so sure of that. CPU side channels allow data to be leaked across security contexts. For example, from a user process to sandboxed JavaScript in a browser, from kernel space to user space, or from one containerized process to another. This is a problem even on a single user system without any VMs.

Things like taking screenshots and setting wallpaper actually do have a standard API. That stuff is just part of xdg desktop portals and not the core Wayland protocols. If, for example, a screenshot app uses the org.freedesktop.portal.Screenshot API then it should work with any compositor (as long as the compositor follows the API standards).

https://docs.godotengine.org/en/stable/getting_started/first_2d_game/index.html

Personally, I'd just slap some aluminum foil tape on there.

I don't see any fundamental reason why systemd would be insecure. If anything, I would expect it to be less prone to security bugs than the conglomerations of shell scripts that used to be used for init systems.

The bloated argument seems to mostly come from people who don't understand systemd init is a separate thing from all the other systemd components. You can use just the init part and not the rest if you want. Also, systemd performs way better than the old init systems anyway. I suspect many of the those complaining online didn't really have first hand experience with the old init systems.

If a different init suits your needs better, then sure go with it. But for the vast majority of typical desktop/server stuff, systemd is probably the best option. That's why most distributions use it.

1Gb EFI, rest of the disk LUKS with a single BTRFS inside. Use BTRFS subvols to divide things up. Swap as a swap file on BTRFS (be sure to set it as no_cow).