Earlier quoted context omitted.
Hosted on a plan9 system
And? One can run a not-so-scalable web server on any OS last time I checked.
Ease up, I'm quite sure it was a joke.
Security in Plan 9 (2002)
11–20 of 74 posts
Re: Security in Plan 9 (2002)
#12The site seems to be down.
Re: Security in Plan 9 (2002)
#13The 9p filesystem lives on in a few "modern" places, like within WSL, QEMU, and other places where it's a good bridge between a host OS and container or VM.
Re: Security in Plan 9 (2002)
#14Earlier quoted context omitted.
That is the best security.
Next up in the blog schedule: "Performance and Scaling in Plan 9"
Already done.
Re: Security in Plan 9 (2002)
#15The 9p filesystem lives on in a few "modern" places, like within WSL, QEMU, and other places where it's a good bridge between a host OS and container or VM.
Apple added support just in 2019!
man mount_9pRe: Security in Plan 9 (2002)
#16Plan 9 seems to be disproportionately influential for an OS nobody who's not into systems engineering has ever heard about.
Re: Security in Plan 9 (2002)
#17[deleted]
Re: Security in Plan 9 (2002)
#18The 9p filesystem lives on in a few "modern" places, like within WSL, QEMU, and other places where it's a good bridge between a host OS and container or VM.
unless i have done it hopelessly wrong, you may be overstating it a little bit by calling it good.
virtfs is the good one, not 9p.
Re: Security in Plan 9 (2002)
#19The 9p filesystem lives on in a few "modern" places, like within WSL, QEMU, and other places where it's a good bridge between a host OS and container or VM.
unless i have done it hopelessly wrong, you may be overstating it a little bit by calling it good. virtfs is the good one, not 9p.
virtfs USES 9p.
Re: Security in Plan 9 (2002)
#20Earlier quoted context omitted.
Next up in the blog schedule: "Performance and Scaling in Plan 9"
I'd actually love to see such a paper. Plan 9 threading is more like coroutines, but it is certainly possible to run multi-core/multi-process code. That said, I can't say I've seen anyone try to write anything that scales like nginx on Plan 9. That doesn't mean it hasn't happened, I've just not seen anyone talk about it too much. It did run on IBM's Blue Gene for a bit ( https://www.usenix.org/legacy/event/usenix07/p…
> I'd actually love to see such a paper. Plan 9 threading is more like coroutines, but it is certainly possible to run multi-core/multi-process code.
Rob Pike was on of the main developers behind plan 9 and Go and involved in concurrent programming research focusing on CSP.
Multi-processing was a main focus of plan 9's design and it works well as procs are cheap to spawn on plan 9. Procs are also the smallest unit of execution on plan 9, threads are just light weight procs with a shared heap to pass pointers around. Thread stacks can also be shared as well by being allocated on the heap via fork(2) RFMEM flag (its all done with malloc in the background).
The issue with vanilla (aka labs or legacy ) plan 9 is there is a hard coded limit of 2k procs statically allocated at boot. This was a pragmatic design decision. The unfortunate side effect is vanilla plan 9 falls over under any sort of work load requiring spawning lots of procs like handling web requests. This is actively being worked on by 9front developers so sites hosted on 9front should hold up better (patches welcome :-).
> That said, I can't say I've seen anyone try to write anything that scales like nginx on Plan 9.
Because you really don't need those big web serving monoliths on plan 9. You wire things up using rc scripts and programs like execfs (implements cgi) plus httpd/tcp80 or another web serving listener and sandbox code using namespaces. Plan 9 is more true to unix philosophy and more unix than unix. (edit: execfs is experimental but available on shuthub.us along with other webstuff like tcp80)