Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

i think that instead of separating the scripts, we should have a table
with script names, some info, like creator etc, and a bunch of
checkboxes to give or deny permission for the script to do stuff, with a
way for client scripts to trigger a permission request dialog. Among the
permissions would be a permission to remember permissions, and another
to save the script locally/with the account.

On 22/2/2010 01:51, Morgaine wrote:
> Dzon:  Nice parable. :-)
> 
> The moral of the story as it pertains to our topic is that when the
> superset is ambiguous as in our case (all scripts running client-side
> are naturally "client-side scripts"), then the ambiguity won't stop
> until you subset the space into disjoint subsets so that you can discuss
> each subset separately without confusion.
> 
> That's what I've been trying to do, because "client-side script" is a
> universal term that naturally denotes all scripts running in the client
> by simple plain English, so you can't call just one subset of the
> scripts by that name without creating ambiguity.
> 
> To remove the ambiguity, I split the space of all scripts that run
> client-side into two disjoint sets (note that we are using "scripts" and
> "programs" interchangeably here):
> 
> * *Trusted / Installed / Not-sandboxed*:  These are scripts which
>   you trust enough to install on your machine, and which typically
>   act as interfaces between the viewer and your local resources,
>   such as your files, applications, I/O devices, and so on.  Because
>   they interface to local resources, these scripts cannot run in a
>   sandbox.  In general, these scripts are for user empowerment ---
>   they can do anything the user wants them to do, and therefore a
>   very good term for them is "*client extensions*".   A large number
>   of accessibility scripts fall into this category, as well as
>   scripts for implementing new detached windows such as multi-screen
>   chat and inventories stored on the PC.
> 
> 
> * *Untrusted / Not-installed / Sandboxed*:  These are scripts which
>   you do not trust because they arrived by some automatic mechanism,
>   possibly from in-world.  They are never installed, but run in a
>   protective sandbox while needed, and disappear automatically when
>   no longer needed.  Because they run in a sandbox to (hopefully)
>   protect your machine from malicious code, these scripts can never
>   access your local resources, as that would be extremely
>   dangerous.  In general, these scripts are not for user
>   empowerment, but for enhancing or assisting the displayed content
>   from the current virtual world in some way.  A possible term for
>   them is therefore "*world extensions*".  This kind of script can
>   implement interesting HUDs using in-world data obtained from the
>   viewer, or new in-viewer windows, menus and improved viewer
>   inventory.
> 
> 
> 
> A separate question is whether it is wise to allow untrusted scripts to
> run on your client at all, given that there will always be bugs and
> protection failures, especially in the first few years.  But that is a
> topic for a later discussion I think, given that currently we have not
> yet managed to open a dialogue with Lindens about client-side scripting
> at all.
> 
> 
> Morgaine.
> 
> 
> 
> 
> 
> ===
> 
> On Mon, Feb 22, 2010 at 12:57 AM, Dzonatas Sol  > wrote:
> 
> Morgaine wrote:
> 
> Carlo, I agree completely with you on the principle of the
> implementation.
> 
> On the terminology, not only are you not being logical in your
> naming, but you also immediately contradict yourself and
> demonstrate beautifully how your suggested naming makes no sense
> at all, not even to yourself.� Let me demonstrate:
> 
> 
> 
> One of Linden Lab's disqualifiers on attempts to be hired had to do
> with a coin placed on any surface and the game of prediction of who
> would win based on who placed the last coin on the surface where
> there was room left over.
> 
> They go through a bunch of different kinds of objects, so I won't
> name them off so they can still use the fair ones.
> 
> However, there was one they were beautifully wrong about: the sphere.
> 
> They even called people "stupid" on the spot who couldn't figure out
> the sphere ended up with even amount of moves. Long story short
> about... stupid.
> 
> We could challenge this since somehow it became more than personal,
> or maybe it was meant to be challenged eventually. It wasn't their
> standard procedure whatever it was.
> 
> If we take a perfect sphere with a perfect surface, there is an
> obvious flaw that wouldn't allow it to be even in number of moves.
> 
> When LL said "here is a sphere th

Re: [opensource-dev] Client-side scripting in Snowglobe

[Tigro Spottystripes]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

the other day i was reading about how the Unreal engine works, they have
the client predicting the physics and sending control events tot he
server. During a lag spike the client continues to simulate the motion
by itself, and then whent he server starts talking again the server
sends the position, speed, rotation etc of stuff and the client adjusts
it's local simulation to match

On 19/2/2010 22:48, Lawson English wrote:
> 
> 
> There's been some talk of client-side physics being extended. 
> Obviously,  once you start doing that, the sim has less and less control 
> over what goes on. The ultimate form would be p2p-ish physics where the 
> sim doesn't participate at all in anything but sending geometry updates 
> and all calculations are shared between clients, either in a cobalt 
> fashion, or using a separate physics server (or hybrid).
> 
> 
> 
> Lawson
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges
> 
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.12 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkuCSs0ACgkQ8ZFfSrFHsmWijwCggPXvBR2irNWxIZv6sqlrjtop
lQkAn0cLUUQJkf3E6GR7wI4HxDlPO5Ht
=se9S
-END PGP SIGNATURE-
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Kajikawa Jeremy]

Client-Side-Scripting Examples,

  Javascript / LindenScript / VBscript / Python,

  The source and result program are one and the same,

Client-Side Extensions,

  Dynamic Link Libraries / Adobe Flash Player / Java / Mono

  The distributed program is NOT the original source
--

  Using the former expands on needing security,

  Using the latter devolves the client and seperates parts into own
program modules.

An Example of using Both is the Firefox Browser / Thunderbird Email
  and similar tools...

Can something similar to that be done?

  Use plugins for secure extension of the client from sandboxed scripts?
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Client-side scripting in Snowglobe

[Argent Stonecutter]

On 2010-02-22, at 03:13, Tigro Spottystripes wrote:
> the other day i was reading about how the Unreal engine works, they  
> have
> the client predicting the physics and sending control events tot he
> server. During a lag spike the client continues to simulate the motion
> by itself, and then whent he server starts talking again the server
> sends the position, speed, rotation etc of stuff and the client  
> adjusts
> it's local simulation to match

That's pretty much what the SL client does, it just has a particularly  
simplistic physics (no collisions, no gravity, everything moves in  
straight lines).

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Dzonatas Sol]

Morgaine wrote:
> Dzon:  Nice parable. :-)

Thank you. Unfortunately, some still challenge it as if they know the 
only answer, yet they should read up on Proton Exchange Membranes, 
especially Zero-Emission, for proof.

For a business to use patented method in their employment process was 
quite remarkable.Sometimes people get jurassically blindsided by... scale.


>
> To remove the ambiguity, I split the space of all scripts that run 
> client-side into two disjoint sets (note that we are using "scripts" 
> and "programs" interchangeably here):

I would go with three. Call the third one: "*Transient Scripts & 
**Transient **Array*s", or something similar with the word "transient" 
being significant.More successful designs have included this third area.

Basically, in the transient area, you wouldn't want the responsibility 
of the existence any particular script to fall upon the corporal 
location of such script, not that the corporal is entirely excluded from 
being responsible.There is a balance that is needed, and it is best to 
keep the nature of the balance away from the two other areas you described.

>
> * *Trusted / Installed / Not-sandboxed*:  These are scripts which
>   you trust enough to install on your machine, and which typically
>   act as interfaces between the viewer and your local resources,
>   such as your files, applications, I/O devices, and so on. 
>   Because they interface to local resources, these scripts cannot
>   run in a sandbox.  In general, these scripts are for user
>   empowerment --- they can do anything the user wants them to do,
>   and therefore a very good term for them is "*client
>   extensions*".   A large number of accessibility scripts fall
>   into this category, as well as scripts for implementing new
>   detached windows such as multi-screen chat and inventories
>   stored on the PC.
>

Good. I would think extensions might confuse what direction they extend 
from, however. If we are to maintain balance, and responsibility, then 
we need to know that direction. The scripts on the client side may have 
nothing to do with the client viewer. These same scripts may also seem 
like a server. Easiest to consider these as "processes," yet that has 
been confused by the organically evolved chipsets and thread technology. 
What the "world" only needs to know from the "world" viewpoint are the 
transfer devices, or membranes. Then we have scripts that can and cannot 
be exchanged through the membrane. Those that can't get through the 
membrane, we call "brains" on one scale and "protons" on another scale. 
That'll work for now.


>
> * *Untrusted / Not-installed / Sandboxed*:  These are scripts
>   which you do not trust because they arrived by some automatic
>   mechanism, possibly from in-world.  They are never installed,
>   but run in a protective sandbox while needed, and disappear
>   automatically when no longer needed.  Because they run in a
>   sandbox to (hopefully) protect your machine from malicious code,
>   these scripts can never access your local resources, as that
>   would be extremely dangerous.  In general, these scripts are not
>   for user empowerment, but for enhancing or assisting the
>   displayed content from the current virtual world in some way.  A
>   possible term for them is therefore "*world extensions*".  This
>   kind of script can implement interesting HUDs using in-world
>   data obtained from the viewer, or new in-viewer windows, menus
>   and improved viewer inventory.
>
>
>
> A separate question is whether it is wise to allow untrusted scripts 
> to run on your client at all, given that there will always be bugs and 
> protection failures, especially in the first few years.  But that is a 
> topic for a later discussion I think, given that currently we have not 
> yet managed to open a dialogue with Lindens about client-side 
> scripting at all.
That is what the transient area handles.

The only way really possible for completely untrusted scripts and arrays 
to compute on the client side as "world extensions" would be to make a 
complete copy of the original on the other-side of the membrane. That 
isn't always true, yet on the scale of "brains" it's a good idea of 
where to start, not where they would have lost control so easily.

20 years of "fighting" about all this has really set us back.Would have 
been easier if "trust" was actually accepted rather than some paper 
masquerade.


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Carlo Wood]

On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote:
> When LL said "here is a sphere the size of a quarter in diameter...
> 1 2 3 4 5 6" as one points top, bottom, left, right,  back, front.
> And says "Stupid" with a superiority look.
> 
> Obviously the person that was challenged, the one to be hired, said "Odd."
> 
> If you know if it is "even" or "odd" then you know who gets the last
> move, and wins.

This is clearly a way to measure someones spatial insight.

Now note that if it's a game, and coins are not allowed to be moved
around once they are placed, then it's very unlikely that you will
be able to place 6 coins on the surface of that sphere (with diameter
equal to the coin), because the one who'd put down the fifth coin
would not put it such that you can put down the sixth coin, but
somewhere in the middle of the left-over surface, leaving no spot
for the sixth coin. Calling people stupid over this game surprises
me however (because I happen to have a extremely large spatial
insight, officially measured mind you (although, they couldn't
actually graph it in their graph because I scored not just out of
the graph but even off the paper that the graph outline was printed
on)), because I'm having a hardtime to quickly guess if you CAN put
five coins on the sphere... It seems not unlikely that only four
coins will make it... which would mean that the one that begins
will try to leave open as much space as possible when putting
down the third coin. The person to move second would try to use
as much space as possible. So, first goes on top say, second on
grounds of symmetry probably on the bottom, then again forced to
play without any strategy, the third coin just goes on the side,
and the fourth coin, wanting to be last, takes the exact
opposite of that, leaving two places free: Oh hell... that
way you STILL end up with six coins being placed, even though
both tried to screw the other with strategy. The only freedom
that still exists would be the one placing the second coin: by
not placing it exactly on the opposite side, you'll likely end
up with only five coins. However, since putting it on the exact
opposite side caused this player to win, he has little reason
to play it elsewhere. Hence, due to perfect symmetry, the first
player has no real choice, ever. And the second one, who wins,
can control the game completely; hence 6 coins.

Not THAT simple however.

-- 
Carlo Wood 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Carlo Wood]

There is no need for A != B.

Why not define the words A and B such that A includes B?  B \in A

Then you can still talk about the subject, since there is still a C = A \not B,
such that the intersection of B and C is empty.

In other words, yes Client-Extensions include plugins that implement
Client-side scripting, but it won't give confusion because if someone means
that, they will say "Client-side scripting", so if they DON'T say that,
they probably mean something else, either something broader (including
client-side script plugins) or something entirely different even.

On Mon, Feb 22, 2010 at 04:51:20AM +, Morgaine wrote:
> The moral of the story as it pertains to our topic is that when the superset 
> is
> ambiguous as in our case (all scripts running client-side are naturally
> "client-side scripts"), then the ambiguity won't stop until you subset the
> space into disjoint subsets so that you can discuss each subset separately
> without confusion.
> 
> That's what I've been trying to do, because "client-side script" is a 
> universal
> term that naturally denotes all scripts running in the client by simple plain
> English, so you can't call just one subset of the scripts by that name without
> creating ambiguity.

-- 
Carlo Wood 
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] New mailing list for aditi (beta) simulator releases

[Soft Linden]

Curious what changes come with a new simulator? Want to know when
something new is landing on aditi?

New server-beta mailing list:
https://lists.secondlife.com/cgi-bin/mailman/listinfo/server-beta

Release notes will always be linked here:
http://bit.ly/ADITI_notes

In-world group:
Second Life Beta

Also Oskar Linden, the owner of the new list, holds QA office hours
with an eye toward aditi. Check past notices or ask in the Second Life
Beta group to learn when and where.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Colin Kern]

On Mon, Feb 22, 2010 at 6:51 PM, Carlo Wood  wrote:
> On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote:
>> When LL said "here is a sphere the size of a quarter in diameter...
>> 1 2 3 4 5 6" as one points top, bottom, left, right,  back, front.
>> And says "Stupid" with a superiority look.
>>
>> Obviously the person that was challenged, the one to be hired, said "Odd."
>>
>> If you know if it is "even" or "odd" then you know who gets the last
>> move, and wins.
>
> This is clearly a way to measure someones spatial insight.
>
> Now note that if it's a game, and coins are not allowed to be moved
> around once they are placed, then it's very unlikely that you will
> be able to place 6 coins on the surface of that sphere (with diameter
> equal to the coin), because the one who'd put down the fifth coin
> would not put it such that you can put down the sixth coin, but
> somewhere in the middle of the left-over surface, leaving no spot
> for the sixth coin. Calling people stupid over this game surprises
> me however (because I happen to have a extremely large spatial
> insight, officially measured mind you (although, they couldn't
> actually graph it in their graph because I scored not just out of
> the graph but even off the paper that the graph outline was printed
> on)), because I'm having a hardtime to quickly guess if you CAN put
> five coins on the sphere... It seems not unlikely that only four
> coins will make it... which would mean that the one that begins
> will try to leave open as much space as possible when putting
> down the third coin. The person to move second would try to use
> as much space as possible. So, first goes on top say, second on
> grounds of symmetry probably on the bottom, then again forced to
> play without any strategy, the third coin just goes on the side,
> and the fourth coin, wanting to be last, takes the exact
> opposite of that, leaving two places free: Oh hell... that
> way you STILL end up with six coins being placed, even though
> both tried to screw the other with strategy. The only freedom
> that still exists would be the one placing the second coin: by
> not placing it exactly on the opposite side, you'll likely end
> up with only five coins. However, since putting it on the exact
> opposite side caused this player to win, he has little reason
> to play it elsewhere. Hence, due to perfect symmetry, the first
> player has no real choice, ever. And the second one, who wins,
> can control the game completely; hence 6 coins.
>
> Not THAT simple however.
>

There's really no way to figure it out without information about
either of the player's strategies.  It seems like what the interview
was really asking is what the maximum number of coins that could be
fit on that surface was, or he should have specified that these two
players were perfect and playing optimally.

Colin
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Consensus? was: Client-side scripting in Snowglobe

[Marine Kelley]

Exactly my thinking too, the problem us not clear whether the players  
are cooperative or in competition. It totally changes the result.

But I guess that the real goal of this challenge is to call you  
"stupid" and to gauge your reaction. If you yell or punch the  
recruiter, you're dismissed. If you say "my bad, you're right", you're  
dismissed. But if you argue and explain your theory clearly, calmly  
and with the objective of solving the problem instead of just  
defending yourself, you prove that you're someone who can integrate a  
team that works on a system that is both technical and social.



On 23 févr. 2010, at 06:55, Colin Kern  wrote:

> On Mon, Feb 22, 2010 at 6:51 PM, Carlo Wood  wrote:
>> On Sun, Feb 21, 2010 at 04:57:18PM -0800, Dzonatas Sol wrote:
>>> When LL said "here is a sphere the size of a quarter in diameter...
>>> 1 2 3 4 5 6" as one points top, bottom, left, right,  back, front.
>>> And says "Stupid" with a superiority look.
>>>
>>> Obviously the person that was challenged, the one to be hired,  
>>> said "Odd."
>>>
>>> If you know if it is "even" or "odd" then you know who gets the last
>>> move, and wins.
>>
>> This is clearly a way to measure someones spatial insight.
>>
>> Now note that if it's a game, and coins are not allowed to be moved
>> around once they are placed, then it's very unlikely that you will
>> be able to place 6 coins on the surface of that sphere (with diameter
>> equal to the coin), because the one who'd put down the fifth coin
>> would not put it such that you can put down the sixth coin, but
>> somewhere in the middle of the left-over surface, leaving no spot
>> for the sixth coin. Calling people stupid over this game surprises
>> me however (because I happen to have a extremely large spatial
>> insight, officially measured mind you (although, they couldn't
>> actually graph it in their graph because I scored not just out of
>> the graph but even off the paper that the graph outline was printed
>> on)), because I'm having a hardtime to quickly guess if you CAN put
>> five coins on the sphere... It seems not unlikely that only four
>> coins will make it... which would mean that the one that begins
>> will try to leave open as much space as possible when putting
>> down the third coin. The person to move second would try to use
>> as much space as possible. So, first goes on top say, second on
>> grounds of symmetry probably on the bottom, then again forced to
>> play without any strategy, the third coin just goes on the side,
>> and the fourth coin, wanting to be last, takes the exact
>> opposite of that, leaving two places free: Oh hell... that
>> way you STILL end up with six coins being placed, even though
>> both tried to screw the other with strategy. The only freedom
>> that still exists would be the one placing the second coin: by
>> not placing it exactly on the opposite side, you'll likely end
>> up with only five coins. However, since putting it on the exact
>> opposite side caused this player to win, he has little reason
>> to play it elsewhere. Hence, due to perfect symmetry, the first
>> player has no real choice, ever. And the second one, who wins,
>> can control the game completely; hence 6 coins.
>>
>> Not THAT simple however.
>>
>
> There's really no way to figure it out without information about
> either of the player's strategies.  It seems like what the interview
> was really asking is what the maximum number of coins that could be
> fit on that surface was, or he should have specified that these two
> players were perfect and playing optimally.
>
> Colin
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting  
> privileges
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges