-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain wrote:
> That last point can be elliminated by strictly enforcing I/O
> restrictions for ANY external addon. An external module/addon/plugin
> could be strictly forbiden to erase any file, modify any file that don't
> share the same base name as the current scene, create any file outside
> the default write permition.
> Going further, strictly forbide any I/O operation to any external library.

That's just it: Once you launch an external process, you have no control
over it. There's no way whatsoever to enforce I/O restrictions.

I suppose that under Unix/Linux you could run it under a chroot, but I'm
not aware that Windows supports anything like that. The ideal solution
would be an OpenBSD jail, but most users don't run OpenBSD...

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you can no longer tell the
difference between the top raytracing book and the "Raytracing for
Dummies" book. To you, they're both hopelessly uninformed.
    -- Taps a.k.a. Tapio Vocadlo
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFG/oSTcCmTzQ++ZncRAgsOAJ9Ysqry0z2mOExNgFPd6z0rwToJuQCgn4pH
+Oo9saOfPo1DkCZfQFIJOxo=
=Bo7d
-----END PGP SIGNATURE-----

Post a reply to this message

William Tracy nous apporta ses lumieres en ce 2007/09/29 13:00:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Alain wrote:
>> That last point can be elliminated by strictly enforcing I/O
>> restrictions for ANY external addon. An external module/addon/plugin
>> could be strictly forbiden to erase any file, modify any file that don't
>> share the same base name as the current scene, create any file outside
>> the default write permition.
>> Going further, strictly forbide any I/O operation to any external library.
> 
> That's just it: Once you launch an external process, you have no control
> over it. There's no way whatsoever to enforce I/O restrictions.
> 
> I suppose that under Unix/Linux you could run it under a chroot, but I'm
> not aware that Windows supports anything like that. The ideal solution
> would be an OpenBSD jail, but most users don't run OpenBSD...
> 
> - --
> William Tracy
> afi### [at] gmailcom -- wtr### [at] calpolyedu
> 
> You know you've been raytracing too long when you can no longer tell the
> difference between the top raytracing book and the "Raytracing for
> Dummies" book. To you, they're both hopelessly uninformed.
>     -- Taps a.k.a. Tapio Vocadlo
There is a way, it's called "sandboxing". The process runs in a limited, closed, 
virtual machine and only have access to what YOU want it to see. That way, the 
process may never even "know" that there is a disk or anything else. It can't 
launch another programm, because it can't locate any programm but those you 
explicitely permit it to see. And those other programms can only be launched in 
that same sandbox. Upon termination, the calling application retreive the 
result, and terminate the virtual machine and anything in it, now and 
unconditionaly.
This can be done indepently of the OS you use and the CPU used.

-- 
Alain
-------------------------------------------------
The strongest reason for the people to retain the right to keep and bear
arms is, as a last resort, to protect themselves against tyranny in
government.
Thomas Jefferson

Post a reply to this message

William Tracy wrote:

>> 5) Allow the linking of external libraries, so that POV can
>> access custom programming routines from various languages. 
> 
> I'm of two minds on this.
> 
> This would be *very* useful. If there's something that you can't do in
> SDL, you can add it. :-)
> 
> On the other hand, it becomes possible to write malicious POV files. How
> would you like to download a scene file and have it erase all your files
> when you try to render it? Not good.
> 
> That's a tough one, because it's not a technological problem so much as
> a social one. :-(

It could also make the POV community diverge in groups with different sets
of libraries. E.g. because some libraries are only available for a 
subset of OSes.

Post a reply to this message

Before adding it to my temporary (until the wiki comes on-line) 
new-POV-page (http://members.chello.nl/a.c.linnenbank/newsdlforpov.html)
I though it would be better to discuss here.

Just an observation:
The syntax for our objects is what makes POV different from most other 
languages its syntax is something like:

object{parameters modifiers)

e.g.

sphere{ <x,y,z>,r
   pigment{rgb <r,g,b>}
   rotate <rx,ry,rz>
   translate <tx,ty,tz>
}

Note that there a re three totally different arguments here.

- the assignment to pigment could be though of as accessing a class 
element, more conventionally denoted as sphere.pigment=...
That might also be the standard (preprocessor ;) ) translation if POV4 
will be based on another language.
There is also the concept that you can have a pigment statement where 
ever you need a texture.

- <x,y,z> and r are unnamed but in a definition of sphere they could be 
defined as (introducing a new object definition syntax [1])

object: sphere(vec3D: location, scalar: radius)

so if you know this definition you could access sphere.location and 
sphere.radius

- the family of modifiers that change the appearance of the object 
(rotate, translate, scale and such). The members of this family interact 
so the natural interpretation is that these are member functions.

[1] do we need a object definition syntax in POV4? I think we do, how 
else could we define new object types? This may also be the point to 
mention that the current set of primitive objects is far from 
consistent. We have sphere{<Center>, Radius} while we also have 
box{<Corner_1>,<Corner_2>}, why don't we have cube{<Center>, size} or
cube{<Center>, <size>}? And why do we have to translate the 
superellipsoid manually with a translate?

PS: what exactly was my point? I am sure I have seen it less than half 
an hour ago.

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Alain wrote:
> There is a way, it's called "sandboxing". The process runs in a limited,
> closed, virtual machine and only have access to what YOU want it to see.

So, you propose that every time POV code loads an external program, you
launch a full-scale virtual machine? Are we going to license something
from VMware? Are you going to ask people to buy extra licenses from
Microsoft for the copies of the operating system running inside the VM?
(Jeez, I'm starting to sound like Warp.)

Sandboxing is great for your language's own scripts/bytecode, but is
less than helpful for _external_ libraries and arbitrary programs, which
is what we were talking about.

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you have gone full circle
and find your self writing a scene that contains only a shiny sphere
hovering over a green and yellow checkered plane.
    -- Ken Tyler
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHACUgcCmTzQ++ZncRAhqzAKCumUBVkzdhWSIUV8/G8eshSDgPtwCgskNO
BG4sB+d9gHRekR6ZpSLULsM=
=hbRb
-----END PGP SIGNATURE-----

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

andrel wrote:
> It could also make the POV community diverge in groups with different sets
> of libraries. E.g. because some libraries are only available for a
> subset of OSes.

If that were the only problem, the extra flexibility would be well worth it.

This is one of those things that I would only expect 10% of the userbase
to even touch--if lots of people wind up needing it, it's because we
screwed something up.

Besides, we already have that showing up with people using modelers and
such. Remember that Pose-ray is Windows-only?

I'd say make as much as you can work inside of Pov (hence the argument
for a much expanded SDL that does things that people now use external
programs for), and then get out of the way of everyone that we can't
directly support.

Unless of course you want to include every obscure scientific
visualization library into Pov. ;-)

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you spent the whole of
Titanic wishing the actors would get out of the way.
    -- Dylan Beattie
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHACaBcCmTzQ++ZncRAoRHAJ9thPyTTKsPvYOMIWxDHEn/h8yMMwCbBog2
tJM2kV5P2tat0y4KqFs+QzY=
=Tek1
-----END PGP SIGNATURE-----

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Nicolas Alvarez wrote:
> Maybe we need something more POV-Ray specific, but I thought I should bring
> this up anyway... Have you heard of the Parrot bytecode[1]?

I haven't, but it looks very interesting.

- --
William Tracy
afi### [at] gmailcom -- wtr### [at] calpolyedu

You know you've been raytracing too long when you know the teapot bezier
patches by heart.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHAClNcCmTzQ++ZncRAjeeAJ4giIt/pRxVNSg5CWzY65A1RPf3AACdEOJf
reBNYooeE7hrsFp1zbAHJyE=
=mI9h
-----END PGP SIGNATURE-----

Post a reply to this message

On Sun, 30 Sep 2007 15:43:13 -0700, William Tracy wrote:

> If that were the only problem, the extra flexibility would be well worth
> it.

Only so far as the features one wants are in the OS that one is using.  
If you've used any OS other than Windows in the last 10 years, you've 
come to expect that full functionality may not be available in the OS of 
your choice.

Purposefully designing a program so that this can happen is a bad idea.  
If you pop over to the povray.unix group, you can see that some are 
already unhappy with the fact that POVRay on Windows has a "nice GUI" 
<spit - I prefer CLI myself>, but on *nix platforms, all you get is an 
"ugly CLI interface".

Now extend that to features in the language itself - that's a recipe for 
chaos, because the POVRay you use on *nix may not necessarily have the 
same functionality as the Windows version, and your scene files won't 
actually render because of missing functionality.  You end up with an SDL 
that is *not* portable.  Nonportability is BAD.

> Besides, we already have that showing up with people using modelers and
> such. Remember that Pose-ray is Windows-only?

That's a bit different than limiting the featureset of POVRay itself for 
users of some OSes.

Jim

Post a reply to this message

William Tracy <wtr### [at] calpolyedu> wrote:
> Nicolas Alvarez wrote:
> Have you heard of the Parrot bytecode[1]?
>
> I haven't, but it looks very interesting.

until you realize it's something, like Perl6 itself, that has been in the
works for about 6 years, without ever managing to get out of beta status.
In the hiatus, the python community came up with an innovative VM system
called PyPy and ruby increased its presence immensely.  And Lua too got a
lot of critical acclaim...

I was thinking... the next Povray supposedly is going to be GPL.  Would you
guys find it feasible to ship it together with GCC?  My point is:
JIT-compilation is still a relatively new area and there aren't sufficient
open-source implementations out there.  But traditional ahead-of-time
compilation is easily achieved.  If it was possible for a povray SDL script
to be compiled before running, performance wouldn't be a problem any more.

then, I could even suggest getting a Scheme implementation like chicken to
be a possible SDL frontend... :)

Post a reply to this message

> Fa3ien <fab### [at] yourshoesskynetbe> wrote:
>> If the shaders are compiled on the fly before rendering (which is, IMMSMW,
>> what POV-Man did), could they really be slower than hard-coded ones ?
> 
>   It assumes that the shaders can be compiled and that the compiler will
> be able to optimize them in the same way is the C++ compiler optimizes the
> current algorithms written in C++.

The most fundamental (and time-consuming) algorithms could be hard-coded
(ior, fractal noise, turbulence, whatever...) to gain the most speed.

And if the shader language is, in fact, an existing language, like C or Ruby,
or any smart choice, making use of POV-Ray-specific classes, efficient
compilation shouldn't be a problem (I think).

Fabien.

Post a reply to this message