[9fans] Do we have a catalog of 9P servers? - Plan9

>>It seems that MS is pushing webdav hard.
>
> that's what's needed when heavy things run out of fuel.

Even as a potential substitute for ftp webdav is a farce. Speaking
from personal experience, the amount of XML you need to generate for a
directory listing is at least 20 times the size of the equivalent ftp
listing, and then you twiddle your thumbs waiting for the webdav
client to parse and render it.

And don't get me started on vista... My wife's new dell laptop uses
up 800 MB of ram doing who knows what after it boots and two times out
of three fails to go to sleep w/ the fan whirling like a banshee. At
times I wonder if I shouldn't have paid the $700 premium for the
macbook. Sorry for the OT rant...

On Nov 8, 2008, at 4:11 AM, Francisco J Ballesteros wrote:
> It seems that MS is pushing webdav hard.

True. But it is not MS that worries me in this particular case. At least
they don't have anything to offer yet. This:
http://docs.amazonwebservices.com/AmazonS3/2006-03-01/
on the other hand, seems to be getting a lot of traction. As in
"people are using it right now" kind of traction.

I wish these guys provided 9P as one of the options to access their
remote storage resources, but, of course, they don't. And why
would they -- FUSE can handle whatever they have perfectly well.

Thus, the letter of the "remote resource access via FS semantics"
law seems to be perfectly fine, while the spirit, of course, is
hopelessly
broken.

Thanks,
Roman.

On Nov 8, 2008, at 11:15 AM, John Barham wrote:
>>> It seems that MS is pushing webdav hard.
>>
>> that's what's needed when heavy things run out of fuel.
>
> Even as a potential substitute for ftp webdav is a farce. Speaking
> from personal experience, the amount of XML you need to generate for a
> directory listing is at least 20 times the size of the equivalent ftp
> listing, and then you twiddle your thumbs waiting for the webdav
> client to parse and render it.

But think about this: why would you care if you have this:
http://noedler.de/projekte/wdfs/

Why would anyone care about what's getting pushed to the
wire?

Thanks,
Roman.

I wrote a functional 9P S3 client but it just seemed silly in the end.
Buy a few T of disk and fossil+venti and it's over. Even aging kenfs
will do.

brucee

On Sun, Nov 9, 2008 at 12:13 AM, Roman Shaposhnik wrote:
> On Nov 8, 2008, at 4:11 AM, Francisco J Ballesteros wrote:
>>
>> It seems that MS is pushing webdav hard.
>
> True. But it is not MS that worries me in this particular case. At least
> they don't have anything to offer yet. This:
> http://docs.amazonwebservices.com/AmazonS3/2006-03-01/
> on the other hand, seems to be getting a lot of traction. As in
> "people are using it right now" kind of traction.
>
> I wish these guys provided 9P as one of the options to access their
> remote storage resources, but, of course, they don't. And why
> would they -- FUSE can handle whatever they have perfectly well.
>
> Thus, the letter of the "remote resource access via FS semantics"
> law seems to be perfectly fine, while the spirit, of course, is hopelessly
> broken.
>
> Thanks,
> Roman.
>
>

On Nov 8, 2008, at 2:19 PM, Bruce Ellis wrote:
> I wrote a functional 9P S3 client but it just seemed silly in the end.
> Buy a few T of disk and fossil+venti and it's over. Even aging kenfs
> will do.


The most ironic thing of all is that one would expect a company which
stood behind a technology like ZFS to easily appreciate that. Especially
since we've always had a userland ZFS. And especially now, that
we are trying to figure out a cloud storage market story. But no.

Now, not to date myself as a green youngling, but how are PHBs
to be convinced? They hear about 9P for the first time in their
life (unlike bull**** lotto items: WebDAV, XML, SOAP and REST) and
when they ask about *existing* client-side support there's not much I
can
tell them.

Network effect (http://en.wikipedia.org/wiki/Network_effect) at its
worst?

Thanks,
Roman.

>> Even as a potential substitute for ftp webdav is a farce. Speaking
>> from personal experience, the amount of XML you need to generate for a
>> directory listing is at least 20 times the size of the equivalent ftp
>> listing, and then you twiddle your thumbs waiting for the webdav
>> client to parse and render it.
>
> But think about this: why would you care if you have this:
> http://noedler.de/projekte/wdfs/
>
> Why would anyone care about what's getting pushed to the
> wire?

i think most everyone here inderstands why one would.
let's let this thread die in peace.

- erik

On Sat, Nov 8, 2008 at 2:59 PM, Roman Shaposhnik wrote:

> The most ironic thing of all is that one would expect a company which
> stood behind a technology like ZFS to easily appreciate that. Especially
> since we've always had a userland ZFS. And especially now, that
> we are trying to figure out a cloud storage market story. But no.

you had a userland nfs too :-)

>
> Now, not to date myself as a green youngling, but how are PHBs
> to be convinced? They hear about 9P for the first time in their
> life (unlike bull**** lotto items: WebDAV, XML, SOAP and REST) and
> when they ask about *existing* client-side support there's not much I can
> tell them.


It's not just the PHBs. I showed the original 9p (for 2.0.36) in 1998
to a fair number of linux people, and back then I had private name
spaces, union mounts, user level servers, in fact just about all you
get in plan 9 today and STILL don't get in linux.

They were strongly convinced there was no use for userland file
systems, or union mounts, or private name spaces, or any of this
stuff. They kept pointing to things that Linux did that were not at
all what I was showing them, saying "we already do that". At some
point I gave up. Years later, FUSE comes along, and ... well you know
the story.

So it goes. We can't blame the PHBs for everything. Sometimes its our own guys.

ron

On Sat, Nov 08, 2008 at 02:16:39PM -0800, Roman Shaposhnik wrote:
> On Nov 8, 2008, at 11:15 AM, John Barham wrote:
> >>>It seems that MS is pushing webdav hard.
> >>
> >>that's what's needed when heavy things run out of fuel.
> >
> >Even as a potential substitute for ftp webdav is a farce. Speaking
> >from personal experience, the amount of XML you need to generate for a
> >directory listing is at least 20 times the size of the equivalent ftp
> >listing, and then you twiddle your thumbs waiting for the webdav
> >client to parse and render it.

it's not that bad!

# readdir in xml...
PROPREQ = array of byte " encoding=\"utf-8\"?> xmlns=\"DAV:\"/> xmlns=\"http://apache.org/dav/props/\"/> xmlns=\"DAV:\"/> xmlns=\"DAV:\"/>";


>
> But think about this: why would you care if you have this:
> http://noedler.de/projekte/wdfs/
>
> Why would anyone care about what's getting pushed to the
> wire?

i guess it's just us who care, since we have to implement the protocols
if we want to use them. for this case, i'm not sure what didn't stop me:

http://www.ueber.net/code/r/webdavfs

unpolished as always, but i've used it to edit files from my homedir at
my isp.

mechiel

On Nov 8, 2008, at 3:11 PM, erik quanstrom wrote:
>>> Even as a potential substitute for ftp webdav is a farce. Speaking
>>> from personal experience, the amount of XML you need to generate
>>> for a
>>> directory listing is at least 20 times the size of the equivalent
>>> ftp
>>> listing, and then you twiddle your thumbs waiting for the webdav
>>> client to parse and render it.
>>
>> But think about this: why would you care if you have this:
>> http://noedler.de/projekte/wdfs/
>>
>> Why would anyone care about what's getting pushed to the
>> wire?
>
> i think most everyone here inderstands why one would.

See that's the problem. I was asking for the arguments that might
help me convince somebody who hasn't ever been exposed
to Plan9/Inferno OSes (and hasn't ever been on this list) to
consider 9P (as a protocol) to be added (as a fronted) to a major
service that Sun wants to roll out. Personally, I ran out of
ammo.

You're now telling me that such a knowledge can only be had via the
process of osmosis. That there are no arguments to be used.
That's fair. This process of osmosis is what makes me read this
list to begin with.

But wouldn't you agree, that in all fairness, if the only people who
want to
see 9P being spoken by any piece of software or hardware are the ones
subscribed to the list -- it is not worth implementing?

> let's let this thread die in peace.


Sure. I'm about to write a reply to the question of requirements
and I would be happy to take the answers off the list.

Sorry to be a bother.

Thanks,
Roman.

> It's not just the PHBs. I showed the original 9p (for 2.0.36) in 1998
> to a fair number of linux people, and back then I had private name
> spaces, union mounts, user level servers, in fact just about all you
> get in plan 9 today and STILL don't get in linux.
>
> They were strongly convinced there was no use for userland file
> systems, or union mounts, or private name spaces, or any of this
> stuff. They kept pointing to things that Linux did that were not at
> all what I was showing them, saying "we already do that". At some
> point I gave up. Years later, FUSE comes along, and ... well you know
> the story.

It is always the same story. People like shiny baubles.
Stuff they can relate to and/or show off to their friends.
You just can't sell them on simplicity or flexibility. They
don't care. If they did, they'd already be using plan9!

If you want to sell them on 9P, build some shiny baubles they
might want. Build a 9p client for iphone. Build a wireless 9p
camera. Build something like openFrameworks.cc but simpler.
People use it for all sorts of things including "spray
painting" graffiti on skyscrapers -- see examples @
GraffitiResearchLab.com. Look at what Johny Lee has done
with wiimote @ http://www.cs.cmu.edu/~johnny/projects/wii/

People are making lots of new fun, creative uses of computers
& IO devices. A simple building block framework can be very
useful here and it will be a while before FUSE gets here!

> I wrote a functional 9P S3 client but it just seemed silly in the end.
> Buy a few T of disk and fossil+venti and it's over. Even aging kenfs
> will do.
>
> brucee

and the Coraid boxes are an excellent option.

purely virtual infrastructure for rolling out services is a good idea
but the pieces aren't there yet. also, it assumes that the vm/vs
service provider will be able to provide as good or better quality of
service as you would maintaining your own infrastructure.

How about if you start a page with a list of the 9p
file servers you know of, say on the plan9 wiki, and
then email 9fans asking them to add any that you have
missed?

I can see how such a thing might be a useful resource
to people on the list as well as a promotional tool.
It could also (perhaps) focus attention of those with
time and interest towards the best ones to tackle next.

"best" in this context is of course a moveable feast.

just my 2cents worth

-Steve

>also, it assumes that the vm/vs
>service provider will be able to provide as good or better quality of
>service as you would maintaining your own infrastructure.

also that they are as sound as a bank and just as unlikely to go bust.
wait a minute ...

>>also, it assumes that the vm/vs
>>service provider will be able to provide as good or better quality of
>>service as you would maintaining your own infrastructure.
>
> also that they are as sound as a bank and just as unlikely to go bust.
> wait a minute ...

exactly; that also crossed my mind. there's the analogous potential
pitfall of counting on service providers that count on other service
providers and soon a problem affecting somebody who's tangentially
involved in your service could bring down your business.

Transitive trust is metastable. "I trust him. Hold on - do I trust who
he trusts" etc.

brucee

On Mon, Nov 10, 2008 at 12:13 AM, Skip Tavakkolian <9nut@9netics.com> wrote:
>>>also, it assumes that the vm/vs
>>>service provider will be able to provide as good or better quality of
>>>service as you would maintaining your own infrastructure.
>>
>> also that they are as sound as a bank and just as unlikely to go bust.
>> wait a minute ...
>
> exactly; that also crossed my mind. there's the analogous potential
> pitfall of counting on service providers that count on other service
> providers and soon a problem affecting somebody who's tangentially
> involved in your service could bring down your business.
>
>
>

* Roman Shaposhnik wrote:

Hi,

> See that's the problem. I was asking for the arguments that might
> help me convince somebody who hasn't ever been exposed
> to Plan9/Inferno OSes (and hasn't ever been on this list) to
> consider 9P (as a protocol) to be added (as a fronted) to a major
> service that Sun wants to roll out. Personally, I ran out of
> ammo.

Actually, I'm even going some steps further and advocating 9P and
the idea of representing resources just as filesystem hierachy as
a generic and elegant way of IPC in complex applications, eg. Mozilla.

Right now, there's an discussion about moving things into their own
processes (eg. one process per tab) @ dev-platform@lists.mozilla.org,
and I just digged out my (old but still unrecognized) point of using
9P as IPC and splitting off the currently monolithic app into a bunch
of fileservers.

Perhaps some of you like to subscribe there and jump at my side


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

* Steve Simon wrote:

> How about if you start a page with a list of the 9p
> file servers you know of, say on the plan9 wiki, and
> then email 9fans asking them to add any that you have
> missed?

If I had write access, I'd just did it ;-o
Meanwhile I've just added my 9P libs (libmixp, libmixpsrv)
to the 9P page @ wikipedia - probably a good starting point, too.

But if we're talking about 9P/Styx in general (not specifically
on Plan9 or Inferno), it might be wise to set up a sepate website.
This site should also contain information on topics like what 9P
is really good for and why application developers should use it

Strange as it sounds, but today everyone seems to live in dozens
of "community portals" (yeah, that funny overblotat sites with
lots of bad excuses for not doing your real work ;-o), so I tend
to prefer an little Joomla over Wiki ;-)

Just let me know if you'd like to feed some input to such a site,
and I'll set up one.


cu
--
----------------------------------------------------------------------
Enrico Weigelt, metux IT service -- http://www.metux.de/

cellphone: +49 174 7066481 email: info@metux.de skype: nekrad666
----------------------------------------------------------------------
Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

On 10-Nov-08, at 6:26 AM, Enrico Weigelt wrote:
> Right now, there's an discussion about moving things into their own
> processes (eg. one process per tab) @ dev-platform@lists.mozilla.org,
> and I just digged out my (old but still unrecognized) point of using
> 9P as IPC and splitting off the currently monolithic app into a bunch
> of fileservers.

I must say that it is highly unlikely that Mozilla will adopt the path
of splitting the "monolithic app into a bunch of fileservers" simply
because that would involve a lot work, and potentially a lot code to
be written from scratch.

There's some history from the old netscape days here; 6.0 bombed
because they decided to rewrite everything: http://www.joelonsoftware.com/articl...000000069.html

Lesson learned. No matter how "messy" the Mozilla code looks, there is
simply no way the developers would agree to a major redesign of the
Mozilla architecture. Solutions that easily "fit into" the existing
codebase would be more than welcomed, and I am sure somebody will come
up with it.

--
Anant

> Right now, there's an discussion about moving things into their own
> processes (eg. one process per tab) @ dev-platform@lists.mozilla.org,
> and I just digged out my (old but still unrecognized) point of using
> 9P as IPC and splitting off the currently monolithic app into a bunch
> of fileservers.

maybe replace the underlying code for XPCOM and ease them into it.
you'll need an IDL compiler that generates 9p server templates -- most
of which is in 9p(2) -- and the stub functions for the client side.
instead of searching the registry for COM objects, look in /srv, etc.

that said, it seems leaving the complexity of COM in place is
a backward step.

On Mon, Nov 10, 2008 at 2:50 PM, Enrico Weigelt wrote:
> * Steve Simon wrote:
>
>> How about if you start a page with a list of the 9p
>> file servers you know of, say on the plan9 wiki, and
>> then email 9fans asking them to add any that you have
>> missed?
>
> If I had write access, I'd just did it ;-o

Everyone has write access to the plan 9 wiki.

> Meanwhile I've just added my 9P libs (libmixp, libmixpsrv)
> to the 9P page @ wikipedia - probably a good starting point, too.
>
> But if we're talking about 9P/Styx in general (not specifically
> on Plan9 or Inferno), it might be wise to set up a sepate website.
> This site should also contain information on topics like what 9P
> is really good for and why application developers should use it
>
> Just let me know if you'd like to feed some input to such a site,
> and I'll set up one.

http://9p.cat-v.org is halfway there, makes more sense to improve
that than start a new site. Get in touch with Uriel if you want
something on there that isn't already there, or if you want to make
his life easy you can send a patch to the document source. You can get
the source by appending .md to the url (eg
http://9p.cat-v.org/implementations.md or http://9p.cat-v.org/index.md
) - they are written in markdown[1] syntax. Also he has something in
the works to enable editing via http, which I believe is implemented
but needs testing...

[1] http://daringfireball.net/projects/markdown/syntax

-sqweek