Very much a fan of this, of the 9p life. What times seeing a shell on the web with 9p access!
9p is very shell coded, as we see here, but I also really want to imagine going further. I want to imagine apps and systems that interoperate via small fine grained files. As a scripting environment, I really hope it's easy and fun for programs and now llms to look at and alter state, to work other systems, and 9p feels like it is rallying around a core truth that's there all the time just more of it, more files. Instead of descending beyond the os into deeper datastructures like toml.
A downside is that now you need lots of kernel syscalls to talk to all the files. That alas has not, historically, been performant.
Hah, I had somewhat similar plan, but based on the concept of FIFO (named pipes) and the Unix tool `mkfifo`, so I built https://mkfifo.com to make it easier for people to build pipes instead of shell commands.
There are also a few FIFOs there that works like rclone, using my own `rfetch` library.
Making the natural comparison to unix pipes. I would say CMS pipes were better for complex pipe lines, the primitive names actually made sense and no need for that awkward setup stage on unix where named pipes need to live on the filesystem. But for simple pipes the unix syntax... felt better? Looking back on that manual now, simple cms pipes look fine, I don't remember why I felt they were worse than unix pipes.
Anyhow it is an interesting alternate take on what pipes could be.
My Chrome flags this site as not secure, but it doesnt tell me why which is strange.
EDIT: Looking at it, chrome seems to hide all security info about sites now and only display a generic 'Not Secure' badge for anything. This is a very awkward change and removes lots of convenience when troubleshooting random sites.
The SSL certificate is fine; the site just redirects from https to http for whatever reason, so you end up with no certificate at all. And there's no SSL issue for Chrome to report about.
I think it was the fact that by default Chrome hides the protocol from the url, so I could'nt see at a glance it was downgraded. This is exactly what I was talking about when mentioning chrome removing this stuff was hindering troubleshooting. Once I found the setting in chrome to always show the http section, it became clear what was happening.
This is an HTTP site. There is no SSL certificate. That's why Chrome isn't telling you anything, it's not that the site is insecure, it's just that it's not secure.
The web(html) is a hierarchical system and as such it's proper place in the world is mapped to the filesystem.
Which is honestly what I thought plan9's webfs https://man.cat-v.org/plan_9/4/webfs did and then you could use the filesystem api to parse it. But alas, I actually read the man page to double check, and it looks like it does the much more sane option and just fetches web resources(http), I am crushed.
But it may be a fun weekend project to see if that mapping could be done and where it fails. So not a complete loss.
15 comments
[ 0.11 ms ] story [ 17.8 ms ] threadVery much a fan of this, of the 9p life. What times seeing a shell on the web with 9p access!
9p is very shell coded, as we see here, but I also really want to imagine going further. I want to imagine apps and systems that interoperate via small fine grained files. As a scripting environment, I really hope it's easy and fun for programs and now llms to look at and alter state, to work other systems, and 9p feels like it is rallying around a core truth that's there all the time just more of it, more files. Instead of descending beyond the os into deeper datastructures like toml.
A downside is that now you need lots of kernel syscalls to talk to all the files. That alas has not, historically, been performant.
https://github.com/pigshell/pigshell/commit/9ad32ce83b7191e8... committed on Aug 24, 2015
Still, I'm a fan of the style. Today, it would probably be an LLM interface to resources, but how much fun would a web shell be?
There are also a few FIFOs there that works like rclone, using my own `rfetch` library.
Still a WIP though.
Making the natural comparison to unix pipes. I would say CMS pipes were better for complex pipe lines, the primitive names actually made sense and no need for that awkward setup stage on unix where named pipes need to live on the filesystem. But for simple pipes the unix syntax... felt better? Looking back on that manual now, simple cms pipes look fine, I don't remember why I felt they were worse than unix pipes.
Anyhow it is an interesting alternate take on what pipes could be.
EDIT: Looking at it, chrome seems to hide all security info about sites now and only display a generic 'Not Secure' badge for anything. This is a very awkward change and removes lots of convenience when troubleshooting random sites.
Still, the site needs to fix its SSL certificate.
Firefox is nice.
Which is honestly what I thought plan9's webfs https://man.cat-v.org/plan_9/4/webfs did and then you could use the filesystem api to parse it. But alas, I actually read the man page to double check, and it looks like it does the much more sane option and just fetches web resources(http), I am crushed.
But it may be a fun weekend project to see if that mapping could be done and where it fails. So not a complete loss.