Really cool. This reminds me of escape rooms. Since they're a newer thing, a lot of them rely on modern low-cost DIY stuff like this.
31 karma · joined July 4, 2026
From what I remember, Wayland is a thinner layer than X11, basically handing clients pointers to shared buffers for them to write into, which seems better than X11's server approach. Thought maybe people were eager to switch for latency reasons, but this benchmark is showing otherwise. And would think Wayland is more efficient too, but I haven't noticed or heard of a difference.
Linux is about choice, but unless you're ready to write a lot of things yourself, it's outside your control how well parts of the ecosystem are supported. For an average user it's unacceptable for your entire GUI to suddenly change in a way that requires relearning, something that Mac and Windows have avoided doing at least since 2000. Even Win8 or Mac26 wasn't so disruptive. It's possibly worse for an average Linux user because they aren't just concerned with how it looks but also compatibility with advanced things like X forwarding or VNC or CRD.
I understand the limitation that you can never put a 128-bit address in a 32-bit field, and one way or another two hosts and everything in between have to understand the new packet format. That didn't force them to make ipv6 its whole separate network from v4 where almost no state is shared with v4. Having separate DHCP6 vs DHCP4 was a choice, likewise with DNS, NAT, and even the routing tables. It makes the difference for service operators who would be fine adopting ipv6 but don't want it to be a big project.
There's no one clever trick to make the transition easy, the idea is to preserve the v4 address blocks in v6. That cascades down to a bunch of different decisions, some of which include keeping NAT around. They've most likely thought of that too, and turned it down because they wanted to start with a clean slate and maybe also had some other vision of pure P2P apps.
Both of these might sound silly if you're used to protobufs, cause you can build little helpers for both, but plenty of people have never used protos. They would shrug proto away if there weren't someone like me to attest that it won't get in the way. It seems like Google focused on gRPC, but the real prize for adoption would've been going after the simple HTTP+JSON use cases. Like an official protobuf Express middleware.
Agree about the rest. Also I did have a note about 6to4 in there but had to remove it due to char limit. RFC 6343 has some retrospective on why it got abandoned, basically the config-free option (anycast) was too flaky.