[sldev] Re: Feature freeze

Paul Oppenheim (Poppy) poppy at lindenlab.com
Tue Apr 8 11:07:48 PDT 2008


Jim Purbrick (Babbage) wrote:
> In fact, this isn't an either or choice. Arguably the biggest benefit of 
> Mono is that it gets us a more stable, tested and secure VM. For example 
> SEC-53  is a simulator crash bug on the LSL runtime, but it causes an 
> exception to be thrown in the Mono runtime, and is caught at compile 
> time by the Mono bytecode verifier. At the moment we're trying to 
> implement post hoc verification of LSL bytecode to fix these problems, 
> but it's finger in the dyke work and it's extremely unlikely that LSL 
> bytecode is completely verifiable. The CIL bytecode that runs on Mono is 
> verifiable by design. ECMA-335 describes the algorithm and the 
> requirements for each opcode. The Mono bytecode verifier is in active 
> development and will be heavily used by Moonlight to run untrusted CIL 
> in browsers.

Thank you for clarifying the specifics with Mono, I just needed to grab the nearest big-project-that's-bringing-stability and found mono. You're right, that's my point. It isn't an either/or choice with anything out right now. Everything lately has a large stability component. Until we release something that doesn't have a large stability or performance component, the "no new features / feature freeze" argument is a strawman.

> Mono may look like a shiny new feature, but it's arguably a better route 
> to stability and security than freezing LSL and fixing bugs in the 
> existing runtime.

And thank you for it! :D

+ poppy



More information about the SLDev mailing list