August 2, 2026
X Gon’ Give It Not
Sharing an X11 Server Across Hosts with FamilyWild
One tiny file tweak beats the dreaded X11 lockout — and yes, the comments got spicy
TLDR: The article says a tiny edit can make remote app sharing work without disabling security entirely. Commenters split between “nice fix,” “just use a different tool,” and nostalgic old-timers reminiscing about the gloriously unsafe 1990s network era.
A wonderfully nerdy fix turned into a full-on comment-section soap opera after one developer showed that the infamous “why won’t this app open?” problem can be solved with one tiny edit to an access file. In plain English: instead of throwing the doors wide open with the risky “just let everyone in” shortcut, the trick is to make the passkey work from any machine while still keeping the lock on. The article’s pitch was basically, “stop using the digital equivalent of leaving your front door open,” and the community absolutely ran with it.
The biggest divide? Team Safe Fix versus Team Just Use Something Else. One commenter breezily shrugged that they “mostly get away with xrdp,” which had big “works on my machine, good luck everyone” energy. Another reader jumped into the weeds to argue the article wasn’t even fair to the old-school shortcut, saying if you’re going to mention the broad version, you should also mention the narrower, more careful versions too. That sparked the classic internet mini-drama: is the author responsibly warning people away from a foot-gun, or oversimplifying for effect?
Then came the nostalgia flex. One commenter dropped a 1996 university war story about giant Sun workstations, public internet addresses, old Windows boxes, and the wild-west days when people casually ran graphical programs across the network like it was nothing. That memory lane detour gave the whole thread a chaotic “kids these days don’t know” vibe. So yes, the article was about a tiny technical fix — but the real show was the comments arguing over safety, convenience, and whether the ancient hack was misunderstood or just plain cursed.
Key Points
- •The article says X11 authentication can fail in containers, chroots, or remote contexts because .Xauthority entries are keyed by both family and hostname, not just by the cookie.
- •A cookie entry such as `myhost/unix:0 MIT-MAGIC-COOKIE-1 ...` is host-specific, so a client on a different hostname may not offer the cookie even when it is valid and mounted correctly.
- •The proposed fix is to convert the entry’s family to FamilyWild (`0xffff`) using `xauth nlist`, `sed`, and `xauth nmerge` to create a portable Xauthority file.
- •The article shows binary dumps to demonstrate that only the first 2-byte family field changes, from `0100` (FamilyLocal) to `ffff` (FamilyWild), while the rest of the record remains identical.
- •The article advises using a FamilyWild cookie instead of `xhost +`, which it says disables access control broadly and can expose keystrokes, windows, and input injection to other reachable clients.