Porting Tailscale to Plan 9

Summary

It’s been said that nothing helps land a joke like explaining it, so here we are to explain yesterday’s Tailscale Plan 9 announcement, even at the risk of killing the joke. But really, if we had to kill a joke by explaining it, there’s no better type of joke to kill than a corporate April Fools’ Day post. They’re admittedly pretty terrible in general. I’m of the opinion that if you’re going to do such a joke, you better put some effort into it; it should actually work. (Otherwise it’s 100% sad instead of whatever percent sad yesterday’s post was.) And to be super clear today on April 2nd because nobody believes anything on April 1st: Tailscale now actually works on Plan 9. For reals. We were amused to find everybody in shock that there was a PR attached to yesterday’s blog post so let’s dig into that PR a bit, and other work that went on. First off: I don’t really know Plan 9. I know of Plan 9, and I know people who know Plan 9, but I’m a Plan 9 newbie and I apologize in advance if I offend any Plan 9 people with my ignorance. I tried to check my cluelessness with others to make sure it’s not too stupid, but there are surely some inaccuracies in these posts and bugs and shortcuts and simplifying assumptions in the code. Anyway. As the quip goes, “We chose to port Tailscale to Plan 9 not because it was easy, but because we thought it would be easy.” Naively it kinda seems like you’d take Tailscale’s two Go binaries and build them with GOOS=plan9 GOARCH=386 go install ./cmd/tailscale{,d} and call it a day. Sure, I expected some syscall or x/net or x/sys/unix symbols to not exists with GOOS=plan9 and some //go:build tag adjustments and some special cases for runtime.GOOS == "plan9" to use different default disk paths like we previously did for AIX, etc. So that’s what I tried in August 2023 when a local acquaintance here in Seattle asked me for Plan 9 support and I finally caved and said okay (after initially rejecting the idea). I tweaked some build tags & paths & com...