[9fans] Pegasus 2.6 is released

[9fans] Pegasus 2.6 is released

[Kenji Arisawa]

Hello,

Pegasus 2.6 is released with new WebDAV script written in Lua.
Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details.

Enjoy

Kenji Arisawa

Re: [9fans] Pegasus 2.6 is released

[lucio]

> Pegasus 2.6 is released with new WebDAV script written in Lua.
> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details.

We need a little bit more than "plan9" in the host name :-)

++L

Re: [9fans] Pegasus 2.6 is released

[John Barham]

Kenji Arisawa wrote:

> Pegasus 2.6 is released with new WebDAV script written in Lua.
> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more details.

Do you have a non-local URL host name?

Re: [9fans] Pegasus 2.6 is released

[Kenji Arisawa]

Sorry,

http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/

Kenji Arisawa

On 2009/02/01, at 13:41, lucio@proxima.alt.za wrote:

>> Pegasus 2.6 is released with new WebDAV script written in Lua.
>> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more
>> details.
>
> We need a little bit more than "plan9" in the host name :-)
>
> ++L
>
>

Re: [9fans] Pegasus 2.6 is released

[andrey mirtchovski]

http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/

Re: [9fans] Pegasus 2.6 is released

[John Barham]

> Pegasus 2.6 is released with new WebDAV script written in Lua.

Interesting that you used Lua.  I think it's generally
under-appreciated but IMO is very well designed and philosophically a
good fit for Plan 9.  However, inasmuch as you had to build a custom
interpreter to add features for Pegasus this exposes a weakness of
Plan 9 in that it can't dynamically load libraries at run-time which
is the normal extension mechanism for scripting languages on other
platforms.

Can someone comment on how feasible it would be to add general support
for dynamically loading libraries to Plan 9?  Is there some structural
reason why it can't be done or is it just that nobody has done the
work yet?  Note that I am specifically not asking about "shared"
libraries...

  John

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> However, inasmuch as you had to build a custom
> interpreter to add features for Pegasus this exposes a weakness of
> Plan 9 in that it can't dynamically load libraries at run-time which
> is the normal extension mechanism for scripting languages on other
> platforms.

pegasus is written in c, not a scripting language.
i believe lua is used as one possible language for
cgi.

the argument that if the normal extension
mechanism for scripting languages is x,
thereforenot having x is a weakness seems
a version of argumentum ad populum.

doesn't dynamic loading seem at odds with the
tools approach?  the more complex the interface,
the less general the tool.

- erik

Re: [9fans] Pegasus 2.6 is released

[John Barham]

> the argument that if the normal extension
> mechanism for scripting languages is x,
> thereforenot having x is a weakness seems
> a version of argumentum ad populum.
>
> doesn't dynamic loading seem at odds with the
> tools approach?  the more complex the interface,
> the less general the tool.

Dynamic loading allows scripting languages to load arbitrary binary
extensions at run-time.  Without dynamic loading in Plan 9 you need to
recompile the Lua (or Python) interpreters to statically link in your
binary extensions, so in this case dynamic loading makes the tool more
general.  (FWIW, as has been pointed out on this list previously,
Inferno applications can dynamically load modules at run-time.)

  John

[9fans] Dynamic loading et al (Was: Pegasus 2.6 is released)

[lucio]

> it can't dynamically load libraries at run-time which
> is the normal extension mechanism for scripting languages on other
> platforms.

Let me sneak in here, irrespective of Erik's objections.

My wild attempts at getting GCC/G++ working have led me to believe
that the right idea is going to be, firstly, to get the Plan 9 kernel
to load static ELF executables and, quickly on its heels, to teach it
to load dynamically linked ELF objects.  So far, the follow on to Lua
and language interpretation, etc.  I now leave this subject about
which I know way too little for a diversion.

I have a three-step path ahead of me:

(a)	cross-build a GNU toolchain targetting Plan 9 instead of, say
	NetBSD, which is my GNU-oriented platform of choice.  The
	target binary format will be ELF, because my efforts at
	reshaping Binutils to produce Plan 9 a.out binaries were
	frustrated by an inability to grasp the complexity of the
	multiple levels of indirection (functions that call function
	through pointers that are overwritten by compiler flags :-(

	My solution does not remove the complications, but it re-uses
	the efforts of others, as ELF binaries are more or less native
	to the GNU toolchain and, hopefully, the best supported
	format.  And before I hear too many arguments against ELF, I
	have done a "careful" study of the format (as it pertains to
	the two targets I have at hand, NetBSD and Linux/Ubuntu) and
	it is not totally evil, even though there are some serious
	gaps/flaws in it.  Bottom line, I think I can use it.

(b)	Construct a start-up module for Plan 9's ELF libc (to be) that
	accepts arguments as passed by the kernel and sets up the
	execution environment required by, at this stage,
	statically-linked ELF binary modules.  I'll get back to this
	issue.  It then becomes possible to produce static ELF
	binaries and execute them under Plan 9.  Of course, all the
	Plan 9 libraries now require recompiling and it all becomes
	massive, but not much worse than previous attempts where
	similar compromises were made.

(c)	Construct a fresh version of the linking loader (I use
	NetBSD's /libexec/ld.elf_so, I'm getting closer to grasping
	more or less how it works) that does not use MMAP to do the
	job of allocating memory and loading the file image.  Once
	again, once this is coded, the kernel will need adjustment to
	trigger its use and, on the other end, a special start-up
	module to connect the kernel and the linking loader correctly.

Now, the tricky parts.  For one, even though assembler (as ageneric
development tool for small applications) is a favourite of mine and I
always felt I would be at home in any variation thereof, I'm having
enormous trouble with the AT&T variations both Plan 9 and the GNU
toolchain use.  Most likely because I have yet to find a comprehensive
manual as I used to be acquainted with when I dealt with Univac, IBM
and Intel Assemblers (to name a few, to me, remarkable ones).

That means that I am embarrassingly stumped both to understand the
existing code and to write fresh code to serve the purposes I
mentioned above.

In case it is not clear: HELP!  I need some tutoring to produce the
start-up modules.  I think there are only two: one for the linking
loader, one for ELF binaries.  I'm hoping that dynamic and static
linking behave identically, someone here may know better.

A totally distinct issue on which I am willing to accept advice is
whether Plan 9 actually needs an ELF version (statically linked) of
the linking loader.  The initial version will be a.out, why should it
not be when I'm re-writing it from scratch?  But an ELF version may
have many advantages, of which needing a third version of the very
same start-up module is not one :-(

Anyway, anyone (besides Cinap with whom I am already in touch), feel
free to mail me any helpful suggestions.

++L

PS: I may be missing something in the cross-compilation step, I have
not dug particularly deep in that direction.  I know David Hogan
needed the APE libraries to be able to generate the GNU toolchain
using itself.  I'm about to find out how hard it all is, although
that's my second step, the first is to produce the cross-toolchain on
NetBSD.  If anyone can save me some failures, please do.

PPS: And after all this, two plugs: firstly, a grateful thank you to
Russ Cox and Cinap Lenrek (I had a chance to discover his real name at
Volos, but I missed it) for providing a lot of guidance with the Linux
emulation code they produced and continue to support.  Secondly, Cinap
and I agree that based on the Linux emulation it becomes useful to
implement MMAP on Plan 9.  So don't be surprised if that is also going
to happen with a little bit of encouragement and assistance.  Oh,
Cinap did a pretty adequate job of MMAP in the Linux emulation (I
believe it postdates Russ' version, but I'm open to historical
correction) and he should be praised for doing it.

Re: [9fans] Pegasus 2.6 is released

[Francisco J Ballesteros]

Can't you just execute new processes to "load" your
extensions?

I understand that's not a dll, but I'm really scared of
dlls after looking at what happen to linux. At least separate
binaries still work if you change libraries.

Just wondering.

On Sun, Feb 1, 2009 at 8:27 AM, John Barham <jbarham@gmail.com> wrote:
>> the argument that if the normal extension
>> mechanism for scripting languages is x,
>> thereforenot having x is a weakness seems
>> a version of argumentum ad populum.
>>
>> doesn't dynamic loading seem at odds with the
>> tools approach?  the more complex the interface,
>> the less general the tool.
>
> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9 you need to
> recompile the Lua (or Python) interpreters to statically link in your
> binary extensions, so in this case dynamic loading makes the tool more
> general.  (FWIW, as has been pointed out on this list previously,
> Inferno applications can dynamically load modules at run-time.)
>
>  John
>
>

Re: [9fans] Pegasus 2.6 is released

[Charles Forsyth]

using a variant of something we developed and then
re-developed for Inferno, you can dynamically load
C modules at run time, and unusually, with type checking,
with support in the compilers and loaders.

well, i say "modules", but of course the language pre-dates
them. people pretend.  it uses import/export tables with type signatures.
those are stashed in the a.out (viz. DYN_MAGIC in a.out.h)
so they stay together.

Re: [9fans] Pegasus 2.6 is released

[lucio]

> well, i say "modules", but of course the language pre-dates
> them. people pretend.  it uses import/export tables with type signatures.
> those are stashed in the a.out (viz. DYN_MAGIC in a.out.h)
> so they stay together.

It's not what the OP suggested.  Nor are Nemo's reservation valid.
We're talking about loading source modules into an interpreter.  This
means that different modules may be loaded, sometimes even by the same
instruction and that libraries are not terribly significant unless the
invoker gets the sequence wrong, which is a programming error.

The remaining reservation is security, can somebody replace a module
with a Trojan horse?  In Plan 9 the risk is much smaller, I dare not
say non-existent.

Recent instances of the Korn shell have this feature.  Bolsky and Korn
describe these features in some details in "The New Korn Shell", 1995.

++L

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> > the argument that if the normal extension
> > mechanism for scripting languages is x,
> > thereforenot having x is a weakness seems
> > a version of argumentum ad populum.
> >
> > doesn't dynamic loading seem at odds with the
> > tools approach?  the more complex the interface,
> > the less general the tool.
>
> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9 you need to
> recompile the Lua (or Python) interpreters to statically link in your
> binary extensions, so in this case dynamic loading makes the tool more
> general.  (FWIW, as has been pointed out on this list previously,
> Inferno applications can dynamically load modules at run-time.)

why do you assume that lua or whatever is not sufficient
for the task?  maybe it's the language itself that needs fixing.

otoh, my experience building websites is that i've never wanted
arbitrary functionality in the cgi.  once things got sufficiently
compliated, it made sense to build a server to manage
user sessions and whatnot.

- erik

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

On Sun Feb  1 06:57:13 EST 2009, lucio@proxima.alt.za wrote:
> > well, i say "modules", but of course the language pre-dates
> > them. people pretend.  it uses import/export tables with type signatures.
> > those are stashed in the a.out (viz. DYN_MAGIC in a.out.h)
> > so they stay together.
>
> It's not what the OP suggested.  Nor are Nemo's reservation valid.
> We're talking about loading source modules into an interpreter.  This
> means that different modules may be loaded, sometimes even by the same
> instruction and that libraries are not terribly significant unless the
> invoker gets the sequence wrong, which is a programming error.

not true.  this is the original quote.

> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9 you need to

- erik

Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released)

[ron minnich]

On Sat, Jan 31, 2009 at 11:31 PM,  <lucio@proxima.alt.za> wrote:


>
> (b)     Construct a start-up module for Plan 9's ELF libc (to be) that
>        accepts arguments as passed by the kernel and sets up the
>        execution environment required by, at this stage,
>        statically-linked ELF binary modules.

This is what I'm doing on bg/p now. I've got a small program that
reads in an elf binary, sets up the argv/env/aux vector(ppc thing) and
jumps to main. It works. I use libmach.

ron

Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released)

[Dave Eckhardt]

> Secondly, Cinap and I agree that based on the Linux emulation
> it becomes useful to implement MMAP on Plan 9.

If you do pay costs on that scale, it might be nice to get
something better than just mmap() when you're done.

http://9fans.net/archive/2008/07/729
http://9fans.net/archive/2008/07/535
http://9fans.net/archive/2008/07/773

Dave Eckhardt

Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released)

[lucio]

> If you do pay costs on that scale, it might be nice to get
> something better than just mmap() when you're done.

I'm sure Cinap will drive this in the right direction.  He certainly
made it clear to me that his vision for MMAP is an improvement on the
present model for Linux emulation.  But I cannot speak for him.

++L

Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released)

[lucio]

> This is what I'm doing on bg/p now. I've got a small program that
> reads in an elf binary, sets up the argv/env/aux vector(ppc thing) and
> jumps to main. It works. I use libmach.

Can you share documentation and code?  Although I would have to limit
my experimentation to the 386 platform rather than the PPC.

And what do you use to generate the ELF code?  Static or dynamic?
Both?

++L

Re: [9fans] Dynamic loading et al (Was: Pegasus 2.6 is released)

[ron minnich]

On Sun, Feb 1, 2009 at 10:42 AM,  <lucio@proxima.alt.za> wrote:
>> This is what I'm doing on bg/p now. I've got a small program that
>> reads in an elf binary, sets up the argv/env/aux vector(ppc thing) and
>> jumps to main. It works. I use libmach.
>
> Can you share documentation and code?  Although I would have to limit
> my experimentation to the 386 platform rather than the PPC.

--rw-r--r-- M 1614 rminnich sys 7183 Feb  1 15:06
/n/sources/contrib/rminnich/bgp/machcnk.c

There is stuff in there specific to bgp, as you can see. This is
derived from gpl'ed code fore coreboot but I was able to use the
wonderful libmach -- which does need a few more changes, I have a
private copy with an enhancement I doubt you will need. It's pretty
simple code and you won't need the devsegment stuff -- that's a very
bgp-specific requirement -- you can just malloc code for text and
data, and you can just use the plan 9 heap, whereas bgp needs a
different heap. Long story.

>
> And what do you use to generate the ELF code?  Static or dynamic?

The BGP toolchain, which produces statically linked binaries.

I am also supporting limited linux emulation on BGP but in kernel. The
notes approach is higher overhead than I want to pay. The open and
write of /dev/cnk is what flips a process into "linux system call
interface" mode. The only mmap I support is for anon memory.

thanks

ron

Re: [9fans] Pegasus 2.6 is released

[John Barham]

> using a variant of something we developed and then
> re-developed for Inferno, you can dynamically load
> C modules at run time, and unusually, with type checking,
> with support in the compilers and loaders.

Is the code to do this available for public consumption?

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 9:38 AM, John Barham <jbarham@gmail.com> wrote:
>> using a variant of something we developed and then
>> re-developed for Inferno, you can dynamically load
>> C modules at run time, and unusually, with type checking,
>> with support in the compilers and loaders.
>
> Is the code to do this available for public consumption?
>
>

I think we're going in circles again. IIRC my discussion of dynload
for python should point at what Charles et. al. enabled and what I
subsequently used to do dynload for python, which is usable in
general, esp. if your code is type-safe (unlike Python).

ron

Re: [9fans] Pegasus 2.6 is released

[sqweek]

On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote:
> Dynamic loading allows scripting languages to load arbitrary binary
> extensions at run-time.  Without dynamic loading in Plan 9...

 You're missing the beauty of 9p. Who needs dynload() when you have mount()?
-sqweek

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote:
>> Dynamic loading allows scripting languages to load arbitrary binary
>> extensions at run-time.  Without dynamic loading in Plan 9...
>
>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?

this thinking goes back to the beginning with pipes
and the shell.  to use object-oriented language out of place,
any program that produces or consumes a byte stream
can be extended by another program that produces or
consumes a byte stream.

with a thread library program that passes messages
on channels, one could do similar extensions by replacing
one end of the channel in a similar manner to replacing
a program in a regular pipe.  though message typing would
limit the generality of the arrangement.

- erik

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Tue, 2009-02-03 at 04:25 +0900, sqweek wrote:
> On Sun, Feb 1, 2009 at 4:27 PM, John Barham <jbarham@gmail.com> wrote:
> > Dynamic loading allows scripting languages to load arbitrary binary
> > extensions at run-time.  Without dynamic loading in Plan 9...
>
>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?

I was going to say exactly that! dynload() is really not very well
suited for a highly distributed age. I have come to realize that
it is nothing but an unfortunate optimization of R out of RPC.

Now, making 'R' fast (if your caller-callee is on the same node, etc)
is very much desired. Trying to get rid of it, or pretend that
it is not needed -- is doomed.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[John Barham]

>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?

Mount allows me to add new names to the process namespace.  Dynload
allows me to call functions or access data in a library that is not
known to the process (e.g., scripting language interpreter) until
runtime.  They solve different problems.

  John

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

>>  You're missing the beauty of 9p. Who needs dynload() when you have mount()?
>
> Mount allows me to add new names to the process namespace.  Dynload
> allows me to call functions or access data in a library that is not
> known to the process (e.g., scripting language interpreter) until
> runtime.  They solve different problems.

there is no fundamental reason they could not solve the same problem.
why are you so keen to remove the rpc?

- erik

Re: [9fans] Pegasus 2.6 is released

[David Leimbach]

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

On Mon, Feb 2, 2009 at 1:22 PM, John Barham <jbarham@gmail.com> wrote:

> >  You're missing the beauty of 9p. Who needs dynload() when you have
> mount()?
>
> Mount allows me to add new names to the process namespace.  Dynload
> allows me to call functions or access data in a library that is not
> known to the process (e.g., scripting language interpreter) until
> runtime.  They solve different problems.


They solve the same class of problems, if you step back far enough.

If your application's mechanism of dealing with processing is to use the
namespace, then binding new functionality over old is roughly equivalent to
a plugin mechanism.

I mean sure you could use FTP to transfer files, but the old shell based
tools are automagically plugged in with network capabilities when they deal
with a FTP backed namespace right?  So without any binary loader
capabilities "cp" "mv" and other existing "small programs" are now "plugged
in".

Dave



>
>
>  John
>
>

[-- Attachment #2: Type: text/html, Size: 1609 bytes --]

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 13:22 -0800, John Barham wrote:
> >  You're missing the beauty of 9p. Who needs dynload() when you have
> mount()?
>
> Mount allows me to add new names to the process namespace.  Dynload
> allows me to call functions or access data in a library that is not
> known to the process (e.g., scripting language interpreter) until
> runtime.  They solve different problems.

Depends on your point of view. Except for accessing data directly
in the same address space, dynload() is just a way of doing fast
RPC. In that line of thought, 9P offers you a very similar mechanism.

I think the most obvious example of how 9P can be used to provide the
kind of extensibility that folks usually associate with dynload()
is factotum. Especially if you compare it with things like PAM.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 13:32 -0800, David Leimbach wrote:

> I mean sure you could use FTP to transfer files, but the old shell
> based tools are automagically plugged in with network capabilities
> when they deal with a FTP backed namespace right?  So without any
> binary loader capabilities "cp" "mv" and other existing "small
> programs" are now "plugged in".

Right. That plus the fact that the "plugin" is now generally available
over the network makes it much more interesting.

In fact, these current trend towards REST in web services seems
to be a validation of 9P view of the world.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote:

> They solve the same class of problems, if you step back far enough.
> If your application's mechanism of dealing with processing is to use the
> namespace, then binding new functionality over old is roughly equivalent to
> a plugin mechanism.


I hate to be the one to bring this up but ... if you are providing
some extended (e.g.) math functionality to a program with a shared
library, people are going to be upset with you if you argue that it
can be done with RPC.

I hope the reason is obvious :-)

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> I hate to be the one to bring this up but ... if you are providing
> some extended (e.g.) math functionality to a program with a shared
> library, people are going to be upset with you if you argue that it
> can be done with RPC.

i thought we were talking about linking c into scripting languages.
you're not using python to actually do the calcuations, are you?

- erik

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> Right. That plus the fact that the "plugin" is now generally available
> over the network makes it much more interesting.
>
> In fact, these current trend towards REST in web services seems
> to be a validation of 9P view of the world.

it's interesting to compare this with the sleezy not-paths
that e.g. gnome programs can take, like uris.  great as long
as long as you don't care to use anything but gnome tools.

i suppose you could link sed &c against gnome.  but that's
crass, even by linux standards.

- erik

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote:
> On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote:
>
> > They solve the same class of problems, if you step back far enough.
> > If your application's mechanism of dealing with processing is to use the
> > namespace, then binding new functionality over old is roughly equivalent to
> > a plugin mechanism.
>
>
> I hate to be the one to bring this up but ... if you are providing
> some extended (e.g.) math functionality to a program with a shared
> library, people are going to be upset with you if you argue that it
> can be done with RPC.
>
> I hope the reason is obvious :-)

It is. It is a trivial case, after all. In non-trivial ones, the
same kind of discussion used to be quite popular in OpenMP vs.
MPI circles. And I shouldn't be the one to tell you where it
is going, right?

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[Francisco J Ballesteros]

But can't you `script' by calling an external program, sending it your
input, and reading its output?

I understand that if you have a language (say limbo) that requires loadable
modules then it's another thing.

However, if you want, say, to be able to process web pages or whatever just
by applying different modules. Why can't them be different processes?

You can just pipe your data through them.

On Mon, Feb 2, 2009 at 11:18 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> On Mon, 2009-02-02 at 14:12 -0800, ron minnich wrote:
>> On Mon, Feb 2, 2009 at 1:32 PM, David Leimbach <leimy2k@gmail.com> wrote:
>>
>> > They solve the same class of problems, if you step back far enough.
>> > If your application's mechanism of dealing with processing is to use the
>> > namespace, then binding new functionality over old is roughly equivalent to
>> > a plugin mechanism.
>>
>>
>> I hate to be the one to bring this up but ... if you are providing
>> some extended (e.g.) math functionality to a program with a shared
>> library, people are going to be upset with you if you argue that it
>> can be done with RPC.
>>
>> I hope the reason is obvious :-)
>
> It is. It is a trivial case, after all. In non-trivial ones, the
> same kind of discussion used to be quite popular in OpenMP vs.
> MPI circles. And I shouldn't be the one to tell you where it
> is going, right?
>
> Thanks,
> Roman.
>
>
>

Re: [9fans] Pegasus 2.6 is released

[Roman V. Shaposhnik]

On Mon, 2009-02-02 at 23:22 +0100, Francisco J Ballesteros wrote:
> But can't you `script' by calling an external program, sending it your
> input, and reading its output?

Well, the way I see it: exec'ing is just a way to get to a transient
channel. Its no different from that very same channel being present
permanently in /srv or /mnt/factotum/rpc. There's *slightly* less
overhead with pipes, but that's about it.

Thanks,
Roman.

Re: [9fans] Pegasus 2.6 is released

[Anthony Sorace]

erik wrote:

> it's interesting to compare this with the sleezy not-paths
> that e.g. gnome programs can take, like uris.  great as long
> as long as you don't care to use anything but gnome tools.

i had that debate with a kde-loving linux admin. i had been explaining
why plan 9 was interesting or significant, and he countered with the
kde example. i was marginally impressed by the number of protocols
they handled, but when i asked how you'd use it with cat and friends,
he said "no, just use kate".

i reeled, stuttered, tried to get out something that sounded like
"layering violation", and ran away. it wasn't even a cost/benefit
argument; there wasn't any recognition of the costs.

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 2:14 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> I hate to be the one to bring this up but ... if you are providing
>> some extended (e.g.) math functionality to a program with a shared
>> library, people are going to be upset with you if you argue that it
>> can be done with RPC.
>
> i thought we were talking about linking c into scripting languages.
> you're not using python to actually do the calcuations, are you?
>

not me. But a depressingly large number of people do, nowadays.

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> not me. But a depressingly large number of people do, nowadays.

i don't drink enough to keep up with modern developments.

- erik

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> i had that debate with a kde-loving linux admin. i had been explaining
> why plan 9 was interesting or significant, and he countered with the
> kde example. i was marginally impressed by the number of protocols
> they handled, but when i asked how you'd use it with cat and friends,
> he said "no, just use kate".
>
> i reeled, stuttered, tried to get out something that sounded like
> "layering violation", and ran away. it wasn't even a cost/benefit
> argument; there wasn't any recognition of the costs.

does he also plans to build a tcp/ip stack into his
applications?  maybe we could dispense with the kernel.
it's complicated anyway.  each application could drive
hardware itself.  but to make this easier, we'll used shared
libraries.  the only system service we'd need is a shared library
loader.

- erik

Re: [9fans] Pegasus 2.6 is released

[Anthony Sorace]

you, um... never mind. what can i say?

http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network

Re: [9fans] Pegasus 2.6 is released

[Bruce Ellis]

Can I just say hahahahahahaha.

Or maybe welcome to the 80's.

brrucee

On Tue, Feb 3, 2009 at 9:57 AM, Anthony Sorace <anothy@gmail.com> wrote:
> you, um... never mind. what can i say?
>
> http://www.gnu.org/manual/gawk/html_node/Special-Network.html#Special-Network
>
>

Re: [9fans] Pegasus 2.6 is released

[David Leimbach]

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

On Mon, Feb 2, 2009 at 2:30 PM, Anthony Sorace <anothy@gmail.com> wrote:

> erik wrote:
>
> > it's interesting to compare this with the sleezy not-paths
> > that e.g. gnome programs can take, like uris.  great as long
> > as long as you don't care to use anything but gnome tools.
>
> i had that debate with a kde-loving linux admin. i had been explaining
> why plan 9 was interesting or significant, and he countered with the
> kde example. i was marginally impressed by the number of protocols
> they handled, but when i asked how you'd use it with cat and friends,
> he said "no, just use kate".
>
> i reeled, stuttered, tried to get out something that sounded like
> "layering violation", and ran away. it wasn't even a cost/benefit
> argument; there wasn't any recognition of the costs.
>
> Right but when you consider KDE runs on windows, then it's not as much of a
layering violation... no more than Java is I guess anyway.
The layering violation that I usually point at is the /dev/tcp created by
the bash shell :-).

[-- Attachment #2: Type: text/html, Size: 1443 bytes --]

Re: [9fans] Pegasus 2.6 is released

[lucio]

> maybe we could dispense with the kernel.
> it's complicated anyway.  each application could drive
> hardware itself.  but to make this easier, we'll used shared
> libraries.  the only system service we'd need is a shared library
> loader.

There's your final word in microkernels.  Throw away security and
things get a lot less complicated.  The human brain does not have,
that I am aware, security boundaries, why can't we model our personal
computers on that?

++L

PS: In jest, of course, but there's some value...

Re: [9fans] Pegasus 2.6 is released

[Bruce Ellis]

Or as Mark V. Shaney once said ...

"Why can't everyone wake up at 3am, totally confused".

I'm not sure of the relevance.

brucee

On Tue, Feb 3, 2009 at 3:26 PM,  <lucio@proxima.alt.za> wrote:
>> maybe we could dispense with the kernel.
>> it's complicated anyway.  each application could drive
>> hardware itself.  but to make this easier, we'll used shared
>> libraries.  the only system service we'd need is a shared library
>> loader.
>
> There's your final word in microkernels.  Throw away security and
> things get a lot less complicated.  The human brain does not have,
> that I am aware, security boundaries, why can't we model our personal
> computers on that?
>
> ++L
>
> PS: In jest, of course, but there's some value...
>
>
>

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Mon, Feb 2, 2009 at 8:26 PM,  <lucio@proxima.alt.za> wrote:
>> maybe we could dispense with the kernel.
>> it's complicated anyway.  each application could drive
>> hardware itself.  but to make this easier, we'll used shared
>> libraries.  the only system service we'd need is a shared library
>> loader.

um, sadly, this *is* the norm nowadays in HPC. And here you all
thought you were joking.

ron

Re: [9fans] Pegasus 2.6 is released

[Richard Miller]

> if you are providing
> some extended (e.g.) math functionality to a program with a shared
> library, people are going to be upset with you if you argue that it
> can be done with RPC.
>
> I hope the reason is obvious :-)

Not obvious to me.  In today's (well, tomorrow's) massively multicore
world, I would expect a remote call to a process in another core, with
its own instruction cache, could easily be more efficient than a local
procedure call.

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

On Tue, Feb 3, 2009 at 2:55 AM, Richard Miller <9fans@hamnavoe.com> wrote:

> Not obvious to me.  In today's (well, tomorrow's) massively multicore
> world, I would expect a remote call to a process in another core, with
> its own instruction cache, could easily be more efficient than a local
> procedure call.
>

well, there's remote calls and remote calls. Remote calls that go
through some shared memory queue are one thing. But a remote call that
goes through the kernel? You'd better have lots of work to amortize
that cost. The packages I've seen do not.

thanks

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> > Not obvious to me.  In today's (well, tomorrow's) massively multicore
> > world, I would expect a remote call to a process in another core, with
> > its own instruction cache, could easily be more efficient than a local
> > procedure call.
> >
>
> well, there's remote calls and remote calls. Remote calls that go
> through some shared memory queue are one thing. But a remote call that
> goes through the kernel? You'd better have lots of work to amortize
> that cost. The packages I've seen do not.

ignorant question.

is the cost in latency or cycles?  if the cost is latency
and your application is parallel, could the simple trick
of having multple outstanding help?

- erik

Re: [9fans] Pegasus 2.6 is released

[ron minnich]

Here's the best answer I can give, check this out:
http://www.scipy.org/

But as for introducing parallelism to cover the latency, it's an old
trick and works well. But do you want to be the one to tell people,
"you're going to have to introduce parallelism and fingernail-pulling
bugs because I want you to use RPC, not shared libraries". I'm sure
not going to do it, I've been handed my head enough times by the
programmers :-)

One thing I've learned: some people will take a hit of a factor of
1000 in performance to preserve their concept of what is easy to use.
Hence things like scipy. It works well for many people.

ron

Re: [9fans] Pegasus 2.6 is released

[erik quanstrom]

> One thing I've learned: some people will take a hit of a factor of
> 1000 in performance to preserve their concept of what is easy to use.
> Hence things like scipy. It works well for many people.

thanks for the reference.

this is an interesting problem.  most of the time a 1000x hit is
a great deal in the interest of simplicity.  the trick is finding
the problems you're willing to pay for.

to the original complaint about gnome and its ilk:
i don't see the argument against using file servers (rpc) instead
of shared libraries (creating a super-secret wormhole world).
it's not like the ftp/http transfers aren't all of the slowness,
at least to a first-order approximation.

- erik

Re: [9fans] Pegasus 2.6 is released

[Kenji Arisawa]

Sorry,

http://plan9.aichi-u.ac.jp/pegasus/eman-2.6/

Kenji Arisawa

On 2009/02/01, at 13:41, lucio@proxima.alt.za wrote:

>> Pegasus 2.6 is released with new WebDAV script written in Lua.
>> Take a look at http://plan9/remoty/pegasus/eman-2.6/ for more
>> details.
>
> We need a little bit more than "plan9" in the host name :-)
>
> ++L