[HN Gopher] Porting Tailscale to Plan 9
___________________________________________________________________
Porting Tailscale to Plan 9
Author : adriangrigore
Score : 311 points
Date : 2025-04-02 15:29 UTC (7 hours ago)
(HTM) web link (tailscale.com)
(TXT) w3m dump (tailscale.com)
| mcdow wrote:
| Rob Pike is in shambles after this devastating betrayal
| pvg wrote:
| I'm sure it takes more than that to shamble an Olympic Silver
| Medal winner in archery.
| tiffanyh wrote:
| Isn't that a joke.
|
| He didn't actually go to the olympics.
|
| https://wiki.c2.com/?RobPike
| pvg wrote:
| It is pretty clear that neither you nor these 'c2'
| characters have lettered in anything, including the
| Olympics.
| rsc wrote:
| Not sure what the betrayal is? He contributed a quote for
| yesterday's post. https://tailscale.com/blog/tailscale-
| enterprise-plan-9-suppo...
| bakul wrote:
| from the above post: > April 1, 1999 >
| > FOR IMMEDIATE RELEASE
|
| Forward to the past?
| renhanxue wrote:
| _> In 1999, Intel introduced the Pentium III processor with SSE
| instructions._
|
| I kinda expected this paragraph to continue with
|
| _> This has made a lot of people very angry and been widely
| regarded as a bad move._
| o11c wrote:
| Better than MMX at least.
| mfro wrote:
| Russ Cox is an absolute legend for committing to this joke.
| pbohun wrote:
| Someone needs to convince Russ that it would be hilarious to
| have a full featured web browser in Plan 9.
| fiddlerwoaroof wrote:
| 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
| moody__ wrote:
| This has been done already:
| https://github.com/aiju/jsdrawterm
| samtheprogram wrote:
| This looks like the opposite -- accessing a plan9 system
| from a web browser?
| moody__ wrote:
| Yes you're correct, my apologies. There has been work on
| this going the other way as well:
| https://github.com/michaelforney/wl9. But there's still a
| lot more than can be done. There are vague plans to test
| the waters implementing something like this in to our
| vmx(1).
| fiddlerwoaroof wrote:
| I think this is the opposite direction?
| adriangrigore wrote:
| 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
| fiddlerwoaroof wrote:
| 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.
| numbsafari wrote:
| Many years ago a roommate and I had an HPUX machine running
| IE on HPUX just so we could forward X session to our
| FreeBSD and Linux desktops and not have to use our Windows
| machine for anything other than PC games.
| adriangrigore wrote:
| Yeah, convince Russ and some investors! :D I would laugh my
| ass off for years at this joke! Yeah, please do this next
| year's April Fools'!
| MisterTea wrote:
| 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 not bigger
| than the kernels they run on. That is an absurd state to be
| in - your runtime requires a billion dollar company to
| maintain. Even open source Firefox needs millions in funding.
|
| Whereas a single human can grasp plan 9 code from the kernel
| to user space. That's the runtime I want, something I can
| understand. The process is the container on plan 9 so you
| have everything you need to build distributed apps without a
| web browser. It's human scale distributed computing. I'd like
| a future without the "modern" corporate scale web.
| pbohun wrote:
| 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.
| MisterTea wrote:
| 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.
| facile3232 wrote:
| > 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.
| MisterTea wrote:
| That is the opposite of good advice.
| http://fqa.9front.org/fqa3.html#3.1
| facile3232 wrote:
| > 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.
| kanwisher wrote:
| wholly cow was not expecting them to patch the plan9 kernel to
| make this work
| nasretdinov wrote:
| Why not though? Seems like relatively little amount of work was
| missing since clearly no one seriously done something like this
| before :)
| packetlost wrote:
| I unironically wish there was an enterprise version of Plan 9.
| I've been writing most of my scripts in `rc` (something my
| coworkers put up with because we use nix and I can pull it in
| automatically with dirnev) and it has been great.
| yjftsjthsd-h wrote:
| I would worry less about other people being able to run rc
| scripts and more about them being able to read/edit them.
| packetlost wrote:
| they're routinely very short, and the only non-obvious syntax
| for someone familiar with a C-like language is the ~ command
| and redirecting to stderr. They're pretty much always easier
| to read (and write) than bash scripts in general because of
| how little weird/surprising syntax there is. Not being a
| derivative of ALGOL has its perks.
|
| Most scripts are write-once:read-never, especially if you
| actually implement -h/--help
| eddythompson80 wrote:
| > Most scripts are write-once:read-never, especially if you
| actually implement -h/--help
|
| I guess the answer is always "it depends", but that
| generally has never been my experience with most things.
| 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? Most
| 40+ year old Unix tools with a thousand flags have their
| limits and you have to script around them to achieve things
| you want.
|
| 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"
| packetlost wrote:
| > 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.
| packetlost wrote:
| 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/~chiefnoa
| h/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.
| moody__ wrote:
| Could you expand more on what you would like out of an
| "enterprise Plan 9"?
| zozbot234 wrote:
| It could be used to replace k8s-based deployments (also
| Docker Swarms, etc.) since system interfaces on Plan 9 are
| namespaced and containerized "out-of-the-box" as part of its
| basic design (and this is one of the most prominent additions
| compared to *NIX). It's not a hacked-on feature as with
| Linux.
| packetlost wrote:
| 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 systems
| (and file systems in general) and an extremely simple syscall
| API. It's a heterogeneous-networked-node OS so it handles
| realistic workloads natively with primitives designed for it
| instead of piling complexity on top of Unix-like APIs (ie.
| Linux). I dunno, I just think a lot of the modern "cloud
| native" stack is unnecessary if you had an OS actually built
| for the workloads we have.
| moody__ wrote:
| 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 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. 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.
|
| 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. It's hard
| to make the plan 9 backplane better enough to warrant
| dealing with integrating the guest and host environment.
| zozbot234 wrote:
| > 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.
| packetlost wrote:
| > 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!
| zozbot234 wrote:
| > Excluding graphical APIs, the basic stuff (file IO,
| networking, etc.) isn't all that hard to add to a
| language (it of course depends).
|
| You could implement a modern graphical API on top of
| virtio-gpu, which would give you low-level access to
| accelerated graphics.
|
| > The real trouble is things that have no equivalent in
| Plan 9, such as mmap and shm.
|
| Some uses of mmap and shm actually seem to have a near-
| equivalent already in plan9's segattach. Other uses would
| require some implementation of distributed shared memory
| (i.e. implementing the usual CPU concurrency model over
| the network) to be made feasible while keeping to the
| usual networked-OS focus of plan9.
| packetlost wrote:
| Right, you could do it... maybe. Some
| languages/libraries/runtimes could have specific
| expectations around the specifics of mmap that can't
| easily be papered over, but I suspect it would be a
| minority of cases
| 0xbadcafebee wrote:
| I like the premise of the joke, but then as the explanation ran
| on... I suddenly became depressed. So much broken stuff, so much
| complexity.... to, what, make a network tunnel? If all this extra
| work was the joke, _that_ would be funny.
| rsc wrote:
| We had to do some Plan 9 work, which makes sense when doing
| something new, but the actual Tailscale implementation is far
| _less_ work than for other Unixes.
| badc0ffee wrote:
| It sounds like the Go compiler is better after this effort -
| fewer Plan 9 special cases in the code.
| adriangrigore wrote:
| Webinar in progress (Google Meet)
| https://ftp.plan9.ts.net/webinar
| packetlost wrote:
| It just wrapped up, for those who would have otherwise been
| interested.
| facile3232 wrote:
| Plan 9 gets tailscale before a browser! Somehow this makes sense
| bradfitz wrote:
| Happy to answer any questions!
|
| A bunch of us are currently in https://meet.google.com/qre-gydb-
| mkv chatting about this. (Edit: the hour is over; we all left)
|
| The earlier Apr 1st blog post was
| https://tailscale.com/blog/tailscale-enterprise-plan-9-suppo...
| undersuit wrote:
| I've never set up a Plan 9 system... does this allow the
| distributed systems communications to run through my Tailnet?
| bradfitz wrote:
| I think so! Caveat is I've never really used Plan 9 outside
| of single-user VMs.
| MisterTea wrote:
| Yes, you could do something like keep a small root fs or pack
| everything into the kernels paqfs to boot into a Tailscale
| VPN and pull root from another 9 machine on the VPN. Then
| pull resources in from other machines including non 9
| systems.
|
| Either way it makes VPN easy between 9 and non 9 machines.
| Otherwise Plan 9 can do it's own VPN-like over tls or ssh
| tunnels and bind remote network stacks to a local namespace.
| But that makes seamless Unix and Windows comms difficult.
| bradfitz wrote:
| > Otherwise Plan 9 can do it's own VPN-like over tls or ssh
| tunnels and bind remote network stacks to a local namespace
|
| Note that one of Tailscale's main party tricks is NAT
| traversal, when both machines are behind different NATs and
| can't otherwise get a connection open to each other. (And
| then Tailscale ultimately falls back to a relay server on
| the internet if it can't get a direct connection for IP
| packets)
| MisterTea wrote:
| 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.
| bradfitz wrote:
| If your 9front machine is in a position on the network
| whereby it could serve a NAT, you don't have many
| networking problems at that point. Almost all operating
| systems can do NAT in such a position.
|
| I'm talking about two machines deep in somebody else's
| network or where you don't control the router/NAT.
| Gualdrapo wrote:
| Yet I still wonder how cool things would be if Plan9 was the most
| popular and used OS
| chaz6 wrote:
| Please consider RISC OS next!
| fidotron wrote:
| Three button mouse dependent UI solidarity!
|
| Golang on RISC OS would be a truly ludicrous porting effort.
| calvinmorrison wrote:
| The 9fans list had this one for April Fools:
|
| Given the huge maintenance cost of immature computer
| architectures such as mips, 386, arm, arm64 and amd64, we decided
| to put our focus on the more mature and stable achitectures:
|
| power64 and itanuim.
|
| Therefore, all architectures other than power64 and itanium are
| thereby frozen, conserved and promoted to end of life.
| chrsw wrote:
| My employer-controlled browser won't let me access that URL. At
| first it was cert errors and now it's just blocked.
| bradfitz wrote:
| Weird. It's just Vercel on AWS. We have no alerts firing about
| any probers having cert errors or anything.
|
| I wonder what your employer/policy doesn't like.
| jen20 wrote:
| I've found that tailscale.com sometimes gets blocked by
| overzealous content filters as "VPN software".
| neckro23 wrote:
| IME some web security gateways block the Tailscale domains
| entirely, presumably because it's a VPN that can bypass said
| gateway.
| fultonb wrote:
| This is so cool to see. Plan9 was a wonderful part of my COVID
| isolation, and I miss playing with it. This might have inspired
| me to spin up a 9front VM this weekend.
| bradfitz wrote:
| Note that the 9front patches to run Tailscale are still in
| progress. I was just told they'll be ready in a couple weeks.
|
| For now only 9legacy (with all the latest changes) works.
| MisterTea wrote:
| > This might have inspired me to spin up a 9front VM this
| weekend.
|
| Please do! Just be careful with your sysupdate.
| gbraad wrote:
| I do expect tailscale drive shares to use 9P in that case ;-P
| bradfitz wrote:
| Indeed. We ran out of time :)
| breckinloggins wrote:
| God I love plan9. Making my own os using many of its principles
| is a retirement project life goal.
|
| EDIt: I reserve the name "chaos10" for this project, since - like
| SerenityOS - there will be no plan.
| raggi wrote:
| In case y'all missed it in the first post, and you just want to
| try this out, it's working in this v86 image:
|
| https://copy.sh/v86/?profile=custom&m=768&vram=16&hda.url=ht...
|
| You can start tailscaled and tailscale inside the VM. It may take
| a while to come online sometimes due to limited proxy
| availability.
|
| Edit: alt gives you the third button. To start a terminal, hold
| alt and right click, select new, release alt, and right click
| drag to size the terminal window.
| stonogo wrote:
| 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?
| bradfitz wrote:
| 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.
| pjmlp wrote:
| Great, maybe Inferno as follow up?
___________________________________________________________________
(page generated 2025-04-02 23:01 UTC)