[9fans] 2 things

[9fans] 2 things

[ron minnich]

http://www.sdsc.edu/srb/index.php/Main_Page -- probably worth reading.

and

this one is kind of weird but widely used it seems
http://ccache.samba.org/

"Our software is so big it takes forever to build! what to do? "
"add more software of course"

ron

Re: [9fans] 2 things

[Lluís Batlle]

I also used samba's distcc too, much more often than ccache.

2007/10/4, ron minnich <rminnich@gmail.com>:
> http://www.sdsc.edu/srb/index.php/Main_Page -- probably worth reading.
>
> and
>
> this one is kind of weird but widely used it seems
> http://ccache.samba.org/
>
> "Our software is so big it takes forever to build! what to do? "
> "add more software of course"
>
> ron
>

Re: [9fans] 2 things

[Geoffrey Avila]

I'll bite. What do 9fans want to know about SRB?

-GBA


> http://www.sdsc.edu/srb/index.php/Main_Page -- probably worth reading.
>
> and
>
> this one is kind of weird but widely used it seems
> http://ccache.samba.org/
>
> "Our software is so big it takes forever to build! what to do? "
> "add more software of course"
>
> ron
>

Re: [9fans] 2 things

[Adrian Tritschler]

[-- Attachment #1: Type: text/plain, Size: 471 bytes --]

Geoffrey Avila wrote:
> I'll bite. What do 9fans want to know about SRB?

Solid Rocket Boosters, for when you want your files delivered *NOW*

> -GBA
> 
> 
>> http://www.sdsc.edu/srb/index.php/Main_Page -- probably worth reading.
>>
>> and
>>
>> this one is kind of weird but widely used it seems
>> http://ccache.samba.org/
>>
>> "Our software is so big it takes forever to build! what to do? "
>> "add more software of course"
>>
>> ron
	Adrain



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 260 bytes --]

Re: [9fans] 2 things

[ron minnich]

On 10/4/07, Geoffrey Avila <avlg@sdsc.edu> wrote:
>
> I'll bite. What do 9fans want to know about SRB?

It's an fyi thing. It's another thing plan 9 could do better, that's all.
ron

Re: [9fans] 2 things

[Geoffrey Avila]

On Thu, 4 Oct 2007, ron minnich wrote:

> On 10/4/07, Geoffrey Avila <avlg@sdsc.edu> wrote:
> >
> > I'll bite. What do 9fans want to know about SRB?
>
> It's an fyi thing. It's another thing plan 9 could do better, that's all.

Hmmm. 'Round about these parts, them's fightin' words....

One of the many things that SRB (and iRODS) address is metadata
management above the layer of the disk filesystem. It's not like we use
it like AFS/NFS, even though that's possible. Lots of people seem to like
getting at their data via an API more rich than what can be reasonably
offered as a seekable bytestream.

Isn't that a very explicitly un-plan9-like thing to want?

I mean, the people who write SRB sorta take it for granted that all of
their users will be running different & incompatible lunix variants and
will want to plug into SRB through their custom HPC app which is probably
written in C++ or Java, if not Python. People are used to a big heavy
library/class thing to call on to do something.

I guess I have a burning desire to know explicitly how & how much better
plan 9 could do this, please don't leave me hanging...

-GBA

Re: [9fans] 2 things

[ron minnich]

On 10/4/07, Geoffrey Avila <avlg@sdsc.edu> wrote:
>Lots of people seem to like
> getting at their data via an API more rich than what can be reasonably
> offered as a seekable bytestream.
>
> Isn't that a very explicitly un-plan9-like thing to want?

that's not un-plan9-like at all.

> People are used to a big heavy
> library/class thing to call on to do something.
>

is this a good thing or just something we live with?

ron

Re: [9fans] 2 things

[Geoffrey Avila]

> >
> > Isn't that a very explicitly un-plan9-like thing to want?
>
> that's not un-plan9-like at all.

Ok, I guess I just can't see it; While it may be possible (and good!) to
let your plan 9 fileserver be a data repository, I'd think that good
middleware needs to be OS-agnostic, so as to be isolated from the details
of things like filesystem implementation.

>
> > People are used to a big heavy
> > library/class thing to call on to do something.
> >
> is this a good thing or just something we live with?
>
> ron
>
I'm not sure if it's good or bad. It seems to be the way modern
environments expect you to write programs that talk to each other.

I'll plead the fifth. My lack of a CS degree absolves me from having an
official opinion!:)

Why coulden't the sort of Grid Middleware (acck! thppt! sorry...) facility
that the irods people want to make be an integral part of the OS;
something that could be manipulated via mount & cat & echo &c.?

My guess is that it is asking a lot of Unix to try and make it work that
way, in a manner that is reliable and dependable and cross-platform enough
to be useful. What the hell else do we use? Windows? It has the virtue at
least, of ubiquity...

Re: [9fans] 2 things

[erik quanstrom]

> Ok, I guess I just can't see it; While it may be possible (and good!) to
> let your plan 9 fileserver be a data repository, I'd think that good
> middleware needs to be OS-agnostic, so as to be isolated from the details
> of things like filesystem implementation.

good middleware.  i'd never thought of combining that adjective with that
noun.  (or is middleware officially a pronoun?)

what's the limit to this sort of indirection?  does someone decide that some
middleware agnostic layer needs to be built, so developers don't have to
bother with the little details of their middleware?

- erik

Re: [9fans] 2 things

[Francisco J Ballesteros]

if you need "middleware" you can use inferno as such. snd your apps will
be really portable. give it a try if you didn´t

> > Ok, I guess I just can't see it; While it may be possible (and good!) to
> > let your plan 9 fileserver be a data repository, I'd think that good
> > middleware needs to be OS-agnostic, so as to be isolated from the details
> > of things like filesystem implementation.
>

>
>

Re: [9fans] 2 things

[Charles Forsyth]

> if you need "middleware" you can use inferno as such. snd your apps will
> be really portable. give it a try if you didn´t

although that's similar to what i do myself, more practically, the plan 9 ports environment shows
that it's reasonably possible to provide a C programming environment with
the small set of Plan 9 primitives on a range of decidedly heterogeneous systems.

this still doesn't quite address the question of how the extended functionality
attributed to SRB might be provided in the Plan 9 environment.
a general answer would be `the design of name spaces to represent those services',
but it would probably be interesting to look in detail at a few examples at least,
to help make the discussion more concrete.  (it needs to be approached from
the application's point of view, in what it's intended to achieve,
not `how would you do SRB's XYZ operation'.)