Re: [opensource-dev] Third party viewer policy

[Erik Anderson]

>From Gareth's analysis, I'm guessing that the "ban" today was a rather
ill-timed bug and that someone probably has egg on their face from messing
up the production login server while in the middle of some rather delicate
negotiations here regarding said server.  Amazon did something similar with
dropping books several months back, so it might be good to take a breather
in all of this...

On Thu, Feb 25, 2010 at 3:08 PM, Rob Nelson wrote:

> My estate's prototype land management/group invite bot was banned last
> night ("Second Life cannot be accessed from this computer, please email
> us at our non-working support email so we can laugh at you") but it
> works this morning.  Looks like they got too many support emails and had
> to reverse that ban.
>
> On Thu, 2010-02-25 at 12:31 -0600, Matrice64 wrote:
> > well put k\o\w :-)
> >
> > On Thu, Feb 25, 2010 at 11:37 AM, Maggie Leber (sl: Maggie Darwin)
> >  wrote:
> > On Thu, Feb 25, 2010 at 11:45 AM, Gigs 
> > wrote:
> > > Henri Beauchamp wrote:
> > >> Thank you for contacting us regarding your issue.
> > >> I am sorry but we can only offer support on issues with the
> > official
> > >> SL viewer.
> > > This sort of response is completely unacceptable.  You
> > weren't asking
> > > for support for your viewer, you were asking for support
> > related to the
> > > server's behavior.
> >
> >
> > I've been blown off with that excuse too.
> >
> > Read http://jira.secondlife.com/browse/SVC-5357 for my
> > trail-of-tears
> > support experience.
> >
> > Sure glad I went premium, I got this nifty free house...
> >
> > ___
> > 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
>
>
> ___
> 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

Re: [opensource-dev] Mailman for opensource-dev on pipermail is slicing posts

[Erik Anderson]

I just was looking at the opensim-dev list last night and it looks like it's
been shredding gears for a week or so now.  Finally stopped logging any
messages at all until a single message came through yesterday.

On Sun, Feb 28, 2010 at 10:59 AM, Morgaine
wrote:

> For the month of February, there are now 4 posts (from different people)
> that have been sliced into pieces and their headers-less tail fragments
> placed into the mailing list archive with a Subject line of "No subject".
> See the top of the threaded 
> viewlisting.
>
> Could someone please request the mail sysadmins to take a look at this bug?
>
> Cheers,
>
> Morgaine.
>
> ___
> 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

Re: [opensource-dev] Script Memory Management Algorithm

[Erik Anderson]

So...

If the script hits a memory wall, there's no way to transparently increase
that wall and start reporting that the script is taking more RAM?  Or has
the stack+heap collided with each other at that point and there's no way to
reform the memory space?  Isn't this already something that scripts are
currently doing with their one-way llGetFreeMemory function?

On Tue, Mar 9, 2010 at 7:51 AM, Dickson, Mike (ISS Software) <
mike.dick...@hp.com> wrote:

> I'm inclined to agree.  Not to mention addressed the cost of maintaining a
> forked version of mono and the effort to forward port it into new releases.
>
> I suppose it's possible that a change to malloc could make script memory
> allocation problems much simpler but that seems highly unlikely.  More
> likely you're trivializing a complex problem (in addition to allocation
> there are the issues of migrating the heap across simulators if a script
> moves, etc).
>
> Mike
>
> -Original Message-
> From: opensource-dev-boun...@lists.secondlife.com [mailto:
> opensource-dev-boun...@lists.secondlife.com] On Behalf Of Argent
> Stonecutter
> Sent: Tuesday, March 09, 2010 9:06 AM
> To: Carlo Wood
> Cc: server-b...@lists.secondlife.com; opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Script Memory Management Algorithm
>
> On 2010-03-09, at 07:26, Carlo Wood wrote:
> > This is exactly the kind of reaction that drives me away from here.
> >
> > I propose a simple way get FOUR times the memory for all the
> > scripts, at
> > no other cost than adding some malloc code to your mono engine.
>
> I don't think you have established that.
>
> ___
> 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
>
___
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] Request for comments about llSetAgentEnvironment / SVC-5520

[Erik Anderson]

On Wed, Mar 10, 2010 at 9:34 AM, Maggie Leber (sl: Maggie Darwin) <
mag...@matrisync.com> wrote:

> On Wed, Mar 10, 2010 at 12:29 PM, Kelly Linden 
> wrote:
> > Windlight settings should be a part of the build and not something
> > you have to opt into or be bugged with a dialog to see.*
>
> Well, then how about automatic applications of animations to your
> avatar, because a "content creator" thought it would be arty or cool?
> Or malicious Windlight settings that blind you, because it's
> "artistic" and "part of the shared experience"?
>
> The enhancement request as it stands calls for a permissions opt-in
> for having your viewer settings changed, and I support it in that
> form.
>

A little scared to jump into this rather heated discussion, but...

The environmental settings are only there to affect what the client sees (as
far as I know), not affect how anyone else sees the avatar.  So this is a
little different than "opt-out animations".  A closer analogy would be
whether the user would be required to opt into seeing particle effects by
one object or another.  This can and has been done maliciously - tons of
particle bombs are out there that pretty much prevent you from seeing
anything on the screen while they have an effect.  Requiring opt-in would
render bling pretty much useless though...

However, you can leave the area, and (if you know where the switch is) you
can turn them off.  I'm hoping that these scripted environmental effects
would be a little easier to turn off than particle effects however...
___
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] Known details of LL 'Firefly' client-side scripting

[Erik Anderson]

Not to mention that .NET does not have an uncontroversial licensing
arrangement, with many lawyers not able to figure out whether or not most
linux distributions are in technical violation...

On Wed, Mar 17, 2010 at 9:51 AM, Argent Stonecutter  wrote:

> > I don't follow you here. What I read in the above was a combination
> > of a well defined client side extension API and a mechanism to load
> > code that can be granted a level of trust based on criteria it needs
> > to do its job.  That might include code signing and metadata about
> > the capabilities the client plugin needs. I don't see any mention of
> > "untrusted binaries" other than the implication that a module that
> > doesn't negotiate additional capabilities gets started in a
> > sandboxed environment with minimal capabilities.
> >
> Any code not explicitly installed by the user is "untrusted".
> Executing untrusted code in a sandbox is an extremely difficult
> operation to perform safely. Doing so in a way that also accepts
> "trusted" code through the same mechanism is something that even
> Microsoft has notoriously failed to successfully pull off... a good
> number of the exploits of the late '90s and early '00s were due to
> failures of this security model.
>
> Doing this securely enough to ship is an extremely difficult
> undertaking, ranking alongside the whole of Second Life in ambition
> and scope, and not doing it securely could destroy Second Life.
>
> I would not use nor recommend using any viewer that implemented it.
>
> ___
> 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

Re: [opensource-dev] Brown-bag meeting to continue dialog on TVPV

[Erik Anderson]

Would Skype be an option?

--piping up from the peanut gallery...

On Fri, Apr 9, 2010 at 8:42 AM, Ron Festa wrote:

> I'm afraid that won't work. The ToS is an agreement between you (the user)
> and Linden Lab, not your avatar and LL.
>
> Personally I think a meeting such as this where many won't be involved due
> to the wording of the ToS and TPVP are preventing major TPV devs from
> entering this discussion would be better suited on a non-LL controlled grid.
> Maybe one of the other opensim grids would be a better choice.
>
> Ron Festa
> Virtual Worlds Admin
> Division of Continuing Studies at Rutgers University
> PGP key: http://bit.ly/b1ZyhY
> Phone: 732-474-8583
>
>
> On Fri, Apr 9, 2010 at 8:43 AM, Simon Disk  wrote:
>
>> Create an alt account for the sole purpose of attending the Brown-Bag
>> meetings, then cancel the account on April 29, 2010 before the ToS/TPVP
>> become effective.
>>
>> ___
>> 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
>
___
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] Brown-bag meeting to continue dialog on TVPV

[Erik Anderson]

Issues understood.  I've just been remembering previous in-world meetings
that were simulcast on skype, although I also remembered that they couldn't
get it working...

On Fri, Apr 9, 2010 at 8:51 AM, Robert Martin  wrote:

> On Fri, Apr 9, 2010 at 11:45 AM, Erik Anderson
>  wrote:
> > Would Skype be an option?
> > --piping up from the peanut gallery...
> >
> 1 not every stake holder even has skype
> 2 still has the not recordable problem
> 3 would it even scale to the needed level??
> --
> Robert L Martin
> ___
> 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

Re: [opensource-dev] Viewers in the directory are being impersonated already

[Erik Anderson]

Yah, but it might start looking a bit suspicious if it looks like you're
using computers as one-time pads, always using a different system for each
connection for a certain account?  Might not be as easily detectable for the
short-term accounts that get banned within minutes, but anything with
history would stick out fairly obviously.

On Mon, Apr 12, 2010 at 2:07 PM, Dale Glass  wrote:

> В сообщении от Вторник 13 апреля 2010 00:52:48 вы написали:
> > There's still other facets.  For example, the approved viewers get some
> > publicity and reputation by being on the approved viewers page, and it
> >  makes people think that much harder about using sketchy viewers to do
> >  sketchy things.  (And yeah, they have to do one extra sketchy thing, as
> >  Thomas mentions.)
> I don't think it makes a big difference.
>
> I'm talking about a group with a "FOR THE LULZ!" motto. I don't think they
> care much about keeping any account of theirs for very long.
>
> >
> > (As an aside, connecting from the same account and/or same IP with random
> > MACs seems pretty obviously strange and detectable.  There's a few more
> > hoops left to jump through there.)
> That will take some work though. At my house there are 5 computers that
> could
> run a SL client, that's 5 MACs, all behind the same NATed IP address.
> Schools,
> workplaces, cafes, etc could have hundreds of legitimate ones.
>
> ___
> 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

Re: [opensource-dev] Viewers in the directory are being impersonated already

[Erik Anderson]

I've heard Linden Labs make this exact same argument multiple times in the
past in response to resident reaction over this, so I'm fairly sure that
they are very fully aware of this fact.

2010/4/13 Ron Festa 

> Whether or not these tools are long term effective is irrelevant. The fact
> these tools exist is simply the point Dale was trying to make. The whole
> TPVP is a "Feel Good" Policy to delude residents into believing Linden Lab
> can prevent the criminal element from having the tools to grief or violate
> IP/CopyRight and keep them out. Despite the fact copybot and proxy hacks
> like God Mode have been around longer then the OS viewer, many residents
> blame the OS viewer for making such acts possible which all of us old timers
> who paid attention and all of us OS developers/contributors know isn't the
> case. As Real Life has proven over and over again, no Law or Policy will
> prevent criminals from obtaining the tools they need to commit crime and
> only hurt legitimate residents in the end.
>
> Ron Festa
> Virtual Worlds Admin
> Division of Continuing Studies at Rutgers University
> PGP key: http://bit.ly/b1ZyhY
> Phone: 732-474-8583
>
>
___
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] Requesting Linden Response: Please move TPVPTopics to a different mailing list

[Erik Anderson]

Unless I'm mistaken this discussion has been going since almost this list's
entire lifetime...

On Thu, Apr 15, 2010 at 4:04 PM, Joel Foner  wrote:

> I wonder if anyone has an easy way to calculate the actual signal (os-dev
> posts) to noise (legal posts) ratio on this list over, let's say the last 30
> days. It's getting hard to recall when the last actual os-dev discussion
> happened. Maybe I'm just missing it.
>
> Back to my regularly scheduled programming, as it were.
>
> Joel
>
> ___
> 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

Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list

[Erik Anderson]

Hey, if you're looking for a review of message queueing agents, I ran across
an SL review of MQs a while back when trying to choose one for our company's
back end COMET server.  It had value in my research and may have for someone
trying to come up with chat alternatives...

http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes


On Fri, Apr 16, 2010 at 9:20 AM, Dale Glass  wrote:

> On Thu, Apr 15, 2010 at 04:09:19PM +0200, Lance Corrimal wrote:
> > - 48 hours after the server code is out in the open, the 25 groups limit
> has
> > been lifted, AND the whole IM/group chat subsystem has been migrated to
> XMPP
> > (including voice via XMPP); another day and there's the possibility to
> connect
> > to jabber.sl.net with any xmpp client, AND talk to friends at any jabber
> > service.
> Very likely, but it doesn't necessarily work for SL.
>
> IIRC, the main issue with the group limit and IM is scaling. There can be
> 70K
> people online. Suppose you bump the groups limit to 100, and those 70K
> people
> end up belonging to 50 groups on average. Now you've double IM load, and if
> you remember the days where most group chat sessions failed, it's probably
> a
> quite heavy loaded system.
>
> Jabber would have the same issue: how to handle 70K people, many with
> multiple
> conversations and conferences. A small jabber server is easy, but
> supporting
> 70K logged in accounts is a serious undertaking.
>
> Of course none of this would be an issue for a third party grid with 50
> concurrent users.
>
> >
> > - 72 hours after the server code is out in the open, SVC-472 is fixed
> Region crossing is complicated in SL. OpenSim doesn't seem to do a lot
> better.
>
> If you'd be willing to improve it there, I'm sure many people would love
> it.
>
>
> But I agree, cool things could happen as a result :-)
>
> ___
> 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

[opensource-dev] message queue stability

[Erik Anderson]

A random thought from a non-contributor after reviewing the wiki a bit...

In the wiki page the biggest issue described for RabbitMQ was the idea that
it could not easily be partitioned without each node having a complete
description of every queue.

I'm wondering if it would be feasible to separate the concept of "exchange"
and "queue" onto different machines.  This would be a two-level structure,
where the lower level (the users or "queues") sends messages to the upper
level (the groups or "exchanges") which forward the messages back down to
the lower level and then to the users.  If this model can be made to make
any sense at all then it would permit partitioning of both users and groups
without each node having to have complete knowledge.

Of course one of the other major issues I see with RabbitMQ is that it
doesn't save messages to disk except for disaster recovery.  I hear they're
trying to create a new persister that actually is willing to have some saved
messages stored on disk, but otherwise I'm not sure I like the idea of
messaging servers crashing whenever people hit their message cap...

On Sat, Apr 17, 2010 at 12:02 AM, Erik Anderson <
eri...@odysseus.anderson.name> wrote:

> Hey, if you're looking for a review of message queueing agents, I ran
> across an SL review of MQs a while back when trying to choose one for our
> company's back end COMET server.  It had value in my research and may have
> for someone trying to come up with chat alternatives...
>
> http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes
>
___
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] Building SG useing VS2010

[Erik Anderson]

I've never even contemplated compiling the source, so this may have limited
value, but I did look at the output and the only real problems I could see
were an incompatibility between the BOOST libraries and the version of the
compiler you are using.

On Mon, May 3, 2010 at 7:31 PM, WolfPup Lowenhar wrote:

>  I’m wanting to get it so that I can build SG using VS2010 C++ express but
> my first attempt is very depressing as I got over 25k lines of output in the
> build window and it looks like there will need to be a few things done to
> make it build in VS2010. Here is a link to the text of that output if anyone
> wants to have a look at it.
>
>
>
> http://wilsontech.dyndns.org/sgv2-vc100-2010-04-25-1700-test-run
>
>
>
>
>
> ___
> 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

Re: [opensource-dev] [POLICY] Configurable HTTP user-agent string

[Erik Anderson]

Are you referring to something like this, which can track browsers even if
(and much easier if) they turn cookies off or tinker with their privacy
settings...

http://panopticlick.eff.org/

On Thu, May 6, 2010 at 6:32 AM, Argent Stonecutter
wrote:

> On 2010-05-06, at 01:23, Ricky wrote:
> > How can that be a source of correlation, unless you are using a viewer
> > that has a userbase of one (yourself and your alts)?
>
> When you're gathering information on someone for tracking purposes you
> don't need certainty. Even a viewer with a few percent of the market
> can be used to direct suspicion at a new account unless they
> completely avoid all their old hangouts.
>
> There are precisely four viewers that are common enough that using one
> wouldn't be a red flag: The current and new Linden viewer, Snowglobe,
> and Emerald.
>
> People who are currently using other viewers and don't pay attention
> to the privacy implications of new features (ie, just about anyone)
> would be wearing a target. New privacy exposures have to be opt-in,
> not opt-out.
>
> This functionality would have to not just be spoofable, but be off by
> default and turning it on would be done through a user interface that
> actually shows you the current string and presents common alternatives.
>
> If you were doing this, then it would be easier, easier to understand,
> and MUCH more useful to implement a general set of account tags or
> properties that people could edit at will. This would provide all the
> functionality people would get from a genuinely secure
> "llDetectedViewer()" type of API, since viewers could have a nice easy
> button that sets "Emerald: yes".
> ___
> 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

Re: [opensource-dev] Introduction

[Erik Anderson]

On Wed, Jun 2, 2010 at 10:58 AM, Carlo Wood  wrote:

> On Wed, Jun 02, 2010 at 11:51:11AM -0400, Monty Brandenberg wrote:
> > On 6/1/2010 9:30 PM, Oz Linden (Scott Lawrence) wrote:
> > > Conflict is
> > > fine - sometimes it's even productive, as long as it's done in a way
> > > that recognizes that everyone is
> > > ___
> >
> > Sorry, people, Oz got into a fight.  He'll pick this up again
> > after the beating...
>
> As inspector Clouseau already wisely said in one of his
> movies: "There is a time for fighting and there is time
> for not fighting... And the time for fighting is..."
>

Isn't that about the time that he would accidentally throw himself out of a
window or something?
___
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] display names = the end of 1.x viewers?

[Erik Anderson]

My interpretation of what was said is that the script using a 2.X viewer
would NOT say "Andromeda Resident", SL is just stating that users in the
future will not be asked for a last name when they sign up, all new users
after that point would have a last name of "Resident", which the 2.X viewers
would likely hide.

On Tue, Aug 17, 2010 at 3:45 PM, Andromeda Quonset <
andromedaquon...@gmail.com> wrote:

> It appears to me that if I create a script using viewer 1.X, it will
> show as being created by Andromeda Quonset.  It also appears to me
> that if I create the same script using a 2.X viewer, that it will say
> it was created by Andromeda Resident.
>
___
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] display names = the end of 1.x viewers?

[Erik Anderson]

I wouldn't say "forever", I suspect a few years down the line it would be
transitioned to "Andromeda.Quonset Resident" and then permanently drop the
last name...

On Tue, Aug 17, 2010 at 3:54 PM, Brian McGroarty  wrote:

> This is correct. Andromeda Quonset will be Andromeda Quonset forever.
> At some point, new residents won't be able to choose a last name -
> only these will be "Resident"
>
> No existing script function will return different results than it does
> today. New script functions are added for fetching/referencing Display
> Names.
>
___
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] display names = the end of 1.x viewers?

[Erik Anderson]

Lol, another peanut thrown from the back rows, but doesn't "Compatibility
with openID" that mean that we may start seeing
"christa...@facebook.comresident" in a few years?

(Note: I am not saying that this has been stated or is acceptable to anyone
any visible timeframe and am not trying to start another flamewar on
something no one said is going to happen)

On Thu, Aug 19, 2010 at 4:18 AM, Jesse Barnett  wrote:

> baloo198731.residentPlenty of names available.
>
> This has absolutely nothing to do with "We listened to our users" as this
> is not what we asked for. Pyske figured it out in the SLU thread. This is a
> move to the openID format and this is confirmed when you look at the Display
> Name wiki page:
>
> "This feature is an important step on our social media strategy that will
> ultimately allow you to connect your inworld identity to other social
> networks, on an opt-in basis. Again, Display Names and eventually, the
> connection to social networks, is all about choice."
>
> Jesse Barnett
>
> On Wed, Aug 18, 2010 at 3:22 PM, Baloo Uriza  wrote:
>
>> On Tue, 17 Aug 2010 16:04:19 -0700, Kelly Linden wrote:
>>
>> > 'Resident' is just the final last name, and is treated specially on new
>> > viewers to be hidden from view when displayed.
>>
>> So new users won't have the choice of picking a last name anymore?  Isn't
>> that going to severely limit the number of names possible now?
>>
>> ___
>> 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
>
___
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] Draw Distance

[Erik Anderson]

Just a quick/late comment for a thread that seems to have left the subject
line a couple days ago anyhow...

Requiring the draw distance to be changed that easily smells like a bad
paradigm that needs adjusting.  It reminds me of a database engine I was
using that required me to set the hash size of indexes in order to improve
performance.  Two major versions later and the engine was suddenly smart
enough to figure it out on its own and the hash size override was
deprecated.

Shouldn't the SL client be able to figure out what a good draw distance
would be?  Maybe have it start autodetecting draw distance based on rolling
average number of polygons visible or something?

On Sat, Aug 21, 2010 at 9:36 PM, Miro Collas  wrote:

> How about bbeing able to just type it in?  Why a slider, or mouse wheel,
> which is inaccurate? How about being able to type it in chat?
>
> On 08/22/2010 12:19 AM, a...@skyhighway.com wrote:
> > !! YES !!  If all i had to do was mouse up over the camera widget and
> roll
> > the scroll button i would be *soo* happy!  Serious.  i mean, Henri's
> > Cool VL innovation is great!  And i think that even if it were a mouse
> > wheel scrollable widget it should still have some kinda additional text
> > box to it where numbers can be typed in.  But to be able to look around
> > like that would be MEGA-AWESOME!!  (Just like opening your eyes *really*
> > wide...!!)
> >
> > - AK
> >
> >I probably use the draw-distance slider more often than any other UI
> > widget. I'd probably map it to my mouse's scroll-wheel, if I could.
> >
> > On 22/08/2010 10:31 AM, Suz Dollar wrote:
> >>> This is one concept that I have wanted for at least four years in SL. I
> >>> change draw distance multiple times a day depending on where I"m
> >>> visiting. Many of my own estate regions I can use a full powered 512
> >>> draw distance. Going to my public sandbox, however, requires an instant
> >>> drop to 128 or lower. Visiting my old 'hometown' of Caledon, mandates
> >>> the same. And I have to be honest, the places I can still use 512 draw
> >>> distance with viewer 2.x has dropped dramatically. I now usually can't
> >>> use higher than 256 yet have been assured since the first beta release
> >>> that there should be no performance difference between 1.23 and 2.x
> with
> >>> regard to graphics. An easily accessible way to change draw distance
> >>> would be awesome. I'm also frustrated that its so much harder with the
> >>> slider to hit the magic numbers: 64, 96, 128,  256 you get the
> idea.
> >>> But if the slider were at least out on the main UI somewhere, my own
> >>> preference being up in the navigation area, but anywhere directly
> >>> accessible, would be AWESOME.
> >>>
> >>> Char
> >>>
> >>>
> >>> a...@skyhighway.com wrote:
> > There was some talk lately about draw distance.  i mentioned that
> > from my
> > place if i have my draw distance turned up over about 150 i can
> almost
> > count on crashing when i tp.  i'm really sorry i can't describe the
> > problem any better than that.  If someone wants to tell me how i
> could
> > understand it better, i'd love to listen?
> >
> > Anyway, i mentioned in mail to this list that it would be really
> > cool if
> > there were an onscreen widget like the movement&   camera controls
> that
> > made draw distance a lot easier to change.  Please forgive me for not
> > having already figured out how to do that myself.  Just sayin' tho,
> it
> > would be really nice if, like for instance, Snowglobe had either a
> > mouse
> > gesture, keyboard short cut, or onscreen widget (all three?) for
> > rapidly,
> > easily changing draw distance,  i think it's a function that lots of
> > people would use heavily.  i know there's performance concerns, but
> if,
> > for instance, the onscreen widget included a simple performance bar
> > indicator that went down as the draw distance was turned up, that
> would
> > communicate pretty well to all the people who didn't know better for
> > whatever reason.
> >
> > The tp crash i get is just one more reason to make the setting easy
> to
> > deal with.  Besides, to me it seems like such a natural part of
> camera
> > controls that i don't know why it's not there already?  If it was me
> > adding the feature i'd put it in the camera controls widget.  i'd
> been
> > using SL for several months before i even realized that draw
> > distance was
> > configurable.
> >
> > Thanks for listening!
> >
> > ___
> > 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/wik

Re: [opensource-dev] Encrypted chat & third-party servers

[Erik Anderson]

Well, looking at the spec that was linked earlier in this thread...

When someone is using a TPV that can do OTR (and the user has indicated a
willingness to use it), then many(all?) their chats
will have "
   " at the end (this
is 
).
 I'm guessing that it is thought that no one would notice these unless they
were looking for them.

If someone wants to begin encryption with someone they think can handle OTR
(is this "coming out of the closet?") then they send "?OTR?v2?" as a chat.

I'm guessing that if a TPV doesn't see those spaces or doesn't get the
response it expects from its query, that it figures out the other person
doesn't support OTR?

On Wed, Aug 25, 2010 at 6:39 PM, Carlo Wood  wrote:

> Nevermind, I should have read the rest of the thread first.
> Looks like a pretty solid protocol.
>
> Does anyone know if it is possible for an arbitrary TPV
> to start an OTR with another TPV? If so, how? Or is it
> needed to be recognized by the other viewer as being
> a viewer that has OTR implemented?
>
> How do two viewer know if they both can do OTR?
>
> On Thu, Aug 26, 2010 at 02:53:25AM +0200, Carlo Wood wrote:
> > On Wed, Aug 25, 2010 at 01:59:49PM -0700, Brian McGroarty wrote:
> > > Has anyone spent time looking at the encrypted chat feature included in
> some
> > > third-party viewers? It's my understanding that this contacts
> third-party
> > > servers in obtaining and validating keys. Is that correct?
> >
> > If that is correct, then I'm pretty sure that the owners of
> > those servers have access to a key that would allow them
> > to read the encrypted messages. Imho, that is not acceptable :p
> >
> > Perhaps in time I'll be interested to implement a better
> > method.
> >
> > Carlo Wood (author of libecc
> http://libecc.sourceforge.net/reference-manual/index.html)
> > ___
> > 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
>
> --
> 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
>
___
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] Snowstorm clarification

[Erik Anderson]

I think the Lindens have pretty much left Subversion alone since they
stopped pushing out "code specially made for the public".  They've switched
to Mercurial, and the repository they're using at
http://hg.secondlife.com/viewer-development seems to have a fair amount of
activity...

On Thu, Sep 9, 2010 at 7:30 PM, Kitty  wrote:

> Maybe I missed something when Snowstorm was announced, but I was under the
> impression that LL was going to be more "open" about viewer development.
>
> Before Snowstorm there were "code drops" into viewer-external on SVN
> several
> times a week (or weekly at worst).
>
> Since Snowstorm there haven't been any noteworthy upstream "code drops"
> from
> LL into viewer-development (2.1.1 was added, but then it was already on SVN
> before) that aren't resident contributions or reintegrating Snowglobe
> patches.
>
> If development of the viewer hasn't been halted for the past three weeks,
> where is all of the code going?  *confuzzled*
>
> Or in the new terminology: as a resident, I would like to know why an "open
> development" announcement has the net effect of LL releasing less than it
> did prior to that announcement.
>
> Kitty
>
> ___
> 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

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

[Erik Anderson]

I hate to break in like this, but we're discussing how inaccurate it is for
Mono scripts to contribute a different multiple than LSL scripts, but in the
end aren't we just counting scripts?  Would it be more accurate to report a
script count and let the user do whatever multiple they want, and then later
when there's a better number out there for memory usage release that as a
new number?  If any assumptions are made by the scriptor at that point they
know where the accuracy lies...
___
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] LGPL violation

[Erik Anderson]

I'm thinking that it may not require full source code if the ABI is
published at least -- the only "static link" that seems involved here is
whatever stub (.a?) is necessary to specify the ABI.  That would permit
someone to link to the library with alternate code (or replace the library
with free source if necessary).  It looks like they're going down a similar
route with the mesh deconstruction code.

On Sat, Oct 23, 2010 at 4:27 AM, Carlo Wood  wrote:

> I am not a lawyer :p, but I think that it is allowed to link an LGPL-ed
> library statically against a proprietary executable provided you
> provide the object code or source code of the work that uses the library.
>
> In other words, it must be possible to make changes to Qt and *relink*.
>
> Translating that idea to linking statically with a shared library, it
> is clear that one still has to be able to make changes to Qt and relink,
> or they are non-compliant. This means they must provide all the object
> code that was used to create (link) libmedia_plugin_gstreamer.so, or
> they must provide the source code so that people can generate this
> object code themselves.
>
> Imho, the only practical solution is to make the source code availabe,
> and most likely just all the source code of the whole viewer.
>
> On Fri, Oct 22, 2010 at 07:02:18PM -0700, Erik Anderson wrote:
> > Not sure this is worth sending to the list, but could you clarify that
> .so
> > files are statically linked to the executable that they are loaded into?
>  This
> > is a bit confusing to me.
> >
> > Or are they considered statically linked if you use the default dynamic
> loading
> > logic, rather than hand-coding GetProcAddr calls or equivalent?
>
> Nah - none of that. libmedia_plugin_gstreamer.so (the extension is
> different
> on OS other than linux I guess) is a shared library. However, it is
> constructed
> by linking statically with a modified version of Qt that was created by LL.
> Obviously, the users need to know what those mods are and they should be
> allowed to make changes of their own.
>
> For example, someone who already made changes to this version of Qt would
> not be able to use the mesh viewer until LL releases the full source code,
> so they are non-compliant if they release a 'beta' version of a viewer
> without
> providing the means to re-link libmedia_plugin_gstreamer.so with a
> different Qt.
>
> --
> 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] LGPL violation

[Erik Anderson]

There is a static component that is linked when linking to dynamic
libraries, however that is present mostly to inform the compiler on what the
ABI is, or how your compiled code is expected to interact with the DLL.  It
is very possible to write a piece of code that explicitly loads the library
by name and manually builds calls to it.  In fact, it's likely possible to
compile a program intended to run with a .dll without any related files
being on the machine at the time.

On Thu, Oct 28, 2010 at 8:52 AM, Carlo Wood  wrote:

> On Thu, Oct 28, 2010 at 08:27:52AM -0500, Dave Booth wrote:
> > On 10/28/2010 06:29, Carlo Wood wrote:
> > libmedia_plugin_webkit.{sp,dll,dylib}
> >
> > Make sure you quote examples of static linking when you're talking about
> > static linking :)
>
> Make sure you read carefully what I say and understand it before
> talking about wrong examples :)
>
> libmedia_plugin_webkit.{sp,dll,dylib} are linked STATICALLY with
> the Qt libs (as in, linked with .a).
>
> Thus:
>
>  Qt*.a (LGPL) + LL*.o (LGPL+FLOSS) = libmedia_plugin_webkit.so
>
>  ==> LL*.o must be made public (or their source code), or
>  libmedia_plugin_webkit.so cannot be shipped.
>
> --
> 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
>
___
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] Request for feedback - Preferences Cleanup

[Erik Anderson]

"Gag" ?

On Mon, Nov 8, 2010 at 10:22 AM, Celierra Darling wrote:

> That mute button sometimes does the opposite of what "mute" means in SL.
>  On the telephones in my house and on my Android, mute turns off the
> *microphone*, not the incoming sound.  (Ditto for some other apps I've seen,
> such as GoToMeeting.  "Hold" is the closest analogue, which turns off both
> directions.)  I'm guessing this is probably the source of some of the
> confusion.
>
> Celi
>
>
>
> On Fri, Nov 5, 2010 at 5:43 PM, Andromeda Quonset <
> andromedaquon...@gmail.com> wrote:
>
>>  FWIW,
>>
>> I would also like to see the return to "Mute" instead of "Block".  With
>> all due respect to your user testing, the telephone on my desk has a "Mute"
>> button, not a "Block" button, and I consider it a very heavily used
>> communications tool.  Perhaps there should be an option in preferences for
>> setting the label for this function to either "Mute" or "Block",  as that
>> would keep all of your users happy.
>>
>> Thank you
>>
>>
>> At 09:10 AM 11/5/2010, Sarah (Esbee) Kuehnle wrote:
>>
>> Thanks for the feedback everyone. I'm working on some updates to the pdf
>> right now and will send that out for further review later today!
>>
>> I can't promise all the suggested additions will go into the prefs, but
>> I'll definitely look at each one as I'm making updates.
>>
>> A few responses to those who's provided feedback so far:
>>
>> @Marine - 1) The text chat logs have been fixed in 2.3 beta. 2) We changed
>> the label from "Mute" to "Block" early on in V2 because our user testing
>> indicated new users were confused about what "Mute" means and understood
>> "Block" because it's used commonly in other communication tools.
>>
>> @GeneJ - That for the reminder on that typo. It was pointed out in my OH
>> the other week and I needed a good kick to remember to fix it! :)
>>
>> @Wolfpup - We're just talking about skinning for now. In the meantime, I'm
>> just gathering color options in one place. But you're right - future
>> skinning preferences will likely require a restart before changes would take
>> effect.
>>
>> @Erin - I've taken note of your request for the numerical debug settings
>> for sculpties. I'm not sure they make sense in this preference cleanup I'm
>> doing now, but will be useful when I can focus my team on a sprint focused
>> on content creation as some point in the near future. As far as local lights
>> go, they've actually been added back in on the Mesh Project Viewer (
>> SH-157 ) (which will
>> eventually be added into the main Second Life Viewer). I'll take a look at
>> the other tickets you referenced today.
>>
>> @Hitomi - Thanks for the additional settings. I'll review these this
>> morning and see what makes sense to incorporate. That's a great list!
>>
>> More updates from me soon!
>>
>> --Esbee
>>
>>
>> On Thu, Nov 4, 2010 at 6:50 PM, WolfPup Lowenhar  
>> wrote:
>>
>> I keep seeing people talking about user readable chat logs and from what
>> I’m seeing in the current dev builds the logs are already back to plain
>> text. I’m currently working on a feature that is dealing with chat and
>> group/personal IM logs.
>>
>>
>>
>> From: opensource-dev-boun...@lists.secondlife.com 
>> [mailto:opensource-dev-boun...@lists.secondlife.com]
>> On Behalf Of Hitomi Tiponi
>> Sent: Thursday, November 04, 2010 4:37 PM
>> To: Opensource_dev
>>
>> Subject: Re: [opensource-dev] Request for feedback - Preferences Cleanup
>>
>>
>>
>> Thanks for the Preferences mock-up (must say that I rather like the anime
>> look of them :)) - some really sensible stuff there.
>>
>> Suggestions (all currently in Debug Settings): Chat - adjustable life and
>> fade times for Startup, IM and Group popups - I find they are too short for
>> me to spot sometimes Chat - Add in spinners to alter the number of times
>> that IM tabs flash and the rate at which they flash at Advanced - Move
>> 'UI Size' slider to Graphics as KL and myself have done - it fits more
>> naturally there Graphics->Hardware - allow forcing on of Antialiasing (as
>> the Viewer GPU presets often gets this wrong) or better still fix the
>> presets :) Move & View - put in spinners for amount of head movement Move
>> & View - Checkbox to allow double-click point-move in-world as an
>> alternative to double-click teleport (which is welcome) Move & View -
>> Checkbox for 'Number keys move avatar' Privacy - Check-box to select
>> option to also create user-readable chat logs (as others have suggested) <-
>> this is what I’m referring to. Advanced - Checkbox for 'Show Grid
>> Selection at login' Advanced - Checkbox for 'Disable Camera Constraints' 
>> Advanced
>> - Checkbox for 'Limit the distance I can select objects at' and
>> sliders/spinners for selection distance and amount you can drag in one step 
>> Advanced
>> - Checkbox for 'Show UI in snapshots'
>>
>>
>>  No virus found in this message.
>> Checked by AVG - www.avg.com
>> Version: 10.0.1153