
Plan 9 public grid - zeveb
http://wiki.9gridchan.org/public_grid/index.html
======
jchw
As far as I can tell, it's services provided over Plan9's '9P' protocol. The
'grid' word makes me think there's some level of decentralization involved,
though it's somewhat unclear exactly how much.

I find it amusing and somewhat strange how many of the modern-day Plan 9
enthusiasts come from 4chan's /g/ board, this project included. Maybe it takes
a certain level of eccentricity to value the elegance over most measures of
practicality. Either way, I fully support it.

~~~
mycroftiv
The decentralization enters in a couple different ways. First, the set of
services is made from several different machines - I didn't make every single
service a separate vps, but there are 4 different nodes that provide the
different 9p fses that are used, and it would be possible to run each service
on a separate vps, but at the moment that would be a bit unnecessary because
load isn't that heavy. The other decentralized aspect is that if people want
to, they can announce their own services to one of the registries that is
being exported, so people could build their grid environment from more
resources than just the ones exported from 9gridchan. That is still mostly
theoretical right now, people are still exploring the possibilities of the set
of 'default' services.

------
mycroftiv
Well, I wasn't really expecting this to show up here, but I guess people have
been paying some attention to plan 9 things around here lately. Hi everybody!
I can try to answer some questions to those who are interested. I've been
working on this kind of thing for a long time and it is interesting to see
this version of things getting some traction.

~~~
tbrock
I’m excited about this because it’s about Plan 9 but I have no idea what it is
or why I should be excited. Please tell me more.

I read the description but I’m not sure if it’s a time sharing system on plan
9 that the public can log into or another internet or... something else.

~~~
mycroftiv
It's a collaborative environment build from 9p services. If you add the
scripts to use it to your plan 9 machine/vm (or use the ANTS iso images), it
will create a grid workspace with a chat, shared filesystems, ability to send
links and images and documents to other connected users, and access to a
registry for adding your own services if you choose. It currently has a small
user community but it seems people are finding it fun and useful.

------
zbentley
Tangential-ish question:

It's often claimed that the Linux /proc virtual filesystem has roots in Plan
9's design, and it's certainly a very powerful abstraction that allows, at the
cost of some _expressiveness_ , near-universal _interoperability_ with some of
Linux's internal state.

However, many BSDs do not support it out of the box, and I've heard it claimed
that they're deprecating/have no plans to keep /proc around, favoring sysctls
which return structs instead.

Assuming that both are true (/proc came from plan9 and BSDs are moving away
from it), why is this the case?

Why abandon a universally-interoperable, so-simple-a-child-can-interface-with-
it interface to what is otherwise a very hard-to-work-with type of system
state?

~~~
jcranmer
Exposing kernel bits via the filesystem makes less sense the more you think
about it:

* You have to build a state machine inside the kernel to handle cases like applications reading a file one byte at a time.

* If the API is complex, you get to build parsers (aka, the easiest way to introduce buffer overflows in C) in kernel-mode.

* Programs now have to deal with malicious applications capable of managing mountpoints giving fake results via the filesystem. I could link to /dev/random to /dev/zero, how many programs are going to check for that?

* You can't let the program go into a chroot jail if it needs to read the kernel's magic filesystem.

* You have to mingle filesystem access bits with kernel security checks for process capabilities and the like.

It's definitely not a simple interface for the kernel to implement, and, quite
frankly, it's much more complex for a security-minded application to poke at
the kernel through a filesystem than it is through a syscall.

~~~
benchaney
None of these should actually be a problem in practice.

> * You have to build a state machine inside the kernel to handle cases like
> applications reading a file one byte at a time.

You need to have this anyway, because regular files exist. Also, the logic is
very simple.

> * Programs now have to deal with malicious applications capable of managing
> mountpoints giving fake results via the filesystem. I could link to
> /dev/random to /dev/zero, how many programs are going to check for that?

Only root could do that. If an attacker has root, there are many more
realistic attacks.

> * You can't let the program go into a chroot jail if it needs to read the
> kernel's magic filesystem.

You can add the magic filesystem to a choot jail.

> * You have to mingle filesystem access bits with kernel security checks for
> process capabilities and the like.

I'm really not sure what this means.

~~~
zbentley
> > * You have to build a state machine inside the kernel to handle cases like
> applications reading a file one byte at a time.

> You need to have this anyway, because regular files exist. Also, the logic
> is very simple.

"State machine" is a bit of a weird term here; it's more to do with
"transactional state". This doesn't exist for regular files. If you read a
regular file one byte at a time and something else is changing it, there's no
transactional guarantee. You might get corrupted data. For that matter, you
might get corrupted/half-changed data if you're reading >1 byte at a time.
This is fundamental to the Unix file model (as distinct from, say, Windows),
and is also the reason that file locking facilities exist.

I think GP was emphasizing the difficulty of having to bind the code that
generates the _contents_ of files in /proc with the status of any code
_reading_ those files. The reader needs a guarantee that it'll get a
"snapshot" of the /proc pseudo-file as of some time (the start of the read?
The end of the read? This is arguable.) Without that, there's no race-free way
to ensure that all readers don't get corrupted data that's changed during the
read.

This is required even if you can assume (which you can't) that all readers
will use a buffer/chunk size larger than the contents of the file, and that
the kernel's updates to the data backing the file are atomic.

A state machine is a common way to implement such snapshot/tx guarantees, but
the fundamental desired property is a _transaction_ , which, while I disagree
with GP on some other points, is absolutely a needed and likely hard-to-get-
right feature in this area.

------
yjftsjthsd-h
"This time, though, we actually have some fucking clue what we are doing."

There's confident, and then there's crazy;)

Best of luck to them:)

------
emmelaich
(sorta offtopic) Does anyone remember a cloud storage service based on 9p? At
least I think it was based on 9p. Or written by plan9 (fossil, venti)
enthusiasts.

It's name was Rangoon. (I think). It even pre-dated Dropbox.

~~~
khm
That was Rangboom from 9netics[1]. Archive link because the site now serves a
very narrowly-focused photographic art installation.

Their later effort was called "9p cloud."[2]

1 -
[https://web.archive.org/web/20170311182215/http://www.9netic...](https://web.archive.org/web/20170311182215/http://www.9netics.com/)

2 - [https://www.9pcloud.net/](https://www.9pcloud.net/)

~~~
mveety
Wasn't that brucee's gig for a while? I remember they had written a windows 9p
client which is hen's teeth now, but I remember it working well.

~~~
emmelaich
Yep, brucee has (or had) a 9netics email address.

------
dredmorbius
"We aren't expecting abuse to be a major problem."

Oh ... dear.

~~~
rnd0
Coming from 4chan, you'd think they would know better.

~~~
mycroftiv
It's amazing what an incredible filter "you have to use plan 9" is for things.
I have been doing public plan 9 services on and off for a long time, and
although I'm sure someone will be a jerk eventually, I have yet to see any
deliberately malicious behavior. On the grid right now, things are pretty open
and the user community is all cooperative and constructive. So far as I can
tell, the venn diagram of "people looking for trolling and malicious lulz" and
"people interested in using plan 9" has approximately zero overlap.

~~~
dredmorbius
That's an awful lot like security-by-obscurity.

In fact, I'm fairly confident it's pretty much the same exact thing.

If you _don 't_ build a system with defences against abuse, you will see
abuse. It's a matter of scale and time.

------
henesy
The grid is back up, a VPS host issue occurred and a fix is underway.

------
hugelgupf
Seems to be down right now, so not sure what services are implemented, but...
someone should port this stuff to upspin. :)

~~~
mycroftiv
My vps host picked the most inconvenient time possible to reboot the root node
for the grid. Things should all be working again now.

------
badloginagain
After a bunch of reading, I still have no idea what this is. Some Linux
variant?

~~~
jf
Plan 9 is an amazing, inspirational, and futuristic operating system from the
past:
[https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs](https://en.wikipedia.org/wiki/Plan_9_from_Bell_Labs)

One of the things that Plan 9 can do is seamlessly treat remote resources as
if they were local. From what I can tell, this is a remote grid that you can
connect a local Plan 9 instance to.

~~~
woolvalley
Do these i/o interfaces tell you their expected latency and throughput
numbers? I could see some fairly silly code being written because they didn't
realize that file was actually a a bad cell phone connection.

~~~
nl
The main author of Plan 9 was Rob Pike. He knows a little bit about networked
software.

I actually had Plan 9 working on some Sun 3/50s at one point. You could use it
over a 2400 baud modem... a kind of broken one where I had to listen to the
connection noises and twiddle the wires at the right moment to make it
connect. A bad cell phone connection would have been nice.

