In an ideal world the headline would be “Google kills Chrome by preventing users from blocking ads”.
In an ideal world the headline would be “Google kills Chrome by preventing users from blocking ads”.
FSR is an AMD technology and it’s not AMD exclusive. So one doesn’t imply the other.
From the repo:
A random DNS and HTTPS internet traffic noise generator provides enhanced privacy and security by obfuscating users’ online activities. It generates random, non-user-initiated queries to DNS servers and encrypted HTTPS connections, making it difficult for third parties such as ISPs, surveillance systems, or malicious actors to analyze and track actual browsing patterns. This added layer of traffic noise reduces the effectiveness of traffic analysis and profiling techniques, making it harder to identify specific behaviors, websites, or services accessed by the user.
Technically, even if your data is encrypted, the amount of data you send (and the time between packets) can be analyzed to at the very least figure out what website you’re on, and who knows what else (i.e. Youtube’s HTML, CSS, and JS files will be different than Facebook’s, so the amount of data sent will be different, and you can train an AI to recognize these patterns). This app pretty much it protects you against packet analysis from your ISP or anyone else who could monitor your network. I guess this assumes that you’re using a VPN or some sort of proxy since it’s not very useful otherwise.
This isn’t really driver related. It is the Wayland compositor’s job to properly handle multiple GPUs, which is lacking in some (a very popular, Wayland library that lacks proper multi-GPU support is wlroots) compositors. Vulkan drivers and DRM are already enough to properly handle multiple GPUs. I guess Wayland implementers just haven’t cared enough about the issue, or maybe are figuring out a “perfect” way to address it (a la 3 year long pull request on wayland-protocols repo incoming)
You know this for a fact?
How does it know when it’s right if you’re the one teaching it?
Doubt it’s a sway problem. You got it to work with waybar in plasma, or just in a terminal? Anyways, my setup is also sway+waybar so I’ll try to use cava later today.
They’re so done with NVIDIA they don’t even have the energy to attack them on a forum anymore
Interesting. Well it was worth trying I guess.
Try increasing the height of the bar to some insane value. Just to make sure it’s not cava being unable to scale down.
I didn’t know you could run kodi straight from the tty, sounds cool. And yes, kodi has Wayland support.
Running kodi on a cage session sounds like a nice idea. Cage’s whole purpose is to run 1 app maximized.
Yeah. Unfortunately most consumers buy NVIDIA, even though they only care about the enterprise sector.
Yes. Wayland protocols take too long to get merged. Actually, a few days ago some people (mostly Valve guys) got tired of it and took action by proposing changes[1, 2, 3, 4]to the way new protocols are handled. Hopefully it gets better. Also, if your compositor is based on wlroots, then you might get support for the new protocol very soon.
The screen capture protocol was merged a month ago. Support will come soon. wayvnc, grim (and by extension grimshot) already have support for it. No compositors have implemented it afaik, but wlroots is very close to it.
That is NVIDIA’s fault. They wanted everyone to use the inferior EGLStreams while knowing GBM is better. Everyone ignored them and moved on, so NVIDIA sucks on Wayland. They did change their mind recently so maybe you’ll get support at some point in the future. Unfortunately there’s nothing to do from the Wayland side to fix this, except for adopting EGLStreams which nobody will do.
There’s no protocol yet that allows apps to observe inputs. They just started working on it so it may be a while.
Steam is not Wayland compatible. The games you are playing are most likely not Wayland compatible. This is not a Wayland issue.
https://wiki.hyprland.org/Configuring/Binds/#global-keybinds