Re: [opensource-dev] An SL appliance...
If you want to use X forwarding, you're probably not going to be happy with the results. Machines on the same gigabit switch can even have poor performance just loading or refreshing a file manager. There may be other ways, and there are always remote desktop-type layers like NX.. Discrete On Thu, Jul 14, 2011 at 10:56 AM, Lee ponzu lee.po...@gmail.com wrote: Does the Linux viewer use X? If you DISPLAY SL on another computer running an XServer, does it behave OK. If so, could you assemble a small Linux host with a high end GPU and then DISPLAY SL on a different computer on the same local network? ponzu ___ 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] Review Request: STORM-1122 Linux viewer sucks up file descriptors, stops loading content and crashes
On April 3, 2011, 8:29 p.m., Merov Linden wrote: indra/llwindow/llwindow.cpp, line 210 http://codereview.secondlife.com/r/245/diff/1/?file=1369#file1369line210 Hmmm, this is basically doing for Linux what is already done for Mac and Win32. If that's the case, I'd rather have your hack move to llwindowsdl.cpp. It might be time to retire that getDynamicFallbackFontList() code entirely then. After speaking to a friend and looking a little deeper, it appears that the function does have some reasonable purpose.. the font files included in the viewer do not have substantial Unicode support, which I discovered when trying to input Japanese. On Windows/Mac, there are sections clearly defining fonts that provide this support, but no such fonts exist for Linux, perhaps because it's not certain that they're on the system. I recall from the past that Arial Unicode isn't a completely free font and can't be included by default.. So I guess the proper solution would actually first be to either add Linux (or universal) fonts that provide proper support, or dig deeper into the fallback font function to figure out why it's going descriptor-crazy. It's a pretty hairy-looking thing.. - Discrete --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/245/#review538 --- On March 30, 2011, 11:49 a.m., Discrete Dreamscape wrote: --- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/245/ --- (Updated March 30, 2011, 11:49 a.m.) Review request for Viewer. Summary --- Resolved Linux file descriptor greediness by removing obsolete fallback font searching (call to LLWindowSDL::getDynamicFallbackFontList()), as this seems to be obsolete unless your skin's configuration references font files that are not packaged with the viewer, which is not the default case. Would like to know if this solves the instability described in STORM-1122 for Linux users, particularly those with lower than average file descriptor limits set (find out by running `ulimit -a`, it's the value 'open files', mine is 1024 on Ubuntu 10.10 and I'd have extreme problems prior to the patch). This addresses bug STORM-1122. http://jira.secondlife.com/browse/STORM-1122 Diffs - doc/contributions.txt a8f868007986 indra/llwindow/llwindow.cpp a8f868007986 Diff: http://codereview.secondlife.com/r/245/diff Testing --- Useful ways to examine file descriptor usage for the viewer lsof -c do-not | less This should be much, much less than 1024 lsof -c do-not | wc -l This shows all descriptors containing the word 'font' along with the number of each (there are tons of duplicates) lsof -c do-not | egrep -o '[^ ]*font[^ ]*' | sort | uniq -c | less Thanks, Discrete ___ 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] Review Request: STORM-1122 Linux viewer sucks up file descriptors, stops loading content and crashes
--- This is an automatically generated e-mail. To reply, visit: http://codereview.secondlife.com/r/245/ --- Review request for Viewer. Summary --- Resolved Linux file descriptor greediness by removing obsolete fallback font searching (call to LLWindowSDL::getDynamicFallbackFontList()), as this seems to be obsolete unless your skin's configuration references font files that are not packaged with the viewer, which is not the default case. Would like to know if this solves the instability described in STORM-1122 for Linux users, particularly those with lower than average file descriptor limits set (find out by running `ulimit -a`, it's the value 'open files', mine is 1024 on Ubuntu 10.10 and I'd have extreme problems prior to the patch). This addresses bug STORM-1122. http://jira.secondlife.com/browse/STORM-1122 Diffs - doc/contributions.txt a8f868007986 indra/llwindow/llwindow.cpp a8f868007986 Diff: http://codereview.secondlife.com/r/245/diff Testing --- Useful ways to examine file descriptor usage for the viewer lsof -c do-not | less This should be much, much less than 1024 lsof -c do-not | wc -l This shows all descriptors containing the word 'font' along with the number of each (there are tons of duplicates) lsof -c do-not | egrep -o '[^ ]*font[^ ]*' | sort | uniq -c | less Thanks, Discrete ___ 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 build without the pausing behaviour
It's due to libcurl, noted in STORM-809, and supposedly fixed (in the autobuild repo)? If someone can verify that, maybe you can build it and solve your problem, otherwise you'll have to build your own libcurl to drop in. Another alternative seems to be maintaining your own DNS server/cache, but that's pretty unnecessary IMO. On Mon, Mar 28, 2011 at 10:50 AM, Francesco Rabbi syt...@gmail.com wrote: Il giorno 28/mar/2011, alle ore 16:41, Mike Chase mike.ch...@alternatemetaverse.com ha scritto: Is there a Linux build of V2 of any version that doesnt exhibit the annoying multi-second pauses that freeze the UI? I find myself without any useable V2 viewer at present. I've tried 2.5.2 and 2.6.3 and both still have this issue. How in the world did this every get past QA? It really renders the viewer unusable. I've been using Imprudence the last few days which is nice but a huge shift in UI and I've actually gotten both used to and productive with the V2 paradigm. Can you explain better the kind of pause? I don't notice sort of... -- Sent by iPhone ___ 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] Help prevent DOS line endings...
This is from the help page on the extension: The optional [repository] section specifies the line endings to use for files stored in the repository. It has a single setting, native, which determines the storage line endings for files declared as native in the [patterns] section. It can be set to LF or CRLF. The default is LF. For example, this means that on Windows, files configured as native (CRLF by default) will be converted to LF when stored in the repository. Files declared as LF, CRLF, or BIN in the [patterns] section are always stored as-is in the repository. Example versioned .hgeol file: [patterns] **.py = native **.vcproj = CRLF **.txt = native Makefile = LF **.jpg = BIN [repository] native = LF So if a file pattern is specifically declared to have Windows line-endings, it should remain that way for everyone and in the repository.. probably worth some quick testing. Discrete On Wed, Feb 2, 2011 at 3:06 PM, Oz Linden (Scott Lawrence) o...@lindenlab.com wrote: On 2011-02-01 15:33, Discrete Dreamscape wrote: Possible cover-all solution: use Mercurial's eol extension. It's worked pretty well for me so far, and handily autofixed all the DOS endings in a particular fork I looked at in one go. It works much like the autoprops configuration does in Subversion; hopefully with less pain. Enable it (should be included by default in all recent versions, dunno about Tortoise) by adding the following section and options to your system-wide or repo-local .hgrc file: [extensions] eol = Then add a .hgeol file to the root of the repository (it can be versioned and thus easily distributed!), and fill it with whatever standard Mercurial pattern entries are needed, like so: [patterns] **.py = native **.txt = native **.h = native **.cpp = native **Makefile = LF As soon as this file exists and the extension is active for you, further hg commands will immediately treat any non-conforming line-endings as modifications to your current working copy. Hope this is helpful; if so, it could be added to that page as well. I considered adding that, but didn't know whether some of the windows-specific files might be broken by it (if so, they too could be configured). Does anyone know? Could always put this into a test repo and run a TeamCity build ___ 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] Help prevent DOS line endings...
Possible cover-all solution: use Mercurial's eol extension. It's worked pretty well for me so far, and handily autofixed all the DOS endings in a particular fork I looked at in one go. It works much like the autoprops configuration does in Subversion; hopefully with less pain. Enable it (should be included by default in all recent versions, dunno about Tortoise) by adding the following section and options to your system-wide or repo-local .hgrc file: [extensions] eol = Then add a .hgeol file to the root of the repository (it can be versioned and thus easily distributed!), and fill it with whatever standard Mercurial pattern entries are needed, like so: [patterns] **.py = native **.txt = native **.h = native **.cpp = native **Makefile = LF As soon as this file exists and the extension is active for you, further hg commands will immediately treat any non-conforming line-endings as modifications to your current working copy. Hope this is helpful; if so, it could be added to that page as well. Discrete On Tue, Feb 1, 2011 at 1:54 PM, Celierra Darling celie...@gmail.com wrote: For those that have already followed the instructions there - the coding standard says to prefer tabs, not spaces, which is the opposite of what the page was instructing until just now. Celi On Tue, Feb 1, 2011 at 7:35 AM, Oz Linden (Scott Lawrence) o...@lindenlab.com wrote: Other than a few files that appear to be completely Windows specific, and I did not know for sure did not require them, I've converted all the DOS line endings in viewer-development back to plain linefeeds. I'll be checking regularly for any that get added (hopefully before they get into the main repo) and advising the perpetrators of the error of their ways... So that I have a resource to direct them to, and to help prevent any new developers from committing this minor sin, we need a set of clear instructions on what Windows tools do this correctly and how to configure them to do so. Please help by adding to: https://wiki.secondlife.com/wiki/How_to_avoid_DOS_line_endings_in_Windows_tools ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
This was one person's decision, and was deliberately done for the sole purpose of messing with the owner of the victim site (although I'd hardly call the particular individual a victim). Regardless, the team was pretty disappointed. The one person currently owns all parts of Emerald's hosting, so it was their decision, albeit a ridiculous one. They don't take the project seriously, and it's more than a little embarrassing to the rest of the people associated with the team that this kind of thing keeps happening, over and over again. Discrete On Aug 21, 2010, at 10:33 AM, Brian McGroarty s...@lindenlab.com wrote: On Sat, Aug 21, 2010 at 7:04 AM, Thomas Grimshaw t...@streamsense.net wrote: Loading 1mb of content per user is hardly a denial of service attack. Crosslinking occurs everywhere on the web, this is simply nothing but paranoid bull. Crosslinking drops the context of hiding gibberish requests to a critic's website in a hidden frame that will never be revealed to the user. This isn't a mere hyperlink to another page or naively stealing someone else's image hosting. My read (but I'm no lawyer) is that this looks like 2.d.iii of http://secondlife.com/corporate/tpv.php and we're already having that discussion. If anyone can come up with specific reasons why this might have had legitimate reason to be there, or how this one could be yet another oversight or mistake, that would be helpful. I sure haven't heard any to date. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ 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] Malicious payloads in third-party viewers: is the policy worth anything?
Actually, I prefer to remember him as: 1) The guy who hacked Emerald's servers before discovering the data storage issue and 2) The active developer of a malicious viewer under the lolguise of promoting exploit/bugfixing. But hey, they keep antagonizing him, so of course this kind of thing continues. Discrete On Aug 21, 2010, at 11:10 AM, Brian McGroarty s...@lindenlab.com wrote: On Sat, Aug 21, 2010 at 7:46 AM, Discrete Dreamscape discrete.dreamsc...@gmail.com wrote: This was one person's decision, and was deliberately done for the sole purpose of messing with the owner of the victim site (although I'd hardly call the particular individual a victim). Regardless, the team was pretty disappointed. The one person currently owns all parts of Emerald's hosting, so it was their decision, albeit a ridiculous one. They don't take the project seriously, and it's more than a little embarrassing to the rest of the people associated with the team that this kind of thing keeps happening, over and over again. Appreciated - it's helpful to have this put plainly and publicly. Am I right that the target server belongs to the guy who: 1) Was interviewed in a previous blog write-up about the IP username database and geolocation tool that he sought to show was built up for Emerald Point visitors, Insilico visitors, and people creating accounts via the Modular Systems website? 2) Demonstrated that Emerald wasn't removing usernames from paths before embedding them in textures even after the team's first attempted fix? I know we already talked to the team and set some conditions after the first one. The second one's been explained as a mistake that Modular Systems would be willing to publicly acknowledge and correct - the potential for collecting usernames would have to be in the viewer's privacy policy otherwise, and it isn't to date. But that one of these incidents was history and the second was supposed to be a mistake made the hidden request activity all the more confusing. -- Brian McGroarty | Linden Lab Sent from my Newton MP2100 via acoustic coupler ___ 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?
I don't care if it's relevant; it should still be clarified. Did nobody think? Of course not, nobody knew he would actually go through with something like that. Discrete On Aug 21, 2010, at 11:31 AM, Katharine Berry kathar...@katharineberry.co.uk wrote: 2) The active developer of a malicious viewer under the lolguise of promoting exploit/bugfixing. As I have pointed out elsewhere – I don't think that anyone was actually considering the target to be terribly virtuous. I also don't think this is terribly relevant. But given you repeatedly emphasise that he is malicious, did nobody think that it might be unwise to secretly load a website owned by a malicious party on login? Aside from WebKit/Qt exploits and the like, the SL client also considers the login frame to be trusted (admittedly, there's not much you can do with this before logging in besides changing the login location, off the top of my head). ___ 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] Viewer blacklist to replace the TPV
I'd like to remark that the information you found is just the data of the ModularSystems website, and all of the other viewer directory listings look about the same as Emerald's. The actual real-life name(s) of people involved aren't required to be publicly viewable, but Linden Lab does have them. Also, consider the possibility that .sl was chosen as a domain because it could be an abbreviation for SecondLife. Cute, eh? I seriously doubt anyone with malicious intent is going to bother trying to register their viewer in the directory. On Thu, Apr 29, 2010 at 8:38 PM, Boy Lane boy.l...@yahoo.com wrote: We certainly should follow the bright example of Emerald / Modularsystems, where you Discrete are a member of. A pseudo company set up and owned by known banned griefer JCool aka who revived his banned account(s) under the names of Fractured Crystal/Fractured Modularsystems. Back to their registration. JCool set up Modularsystems. A mailbox company with the following contact details: http://modularsystems.sl/ P.O. Box 5702 West Columbia, South Carolina 29171-5702 United States administra...@modularsystems.sl That is an untraceable anonymized entity without any name attached to it and unknown legal status, registered with a domain name in Sierra Leone, a country that does not even have a WHOIS. This information was used to register and self-certify Emerald in the Viewer Directory. As I as a legally uniformed hobby programmer without commercial interest can evaluate this situation and validity of the Emerald listing, it is meant to circumvent any means of the viewer directory to hold a developer accountable for their viewers. It is also meant to avoid any possible litigation from LL in case indeed some malicious code may be found in their viewer(s). Besides Emerald, Modularsystems also develops and uses a malicious viewer named Onyx that is in clear violation of ToS/TPV. So no, Discrete, all these things completely contradict your argument. As shown a listing in Lindens viewer directory doesn't add a single piece of safety or security. To look for a legitimate viewer the Alternate Viewer list in the community edited SL Wiki is a better place to, for the simple reason malicious clients may not easily slip in as this is possible with self-certification. A blacklist is a good thing and could at least complement Viewer Directory and Alternate Viewers list. But of course it would include most of the malicious viewer from the key developers behind Modularsystems which obviously you try to avoid. Additional question to Linden Lab: How can for repeated ToS violations permanently banned people just circumvent that ban by creating new accounts as many of the Emerald developers did? Is it money spent for SL that counts rather than ToS? Boy - Original Message - Date: Thu, 29 Apr 2010 16:39:16 -0400 From: Discrete Dreamscape discrete.dreamsc...@gmail.com Subject: Re: [opensource-dev] Viewer blacklist to replace the TPV directory ? To: Tigro Spottystripes tigrospottystri...@gmail.com Cc: opensource-dev@lists.secondlife.com Message-ID: g2nc38195a91004291339p41f404edgfe05a593c813c...@mail.gmail.com Content-Type: text/plain; charset=utf-8 This discussion seems to have been created with misleading intentions. Because some TPV creators don't want to reveal any personal information about themselves, they can't be posted on the TPV directory, and because of this, it's understandable they might view the directory as unfair. But, this doesn't strike me as a valid reason to criticize the list. It's certainly valid to say that the viewers on the list are not absolutely trustworthy unless a full code audit is done, but even then, do you really know that what's in the code is the same as what's in the binary? Isn't there a limit to what LL can do, given a lack of resources to perform such audits, especially when what you download requires trust that it's the same as what they've audited? But really, trust is supposed to be provided by the fact that the viewer has indeed registered using real-life contact information, because who would give such a thing knowing they could be held liable if they indeed decided to include malicious code? In general, there is no way to certify purity here, you can only provide a level of trust as a guideline. You can't rely on babysitting the users, because LL isn't going to compile every third party's code and release the binaries themselves. In this regard, you may begin to argue that indeed, a blacklist would better serve users. I argue that this is exactly the opposite. You may be able to pick out which viewers are explicitly untrusted, but you make no statements about the trustworthiness of any others. In this situation, a user is left to choose between either a viewer which is in the grey about its status, or an official Linden
Re: [opensource-dev] Viewer blacklist to replace the TPV directory ?
Users could then assume all unlisted viewers are safe enough for use, which is far more misleading than assuming a specific few are safe. A few who are both known and have contact information on file, no less. If they don't make this assumption, an action which any smart user should choose, then in general no third party viewers would be trusted and used. If you want a blacklist, there's already an informal one at http://onyx.modularsystems.sl/viewer_reference.html . On Thu, Apr 29, 2010 at 2:09 PM, Henri Beauchamp sl...@free.fr wrote: On Thu, 29 Apr 2010 14:04:21 -0400, Discrete Dreamscape wrote: A list of trusted entities is virtually always more robust and reliable than a list of untrusted ones. This would be only true if LL was to *guarantee* that the listed viewer can *actually* be trusted, which is *not* the case with the current implementation of teh TPV directory. Weigh the two possibilities that would occur and their consequences, given that the user is making assumptions, as you say: - User believes viewers ON the whitelist are the ONLY ones that can be used - User believes viewers NOT on the blacklist can ALL be used The latter is clearly not a situation that benefits users in any way. Not when the blacklist in question is edited by LL themselves: you then are sure that the listed viewers are illegal, which gives more reliable info than an unwarranted white list... Henri. ___ 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] Viewer blacklist to replace the TPV directory ?
That's right. However, note what I implied: a blacklist would be worse by misleading users even more, and it would discourage TPV usage in general. On Thu, Apr 29, 2010 at 3:54 PM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Discrete, in both ways you can have viewers that the users think can be trusted, but actually shouldn't On 29/4/2010 15:04, Discrete Dreamscape wrote: A list of trusted entities is virtually always more robust and reliable than a list of untrusted ones. Weigh the two possibilities that would occur and their consequences, given that the user is making assumptions, as you say: - User believes viewers ON the whitelist are the ONLY ones that can be used - User believes viewers NOT on the blacklist can ALL be used The latter is clearly not a situation that benefits users in any way. Discrete On Thu, Apr 29, 2010 at 1:59 PM, Henri Beauchamp sl...@free.fr mailto:sl...@free.fr wrote: On Thu, 29 Apr 2010 05:40:15 -0700 (PDT), Nicky Perian wrote: +1 A blacklist would just give potential bad actors a menu and template to use for more bad viewers that could be modified and get past the login screens. What you must understand is that the TPV policy is in no way a mean to prevent pirates from connecting to SL with hacked viewers (or through hacked proxies)... All what pirates have to do is to make sure these viewers impersonate an official (Linden) one (which is done very simply) and then they can pursue their illegal activity without even being spotted... The TPV policy might give some better ground to LL to sue such pirates when they are lucky enough to spot and trace one, but the true aim of the TPV is to set acceptable standards for non-hacked viewers as well as to provide their user with some minimum confidence that such viewers will not try to steal their private data or put them into troubles. As such, the blacklist would provide a much better service to the users by clearly identifying viewers which are *known* to be not compliant. With the current directory, you only got a *partial* list of *possibly* compliant viewers (without any guarantee from LL) and know nothing at all about non-listed viewers. Henri. ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.14 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEUEAREKAAYFAkvZ5A4ACgkQ8ZFfSrFHsmXOBQCfcpptZyKU+Tr1uv+FsJVUj04s 6c8AmPF6F2bQpBxhVHCTLY4yrcC38sM= =Cbvj -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ 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] Viewer blacklist to replace the TPV directory ?
This discussion seems to have been created with misleading intentions. Because some TPV creators don't want to reveal any personal information about themselves, they can't be posted on the TPV directory, and because of this, it's understandable they might view the directory as unfair. But, this doesn't strike me as a valid reason to criticize the list. It's certainly valid to say that the viewers on the list are not absolutely trustworthy unless a full code audit is done, but even then, do you really know that what's in the code is the same as what's in the binary? Isn't there a limit to what LL can do, given a lack of resources to perform such audits, especially when what you download requires trust that it's the same as what they've audited? But really, trust is supposed to be provided by the fact that the viewer has indeed registered using real-life contact information, because who would give such a thing knowing they could be held liable if they indeed decided to include malicious code? In general, there is no way to certify purity here, you can only provide a level of trust as a guideline. You can't rely on babysitting the users, because LL isn't going to compile every third party's code and release the binaries themselves. In this regard, you may begin to argue that indeed, a blacklist would better serve users. I argue that this is exactly the opposite. You may be able to pick out which viewers are explicitly untrusted, but you make no statements about the trustworthiness of any others. In this situation, a user is left to choose between either a viewer which is in the grey about its status, or an official Linden viewer. This point is key, as far less warranty is provided for users that they won't be banned for using a third party viewer. I suspect that in this case, many would simply give up and use the official client rather than risk their business, etc. If you want to provide a system where users can trust the clients they use, it seems like our current one is decent enough. In any case, a blacklist doesn't appear to be any safer. Discrete On Thu, Apr 29, 2010 at 4:02 PM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 the disclaimer instead of being hidden in small print in the bottom should be the first thing in the page, in big bold red font, to at least start helping users be less confused about how much trust they should put on the viewers listed On 29/4/2010 16:35, Kitty wrote: *From:* opensource-dev-boun...@lists.secondlife.com [mailto:opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Ron Festa *Sent:* Thursday, April 29 2010 20:27 *To:* Henri Beauchamp *Cc:* opensource-dev@lists.secondlife.com *Subject:* Re: [opensource-dev] Viewer blacklist to replace the TPV directory ? Despite claiming the list is Self-Certified those viewers on the list still had to have their viewer reviewed by LL before being listed so really all the TPV's on the TPV Directory are Certified by LL ensuring they comply with their standards policies. - release a viewer that's the LL source + a handful of innocent patches - apply for the directory and get listed - release a new viewer The last step doesn't invalidate the current listing as far as I know so I really don't see how the viewer directory could possibly be stamped as reviewed by LL by any stretch, let alone go as far as claiming that they're certified by LL as compliant. Since the reason for the directory is really end-user assurance the viewer directory doesn't really work in that sense because it doesn't actually offer much: LL still reserves the right to ban anyone just for using any third party viewer (whether listed or unlisted). With all the threatening (whether intended or not) language in blog posts or emails a lot of people are going by the assumption that listed means I won't get banned or that it means approved/sanctioned/verified/vouched for by LL but that's just not the case. It would be a lot better for any resident wanting to use any third party viewer to at least know that if they go by the list that their account isn't in jeopardy (no matter how unlikely a ban might be) for as long as that viewer is listed. For better or worse the perception that the viewer directory is a safelist is already there now, in spite of any disclaimers on that same page, and it's too late to still reverse that. Personally it seems best if the directory just officially became a safelist. If a malicious viewer ever makes the list then that wouldn't undermine people's trust in any other listed viewer because LL would guarantee that any viewer they list is indeed safe in the sense that noone can be banned for using it, even if they accidentally list one that turns out to
Re: [opensource-dev] Quiet amendments of TPV (again)
Agreed, this is a major improvement. Thanks, Joe. On Tue, Apr 20, 2010 at 10:12 AM, Latif Khalifa lati...@streamgrid.netwrote: I second that Gigs, very positive changes indeed. My thanks to Joe for making this happen. Latif On Tue, Apr 20, 2010 at 4:10 PM, Gigs gigstagg...@gmail.com wrote: These look like positive changes that address some of the concerns. Thank you for your efforts Joe. Joe Linden wrote: Boy, There was nothing quiet, or in the background about it, believe me. This update is the topic of conversation at the noon PDT brown bag I'm hosting today. The changes were pushed live ahead of the meeting, so there would be no question they are incorporated in to the TPV and TOS, both of which are effective on 4/30. I'll see those of you still interested in the subject at noon here: http://maps.secondlife.com/secondlife/Linden%20Estate%20Services/229/230/29 -- joe ___ 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] Requesting Linden Response: Please move TPVP Topics to a different mailing list
It's possible to willingly agree to liability and wave whatever protections you wish that are normally under the GPL, which seems to be what the TPV asks you to do. The issue most people seem to have is that it's not explicit in this regard and it also doesn't make it clear that it is a contract between you and LL. On Thu, Apr 15, 2010 at 11:42 AM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 from what i understand, according to GPL, developers and distributers of GPL'd stuff are _*NOT*_ liable for any GPL code they create, modify or distribute On 15/4/2010 12:28, Robert Martin wrote: On Thu, Apr 15, 2010 at 11:01 AM, Gareth Nelson gar...@garethnelson.com wrote: A quick note on that - this is not the whole meeting, some of the start was missing suggestion for the next meeting MAKE IT TEXT CHAT ONLY. how much of the meeting was lost to overhead related to voice links getting garbled or relaying info being given in voice or a client crashing or ... anyway i think that the core problem of the current TPVp is not limiting the liability of a developer to 1 code he changed 2 fixing bugs in said code so LL is only liable for Linden Core Code* a TPV is only liable for code changed from LLC** a user is liable for actions on the grid (and whatever changes done to either LLC or TP code) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvHM9UACgkQ8ZFfSrFHsmUi3gCdF9rXeLoWwsxEF1bwaXjSeqmV jWsAn3i1Dpa0KjNrokHYukjq4YONoGcm =t1M5 -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ 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
Many coders would likely accept liability when being paid well, or possibly at all. But in the case of open source code created as a hobby, the GPL idea of no warranty has so far been successful in the community because code can be inspected by its users, and because the users can verify, alter, and fix any problems in it on their own, so they shouldn't claim fault on the developer when it was their own choice to use the code. However, in LL's case, they don't even get to choose whether they use your code. Anyone can basically force it upon their service to feel the effects of using arbitrary viewer code. Thus, since there is no choice, ultimately some liability is inherent. Basically, consent does agree on both sides. LL is forced into the situation by the nature of their service, and starting April 30th, developers consent as well, if they wish to use the service. On Thu, Apr 15, 2010 at 11:57 AM, Gareth Nelson gar...@garethnelson.comwrote: The problem with that is a contract requires assent on both sides On Thu, Apr 15, 2010 at 4:47 PM, Discrete Dreamscape discrete.dreamsc...@gmail.com wrote: It's possible to willingly agree to liability and wave whatever protections you wish that are normally under the GPL, which seems to be what the TPV asks you to do. The issue most people seem to have is that it's not explicit in this regard and it also doesn't make it clear that it is a contract between you and LL. On Thu, Apr 15, 2010 at 11:42 AM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 from what i understand, according to GPL, developers and distributers of GPL'd stuff are _*NOT*_ liable for any GPL code they create, modify or distribute On 15/4/2010 12:28, Robert Martin wrote: On Thu, Apr 15, 2010 at 11:01 AM, Gareth Nelson gar...@garethnelson.com wrote: A quick note on that - this is not the whole meeting, some of the start was missing suggestion for the next meeting MAKE IT TEXT CHAT ONLY. how much of the meeting was lost to overhead related to voice links getting garbled or relaying info being given in voice or a client crashing or ... anyway i think that the core problem of the current TPVp is not limiting the liability of a developer to 1 code he changed 2 fixing bugs in said code so LL is only liable for Linden Core Code* a TPV is only liable for code changed from LLC** a user is liable for actions on the grid (and whatever changes done to either LLC or TP code) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvHM9UACgkQ8ZFfSrFHsmUi3gCdF9rXeLoWwsxEF1bwaXjSeqmV jWsAn3i1Dpa0KjNrokHYukjq4YONoGcm =t1M5 -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ 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 -- “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.org/philosophy/no-word-attachments.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
Re: [opensource-dev] Requesting Linden Response: Please move TPVPTopics to a different mailing list
I would assume that, to be more detailed, your code would either not allow connections to the LL grid, or you would have to decline the updated ToS/TPVp, thus not agreeing to be bound to it but also preventing you from using the LL grid yourself. On Thu, Apr 15, 2010 at 3:58 PM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 So any developer not willing to abide by the TPVp can simply say their viewer is not meant for LL's grid and that is it? On 15/4/2010 16:54, VR Hacks wrote: Tigro wrote: What if the developer develops a viewer for other grids? Then the TPV policy does not apply to them. Though, again, and imo, it would still be prudent for them to include a EULA with their binary distribution. And, of course, if their code is extending GPL code, they must retain said GPL with the souce code distribution. Angela Talamasca (in-world) MA Forensic Psychology VR Hacks Blog: http://bit.ly/VRHacksBlog VR Hacks Twitter: http://bit.ly/VRHacksTwitter VR Hacks YouTube: http://bit.ly/VRHacksYouTube Digital DNA in SL: http://bit.ly/VRHacksSLmap Digital DNA in Blue Mars: http://bit.ly/BMclient -- Ordinary riches can be stolen, real riches cannot. In your soul are infinitely precious things that cannot be taken from you. - Oscar Wilde ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvHb8wACgkQ8ZFfSrFHsmWpPwCeMIV18rdRa3EPca4SGEAPENbm HU0An2JEkCBTgZ7mO7ccPACDcsswBHCa =yy0t -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ 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
Devs for other grids that don't need to agree to LL's policy probably wouldn't have anything to worry about at all, especially if they included EULAs with the right terms. As for residents, I wouldn't say their account becomes 'unsafe.' However, my (emphasis on my) interpretation of the policy is that you would be responsible (read: liable) to LL for the results of your code. On Thu, Apr 15, 2010 at 4:03 PM, Tigro Spottystripes tigrospottystri...@gmail.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Why developers for other grids would need to do any changes on their code? And why can't a SL resident develop clients for other grids while keeping their SL accounts safe without being forced to jump thru hoops? On 15/4/2010 17:00, Discrete Dreamscape wrote: I would assume that, to be more detailed, your code would either not allow connections to the LL grid, or you would have to decline the updated ToS/TPVp, thus not agreeing to be bound to it but also preventing you from using the LL grid yourself. On Thu, Apr 15, 2010 at 3:58 PM, Tigro Spottystripes tigrospottystri...@gmail.com mailto:tigrospottystri...@gmail.com wrote: So any developer not willing to abide by the TPVp can simply say their viewer is not meant for LL's grid and that is it? On 15/4/2010 16:54, VR Hacks wrote: Tigro wrote: What if the developer develops a viewer for other grids? Then the TPV policy does not apply to them. Though, again, and imo, it would still be prudent for them to include a EULA with their binary distribution. And, of course, if their code is extending GPL code, they must retain said GPL with the souce code distribution. Angela Talamasca (in-world) MA Forensic Psychology VR Hacks Blog: http://bit.ly/VRHacksBlog VR Hacks Twitter: http://bit.ly/VRHacksTwitter VR Hacks YouTube: http://bit.ly/VRHacksYouTube Digital DNA in SL: http://bit.ly/VRHacksSLmap Digital DNA in Blue Mars: http://bit.ly/BMclient -- Ordinary riches can be stolen, real riches cannot. In your soul are infinitely precious things that cannot be taken from you. - Oscar Wilde ___ 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 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.12 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkvHcSEACgkQ8ZFfSrFHsmXSNQCfdYb7Oshh7XjnJh8D3a+2UjGB uLcAniiljZlImaLgf2MBhyZWbQO/Hd42 =HZCv -END PGP SIGNATURE- ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Requesting Linden Response: Please move TPVPTopics to a different mailing list
These comments are beginning to seem rather like pure speculation. If you're concerned about your project or your liabilities, I recommend consulting with someone from LL or with your lawyer. Anyhow, the discussion at hand could use some more focus on what further modifications would be appreciated in the TPVp pending further discussions with Joe. On Thu, Apr 15, 2010 at 5:24 PM, VR Hacks vrha...@gmail.com wrote: Michael wrote in part (full off-list comment is included below sig): That means that you can write and distribute anything you please, but if you connect to the grid with something like NeilLife and you get caught doing it then you will loose your account. Yup, something to that effect. I mean you can't legally be held liable for users who refuse to follow a contract they made with you, can you? Sure you can. After all, if you write malicious code, you know you're doing it. So, if you choose to distribute that code that allows connection to the grid, and even if you included a connect to the grid at your own risk clause in your EULA, it could easily be shown in a court of law that you were attempting to circumvent the lab's TPV policy. In fact, if anything, such a clause in the EULA would clearly indicate that you know you're distributing a non-compliant viewer for connecting to the SL grid. Again, this would only apply if you provided a means for your viewer to connect to the SL grid. Angela Talamasca (in-world) MA Forensic Psychology VR Hacks Blog: http://bit.ly/VRHacksBlog VR Hacks Twitter: http://bit.ly/VRHacksTwitter VR Hacks YouTube: http://bit.ly/VRHacksYouTube Digital DNA in SL: http://bit.ly/VRHacksSLmap Digital DNA in Blue Mars: http://bit.ly/BMclient -- Ordinary riches can be stolen, real riches cannot. In your soul are infinitely precious things that cannot be taken from you. - Oscar Wilde Angela Talamasca (in-world) MA Forensic Psychology VR Hacks Blog: http://bit.ly/VRHacksBlog VR Hacks Twitter: http://bit.ly/VRHacksTwitter VR Hacks YouTube: http://bit.ly/VRHacksYouTube Digital DNA in SL: http://bit.ly/VRHacksSLmap Digital DNA in Blue Mars: http://bit.ly/BMclient -- Ordinary riches can be stolen, real riches cannot. In your soul are infinitely precious things that cannot be taken from you. - Oscar Wilde - Original Message - From: Michael Daniel m.a.dan...@iup.edu To: VR Hacks vrha...@gmail.com Sent: Thursday, April 15, 2010 1:38 PM Subject: Re: [opensource-dev] Requesting Linden Response: Please move TPVPTopics to a different mailing list I know many others have looked at this, but to me the important part of the policy is this: This Policy does not place any restriction on modification or use of our viewer source code https://wiki.secondlife.com/wiki/Source_downloads that we make available under the GPL http://secondlifegrid.net/technology-programs/license-virtual-world/viewerlicensing/gplv2 . Rather, the Policy sets out requirements for connecting to our Second Life service using a Third-Party Viewer, regardless of the viewer source code used, and for participating in our Viewer Directory http://viewerdirectory.secondlife.com. That means that you can write and distribute anything you please, but if you connect to the grid with something like NeilLife and you get caught doing it then you will loose your account. If you don't want the liability just toss something in the EULA for your users that makes them agree to not use your TPV to connect to SL and you're covered, I think. I'm pretty sure that counts as due dilligance. I mean you can't legally be held liable for users who refuse to follow a contract they made with you, can you? Again, I'm not a lawyer. ~Bubblesort VR Hacks wrote: Tigro Spottystripes Why developers for other grids would need to do any changes on their code? And why can't a SL resident develop clients for other grids while keeping their SL accounts safe without being forced to jump thru hoops? For argument's sake, let's say I, as an SL user, choose to extend the linden lab viewer code base to access, say, reaction grid. Let's also say that I do wish to agree to the TPV policy for my code. In other words, say, I want to include functionality that is allowable on that grid but not allowable on the SL grid. It is then my responsibility to create my viewer such that the option for connecting to the SL grid is not available without some sort of code change. At which point I can deploy my code. Of course, I still plan to access the second life grid. In order to do so, I cannot use my viewer. Rather, I must use a viewer that was developed by someone who agreed to the TPV policy (as put forth in the new ToS). In other words, as long as I am using a viewer that adheres to the TPV policy, all is
Re: [opensource-dev] oh give me a break
You can find grids exactly like you want already, but they have online concurrencies that can be counted on one hand and are slow as molasses, plus no one makes any content there for exactly the reasons you would like to use them. It would be narrow-minded to think that open source is the only business model that should ever be employed, especially when the existing models produce livable income for only a small percentage of the Linden grid. On Sun, Mar 14, 2010 at 6:39 PM, New Hax newh...@gmail.com wrote: agree to disagree yea but then your days are numbered in SL. If the project forks then there will be a VW without all these restrictions and lindens threatening people for asking them to keep their promises? On 3/14/10, New Hax newh...@gmail.com wrote: I want a grid where people can have the freedom to develop what they want and do what they want, without being told whats allowed, and without being watched because you might move the wrong bits from one place to another. and without lindens threatening if we dont play nice with draconinan DRM. That was what i hoped the spirit of Open source SL would be. but i guess im wrong. On 3/14/10, Glen Canaday gcana...@gmail.com wrote: Then what are you doing here? On 03/14/2010 06:32 PM, New Hax wrote: I know better than to try to get rich off of selling ones and zeroes. On 3/14/10, Glen Canadaygcana...@gmail.com wrote: Then what are you doing in SL? Not making a living, I can assure you. Nor are you putting food on the table RL except perhaps by manual labor, which cannot be copied. Ex: Ditches need to be dug. The ditch-digger can be changed out, but that doesn't change the fact that even if you get a new digger, you still have a ditch when you're done. OSS/Free Software and Proprietary software are the diggers; they're not the ditch itself. On 03/14/2010 06:18 PM, New Hax wrote: then what are you doing on an opensource list if you want your content wrapped in DRM. sl will die if its not open. and you can't compare rl doors to the internet. if you dont lock your rl door I can come in and take something of yours that isnt replaceable. but on the internet as a content maker you can make INFINITE products so you arent losing anything if i copy it and make no money off of it. On 3/14/10, Marine Kelleymarinekel...@gmail.com wrote: well I am a content creator, content theft is a problem to me, it is tied to IP rights which are a legal issue. And I am not one of those who say content theft is inevitable, let's not do anything about it. Doors can be lock picked, that's not a reason for me to leave my door wide open. On 14 March 2010 23:04, New Haxnewh...@gmail.com wrote: On 3/14/10, Marine Kelleymarinekel...@gmail.com wrote: Err... Content theft has always been a problem, will always be a problem, and LL better be on the same page with developers, content makers and customers here. content theft isn't a problem, never has been a problem, and is the nature of the internet and digital things. if content makers are worried about content theft then they shouldn't be on SL. because its inevitable and cant be stopped. ___ 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 ___ 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
