Re: [opensource-dev] step by step guide to compiling snowglobe
On Wed, Feb 17, 2010 at 02:30:07PM -0500, kow wrote: > Snowglobe should work out of the box with VS2005. Emerald and Imprudence are > easier options if you're using VS2008. I believe the only issue with VS2008 + > snowglobe is boost, and the libs from Emerald or Imprudence can be dropped in > to fix that. One would wonder why Emerald can fix this, and LL can't. -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Client-side scripting in Snowglobe
I referred recently to Linden's internal project "Firefly" to add client-side scripting to SL viewers. This has been the topic of open discussion at several Office Hours with Lindens in SL, but that openness has not extended to many design details --- the Firefly design process is not open to the community. The only technical details that are being disclosed about Firefly appear to be: - "Scripts" are actually *Mono assemblies*, so that only languages that compile to Mono will be allowed. - The programs run in a *sandbox*, which means that most platform resources are not accessible to them. Please note that I quite like C# as a language, but the following remarks are about Mono use *in the SL viewer*, only, where its tradeoffs are poor. The first known detail about Firefly (mandatory Mono) is problematic on several fronts: 1. Only a tiny fraction of the world's applications, libraries and languages work on Mono, so client-side scripting will be unable to benefit from the huge mountain of resources available on the Internet. This is an extremely severe limitation, and an unnecessary restriction in the context of client-side viewer scripting. If I want to use a locally-installed package X from within my client-side script, I should be able to. What runs client-side should always be our individual choice, not someone else's. 2. Programmers want to write client-side scripts in the language that they know best, because that always yields the fastest progress and highest quality results. There was a good technical reason for forcing everyone to use LSL server-side, but there is no technical reason to impose this requirement on all client-side scripting. It is counter-productive to force CLR compatibility on client-side script developers when there is a simple alternative: define a *socket-based viewer API* for client-side scripts instead, hence usable from any language. 3. Mono runs poorly on Linux, so from being rock-solid on Linux now, the LL-derived viewers will become second-rate on this platform. 4. The viewer is already extremely bloated and a memory hog. Adding a Mono dependency will compound that horribly. 5. There is only one effective supplier of Mono: Novell. That is a very bad situation to encourage and to support in the viewer. 6. Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, The second known detail about Firefly (mandatory sandbox) is problematic on two related fronts: 1. Sandboxes by design do not allow most platform resources to be accessed, as a security measure. This is fine and important when scripts are being downloaded from unknown places (like Javascript in web pages), but that same protection also means that client-side scripts would be powerless to do useful things for us in concert with local applications, files, devices, etc. Sandboxing client-side scripts effectively hardwires in script weakness for no reason discussed as a requirement. 2. Sandboxed applications cannot be linked with user-chosen native libraries since allowing native code breaks sandbox protection. This means no accelerators, no extensions, and no interop with other systems since sockets are inaccessible from any strong sandbox. This also means no evolution or progress outside of what the sandbox designers permit. This mailing list is concerned with development of open source viewers, in particular Snowglobe. This is heralded as a *community* viewer, embodying * community* requirements much more directly than the LL mainstream viewer. Client-side scripting will impact on every single aspect of Snowglobe bar none, yet the community is being excluded from the design of its most powerful infrastructure element. This is entirely wrong, far beyond the normal observation that secrecy in design has no place in open source. It is hard to assess things technically when the design requirements are formulated in secret. The Snowglobe community has design requirements too. Those deserve to be examined here openly, not limiting Snowglobe to a design that stems from Linden requirements alone. Morgaine. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
A line got lost from my post owing to finger trouble. Item 6 about Mono should have read: 6. Some parties identify other reasons for avoiding Mono in general. Without getting into that subject at all, requiring Mono for client-side scripting would make scripting unavailable to that portion of the user base. Since client-side scripting without Mono is perfectly feasible, Mono should not be made mandatory for scripting, so that the widest user base can be supported. Morgaine. On Thu, Feb 18, 2010 at 12:42 PM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design details --- the Firefly design process is not > open to the community. The only technical details that are being disclosed > about Firefly appear to be: > > >- "Scripts" are actually *Mono assemblies*, so that only languages that >compile to Mono will be allowed. >- The programs run in a *sandbox*, which means that most platform >resources are not accessible to them. > > > Please note that I quite like C# as a language, but the following remarks > are about Mono use *in the SL viewer*, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on > several fronts: > >1. Only a tiny fraction of the world's applications, libraries and >languages work on Mono, so client-side scripting will be unable to benefit >from the huge mountain of resources available on the Internet. This is an >extremely severe limitation, and an unnecessary restriction in the context >of client-side viewer scripting. If I want to use a locally-installed >package X from within my client-side script, I should be able to. What > runs >client-side should always be our individual choice, not someone else's. >2. Programmers want to write client-side scripts in the language that >they know best, because that always yields the fastest progress and highest >quality results. There was a good technical reason for forcing everyone to >use LSL server-side, but there is no technical reason to impose this >requirement on all client-side scripting. It is counter-productive to > force >CLR compatibility on client-side script developers when there is a simple >alternative: define a *socket-based viewer API* for client-side >scripts instead, hence usable from any language. >3. Mono runs poorly on Linux, so from being rock-solid on Linux now, >the LL-derived viewers will become second-rate on this platform. >4. The viewer is already extremely bloated and a memory hog. Adding a >Mono dependency will compound that horribly. >5. There is only one effective supplier of Mono: Novell. That is a >very bad situation to encourage and to support in the viewer. >6. Some parties identify other reasons for avoiding Mono in general. > Without getting into that subject at all, > > > The second known detail about Firefly (mandatory sandbox) is problematic on > two related fronts: > >1. Sandboxes by design do not allow most platform resources to be >accessed, as a security measure. This is fine and important when scripts >are being downloaded from unknown places (like Javascript in web pages), > but >that same protection also means that client-side scripts would be powerless >to do useful things for us in concert with local applications, files, >devices, etc. Sandboxing client-side scripts effectively hardwires in >script weakness for no reason discussed as a requirement. >2. Sandboxed applications cannot be linked with user-chosen native >libraries since allowing native code breaks sandbox protection. This means >no accelerators, no extensions, and no interop with other systems since >sockets are inaccessible from any strong sandbox. This also means no >evolution or progress outside of what the sandbox designers permit. > > > This mailing list is concerned with development of open source viewers, in > particular Snowglobe. This is heralded as a *community* viewer, embodying > *community* requirements much more directly than the LL mainstream viewer. > Client-side scripting will impact on every single aspect of Snowglobe bar > none, yet the community is being excluded from the design of its most > powerful infrastructure element. This is entirely wrong, far beyond the > normal observation that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements are > formulated in secret. The Snowglobe community has design requirements too. > Those deserve to be examined here openly, not limiting Snowglobe to a > design that stems from Linden requirements alone. > > > Morgaine. > > __
Re: [opensource-dev] step by step guide to compiling snowglobe
> One would wonder why Emerald can fix this, and LL can't. It's been addressed. https://lists.secondlife.com/pipermail/sldev/2009-June/014269.html "The problem is that it's not possible to provide precompiled Boost libraries that work for both VS 2005 and VS 2008. Since Linden Lab has standardized on VS 2005, that's what we provide." -Rob Later in that thread we see: https://lists.secondlife.com/pipermail/sldev/2009-June/014273.html "I will be looking into providing library packages that contain binaries for both versions shortly. Hopefully in the next week or two." -Brad Linden Obviously, that didn't happen. But I've always wondered if it's possible to bribe Lindens with confectionery. -Stickman ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
On Thu, Feb 18, 2010 at 7:42 AM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design details --- the Firefly design process is not > open to the community... Personally, I find it difficult to escape the conclusion that the preposterous amount of secrecy now surrounding viewer development has any legitimate purpose. The argument that it is to preserve some commercial competitive advantage for Linden Research is silly. Competing solutions are constrained by their own architectures in the functions they can deliver. (I suppose it might be possible that this stealth systems design might be intended to sabotage efforts by other users of the Second Life Viewer codebase. If so, I'd be interested in the legal implications of that relative to antitrust and unfair trade practices law. But IANAL.) Most charitably, I'm left to conclude that -- like so many other activities conducted by Linden Research -- it is being done in secret with the intention of maximizing spin control of reactions of the user community until such initiatives are fait accompli. Whatever the motivation for this, I think soliciting and exploiting developer involvement and contributions from the open-source community and then turning around and treating them like mushrooms is reprehensible. Trade press reporting of statements made by Joe Linden about restrictions to be placed on third-party viewers (including implementation of mandatory technical standards that enable servers to discriminate against various viewer implementations) call for an immediate response from Linden Research that goes beyond simple ad-hominem attacks on their source to authoritative clarification, denial or confirmation. "You'l find out when it's most advantageous to us to tell you" is a deep expression of contempt for your customers and business partners. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't eyeball them. Creating a sandbox is a huge, complex, and difficult job, even in an application designed to run untrusted content from the ground up. Putting a blind scripting environment inside something like the SL client is risky. Putting one that isn't inherently secure in there is scary. Linden Lab does not trust the Mono sandbox on the server: you can't upload Mono bytecodes like you could LSL bytecodes. And they shouldn't. LSL bytecodes are run in an inherently secure environment... they can not perform any operation outside the capabilities of the LSL runtime: security and access controls are implemented outside the interpreter. Javascript and Activescript in Flash are in the same situation: they are languages that can (and usually do) run in an interpreter that does not even implement unsafe operations. Java and Mono/.NET intermediate language can do anything native code can, they are not inherently secure, and should not be treated the same way. * Even if the entire viewer was run in a provably secure virtual machine this would not seem like a safe option to me, since the viewer has full access to all my assets and account information in Second Life. Now there are situations where this kind of assembly would be acceptable, where it's treated and presented to the user as an application, where the user has to explicitly request that it be installed, where it is made clear that installing a plugin is the same kind of risk as installing and running an application. But not when it's something that can be pushed from an untrusted source with no more than a warning dialog between you and HonestImNotInThePN ThrowawayAlt. Even if they were using an inherently safe language, accepting unexaminable binary payloads from untrusted sources and running them in the SL client in anything like its current state would raise all kinds of warning flags with me. Doing this using an internally- sandboxed interpreter just isn't something I'm prepared to do. * No, I don't use Silverlight and I have Java disabled. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
On Thu, Feb 18, 2010 at 8:45 AM, Argent Stonecutter wrote: > Java and Mono/.NET intermediate language can do anything native code can... Quibble: I can't speak for the MSFT-proprietary platforms, but Java code runs subject to the classloader's SecurityManager. I do hear talk that Silverlight is gaining the ability to do ActiveX calls. Joy. I do worry even when I hear talk of a Flash MediaPlugin, because Adobe code is famous for being exploited through scripting. "In the first quarter of 2009, malicious PDF files made up 56% of all exploits tracked by ScanSafe. That figure climbed above 60% in the second quarter, over 70% in the third and finished at 80% in the fourth quarter..." ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
Look into Code Access Security (CAS) in .NET - it is a pretty damn tough security sandbox; every operation that can be called in the default libraries is security rated; everything outside that is weighted based on: - What it declares itself - What functions in the Standard Library it calls (can only be as secure as all the functions it calls) - If it uses native code (automatically 'unsafe') >From what I understand, Mono ended up implementing a lot of that for >Silverlight; although I do not know how the security holds up compared to the >official .NET runtime; but AppDomains + CAS is a pretty rock solid sandbox on >Windows. Regards, Adam > -Original Message- > From: opensource-dev-boun...@lists.secondlife.com [mailto:opensource- > dev-boun...@lists.secondlife.com] On Behalf Of Argent Stonecutter > Sent: Thursday, 18 February 2010 5:46 AM > To: Morgaine > Cc: opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Client-side scripting in Snowglobe > > 7. 8. 9. 10. ... I'm not going to run client-side scripts if I can't > eyeball them. Creating a sandbox is a huge, complex, and difficult > job, even in an application designed to run untrusted content from the > ground up. Putting a blind scripting environment inside something like > the SL client is risky. Putting one that isn't inherently secure in > there is scary. > > Linden Lab does not trust the Mono sandbox on the server: you can't > upload Mono bytecodes like you could LSL bytecodes. And they > shouldn't. LSL bytecodes are run in an inherently secure > environment... they can not perform any operation outside the > capabilities of the LSL runtime: security and access controls are > implemented outside the interpreter. Javascript and Activescript in > Flash are in the same situation: they are languages that can (and > usually do) run in an interpreter that does not even implement unsafe > operations. Java and Mono/.NET intermediate language can do anything > native code can, they are not inherently secure, and should not be > treated the same way. * > > Even if the entire viewer was run in a provably secure virtual machine > this would not seem like a safe option to me, since the viewer has > full access to all my assets and account information in Second Life. > > Now there are situations where this kind of assembly would be > acceptable, where it's treated and presented to the user as an > application, where the user has to explicitly request that it be > installed, where it is made clear that installing a plugin is the same > kind of risk as installing and running an application. But not when > it's something that can be pushed from an untrusted source with no > more than a warning dialog between you and HonestImNotInThePN > ThrowawayAlt. > > Even if they were using an inherently safe language, accepting > unexaminable binary payloads from untrusted sources and running them > in the SL client in anything like its current state would raise all > kinds of warning flags with me. Doing this using an internally- > sandboxed interpreter just isn't something I'm prepared to do. > > * No, I don't use Silverlight and I have Java disabled. > ___ > 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] Client-side scripting in Snowglobe
On Thu, Feb 18, 2010 at 9:06 AM, Frisby, Adam wrote: > From what I understand, Mono ended up implementing a lot of that for > Silverlight; although I do not know how the security holds up compared to the > official .NET runtime; but AppDomains + CAS is a pretty rock solid sandbox on > Windows. Last I heard, Babbage was trying to recruit volunteer labor to build a bytecode verifier so the server-side could be safely scripted in C#. I think we all can agree that a Windows-only viewer is unacceptable. And that's a fundamental weakness of embracing MSFT tech. Imagine if LL had to run the grid on licensed Windows servers to get acceptable performance...not that they're getting it now, and the Mono LSL implementation is a big part of that problem. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
Actually, Windows server isn't that expensive. Look up the SPLA pricing on things, reduces the cost down to about $10/mo, which isn't bad at all compared to the other fees you pay for hosting. ;) Adam > -Original Message- > From: margaret.le...@gmail.com [mailto:margaret.le...@gmail.com] On > Behalf Of Maggie Leber (sl: Maggie Darwin) > Sent: Thursday, 18 February 2010 6:35 AM > To: Frisby, Adam > Cc: Argent Stonecutter; Morgaine; opensource-dev@lists.secondlife.com > Subject: Re: [opensource-dev] Client-side scripting in Snowglobe > > On Thu, Feb 18, 2010 at 9:06 AM, Frisby, Adam > wrote: > > > From what I understand, Mono ended up implementing a lot of that for > Silverlight; although I do not know how the security holds up compared > to the official .NET runtime; but AppDomains + CAS is a pretty rock > solid sandbox on Windows. > > Last I heard, Babbage was trying to recruit volunteer labor to build a > bytecode verifier so the server-side could be safely scripted in C#. > > I think we all can agree that a Windows-only viewer is unacceptable. > And that's a fundamental weakness of embracing MSFT tech. Imagine if > LL had to run the grid on licensed Windows servers to get acceptable > performance...not that they're getting it now, and the Mono LSL > implementation is a big part of that problem. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
This makes me sad. I've been trying to have an open discussion about some of the design issues in my office hours, specifically to understand the constraints and requirements of the community. But every office hour seems to be followed up by flames on this list and in other forums interpreting what was said in the worst possible way. I'm afraid the tone and direction of this discussion are making it impossible for us to talk about this project productively. Q On Feb 18, 2010, at 7:42 AM, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add client-side > scripting to SL viewers. This has been the topic of open discussion at > several Office Hours with Lindens in SL, but that openness has not extended > to many design details --- the Firefly design process is not open to the > community. The only technical details that are being disclosed about Firefly > appear to be: > > "Scripts" are actually Mono assemblies, so that only languages that compile > to Mono will be allowed. > The programs run in a sandbox, which means that most platform resources are > not accessible to them. > > Please note that I quite like C# as a language, but the following remarks are > about Mono use in the SL viewer, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on > several fronts: > Only a tiny fraction of the world's applications, libraries and languages > work on Mono, so client-side scripting will be unable to benefit from the > huge mountain of resources available on the Internet. This is an extremely > severe limitation, and an unnecessary restriction in the context of > client-side viewer scripting. If I want to use a locally-installed package X > from within my client-side script, I should be able to. What runs > client-side should always be our individual choice, not someone else's. > Programmers want to write client-side scripts in the language that they know > best, because that always yields the fastest progress and highest quality > results. There was a good technical reason for forcing everyone to use LSL > server-side, but there is no technical reason to impose this requirement on > all client-side scripting. It is counter-productive to force CLR > compatibility on client-side script developers when there is a simple > alternative: define a socket-based viewer API for client-side scripts > instead, hence usable from any language. > Mono runs poorly on Linux, so from being rock-solid on Linux now, the > LL-derived viewers will become second-rate on this platform. > The viewer is already extremely bloated and a memory hog. Adding a Mono > dependency will compound that horribly. > There is only one effective supplier of Mono: Novell. That is a very bad > situation to encourage and to support in the viewer. > Some parties identify other reasons for avoiding Mono in general. Without > getting into that subject at all, > > The second known detail about Firefly (mandatory sandbox) is problematic on > two related fronts: > Sandboxes by design do not allow most platform resources to be accessed, as a > security measure. This is fine and important when scripts are being > downloaded from unknown places (like Javascript in web pages), but that same > protection also means that client-side scripts would be powerless to do > useful things for us in concert with local applications, files, devices, etc. > Sandboxing client-side scripts effectively hardwires in script weakness for > no reason discussed as a requirement. > Sandboxed applications cannot be linked with user-chosen native libraries > since allowing native code breaks sandbox protection. This means no > accelerators, no extensions, and no interop with other systems since sockets > are inaccessible from any strong sandbox. This also means no evolution or > progress outside of what the sandbox designers permit. > > This mailing list is concerned with development of open source viewers, in > particular Snowglobe. This is heralded as a community viewer, embodying > community requirements much more directly than the LL mainstream viewer. > Client-side scripting will impact on every single aspect of Snowglobe bar > none, yet the community is being excluded from the design of its most > powerful infrastructure element. This is entirely wrong, far beyond the > normal observation that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements are > formulated in secret. The Snowglobe community has design requirements too. > Those deserve to be examined here openly, not limiting Snowglobe to a design > that stems from Linden requirements alone. > > > Morgaine. > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the pol
Re: [opensource-dev] Client-side scripting in Snowglobe
On Thu, Feb 18, 2010 at 10:57:52AM -0500, Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues in > my office hours, specifically to understand the constraints and requirements > of > the community. But every office hour seems to be followed up by flames on this > list and in other forums interpreting what was said in the worst possible way. I don't have time to attend office hours at those exact moments. Not everyone lives in the States. > I'm afraid the tone and direction of this discussion are making it impossible > for us to talk about this project productively. Yeah right. I read the posts too, and they seem to be all true. This remark sounds like a poor excuse to explain why there is no open development of client-side scripting ON THIS LIST, where it belongs. I'm sorry, but I agree with the statement of Maggie that the only sane conclusion is that, as always seems to be the case, "it is being done in secret with the intention of maximizing spin control of reactions of the user community until such initiatives are fait accompli" LL is simply not willing nor interested to listen to the (open source) community; they want no discussion and want to push what they think is best. > Q -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
My suggestion would be to in cases where policies and such are being decided that LL not have an office hour (or a couple office hours) but an office DAY and yes im suggesting that a linden or lindens put in a full 12 hour time where folks can discuss the subject. Even if Y'all did it tag team style where a given linden could tag out (and another linden tag in) this would help. (maybe 3 hour blocks with a 30 minute break to keep the transcript from getting to huge) -- Robert L Martin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
If you were trying to have an open discussion, then you went about it quite wrong. Nothing was mentioned on this mailing list. I don't think anything was mentioned in the Open Source Meeting (which has of late become nothing more than a Snowglobe bug triage) and I don't see any transcripts on the wiki of any other office hours discussing it. On Dec 12th Babbage Linden said "there are plans, but they are a long way off" So if you rely on hearsay to communicate your ideas, don't act surprised when they are misinterpreted. I don't mean to sound harsh, but from my viewpoint, there's nothing very "open" about SL Open Source anymore. Mike Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design > issues in my office hours, specifically to understand the constraints > and requirements of the community. But every office hour seems to be > followed up by flames on this list and in other forums interpreting what > was said in the worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
Kent, it is true that Office Hour discussions can sometimes get a bit heated because of the format, which allows little time for careful consideration and reflection before writing, but that is not the case here. My opening post above was polite and factual, and it considered all the points that have been revealed to us. Please do not make blanket accusations about flaming as an excuse for keeping the project under wraps, when my goal in the thread is collaboration. Quite the opposite of flaming, I am trying to bring into the open here some very key issues of viewer design that will directly affect the Snowglobe community branch of the viewer in numerous far-reaching ways. That discussion belongs here, not in informal chat at Office Hours which is a completely inappropriate medium for technical design. Re your closing line: On Thu, Feb 18, 2010 at 3:57 PM, Kent Quirk (Q Linden) wrote: > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > The direction of this discussion is towards involving the Snowglobe community in the design process for their viewer. The tone of this discussion is (speaking for myself) polite. I see no reason why you would not wish to talk about the design of client-side scripting with us, very productively. Morgaine. On Thu, Feb 18, 2010 at 3:57 PM, Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues > in my office hours, specifically to understand the constraints and > requirements of the community. But every office hour seems to be followed up > by flames on this list and in other forums interpreting what was said in the > worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > > Q > > > On Feb 18, 2010, at 7:42 AM, Morgaine wrote: > > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that openness has > not extended to many design details --- the Firefly design process is not > open to the community. The only technical details that are being disclosed > about Firefly appear to be: > > >- "Scripts" are actually *Mono assemblies*, so that only languages that >compile to Mono will be allowed. >- The programs run in a *sandbox*, which means that most platform >resources are not accessible to them. > > > Please note that I quite like C# as a language, but the following remarks > are about Mono use *in the SL viewer*, only, where its tradeoffs are poor. > > The first known detail about Firefly (mandatory Mono) is problematic on > several fronts: > >1. Only a tiny fraction of the world's applications, libraries and >languages work on Mono, so client-side scripting will be unable to benefit >from the huge mountain of resources available on the Internet. This is an >extremely severe limitation, and an unnecessary restriction in the context >of client-side viewer scripting. If I want to use a locally-installed >package X from within my client-side script, I should be able to. What > runs >client-side should always be our individual choice, not someone else's. >2. Programmers want to write client-side scripts in the language that >they know best, because that always yields the fastest progress and highest >quality results. There was a good technical reason for forcing everyone to >use LSL server-side, but there is no technical reason to impose this >requirement on all client-side scripting. It is counter-productive to > force >CLR compatibility on client-side script developers when there is a simple >alternative: define a *socket-based viewer API* for client-side >scripts instead, hence usable from any language. >3. Mono runs poorly on Linux, so from being rock-solid on Linux now, >the LL-derived viewers will become second-rate on this platform. >4. The viewer is already extremely bloated and a memory hog. Adding a >Mono dependency will compound that horribly. >5. There is only one effective supplier of Mono: Novell. That is a >very bad situation to encourage and to support in the viewer. >6. Some parties identify other reasons for avoiding Mono in general. > Without getting into that subject at all, > > > The second known detail about Firefly (mandatory sandbox) is problematic on > two related fronts: > >1. Sandboxes by design do not allow most platform resources to be >accessed, as a security measure. This is fine and important when scripts >are being downloaded from unknown places (like Javascript in web pages), > but >that same protection also means that client-side scripts would be powerless >to
Re: [opensource-dev] Client-side scripting in Snowglobe
On Thu, Feb 18, 2010 at 10:57 AM, Kent Quirk (Q Linden) wrote: > This makes me sad. There's lots to be sad about. I think current Linden Research policies regarding viewer design and development has severely damaged the trust relationship that should exist within an open-source developer community. That's a much bigger impact on productivity than any personal complaints about "tone". ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
I for one agree with Q. The biggest complaints come from the most insignificant people. If LL prioritized development based on the complaints in this mailing list, they would be rewriting SL for Linux using GTK and maintaining a dozen branches for ever popular flavour of unix. But then we'd just be playing a thinly veiled OpenCroquet. Instead of making accusations and generating pages upon pages of arguments based on hearsay, why not ask a well thought out question that a developer can answer with a simple yes or no? I'd much rather Q and his coworkers spent time developing cool things than entertaining your pointless nerd rage about Mono. On 2/18/2010 12:28 PM, Maggie Leber (sl: Maggie Darwin) wrote: > On Thu, Feb 18, 2010 at 10:57 AM, Kent Quirk (Q Linden) > wrote: > >> This makes me sad. >> > There's lots to be sad about. > > I think current Linden Research policies regarding viewer design and > development has severely damaged the trust relationship that should > exist within an open-source developer community. > > That's a much bigger impact on productivity than any personal > complaints about "tone". > ___ > 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] Client-side scripting in Snowglobe
On Thursday 18 February 2010 17:57:52 Kent Quirk (Q Linden) wrote: > This makes me sad. > > I've been trying to have an open discussion about some of the design issues > in my office hours, specifically to understand the constraints and > requirements of the community. But every office hour seems to be followed > up by flames on this list and in other forums interpreting what was said > in the worst possible way. > > I'm afraid the tone and direction of this discussion are making it > impossible for us to talk about this project productively. > > Q I think this is a good point in this budding flamewar to bring this up: http://lwn.net/Articles/370157/ Josh Berkus' patented ten-step method on how to free a project of unwelcome community involvement. (A little) more seriously, if the current trend towards secrecy at LL is a result of 3rd party viewers based on LL code "stealing" mindshare, it should be pointed that the developers of those viewers chose that route mainly as a result of LLs past lack of involvement with open source contributors, and (again, past) opaque and SLOW process of patch submission. To move this to a more productive direction, can you give a summary of what Firefly is, for those of us who weren't at your office hour? -- Thickbrick ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
OK. I get it. You like fanning the fires of flame wars. Very funny. Mike k\o\w wrote: > I for one agree with Q. The biggest complaints come from the most > insignificant people. If LL prioritized development based on the > complaints in this mailing list, they would be rewriting SL for Linux > using GTK and maintaining a dozen branches for ever popular flavour of > unix. But then we'd just be playing a thinly veiled OpenCroquet. > > Instead of making accusations and generating pages upon pages of > arguments based on hearsay, why not ask a well thought out question that > a developer can answer with a simple yes or no? I'd much rather Q and > his coworkers spent time developing cool things than entertaining your > pointless nerd rage about Mono. ___ 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] step by step guide to compiling snowglobe
On Thu, 18 Feb 2010 13:36:13 +0100 Carlo Wood wrote: > On Wed, Feb 17, 2010 at 02:30:07PM -0500, kow wrote: > > Snowglobe should work out of the box with VS2005. Emerald and > > Imprudence are easier options if you're using VS2008. I believe the > > only issue with VS2008 + snowglobe is boost, and the libs from > > Emerald or Imprudence can be dropped in to fix that. > > One would wonder why Emerald can fix this, and LL can't. why ppl don't understand how work a opensource community, and prefer work on own project in place to work together for a common powerfull project... ___ 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] step by step guide to compiling snowglobe
That's the open-source way. Regardless of community, we're still human and us humans love ownership...whether its taking our favorite phone and customizing it with all our favorite apps or taking the concept of a viewer and releasing our own spin on it. I gotta give credit to the Emerald folks for pushing their own ideas and moving forward with it and then watch it blossom into one of the most-used 3rd-party viewers out there. Developers kill for that kind of recognition. I think they should keep on trucking on their current path and when Viewer II comes out, use the positives of it, fix the negatives, and make an Emerald II viewer. I can only imagine the possibilities! As far as SnowGlobe goes, I wish it was more modular like linux goes. To where we can add packages or remove them from the base install to grant us this or that. When one module gets updated we can just download it as needed. Also*Hey Linden Labs, when are we going to put Second Life in linux package format so we can just link to your repo and have us be able to install and upgrade from our respective package managers, i.e Yum & Apt-Get? * On Thu, Feb 18, 2010 at 12:53, Tayra Dagostino wrote: > On Thu, 18 Feb 2010 13:36:13 +0100 > Carlo Wood wrote: > > > On Wed, Feb 17, 2010 at 02:30:07PM -0500, kow wrote: > > > Snowglobe should work out of the box with VS2005. Emerald and > > > Imprudence are easier options if you're using VS2008. I believe the > > > only issue with VS2008 + snowglobe is boost, and the libs from > > > Emerald or Imprudence can be dropped in to fix that. > > > > One would wonder why Emerald can fix this, and LL can't. > > why ppl don't understand how work a opensource community, and prefer > work on own project in place to work together for a common powerfull > project... > ___ > 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] Client-side scripting in Snowglobe
I haven't been following this topic in any office hours so I hope my comments aren't too off base. Personally I'd prefer to be able to run extensions as sandboxed, and maybe have the option of running them unprotected on a per-extension basis. To me, an environment such as SL or the web in general tend to attract a few malicious developers, or more so, companies and individuals who are interested in collecting personal data and usage patterns. I'd prefer some level of control over what they can access without needing to understand the source code of any scripted extensions (if indeed source was available). Concerning Morgaine's list: while I may not fully agree with reasons 1-4, they appear to reflect valid concerns and are presented in a agreeable manner. Reasons 5 and 6 seem to imply political overtones to me, and I suspect any platform choice will carry some political burden with it. Personally I believe mono to be a reasonable choice for a scripting environment, especially given LL's experience with it in their servers. And now since I don't contribute to the LL viewer source, I'll shut up :) -d On Thu, Feb 18, 2010 at 4:57 AM, Morgaine wrote: > A line got lost from my post owing to finger trouble. Item 6 about Mono > should have read: > > > 6. Some parties identify other reasons for avoiding Mono in general. > Without getting into that subject at all, requiring Mono for client-side > scripting would make scripting unavailable to that portion of the user > base. Since client-side scripting without Mono is perfectly feasible, Mono > should not be made mandatory for scripting, so that the widest user base can > be supported. > > > Morgaine. > > > > > > > > > On Thu, Feb 18, 2010 at 12:42 PM, Morgaine > wrote: > >> I referred recently to Linden's internal project "Firefly" to add >> client-side scripting to SL viewers. This has been the topic of open >> discussion at several Office Hours with Lindens in SL, but that openness has >> not extended to many design details --- the Firefly design process is not >> open to the community. The only technical details that are being disclosed >> about Firefly appear to be: >> >> >>- "Scripts" are actually *Mono assemblies*, so that only languages >>that compile to Mono will be allowed. >>- The programs run in a *sandbox*, which means that most platform >>resources are not accessible to them. >> >> >> Please note that I quite like C# as a language, but the following remarks >> are about Mono use *in the SL viewer*, only, where its tradeoffs are >> poor. >> >> The first known detail about Firefly (mandatory Mono) is problematic on >> several fronts: >> >>1. Only a tiny fraction of the world's applications, libraries and >>languages work on Mono, so client-side scripting will be unable to benefit >>from the huge mountain of resources available on the Internet. This is an >>extremely severe limitation, and an unnecessary restriction in the context >>of client-side viewer scripting. If I want to use a locally-installed >>package X from within my client-side script, I should be able to. What >> runs >>client-side should always be our individual choice, not someone else's. >>2. Programmers want to write client-side scripts in the language that >>they know best, because that always yields the fastest progress and >> highest >>quality results. There was a good technical reason for forcing everyone >> to >>use LSL server-side, but there is no technical reason to impose this >>requirement on all client-side scripting. It is counter-productive to >> force >>CLR compatibility on client-side script developers when there is a simple >>alternative: define a *socket-based viewer API* for client-side >>scripts instead, hence usable from any language. >>3. Mono runs poorly on Linux, so from being rock-solid on Linux now, >>the LL-derived viewers will become second-rate on this platform. >>4. The viewer is already extremely bloated and a memory hog. Adding a >>Mono dependency will compound that horribly. >>5. There is only one effective supplier of Mono: Novell. That is a >>very bad situation to encourage and to support in the viewer. >>6. Some parties identify other reasons for avoiding Mono in general. >> Without getting into that subject at all, >> >> >> The second known detail about Firefly (mandatory sandbox) is problematic >> on two related fronts: >> >>1. Sandboxes by design do not allow most platform resources to be >>accessed, as a security measure. This is fine and important when scripts >>are being downloaded from unknown places (like Javascript in web pages), >> but >>that same protection also means that client-side scripts would be >> powerless >>to do useful things for us in concert with local applications, files, >>devices, etc. Sandboxing client-side scripts effectively hardwires in >>
[opensource-dev] Second Life Package Repo
Moving this to it's own thread... Hey Linden Labs, when are we going to put Second Life in linux package format so we can just link to your repo and have us be able to install and upgrade from our respective package managers, i.e Yum & Apt-Get? This would really speed up the way we handle SnowGlobe. ___ 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] Second Life Package Repo
On Thu, Feb 18, 2010 at 7:08 PM, Jonathan Irvin wrote: > Moving this to it's own thread... > > Hey Linden Labs, when are we going to put Second Life in linux package > format so we can just link to your repo and have us be able to install and > upgrade from our respective package managers, i.e Yum & Apt-Get? This would > really speed up the way we handle SnowGlobe. > Well i'm not from LL, but i have been maintaining Debian and Ubuntu repositories for the more than 2 years. Originaly as a fork viewer known as omvviewer, i'm focusing on snowglobe a lot more now (on the repositories) and have the 1.3 version of snowglobe (well 1.3 SVN + patches i hope to commit to SVN) up and running for testing. So you can apt-get install snowglobe directly from my repository. I'm also a committer to snowglobe and helping with various build and cmake issues are one of the things i have done to help ensure keeping this on a resposotory is as smooth a process as possible. The basic details can be found at http://omvviewer.byteme.org.uk linking to debian and ubuntu (and others) instructions and the package. Although that page is a little out of date as it still talks mostly about omvviewer. Regards Robin ___ 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] Second Life Package Repo
Do we have any ubuntu folks on the list who might consider setting up a PPA? A few years ago (May 2008), I did a bit of work putting together a build system using gar called "garindra". It's totally out of date now, but I learned enough then, and I've learned enough since then about packaging stuff for debuntu, that I can probably make something go. If people care enough to warrant such an effort ;) Cheers, C.J. On Thu, 2010-02-18 at 13:08 -0600, Jonathan Irvin wrote: > Moving this to it's own thread... > > Hey Linden Labs, when are we going to put Second Life in linux package > format so we can just link to your repo and have us be able to install > and upgrade from our respective package managers, i.e Yum & Apt-Get? > This would really speed up the way we handle SnowGlobe. > ___ > 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 signature.asc Description: This is a digitally signed message part ___ 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] Second Life Package Repo
On Thu, Feb 18, 2010 at 7:57 PM, C.J. Adams-Collier wrote: > Do we have any ubuntu folks on the list who might consider setting up a > PPA? > https://launchpad.net/~openmetaverse/+archive/ppa?field.series_filter=karmic But if people want to join in and help with the snowglobe building for ubuntu, you are more than welcome to come and join me. Robin ___ 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] Second Life Package Repo
Does it depend on a different PPA? The following packages have unmet dependencies: snowglobe: Depends: snowglobe-data (= 1.3.1-6) but it is not going to be installed Recommends: gstreamer0.10-plugins-ffmpeg but it is not installable Recommends: gstreamer0.10-pitfdll but it is not installable Recommends: w32codecs but it is not installable On Thu, 2010-02-18 at 20:00 +, Robin Cornelius wrote: > On Thu, Feb 18, 2010 at 7:57 PM, C.J. Adams-Collier > wrote: > > Do we have any ubuntu folks on the list who might consider setting up a > > PPA? > > > > https://launchpad.net/~openmetaverse/+archive/ppa?field.series_filter=karmic > > But if people want to join in and help with the snowglobe building for > ubuntu, you are more than welcome to come and join me. > > Robin signature.asc Description: This is a digitally signed message part ___ 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] Second Life Package Repo
On Thu, Feb 18, 2010 at 8:42 PM, C.J. Adams-Collier wrote: > Does it depend on a different PPA? > > The following packages have unmet dependencies: > snowglobe: Depends: snowglobe-data (= 1.3.1-6) but it is not going to be > installed > Recommends: gstreamer0.10-plugins-ffmpeg but it is not installable > Recommends: gstreamer0.10-pitfdll but it is not installable > Recommends: w32codecs but it is not installable > No snowglobe-data is a dependency and is built off the same snowglobe source? the repository should have everything that is not in a standard karmic release of ubuntu. The recommends are in the full unrestricted ubuntu repository (non-free), as thats got the various win32 codecs and other decoders that are needed if you want to play all video in world via gstreamer. Is it the recommends that are causing the issue here? Robin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > To me, an environment such as SL or the web in general tend to attract a > few malicious developers, or more so, companies and individuals who are > interested in collecting personal data and usage patterns. I'd prefer some > level of control over what they can access without needing to understand the > source code of any scripted extensions (if indeed source was available). > > Dahlia, I agree with part of that, to the extent where it applies: The "malicious users" argument presupposes that scripts come from 3rd parties, some of whom are malicious. When people write their own scripts, which is very common in this opensource-dev community, they are not malicious 3rd parties, and they do not generally want to be treated as such. Quite the opposite, they want all the power that scripting on their local platform can give them. Therefore the "malicious users" argument applies only to a subset of scripts, the downloaded ones, and it is perfectly valid there. However, it does not apply to one's own scripts, nor to any other power-users' scripts that one wishes to trust. This leads directly to a rather fundamental requirement: the sandbox must be optional, applying only to the use case of unknown downloaded scripts, and not applying when the user wishes her scripts to be used as an interface to local facilities. It is considerations such as this that Lindens should be exploring together with the community here, because it impacts on the future of Snowglobe directly and in a colossal way. We are all affected. Designing this behind closed doors is not adequate, nor is it appropriate in an open source community viewer. Morgaine. == On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble wrote: > I haven't been following this topic in any office hours so I hope my > comments aren't too off base. > > Personally I'd prefer to be able to run extensions as sandboxed, and maybe > have the option of running them unprotected on a per-extension basis. To me, > an environment such as SL or the web in general tend to attract a few > malicious developers, or more so, companies and individuals who are > interested in collecting personal data and usage patterns. I'd prefer some > level of control over what they can access without needing to understand the > source code of any scripted extensions (if indeed source was available). > > Concerning Morgaine's list: while I may not fully agree with reasons 1-4, > they appear to reflect valid concerns and are presented in a agreeable > manner. Reasons 5 and 6 seem to imply political overtones to me, and I > suspect any platform choice will carry some political burden with it. > Personally I believe mono to be a reasonable choice for a scripting > environment, especially given LL's experience with it in their servers. > > And now since I don't contribute to the LL viewer source, I'll shut up :) > > -d > > > On Thu, Feb 18, 2010 at 4:57 AM, Morgaine > wrote: > >> A line got lost from my post owing to finger trouble. Item 6 about Mono >> should have read: >> >> >> 6. Some parties identify other reasons for avoiding Mono in general. >> Without getting into that subject at all, requiring Mono for client-side >> scripting would make scripting unavailable to that portion of the user >> base. Since client-side scripting without Mono is perfectly feasible, Mono >> should not be made mandatory for scripting, so that the widest user base can >> be supported. >> >> >> Morgaine. >> >> >> >> >> >> >> >> >> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine < >> morgaine.din...@googlemail.com> wrote: >> >>> I referred recently to Linden's internal project "Firefly" to add >>> client-side scripting to SL viewers. This has been the topic of open >>> discussion at several Office Hours with Lindens in SL, but that openness has >>> not extended to many design details --- the Firefly design process is not >>> open to the community. The only technical details that are being disclosed >>> about Firefly appear to be: >>> >>> >>>- "Scripts" are actually *Mono assemblies*, so that only languages >>>that compile to Mono will be allowed. >>>- The programs run in a *sandbox*, which means that most platform >>>resources are not accessible to them. >>> >>> >>> Please note that I quite like C# as a language, but the following remarks >>> are about Mono use *in the SL viewer*, only, where its tradeoffs are >>> poor. >>> >>> The first known detail about Firefly (mandatory Mono) is problematic on >>> several fronts: >>> >>>1. Only a tiny fraction of the world's applications, libraries and >>>languages work on Mono, so client-side scripting will be unable to >>> benefit >>>from the huge mountain of resources available on the Internet. This is >>> an >>>extremely severe limitation, and an unnecessary restriction in the >>> context >>>of client-side viewe
Re: [opensource-dev] Client-side scripting in Snowglobe
On Thu, Feb 18, 2010 at 5:27 PM, Morgaine wrote: > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble > wrote: >> >> To me, an environment such as SL or the web in general tend to attract a >> few malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). > > Dahlia, I agree with part of that, to the extent where it applies: > > The "malicious users" argument presupposes that scripts come from 3rd > parties, some of whom are malicious. When people write their own scripts, > which is very common in this opensource-dev community, they are not > malicious 3rd parties, and they do not generally want to be treated as such. > > Quite the opposite, they want all the power that scripting on their local > platform can give them. Therefore the "malicious users" argument applies > only to a subset of scripts, the downloaded ones, and it is perfectly valid > there. However, it does not apply to one's own scripts, nor to any other > power-users' scripts that one wishes to trust. > > This leads directly to a rather fundamental requirement: the sandbox must > be optional, applying only to the use case of unknown downloaded scripts, > and not applying when the user wishes her scripts to be used as an interface > to local facilities. > > It is considerations such as this that Lindens should be exploring together > with the community here, because it impacts on the future of Snowglobe > directly and in a colossal way. We are all affected. Designing this behind > closed doors is not adequate, nor is it appropriate in an open source > community viewer. > > > Morgaine. > > > > and this is where languages like perl/python have a strength since the files are plain text so if you think that a script is doing something funky you can just look at the script and see. Mono/dotnet code is compiled and very easily could hide just about anything. -- Robert L Martin ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
On 2/18/10 7:57 AM, Kent Quirk (Q Linden) wrote: > I've been trying to have an open discussion about some of the design > issues in my office hours, specifically to understand the constraints > and requirements of the community. But every office hour seems to be > followed up by flames on this list and in other forums interpreting what > was said in the worst possible way. Could you please post the transcripts of your office hours? The newest I see for you is http://wiki.secondlife.com/wiki/User:Q_Linden/Office_Hours/2008-01-07 Thanks! + poppy ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Client-side scripting in Snowglobe
B-B-But what about Lua, which has already been implemented in FlexLife (http://flexlife.nexisonline.net)? :( Fred Rookstown Lead Developer On Thu, 2010-02-18 at 12:42 +, Morgaine wrote: > I referred recently to Linden's internal project "Firefly" to add > client-side scripting to SL viewers. This has been the topic of open > discussion at several Office Hours with Lindens in SL, but that > openness has not extended to many design details --- the Firefly > design process is not open to the community. The only technical > details that are being disclosed about Firefly appear to be: > > * "Scripts" are actually Mono assemblies, so that only languages > that compile to Mono will be allowed. > * The programs run in a sandbox, which means that most platform > resources are not accessible to them. > > Please note that I quite like C# as a language, but the following > remarks are about Mono use in the SL viewer, only, where its tradeoffs > are poor. > > The first known detail about Firefly (mandatory Mono) is problematic > on several fronts: > 1. Only a tiny fraction of the world's applications, libraries > and languages work on Mono, so client-side scripting will be > unable to benefit from the huge mountain of resources > available on the Internet. This is an extremely severe > limitation, and an unnecessary restriction in the context of > client-side viewer scripting. If I want to use a > locally-installed package X from within my client-side script, > I should be able to. What runs client-side should always be > our individual choice, not someone else's. > 2. Programmers want to write client-side scripts in the language > that they know best, because that always yields the fastest > progress and highest quality results. There was a good > technical reason for forcing everyone to use LSL server-side, > but there is no technical reason to impose this requirement on > all client-side scripting. It is counter-productive to force > CLR compatibility on client-side script developers when there > is a simple alternative: define a socket-based viewer API for > client-side scripts instead, hence usable from any language. > 3. Mono runs poorly on Linux, so from being rock-solid on Linux > now, the LL-derived viewers will become second-rate on this > platform. > 4. The viewer is already extremely bloated and a memory hog. > Adding a Mono dependency will compound that horribly. > 5. There is only one effective supplier of Mono: Novell. That > is a very bad situation to encourage and to support in the > viewer. > 6. Some parties identify other reasons for avoiding Mono in > general. Without getting into that subject at all, > > The second known detail about Firefly (mandatory sandbox) is > problematic on two related fronts: > 1. Sandboxes by design do not allow most platform resources to be > accessed, as a security measure. This is fine and important > when scripts are being downloaded from unknown places (like > Javascript in web pages), but that same protection also means > that client-side scripts would be powerless to do useful > things for us in concert with local applications, files, > devices, etc. Sandboxing client-side scripts effectively > hardwires in script weakness for no reason discussed as a > requirement. > 2. Sandboxed applications cannot be linked with user-chosen > native libraries since allowing native code breaks sandbox > protection. This means no accelerators, no extensions, and no > interop with other systems since sockets are inaccessible from > any strong sandbox. This also means no evolution or progress > outside of what the sandbox designers permit. > > This mailing list is concerned with development of open source > viewers, in particular Snowglobe. This is heralded as a community > viewer, embodying community requirements much more directly than the > LL mainstream viewer. Client-side scripting will impact on every > single aspect of Snowglobe bar none, yet the community is being > excluded from the design of its most powerful infrastructure element. > This is entirely wrong, far beyond the normal observation > that secrecy in design has no place in open source. > > It is hard to assess things technically when the design requirements > are formulated in secret. The Snowglobe community has design > requirements too. Those deserve to be examined here openly, not > limiting Snowglobe to a design that stems from Linden requirements > alone. > > > Morgaine. > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Plea
Re: [opensource-dev] Client-side scripting in Snowglobe
I suspect that there are two things being discussed here without distinction: Client scripting, and client extensions. Confusing the two is easy. Client-side scripting SHOULD be sandboxed, and in a controlled set of languages. For a close example think of javascript in web browsers. Client extensions, or alternatively named as "plugins", would be modules that can be plugged in and out of the client and run /as if/ they were a part of the client. Think of browser add-ons/plugins/extensions. Client side scripts could (read might be, could possibly, needs further thought, etc.) be given permission to be loaded in by worn items automatically. Other objects would likely need to request permission via a security warning. Client extensions would have to be downloaded and installed externally; not delivered in-world. These would truly be programs on your computer, and should be treated as such. Just my thoughts hoping for a clearer discussion. Ricky Cron Stardust On Thu, Feb 18, 2010 at 2:27 PM, Morgaine wrote: > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble > wrote: > >> To me, an environment such as SL or the web in general tend to attract a >> few malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). >> >> > Dahlia, I agree with part of that, to the extent where it applies: > > The "malicious users" argument presupposes that scripts come from 3rd > parties, some of whom are malicious. When people write their own scripts, > which is very common in this opensource-dev community, they are not > malicious 3rd parties, and they do not generally want to be treated as such. > > Quite the opposite, they want all the power that scripting on their local > platform can give them. Therefore the "malicious users" argument applies > only to a subset of scripts, the downloaded ones, and it is perfectly valid > there. However, it does not apply to one's own scripts, nor to any other > power-users' scripts that one wishes to trust. > > This leads directly to a rather fundamental requirement: the sandbox must > be optional, applying only to the use case of unknown downloaded scripts, > and not applying when the user wishes her scripts to be used as an interface > to local facilities. > > It is considerations such as this that Lindens should be exploring together > with the community here, because it impacts on the future of Snowglobe > directly and in a colossal way. We are all affected. Designing this behind > closed doors is not adequate, nor is it appropriate in an open source > community viewer. > > > Morgaine. > > > > > > == > > > On Thu, Feb 18, 2010 at 7:07 PM, Dahlia Trimble > wrote: > >> I haven't been following this topic in any office hours so I hope my >> comments aren't too off base. >> >> Personally I'd prefer to be able to run extensions as sandboxed, and maybe >> have the option of running them unprotected on a per-extension basis. To me, >> an environment such as SL or the web in general tend to attract a few >> malicious developers, or more so, companies and individuals who are >> interested in collecting personal data and usage patterns. I'd prefer some >> level of control over what they can access without needing to understand the >> source code of any scripted extensions (if indeed source was available). >> >> Concerning Morgaine's list: while I may not fully agree with reasons 1-4, >> they appear to reflect valid concerns and are presented in a agreeable >> manner. Reasons 5 and 6 seem to imply political overtones to me, and I >> suspect any platform choice will carry some political burden with it. >> Personally I believe mono to be a reasonable choice for a scripting >> environment, especially given LL's experience with it in their servers. >> >> And now since I don't contribute to the LL viewer source, I'll shut up :) >> >> -d >> >> >> On Thu, Feb 18, 2010 at 4:57 AM, Morgaine > > wrote: >> >>> A line got lost from my post owing to finger trouble. Item 6 about Mono >>> should have read: >>> >>> >>> 6. Some parties identify other reasons for avoiding Mono in general. >>> Without getting into that subject at all, requiring Mono for client-side >>> scripting would make scripting unavailable to that portion of the user >>> base. Since client-side scripting without Mono is perfectly feasible, Mono >>> should not be made mandatory for scripting, so that the widest user base can >>> be supported. >>> >>> >>> Morgaine. >>> >>> >>> >>> >>> >>> >>> >>> >>> On Thu, Feb 18, 2010 at 12:42 PM, Morgaine < >>> morgaine.din...@googlemail.com> wrote: >>> I referred recently to Linden's internal project "Firefly" to add client-side scripting to SL viewers. This has been the topic
