Yes Wayland doesn't have a printer protocol like Xorg, I know.
This is an incomplete list of protocols that aren't part of core Wayland. Compositors implement additional protocols that aren't even part of this process (e.g. wlr-screencopy-unstable). See the wlroota protocols here: https://gitlab.freedesktop.org/wlroots/wlroots/-/tree/master...
- Know the global state of your GPU cluster via the client.
- Target the most struggling GPU instances specifically since the client decides which one to hit.
You offer a free tier which means anyone can get an account and try to do it (e.g. you can have one "harmless, mostly inactive" free account with the only purpose of retrieving GPU cluster status, and a bunch of burner accounts to overload struggling instances).
I may be completely wrong, but this sounds like DDoS served on a silver plate to me.
It would indeed be very strange to hope your random users coordinate with your client side load balancer. You wouldn't even have to send real traffic. You could just manipulate redis directly to force all the real traffic to go to a single node. DoSing redis itself is also pretty easy.
If you know the architecture and oldest CPU model, we're better served with added a bunch more flags, no?
I wish I could compile my server code to target CPU released on/after a particular date like:
-O2 -cpu-newer-than=2019Did you consider making this a view instead? Just curious if there is a reason why you couldn't.
Deleted Comment
In some ways I think this is probably realistic, but it's not compatible with outcomes touted by boosters. They estimate 28 PJ/year, which is only about 0.9 GW. Stargate was planned to build 10 GW of capacity alone, so they can't both be true