[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