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
Porting Tailscale to Plan 9
71–80 of 100 posts
Re: Porting Tailscale to Plan 9
#72Re: Porting Tailscale to Plan 9
#73Earlier 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
Re: Porting Tailscale to Plan 9
#74Earlier 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…
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
#75Earlier 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.
I would avoid laptops altogether, honestly. Not a great fit.
Re: Porting Tailscale to Plan 9
#76I do expect tailscale drive shares to use 9P in that case ;-P
Re: Porting Tailscale to Plan 9
#77Seems 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?
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
#78Earlier 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…
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
#79Re: Porting Tailscale to Plan 9
#80Earlier 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…
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!