Live data from Hacker News

Porting Tailscale to Plan 9

tailscale.com

71–80 of 100 posts

Re: Porting Tailscale to Plan 9

#71

Earlier quoted context omitted.

Doesn’t plan9 support frame buffers over 9p or something like that? You could probably write a wrapper that just forwards a Linux browser to a plan9 window

There are solutions, like VNC to some UNIX-ish machine, but, yeah, a native browser would be cool! 9front has a hypervisor, you could run something in there. https://man.9front.org/1/vmx

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.

Re: Porting Tailscale to Plan 9

#73
post #36

Earlier quoted context omitted.

Someone needs to convince Russ that it would be hilarious to have a full featured web browser in Plan 9.

Doesn’t plan9 support frame buffers over 9p or something like that? You could probably write a wrapper that just forwards a Linux browser to a plan9 window

It's probably easier to just run a VM directly into a window.

Re: Porting Tailscale to Plan 9

#74
post #36

Earlier quoted context omitted.

Someone needs to convince Russ that it would be hilarious to have a full featured web browser in Plan 9.

On 9 front there's vmx which is hardware virtualization. You can boot a Linux kernel with an nfs root from the local machine and use headless vnc to run a browser in a vnc client window. I'd also like to point out that most users of Plan 9 dislike web technology because it's a giant nightmare of code. No one human can even begin to comprehend the code base of Chrome, let alone Firefox - programs that are as big, if n…

> You can boot a Linux kernel with an nfs root from the local machine and use headless vnc to run a browser in a vnc client window.

Not only is the VNC redirection unnecessary, so it is the entire filesystem. You could just render the vm directly to the window and boot a read only image. Plus then you don't have to deal with VNC.

Re: Porting Tailscale to Plan 9

#75
post #59

Earlier quoted context omitted.

Oh yes I absolutely agree. I would definitely like to completely replace the web. It's just that in order to (currently) do my banking, pay my bills, book airline tickets, order from Amazon, etc. I must use a browser. If I could escape all that I would run Plan 9 exclusively without another OS or hacks to access a browser from another OS/virtual machine.

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.

> If you like you can experiment with this on a used laptop with supported hardware, thinkpad best.

I would avoid laptops altogether, honestly. Not a great fit.

Re: Porting Tailscale to Plan 9

#77
post #70

Seems like the real story here is that the Plan 9 port of Go is not particularly healthy, and that it's easier to modify an OS kernel than it is to fix Go?

The Plan 9 port of Go _was_ not particularly healthy. It is now.

Fixing Go to not special case Plan 9 benefits all platforms--- all operating systems use the same code paths now, making the code simpler.

Re: Porting Tailscale to Plan 9

#78
post #69

Earlier quoted context omitted.

the distributed computing model is pretty nice in theory (maybe not in practice) and the uniform system APIs are also nice. The userspace tools in particular are just plain better (structured regex commands are quite a bit better than ed-style and I find myself using them far more frequently in vis than I do in vim, they're far more composable and intuitive). The biggest thing is the heavy reliance on union file syst…

There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model. 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? In regards to using it for a "cloud native" stack, the issue is that people wan…

> 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.

Re: Porting Tailscale to Plan 9

#80
post #69

Earlier quoted context omitted.

the distributed computing model is pretty nice in theory (maybe not in practice) and the uniform system APIs are also nice. The userspace tools in particular are just plain better (structured regex commands are quite a bit better than ed-style and I find myself using them far more frequently in vis than I do in vim, they're far more composable and intuitive). The biggest thing is the heavy reliance on union file syst…

There aren't really union filesystems per se, the plan 9 kernel provides unions through its namespace model. 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? In regards to using it for a "cloud native" stack, the issue is that people wan…

> 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!

Post reply on HN