Re: [opensource-dev] New Release Viewer 3.4.0 being partially blocked by popular antivirus-software AVAST
On Fri, Sep 14, 2012 at 3:47 AM, Martin Fürholz fuerh...@gmx.net wrote: The latest release viewer 3.4.0 from http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/viewer-release/rev/264700/arch/CYGWIN/installer/Second_Life_3-4-0-264700_Setup.exe is being partially blocked by the popular antivirus-software AVAST. The webkit plugin fails to load. Avast puts it into a sandbox by default because it is: 'not wide-spread enough or has bad reviews'. Avast's heuristics do that with more obscure software all the time. I've even had them randomly sandbox fairly well-known games downloaded from Steam. It might be worth you just disabling some or all of the heuristics until they manage to reduce the false positives a bit. ___ 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] Linux64 boost 1.39 is still actually boost 1.34.1
Hi, It looks like the packaged linux64 version of boost, http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boost-1.39.0-linux64-20100119.tar.bz2, is still actually the mislabelled boost 1.34.1. Is there a newer build available? Thanks, Aidan ___ 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] Convexdecomposition for open source devs
On Thu, Dec 30, 2010 at 2:03 PM, WolfPup Lowenhar wolfpu...@earthlink.net wrote: Bullet Physics Library(just the convexdecomp section): Web site : http://code.google.com/p/bullet/ John Ratcliff's: Web Site : http://codesuppository.blogspot.com/2009/11/convex-decomposition-library-now.html I seem to recall that the Bullet convex decomposition is actually based on an older version of John Ratcliff's code with their own improvements added. The two use completely different APIs, though, so there's probably no easy way to switch between them. ___ 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] Linux 64bit and gstreamer
On 12/12/10, Argent Stonecutter secret.arg...@gmail.com wrote: You know what would really help people get over the hump of setting up for building SL? A VMware appliance containing a working SL build environment, for 32 and 64 bit Linux. It's sort of vaguely on my TODO list, possibly including a way of creating all the prebuilt library bundles needed to make an actual SL release. There are certain practical and licensing issues, though. Also, being able to actually run Second Life within the VM could be fun... ___ 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] Linux 64bit and gstreamer
On 12/12/10, Marc Adored m...@inworlddesigns.com wrote: Awesome I will checkout the latest then and try to compile it. I wasn't aware it was even close to working. I'm excited now. It's actually been possible for a while, but until recently you had to manually dig up patches from the Wiki in order to compile a 64-bit viewer successfully. Last time I tried, the major obstacles were: * Having compiled Google Breakpad, getting the viewer build process to find it is fiddly. It seems to require a slightly odd layout for the header files. I had to manually create some directories with the correct names and copy the headers to them. * Building a 64-bit version of llqtwebkit is a real pain. I believe the Imprudence developers have created a pre-compiled version of this recently - if it was available when I was trying, I'd have been tempted to use 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
Re: [opensource-dev] LGPL violation
On 10/28/10, Erik Anderson eri...@odysseus.anderson.name wrote: 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. Yeah, but that's not what we're talking about. libmedia_plugin_webkit.so is in fact linked statically with various Qt libraries - the entirety of the code for those Qt libraries is incorporated into libmedia_plugin_webkit.so by the linker at compile time, not just a stub. The same happens with libmedia_plugin_webkit.a and libmedia_plugin_webkit.dylib. I'm not sure exactly why Linden Lab decided to do this - it's not a common thing to do and getting it to work right requires a certain amount of mucking with the build system, since static libraries normally aren't compiled with options that allow them to be included in a shared library - but do it they did. ___ 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] Mesh Source Code ETA
On 10/22/10, Zabb65 zab...@gmail.com wrote: Looks like this does not need an answer now. Code is up. http://hg.secondlife.com/mesh-development/ \o/ Looks like convex decomposition support has been pulled. LLConvexDecomposition is a proprietary library based on Havok (TM) physics libraries. In its place, Linden Lab shares the code for LLConvexDecompositionStub, a stub version of the same library with no proprietary components. I'd suggest porting the convex decomposition code from something like (for example) Bullet instead might be a good idea. ___ 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] Mesh Source Code ETA
On 10/22/10, Zabb65 zab...@gmail.com wrote: Looks like this does not need an answer now. Code is up. http://hg.secondlife.com/mesh-development/ \o/ Oh, lovely: /** * @filellphysicsshapebuilder.cpp * @brief Generic system to convert LL(Physics)VolumeParams to physics shapes * @author fal...@lindenlab.com * * $LicenseInfo:firstyear=2010license=internal$ * * Copyright (c) 2010, Linden Research, Inc. * * The following source code is PROPRIETARY AND CONFIDENTIAL. Use of * this source code is governed by the Linden Lab Source Code Disclosure * Agreement (Agreement) previously entered between you and Linden * Lab. By accessing, using, copying, modifying or distributing this * software, you acknowledge that you have been informed of your * obligations under the Agreement and agree to abide by those obligations. * * ALL LINDEN LAB SOURCE CODE IS PROVIDED AS IS. LINDEN LAB MAKES NO * WARRANTIES, EXPRESS, IMPLIED OR OTHERWISE, REGARDING ITS ACCURACY, * COMPLETENESS OR PERFORMANCE. * $/LicenseInfo$ */ I do wish organisations wouldn't do things like this... it's a real pain. ___ 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] O.O Display name code DROP!
On Fri, Oct 15, 2010 at 7:15 AM, Jamey Fletcher ja...@beau.org wrote: Is there actually a *reason* for this change, or is it just to screw around in the code to do provide an opportunity for new bugs, such as the one you found already? I suspect the reason for the change is that with display names, the names of participants in IMs and group chat no longer uniquely identify them - and the usernames, which are unique, aren't available at the point where the logging of chat and IMs is done. This also has the interesting side-effect that it's incredibly difficult to figure out who actually said something just from your chat logs, because the only information in there that actually identifies them is their UUID. ___ 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
On Sun, Oct 3, 2010 at 2:47 AM, Kelly Linden ke...@lindenlab.com wrote: Unfortunately no. LSL scripts take up 16k of memory no matter how much they actually use. Is there any technical reason why this can't be made adjustable, though? I know that changing the amount of script memory available for LSL scripts would require a recompile, since it's fixed at compilation time, but I suspect it could be done. ___ 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] Openjpeg/KDU the cold hard metrics
On 9/21/10, Robin Cornelius robin.cornel...@gmail.com wrote: I'm still not 100% sure why the build of openjpeg supplied by imprudence is better than my builds on 2005. Imprudence is using the openjpeg SVN trunk version from a few months ago, which is essentially a pre-release version of openjpeg 1.4 and is slightly more optimised than 1.3. You might want to try openjpeg from SVN yourself (the trunk version, not the 2.0 branch). Make sure to try it with SSE enabled too - it has some SSE-specific optimisations. ___ 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] User Story: Improved Cache
On 9/19/10, Argent Stonecutter secret.arg...@gmail.com wrote: Perhaps Tateru was referring to the prim data changing (eg, geometry) while the prim UUID stays the same. I don't think the viewer makes any assumptions about prims being unchanged from session to session, so that's not something that would need to be verified in the cache. Actually, I'm pretty sure it does, at least in viewer versions where caching hasn't accidentally been rendered totally ineffective by a Linden Labs typo. In fact, there's a fairly elaborate system for caching prim data to disk. As I recall, it detects changed prims using the CRC field, which is completely misnamed and is really a generation counter that records the number of changes to the prim. Then there's the CacheID, which invalidates the whole sim's cached data where necessary (e.g. if the sim moves or crashes, or perhaps even if it just restarts at all - would have to ask one of the Lab folks). ___ 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] This is how Linden Lab treats it's customers...
On Sat, Aug 28, 2010 at 6:54 PM, Meadhbh Hamrick ohmead...@gmail.com wrote: but for reasons i never learned, linden never implemented prim restrictions for openspace sims. so even though you were only supposed to have some small number of prims in an openspace sim, the system let you go over that limit. so guess what happened? yes, that's right, people started putting a lot of prims on sims hosted on overloaded cores. some sim owners even went so far as to rent out openspace sims to people without mentioning the fact that their new virtual parcels were hosted on CPUs that were a touch overtaxed. That's the interesting thing. Linden Labs did implement prim restrictions for openspace sims from the start. In fact, they had quite a small prim limit - 1875 prims, which was enough for the intended use and possibly a low-prim house somewhere for one or two users. Then Linden Labs, in an effort to make them more widely useful, *doubled* the prim limit. This was quite widely advertised at the time, and a large number of people bought them... just in time for Linden Labs to pull off a significant and unexpected price increase together with more restrictions. Of course, at that point everyone had already invested money and time in their regions that they didn't want to see wasted. ___ 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] Encrypted chat third-party servers
On 8/25/10, Brian McGroarty s...@lindenlab.com 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 so, do these connections share any information about the user that we should require to be disclosed per section 4.b of the TPV Policy?[1] I haven't looked too closely at the encrypted chat in Emerald and similar viewers, but my understanding is that it - and all the other third-party viewers - use OTR in a fairly standard way. OTR is deliberately designed not to use any third party server to obtain or validate keys - instead, it provides a way for pairs of OTR users to validate each other's keys directly with each other[2]. All communication happens over the underlying IM protocol, in this case Second Life IMs. Unless someone's really screwed up the implementation in one of the viewers, OTR should have no interesting privacy implications whatsoever. OTR keys are designed to be per-account (so provide no way of matching up alts) and the encryption scheme used carefully avoids non-repudiation; that is, neither party can use it to prove what the other said to a third party after the fact any more than they could with plain-text IMs. It's basically pretty benign. [1] NMF. [2] Specifically, it uses the Socialist Millionaire Protocol to verify the keys, using a piece of information that only the two people know. See http://en.wikipedia.org/wiki/Socialist_millionaire - note that neither the secret answer nor any information that could usefully help to determine it is ever shared with the other party! ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
On 8/22/10, Phox p...@modularsystems.sl 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 down because of the load, though - a whole bunch of times in fact! There's even still an entry in the Emerald FAQ about it[1]: Due to a problem with our webhost 500 errors are increasingly common with new traffic. Please wait a few seconds and try to reload the page, it may take a few tries before you get through. The only reason it doesn't anymore is because you moved to a bunch of really chunky and expensive dedicated servers. http://blog.modularsystems.sl/2010/07/19/emerald-user-statistics/ says that you're using two of http://www.hetzner.de/en/hosting/produkte_rootserver/eq4/ - each of which is about as powerful as some of the older Class 5 Linden Labs servers that host 4 regions each - plus a third unspecified dedicated server. Hazim was using cheap shared hosting. What's more, the guy from the Emerald project who did this knows just how much load the Emerald login screen puts on Emerald's servers, because he apparently pays for and runs them! On 8/22/10, Katharine Berry kathar...@katharineberry.co.uk wrote: No it doesn't. If it was a PHP script then I could've made much of the code much simpler when I made the thing. It was very deliberately not a PHP script, for reasons of load. Yep, looking at the headers it's definitely static HTML. We've got an Accept-Ranges header, a Content-Length header (both of which you can get from PHP scripts but wouldn't normally), and most importantly an ETag in the same format lighttpd uses for static content. Also, the login page wasn't just making one request for a PHP-generated page from Hazim's website - it was making 20 requests for the same page. [1] http://www.modularsystems.sl/wiki/wikka.php?wakka=FAQ ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
On Sun, Aug 22, 2010 at 1:22 PM, Ann Otoole missannoto...@yahoo.com 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 the incident. It would also eliminate a tpv team from monitoring logins and usage but then where exactly did they get to do that in the first place? It also prevents third-party viewers from notifying users that updates are available, including security updates. Whole bunch of other stuff too - for example the official Second Life login screen doesn't actually work on unofficial viewers. Besides, both incidents like this and undisclosed monitoring of usage violate the TPV policy anyway (and at least one of Emerald's privacy issues didn't involve connecting to any non-LL server at all). Have you taken a look at Imprudence's Privacy Policy, for example (http://imprudenceviewer.org/wiki/Imprudence:Privacy_policy)? This is roughly the level of disclosure the policy calls for regarding data collection associated with viewer use (the information related to the website goes beyond what the policy requires). I assume Emerald has a similar page somewhere too. ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
You may recall that the Emerald viewer has been leaking potentially privacy-infringing information - specifically, the directory to which it's been installed, which in some cases includes usernames - in encrypted form in baked textures. You may also recall that the developers lied and said the issue was fixed, when really they just leaked the same data but with stronger encryption to hide it better. Well, it turns out that the Emerald developers have been using their viewer to launch a Distributed Denial of Service attack on the website of the person who discovered this[1]. The attack involved loading about 1 MB of images and a whole bunch of dynamically-generated content from the Emerald login screen displayed every time a user opened Emerald to consume both bandwidth and server CPU time.[2] This served no purpose other than to try and DoS the server - none of the loaded content was visible or used. The Emerald developers have even admitted as much, though they're trying to spin it interestingly[3]. (Their explanation is total bullshit - if they just wanted to make a point about the number of Emerald users rather than attack the server, loading a single file would do.) Now, this is of course entirely in violation of the TPV policy, which forbids certain content - including DoS attacks - within third party viewers. The question is, does the Lab care and will they even remove the viewer in question from the TPV directory? [1] http://www.sluniverse.com/php/vb/general-sl-discussion/47885-emerald-problem-conspiracy-theory-3.html#post997824 [2] See http://pastebin.ca/1921405 for a copy of the actual code. [3] http://blog.modularsystems.sl/2010/08/20/shenanigans/ ___ 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] Open Viewer Development Announcement
On 8/16/10, Oz Linden (Scott Lawrence) o...@lindenlab.com wrote: Think about it for a minute - there are an infinite number of possible solutions for how to build a UI for a virtual world viewer - what are the odds that the first or second attempt produced the best possible UI? We need new and creative ideas focused on specific problem descriptions. The trouble is - and I've said this before - that whoever designed the New, Shiny and Improved Viewer 2.0 interface clearly didn't think too much about why the Viewer 1.0 UI was designed the way it was, what advantages this has, or how it was actually used. For example, this shows up in the replacement of pie menus with standard right-click menus. The big advantage of pie menus is that they're fast to use - all the entries are large and easy to hit with the mouse. The new right-click menu, on the other hand, has really tiny entries that make you hunt with the mouse. Unlike in Second Life, in most applications the right-click menu is not intended as the main way to interact with the application - anything commonly-used can be accessed in another faster way. Then there's the sidebar and the impossibility of opening more than one person's profile at once, or of getting back to someone's profile once you've clicked on one of the groups listed therein... Oh, and Viewer 2 is still a bit hit and miss about making keyboard shortcuts for commonly-used functionality discoverable in some places. For example, I'm not sure if the shortcuts for Always Run or Fly/Stop Flying are displayed anywhere. ___ 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] Mesh rendering: What does indicesp provide?
Hi,
On Thu, Jun 3, 2010 at 12:35 AM, Rob Nelson
nexisentertainm...@gmail.com wrote:
I am working on the rendering code in the SL viewer at the moment,
having completed the server-side code and some of the client-side
packet-handling classes. However, I have zero familiarity with OpenGL,
so bear with me.
My viewer needs to construct a terrain surface (a mesh) for display. I
have completed an LLViewerObject to this end, except for:
::getGeometry(LLStriderLLVector3 verticesp,
LLStriderLLVector3 normalsp,
LLStriderLLColor4U colorsp,
LLStriderLLVector2 texCoords0p,
LLStriderLLVector2 texCoords1p,
LLStriderU16 indicesp)
What is confusing me is indicesp. I think it has something to do with
connecting vertices, but I'm not sure how.
I think you should find it's a list of indexes into the vertex,
normal, etc arrays that's later passed to glDrawElements, but I'm not
100% sure.
The example code I am
working with uses a mess of lookup tables in the following loop for each
voxel:
//Draw the triangles that were found. There can be up to five per cube
for(iTriangle = 0; iTriangle 5; iTriangle++)
{
if(a2iTriangleConnectionTable[iFlagIndex][3*iTriangle] 0)
break;
for(iCorner = 0; iCorner 3; iCorner++)
{
iVertex =
a2iTriangleConnectionTable[iFlagIndex][3*iTriangle+iCorner];
vGetColor(sColor, asEdgeVertex[iVertex],
asEdgeNorm[iVertex]);
glColor4f(sColor.fX, sColor.fY, sColor.fZ, 0.6);
glNormal3f(asEdgeNorm[iVertex].fX,
asEdgeNorm[iVertex].fY, asEdgeNorm[iVertex].fZ);
glVertex3f(asEdgeVertex[iVertex].fX,
asEdgeVertex[iVertex].fY, asEdgeVertex[iVertex].fZ);
}
}
So, for example, you would convert this code by appending each iVertex
used to indicesp in turn rather than rendering the corresponding
vertex immediately. It appears there's a slight complication in that
all the arrays could contain items that have already been added
previously and these may affect your indices, but you should be able
to figure this out from the existing code.
Aidan
___
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] Oh, the drama. (was: Viewer blacklist...)
On Fri, Apr 30, 2010 at 10:51 PM, Rob Nelson nexisentertainm...@gmail.com wrote: As a person who is trying to patch (a now rather old version) of OpenSim to handle voxel terrain, there's MANY, MANY flaws to the messaging subsystem of both the viewer and the server. For one, I wanted to tack on an additional UDP/TCP message to handle voxelmap transmissions and modification. Unfortunately, it appears that even a tiny change to the messaging template would completely destroy compatibility with SL, and even adding one packet handler in OpenSim would involve changing LibOMV, 3 packet handling packages, and an extremely long PacketType enum. This is NOT a flexible protocol that we're using. Yeah. You can try using GenericMessage - apparently RealExtend have - but it has the rather interesting limit that each Parameter is limited to 255 bytes. ___ 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
On Thu, Apr 15, 2010 at 3:09 PM, Lance Corrimal lance.corri...@eregion.de wrote: Am Mittwoch, 14. April 2010 20:49:59 schrieb Joe Linden: **we've had a lot of internal debate around cost/benefit of OS **... and we're fully committed to redoubling our commitment to make this a successful program*. then... how about... opensourcing the SERVER (like someone pretty high up suggested several years ago)? and there's no reason to be afraid that giving away the other half of the software would cause you longtime harm anyways... ...after all, the grid is more than server client. the grid also is all those boxes that it is running on... no way that a competitior could pull 1 PCs out of a hat on short notice. on the other hand, I would like to bet actual money on the following predictions: - 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. XMPP doesn't actually scale that well, unfortunately; a lot of the really big installs actually run their own protocol internally with better scaling. - a few weeks later, all communications between client and server, and the various server subsystems, has been ported to tcp/ssl and is transaction safe. Unlikely. Transactions are hard. There's some low-hanging fruit with regards to LSL support though. In theory, one should be able to statically verify nearly all traditional non-Mono LSL scripts, and then optionally compile them down to native code. (The static verification would probably take a day or two to code; compilation down to native code would take longer and have more interesting tradeoffs. Direct threading might be a better approach.) ___ 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] Can you legally agree to incomprehensible conditions
On Fri, Apr 2, 2010 at 4:49 PM, Gareth Nelson gar...@garethnelson.com wrote: It's a lot of work to maintain, trust me - anyway, it'd be better to convince the opensim team to allow viewer developers in. Yep - people seem to end up writing their own simulator from scratch instead as a result. I know that I did[1], and I recall that both you and John Hurliman had your own projects too (litesim and Simian respectively). [1] http://www.makomk.com/gitweb/?p=cajeput.git;a=summary ___ 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
