Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

And now, perhaps, we can get back to the important stuff, like the viewer itself. ;) On 23/08/2010 3:15 PM, Miro Collas wrote: > Yes she did. Here's the interview from treet.tv: > http://treet.tv/people/gracer/blog/20100822/audio-excerpt-interview-arabella-and-jessica >

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

And my own writeup: http://dwellonit.taterunino.net/2010/08/22/arabella-steadham-asked-to-lie-about-emerald-viewer/ On 23/08/2010 3:15 PM, Miro Collas wrote: > Yes she did. Here's the interview from treet.tv: > http://treet.tv/people/gracer/blog/20100822/audio-excerpt-interview-a

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Yes she did. Here's the interview from treet.tv: http://treet.tv/people/gracer/blog/20100822/audio-excerpt-interview-arabella-and-jessica See also: http://blog.modularsystems.sl/2010/08/22/emerald-resurgence/ On 08/23/2010 12:17 AM, Tateru Nino wrote: > Sure do. Although apparentl

Re: [opensource-dev] Draw Distance

Marine Kelley a écrit : > Please be careful not to screw up debug settings that must NOT be > changed. Some are capital for the viewer to function normally, and > would completely shut out users who don't know how to change them back > offline, and to what. Wouldn't it be possible to have an

Re: [opensource-dev] display names = the end of 1.x viewers?

On 2010-08-22, at 22:53, Joshua Bell wrote: > (3) casual conversational identifier Well, we really have that, and I've never thought it's something that needs to be maintained by the system. It's something that comes out of human interaction, and it's just something people know. For example, Far

Re: [opensource-dev] display names = the end of 1.x viewers?

On Sat, Aug 21, 2010 at 1:36 PM, Argent Stonecutter wrote: > > That's one thing Blue Mars does better. Your actual login identification is > by an email address they don't share with anyone, so there's no collection > of login names available for bulk attacks. > > I really wanted LL to add anothe

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

i dont think emerald is TPV compliant. data mining, DDoS attacks, User data leakage. clearly they have violated not only the TOS but the TPV. so no emerald IS NOT TPV Compliant. On Sun, 22 Aug 2010 16:55:56 -0400, Altair Sythos Memo wrote: > On Sun, 22 Aug 2010 15:30:55 -0500 > Brandon Hus

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Posted by Bubblesort moments ago- by way of the Alphaville Herald: "This just in: LLG just released his own viewer named Emergence!" http://code.google.com/p/emergence-viewer/ -- From: "Michael Daniel" Sent: Sunday, August 22, 2010 5:16 PM To: S

Re: [opensource-dev] RenderVolumeLODfactor (branch from Draw Distance)

On Sun, 22 Aug 2010 15:26:06 -0700, leliel wrote: > On Sun, Aug 22, 2010 at 7:48 AM, Trilo Byte > wrote: >> Actually, it would be nice if RenderVolumeLODfactor could either >> persist from one version to the next (instead of getting reset with >> everey >> new version installation), or be set ba

Re: [opensource-dev] RenderVolumeLODfactor (branch from Draw Distance)

On Sun, Aug 22, 2010 at 3:32 PM, Trilo Byte wrote: >> That's because you're running into RenderMaxNodeSize. > > Thanks, will take a look into that Be careful with that setting. RenderMaxNodeSize specifies the maximum amount of vertex data an object can use in kilobytes, the default on class 2 and

Re: [opensource-dev] RenderVolumeLODfactor (branch from Draw Distance)

> The default for class 1 and up is 2.0. I've been on machines meeting/exceeding class 1 for nearly 2 years. Every single viewer update (at least on Mac OS) *still* reverts to 1.125 >> On a side note, I've found that setting above 6.0 can have unexpected and >> unwanted results, most notably 'd

Re: [opensource-dev] RenderVolumeLODfactor (branch from Draw Distance)

On Sun, Aug 22, 2010 at 7:48 AM, Trilo Byte wrote: > Actually, it would be nice if RenderVolumeLODfactor could either > persist from one version to the next (instead of getting reset with everey > new version installation), or be set based on GPU detection. Put it in the settings_per_account.xml

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Here it is. Paisley mentions it in the introduction to her show tonight: Its 11.00pm here in Sydney Australia, and I’ve just been informed by > Communications Manager Arabella Steadham from the Emerald > Team who > is appearing on Tonight Live with Paisley > Beebe

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On 2010-08-22, at 15:20, Will wrote: > Then this is confusing, to be listed you have to within the policy > "approved" for lack of a better word: > Someone please clarify- > > "If a Third-Party Viewer or your use or distribution of it violates > this Policy or any Linden Lab policy, your permis

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

As a X-emerald Dev (I am Dimentox) Most of the stuff people are saying that is going on or has gone on.. Most of the other devs had no idea. We just did our parts to make the viewer better. I left due to the fact that i did not have time to continue to work on the project. Unfortunately a few bad

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

I was hoping for something first hand - like a post by her or some other member of the Emerald team. Sorry, but so many things have been written that are not supported by evidence. Like videos of chats logs: text can be altered so that's hardly reliable, solid evidence of anything. On 08/22/20

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, 22 Aug 2010 22:36:13 +0200, Altair "Sythos" Memo wrote: > On Sun, 22 Aug 2010 22:30:20 +0200 > Henri Beauchamp wrote: > > > On Sun, 22 Aug 2010 21:10:00 +0100, Gareth Nelson wrote: > > > > > There isn't anything in the policy itself which says you must be > > > listed, there is however

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, 22 Aug 2010 22:40:26 +0200 Henri Beauchamp wrote: > > > > There isn't anything in the policy itself which says you must be > > > > listed, there is however a note on the directory page warning > > > > users to be wary of unlisted viewers. > > > > > > Which is a non-sence. > > > > sorry

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, 22 Aug 2010 22:30:20 +0200 Henri Beauchamp wrote: > On Sun, 22 Aug 2010 21:10:00 +0100, Gareth Nelson wrote: > > > There isn't anything in the policy itself which says you must be > > listed, there is however a note on the directory page warning users > > to be wary of unlisted viewers.

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Users are not allowed to connect with a viewer that does not comply, but a viewer does not need to be in the directory in order to comply. On Sun, Aug 22, 2010 at 9:36 PM, Altair Sythos wrote: > On Sun, 22 Aug 2010 22:30:20 +0200 > Henri Beauchamp wrote: > >> On Sun, 22 Aug 2010 21:10:00 +0100,

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Then this is confusing, to be listed you have to within the policy "approved" for lack of a better word: Someone please clarify- "If a Third-Party Viewer or your use or distribution of it violates this Policy or any Linden Lab policy, your permission to access Second Life using the Third-Party Vi

Re: [opensource-dev] Login Pic

I don't know. If in doubt, search the string (or parts of it, in case it gets constructed on-the-fly) in the config files and edit it there. If that too doesn't help, search it in the source. Probably creators of TPVs can tell you more, as they have to handle that issue anyway. cheers Boroondas

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, 22 Aug 2010 21:10:00 +0100, Gareth Nelson wrote: > There isn't anything in the policy itself which says you must be > listed, there is however a note on the directory page warning users to > be wary of unlisted viewers. Which is a non-sence. Quoting the TPV policy: " 6. The Viewer Direc

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, 22 Aug 2010 15:30:55 -0500 Brandon Husbands wrote: > As a X-emerald Dev (I am Dimentox) Most of the stuff people are > saying that is going on or has gone on.. Most of the other devs had > no idea. We just did our parts to make the viewer better. I left due > to the fact that i did not ha

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, 22 Aug 2010 21:10:00 +0100 Gareth Nelson wrote: > There isn't anything in the policy itself which says you must be > listed, there is however a note on the directory page warning users to > be wary of unlisted viewers. wait... TPV listing is based on volunteer action, somebody can develo

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

There isn't anything in the policy itself which says you must be listed, there is however a note on the directory page warning users to be wary of unlisted viewers. On Sun, Aug 22, 2010 at 8:54 PM, Will wrote: > hmm ok I may be wrong but remember a rush to update viewers from the > approved list,

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

hmm ok I may be wrong but remember a rush to update viewers from the approved list, didn't look over my shoulder and just for good housekeeping I don't venture from approved viewers. Seriously hope you are wrong or there will be little to no control over who gets to connect. --

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Do you have a cite for that, Tateru? Not saying it is false, I'd just like to see it in context if possible. On 08/22/2010 01:38 PM, Tateru Nino wrote: > Arabella has also resigned. > > On 23/08/2010 3:32 AM, Jesse Barnett wrote: >> Fractured has stepped down and out of the Emerald picture >> >

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

As I understand it, you don't need to be in the list, just comply with the policy. On Sun, Aug 22, 2010 at 8:19 PM, Will wrote: > They may be waiting to make a formal announcement before they pull the plug > on the viewer- didn't they make a policy of not allowing any viewer to > connect that was

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

They may be waiting to make a formal announcement before they pull the plug on the viewer- didn't they make a policy of not allowing any viewer to connect that wasn't on the list? I think so- -- From: "Gareth Nelson" Sent: Sunday, August 22, 2010

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

As they shouldn't be! Although one does wonder whether users are now at risk of being banned if they keep using it On Sun, Aug 22, 2010 at 7:01 PM, Lance Corrimal wrote: > Am Sunday 22 August 2010 schrieb L. Christopher Bird: >> On Sun, Aug 22, 2010 at 11:32 AM, Jesse Barnett > wrote: >> > Ignor

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

oh.. what this mean? we cant use emerald anymore? On 22/08/2010 2:01 PM, Lance Corrimal wrote: Am Sunday 22 August 2010 schrieb L. Christopher Bird: On Sun, Aug 22, 2010 at 11:32 AM, Jesse Barnett wrote: Ignoring this and giving the all clear with no other action taken on the part of Linden

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Am Sunday 22 August 2010 schrieb L. Christopher Bird: > On Sun, Aug 22, 2010 at 11:32 AM, Jesse Barnett wrote: > > Ignoring this and giving the all clear with no other action taken > > on the part of Linden Lab will instead demonstrate that the TPV > > is a worthless scrap of paper. > > Correcti

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, Aug 22, 2010 at 11:32 AM, Jesse Barnett wrote: > > > Ignoring this and giving the all clear with no other action taken on the > part of Linden Lab will instead demonstrate that the TPV is a worthless > scrap of paper. > > Correction, it only exist on paper if printed. The proper phrase is

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Arabella has also resigned. On 23/08/2010 3:32 AM, Jesse Barnett wrote: Fractured has stepped down and out of the Emerald picture http://blog.modularsystems.sl/2010/08/22/emerald-off-with-his-head/ But it is painfully obvious that the comments are being heavily moderated and I know that neit

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Fractured has stepped down and out of the Emerald picture http://blog.modularsystems.sl/2010/08/22/emerald-off-with-his-head/ But it is painfully obvious that the comments are being heavily moderated and I know that neither of mine have gotten through. The Phox is still in the hen house and it i

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Tell me, what's the default install path on linux, if there even is an installer? I know personally when I use a new viewer I do this: wget http://whatever gunzip whatever.tar.gz tar xvf whatever.tar cd ~/whatever ./whatever or: svn co http://whatever cd whatever cd indra python develop.py build

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

this has been put many ways and this is the clearest it can be put. FC quits, hands off to Arabella (read the sandbox dialogs to gauge her reliability), FC creates new account with new name, make some meaningless webserver changes, FC comes back with a new name, lather/rinse/repeat. They have pr

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, Aug 22, 2010 at 10:56 AM, JB Hancroft wrote: > If the TPVP really matters, we'll see Emerald shut down from the TPVP > program, because of this accumulated nonsense. > If not, then it confirms that it's all just a paper chase. actually lets see whats going on here 1 the whole texture thin

Re: [opensource-dev] Draw Distance

On 2010-08-22, at 10:14, Lance Corrimal wrote: > Am Sunday 22 August 2010 schrieb Marine Kelley: >> Please be careful not to screw up debug settings that must NOT be >> changed. Some are capital for the viewer to function normally [...] > could someone please elaborate on why those settings even e

Re: [opensource-dev] Draw Distance

Am Sunday 22 August 2010 schrieb Marine Kelley: > Well, I believe there are SOME debug settings that are worth > changing for a developer, but NOT for the user. I am thinking of > "ConnectionPort" for example. Change that for the average user and > they can't connect to SL anymore until they actua

Re: [opensource-dev] SVN dead at LL?

Yes. We have switched to hg (Mercurial) entirely. And we are lots happier. Some day with a better keyboard and two working hands I could explain why. -- Q (iPhone => terse) On Aug 22, 2010, at 8:32 AM, Gareth Nelson wrote: > In the subject really - is subversion just dead now? > > -- > “La

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

(Replied offlist by accident.) Funny how you allow Phox and crew to continue operating after they purposefully leak info and attack a website, and then you ban me for running a freakin' rental company to help pay a friend's bills. Get your priorities straight and either enforce ALL of your ru

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Agreed, I think most users treat the viewers on that directory as having been approved for use by Linden Lab. Sort of a 'good housekeeping seal of approval' for the SL grid, if you will. On Aug 22, 2010, at 7:58 AM, Gareth Nelson wrote: > Being listed in the directory is a sign that viewer devs

Re: [opensource-dev] Draw Distance

related line of thought: how much faster could the viewer be if every single of these "do not change this ever" settings was replaced with a #define in a central include file? or in other words, what is the cpu cycle penalty for a SavedSettings.getBOOL() and the others? bye, LC Am Sunday

Re: [opensource-dev] Draw Distance

On 22 August 2010 17:14, Lance Corrimal wrote: > > could someone please elaborate on why those settings even exist and > are changeable? > > Well, I believe there are SOME debug settings that are worth changing for a developer, but NOT for the user. I am thinking of "ConnectionPort" for example.

Re: [opensource-dev] Draw Distance

Am Sunday 22 August 2010 schrieb Marine Kelley: > Please be careful not to screw up debug settings that must NOT be > changed. Some are capital for the viewer to function normally [...] could someone please elaborate on why those settings even exist and are changeable? i mean, basically, a de

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Being listed in the directory is a sign that viewer devs have self-certified compliance, but it's also an unconcious sign to users that the viewer is legit, even if not intended. On Sun, Aug 22, 2010 at 3:56 PM, JB Hancroft wrote: > Hi Ann, > > You suggested:  "What I think LL should consider is

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Hi Ann, You suggested: * "What I think LL should consider is something in the TPV policy that prohibits any tpv from connecting to any non LL server for any reason when a LL grid is selected for login."* I'd change that to require that any TPV *disclose* the specifics of any and all non-LL server

Re: [opensource-dev] Draw Distance

Please be careful not to screw up debug settings that must NOT be changed. Some are capital for the viewer to function normally, and would completely shut out users who don't know how to change them back offline, and to what. It would be easy to make a gesture that completely messes up your debug s

Re: [opensource-dev] RenderVolumeLODfactor (branch from Draw Distance)

Actually, it would be nice if RenderVolumeLODfactor could either persist from one version to the next (instead of getting reset with everey new version installation), or be set based on GPU detection. I imagine the default of 1.125 is based on "class 0" (intel integrated graphics) but anybody usin

Re: [opensource-dev] Draw Distance

On Sun, Aug 22, 2010 at 7:01 AM, leliel wrote: > > /set debugvar value > > +1 lelie This symmetrical handling for all parameters is far superior to defining abbreviations for each one, and it is inherently extensible as the set of parameters grows. I support this. Morgaine. ==

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

Found this morning, forgive me for not noting where, but it puts it in context: Anonymous said... Why did they do that? Well, you may recall that Emerald (more specifically the libemkdu library in it) was caught leaking personally-identifiable information about its users in an encrypted form tha

[opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sat, Aug 21, 2010 at 7:48 PM, Phox wrote: > (Since then, all additional metadata information has been removed from > emkdu). > The change in encryption was simply a result of inertia being able to > decode the viewer window title information. > It is my understanding that the emku was placing

[opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

The login screen and this attack happened before you select the grid. On Sun, Aug 22, 2010 at 8:22 AM, Ann Otoole wrote: > I hate replying to a policy thread here but will make this one time > exception for my humble input for LL's consideration: > > What I think LL should consider is something

Re: [opensource-dev] SVN dead at LL?

So basically, server is still up but no updates, that pretty much answers my question On Sun, Aug 22, 2010 at 2:05 PM, Boroondas Gupte wrote: > On 08/22/2010 02:32 PM, Gareth Nelson wrote: > > In the subject really - is subversion just dead now? > > Define "dead". The server is still up and runni

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On Sun, Aug 22, 2010 at 1:22 PM, Ann Otoole wrote: > What I think LL should consider is something in the TPV policy that > prohibits any tpv from connecting to any non LL server for any reason when a > LL grid is selected for login. This simple policy, if correctly followed, > would have prevented

Re: [opensource-dev] SVN dead at LL?

On 08/22/2010 02:32 PM, Gareth Nelson wrote: > In the subject really - is subversion just dead now? Define "dead". The server is still up and running and I guess it'll stay like that for the foreseeable future. About the code hosted there, and the projects behind that: * I assume there will b

Re: [opensource-dev] SVN dead at LL?

On 2010-08-22 8:32, Gareth Nelson wrote: In the subject really - is subversion just dead now? I know that it seems like a simple question, but it may be that it has gone over the edge to "too simple". Linden Lab has for some time been using Mercurial (hg) internally for nearly everything.

[opensource-dev] SVN dead at LL?

In the subject really - is subversion just dead now? -- “Lanie, I’m going to print more printers. Lots more printers. One for everyone. That’s worth going to jail for. That’s worth anything.” - Printcrime by Cory Doctrow Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

"You must not launch Denial of Service (“DoS”) attacks, engage in griefing, or distribute other functionality that Linden Lab considers harmful or disruptive to Second Life or the Second Life community" would have prevented this incident too, if it was obeyed and enforced. On Sun, Aug 22, 2010 at

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

I hate replying to a policy thread here but will make this one time exception for my humble input for LL's consideration: What I think LL should consider is something in the TPV policy that prohibits any tpv from connecting to any non LL server for any reason when a LL grid is selected for log

Re: [opensource-dev] Malicious payloads in third-party, viewers: is the policy worth anything?

I've reported emerald for violating this clause of the TPV policy: "You must not launch Denial of Service (“DoS”) attacks, engage in griefing, or distribute other functionality that Linden Lab considers harmful or disruptive to Second Life or the Second Life community." So, hopefully that'll be th

Re: [opensource-dev] Login Pic

On 08/22/2010 10:09 AM, a...@skyhighway.com wrote: > So, is it fixable? Yes, but the proper fix would be server side, so we volunteers can't do it. (Except we would create our own login page altogether and point the viewer at that. Dunno how good an idea that would be.) > Is there some way to cha

Re: [opensource-dev] Draw Distance

On Sun, Aug 22, 2010 at 2:36 AM, Robin Cornelius wrote: > > Thats a powerful idea, is there a new feature JIRA for this on the LL > pJIRA currenty? if not could I kindly ask you to create one for it and > post the issue number back here. http://jira.secondlife.com/browse/VWR-20887 > The problem

Re: [opensource-dev] Draw Distance

> I like a lot leliel's suggestion about Windlight control > via commandline, especially because I guess that would > evolve into gestures = tradeable assets (correct?) Assuming that everyone using that gesture has the same windlight prefs installed, probably yes. That's also assuming that the c

Re: [opensource-dev] Draw Distance

On Sun, 22 Aug 2010 10:36:18 +0100, Robin Cornelius wrote: > On Sun, Aug 22, 2010 at 10:09 AM, leliel wrote: >> On Sun, Aug 22, 2010 at 12:09 AM, Miro Collas >> wrote: >>> >>> That's what I referring to, the command line commands. VERY handy! And >>> dd is one I use a great deal. btw, recent K

Re: [opensource-dev] Draw Distance

On Sun, Aug 22, 2010 at 10:09 AM, leliel wrote: > On Sun, Aug 22, 2010 at 12:09 AM, Miro Collas wrote: >> >> That's what I referring to, the command line commands. VERY handy! And >> dd is one I use a great deal. > /set RenderFarClip 128 > /set RenderVolumeLODFactor 2.0 > /set WindLightUseAtmosS

Re: [opensource-dev] Draw Distance

That makes sense yes. I wasn't asking for Emerald to be copied, which is why my initial response to the issue was vague. But the basic idea is nice, I think: a nice, fast and easy way to set parameters without having to use clumsy sliders and navigate pages of dialog boxes, all via the command

Re: [opensource-dev] Draw Distance

On Sun, Aug 22, 2010 at 12:09 AM, Miro Collas wrote: > > That's what I referring to, the command line commands. VERY handy! And > dd is one I use a great deal. The problem I have with that is that the draw distance is only one of several debug settings that affect performance. I've been running w

Re: [opensource-dev] Malicious payloads in third-party, viewers: is the policy worth anything?

Since I am a student on summer break until next week, I have way too much time on my hands, and I like numbers (famous last words) so I did some analysis of modular systems attack on iheartanime.com. I think the amount of data involved has been understated in many discussions I've seen so far,

Re: [opensource-dev] SSH authentication

On Sun, Aug 22, 2010 at 12:21 AM, Nicky Perian wrote: > How do you do this in windows. Can you take your local key from Linux? Yes, but you need the full key not just the public key. Puttygen part of the putty ssh suite has the ability to import/export OpenSSL keys as well as some other formats,

[opensource-dev] Login Pic

So, is it fixable? Is there some way to change the Snowglobe login channel? Or can the server be configured to respond to the channel Snowglobe already has? Or is this just something Snowglobe users should not care about? For reals, it's not important, but i miss it, & the pics are a nice touch

Re: [opensource-dev] Malicious payloads in third-party viewers: is the policy worth anything?

On 8/22/10, Phox wrote: > The website in question suffered no ill effects, and to imply that > loading a .php and a few images is an attempt at DDOS is just > ridiculous, our login page consists of a .php script a hi-res picture, > and our website doesn't go down as a result. Your website did go

Re: [opensource-dev] (no subject)

On Sun, Aug 22, 2010 at 5:26 AM, wrote: > Hey!  Um, i've been meaning to ask...  Why don't i ever get the login > screen pics with Snowglobe?  i just installed the latest release (1.5.0 > 3625) from the website and still all i ever get are little arrow icons in > the middle of a black screen.  It

Re: [opensource-dev] VWR-20879 - Fix packaging/staging for VC Express

> >> It is currently synced with viewer-development and i can resync as >> necessary depending on its position in the queue. > > Can we get confirmation from users other than Robin that using his > change enables them to build using one of the tools it adds (preferably > users who do not have VS 20

Re: [opensource-dev] Display names, again.

Am Saturday 21 August 2010 schrieb Oz Linden (Scott Lawrence): > This list is really not the place for this discussion - the Display > Names blog comment area is much better. /me collapses with laughter ___ Policies and (un)subscribe information avail

Re: [opensource-dev] Draw Distance

That's what I referring to, the command line commands. VERY handy! And dd is one I use a great deal. On 08/22/2010 03:01 AM, Serra Anansi wrote: > I like the command line in emerald, you just type in "dd 512" and it's done. > > ((I really like all the command lines in emerald. Took me a bit to g

Re: [opensource-dev] Draw Distance

I like the command line in emerald, you just type in "dd 512" and it's done. ((I really like all the command lines in emerald. Took me a bit to get used to them, but after I did I am really missing them now that I came back to V2 to give it another go while you all are working on it.)) On Sun,