Porting Tailscale to Plan 9

For situations where you have no control over the NAT then this is indeed the case.

Though, 9front lets you run your own NAT giving you an Internet facing 9 machine you can serve a TLS tunnel from directly. So the server side is solved making the client side NAT a non issue.

This looks like the opposite -- accessing a plan9 system from a web browser?

I think this is the opposite direction?

So, something I’m thinking about here is that the 9p vision has always seemed really cool to me: expose all the resources in the network in a unified way that enables the whole network to be used as if it was a single computer. But, since this is a protocol-oriented vision of computing, it enables arbitrary implementers of the protocol to participate “natively”, even if they aren’t actually plan9 systems.

You're making me explain this whole post. :p

Their April Fools' jokes are real and work as you can see in the submitted link.

So basically, a Plan 9 web browser, would be a great April Fools' prank! (because, again, their "pranks" are real and work)

Totally get it. Vmx on 9front with a Linux or BSD VM is the way to go if you want to try to go 100% 9. If you like you can experiment with this on a used laptop with supported hardware, thinkpad best. It's not lightning fast at the moment (patches welcome) but it works well enough.

Even though most of the UIs I work on nowadays are Web based, I miss the native apps with Internet protocols, and most of my side projects are native apps, nothing to do with Web.

You can, just not all at once.

And which plan 9 release and when? Ghostscript and Python were originally distributed with 9front which are both HUGE compared to the rest of the system. Remove those and its much, much smaller. Unsure if ghostscript was included in vanilla 9 from the labs. Python was included in 9front because it was necessary for mercurial. Once git9 arrived python was nuked from base and removed many lines of code. Ghostscript is next to go from base once pdffs is running (patches welcome.)

> Are you over-engineering the shit out of every script to the degree the script itself is a Turing complete machine and with enough —-help flags anything is possible?

No. They're 30 line scripts with 0-5 or so flags. They mostly exist to remove choices from other utilities. Put another way: create named (and namespaced) abstractions by making choices and slapping a name on it. They're functions.

> In my experience, eventually a business need will arise that require you to change a script. Are your coworkers comfortable changing these scripts or are you in the mind set of “that’s a simple enough change, I’ll do it”

They're small enough that they can be ignored if they don't do exactly what you want. I'm fine changing them, but it's most likely they'd just get rewritten or bitrot after I'm gone.

Not work related, but here's some examples of what these scripts look like (this is how I mirror public repos locally using cron/timers): https://paste.sr.ht/~chiefnoah/3b8990fc0b8eb3f50e511d5d4051a...

Even if you aren't super familiar with rc, it's not that weird to look at. I find it way more readable than (ba)sh syntax.

> Unless someone does a great deal of effort to port all of those environments that people want (nodejs, modern python, etc) you're going to be stuck using a VM and losing a lot of the benefit.

It should not be a huge deal of effort since as you mention the plan9 syscall API is simpler than on Linux. The added plan9 support could then also serve as a kind of "toy" backend that could make the rest of the code more understandable in other ways.

I'd even argue that OP's early experiment with such a port of tailscale shows precisely such an outcome.

> There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model.

Yes, this is what I'm referring to. It's really many filesystems unioned into one namespace that is controllable per-process.

> In my opinion part of the reason why the userspace tools can be as nice as they are, are due to the use of file system interfaces and the simplistic syscall API. Could you elaborate more on the issues you see with the use of these?

I didn't say I had any issues, I said I preferred them! Aside from a lack of familiarity and needing to install plan9ports on other systems, I haven't had issues.

> In regards to using it for a "cloud native" stack, the issue is that people want to run code that isn't designed for Plan 9. You could build whatever backplane type thing you want out of plan 9 but the end goal is still likely to be to run some web app or REST api server.

Right, language support is the biggest issue with running on Plan 9 from that perspective, at least for "server" workloads. Excluding graphical APIs, the basic stuff (file IO, networking, etc.) isn't all that hard to add to a language (it of course depends). The real trouble is things that have no equivalent in Plan 9, such as mmap and shm.

> This feels similar to what Joyent did with lxzones in SmartOS, where the backplane was solaris based but the apps they were running for clients were using Linux.

This is also what Oxide is doing. Their rack's OS is IllumOS but their customers are expected to only interface with the OS via their tooling and instead provision VMs.

> It's hard to make the plan 9 backplane better enough to warrant dealing with integrating the guest and host environment

If I were doing it, I would do it the other way! Run Plan 9 in a backplane/hypervisor and target it from the language level. The nice part is the systems programming model!