Having been using LSL since 2005, I can say that this argument about 'backward' compatibility holding things has bee used often, even then. So it is often used to shift blame.<div>I personally believe that the real issue is that as new requirements emerge while working within this specific domain, we hit totally new problems that are not faced by the other list of languages often mentioned as being better than LSL. LSL does have many problems, especially trivial and annoying ones, even at the level of syntax which makes coding confusing ... LSL's front end could be preserved so that content does not break, the back end could be optimized etc... / re implemented. </div>
<div>Sometimes, visiting places showcased by Linden Lab as recent as yesterday, also illustrates how we are still far for a really pleasant experience in SL.</div><div>It appears to me that SL allows a lot more than can be done at the level of granularity of interactions, and building of content. It feels like VRML ... in the last stages before nobody talked about it .. I can only hope that there are better engineers at LL working secretly on the problems we all concerned about on the exterior. Which is pretty unlikely, but I hope this is case.<br>
<br><div class="gmail_quote">On Fri, Feb 17, 2012 at 2:56 AM, Wade Schuette <span dir="ltr"><<a href="mailto:wade.schuette@gmail.com">wade.schuette@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
I imagine that, aside from coding language, the rest of the
architecture and database design are equally adhoc, were great at
the time as one of those "temporary solutions" that LL outgrew
rapidly. Are they running MySQL under the covers?<br>
<br>
The asset server has clearly bogged down and probably the tables are
incredibly fragmented but I don't think they have the ability to
defrag them, or recognize the problem for what it is. Whatever it
is certainly didn't scale well or age well, and clearly has no
transaction control so things get lost routinely. <br>
<br>
A monolithic non-distributed design, implemented on a cloud of
servers, is an astoundingly poor use of resources. The whole
busy/idle problem is as well, where 100 avatars can work fine one
per sim, but if they all come together that one cpu stops while 99
cpu's are idle. Easily 95% of the computing power of the
server farm is wasted.<br>
<br>
The "silos with messaging" approach to growth also results in the
total chaos when anyone or anything simply attempts to move from one
sim across a boundary to the next sim. <br>
<br>
Still, all of the above problems could be fixed and redesigned away
without having to break anything at the user's level. <br>
<br>
I think their largest constraint on growth IS somewhat more deeply
embedded in code, which is their data structures for "objects" that
have only a single level of linking. Once you link those
"wheels" to the "car" there are no "wheel" objects any more, and God
help you if you want to change the tires. <br>
<br>
Also the way the code is implemented discourages building with
distributed intelligence among the parts, and encourages monolithic
scripts that run everything from the root prim. More than once
I've tried to do a clean distributed intelligence object and given
up and gone back to central scripts. <br>
<br>
Overall, I suspect that, as always, "the work of the hands reflects
the state of the heart." Their management style involves silos of
teams that may message each other but don't cross boundaries well,
with massive central control that limits creativity and makes
changes have to be prohibitively huge and staged instead of
incremental and continuous. <br>
<br>
As near as I can tell the whole architecture is on "milking status"
with effective freeze on putting money into fixing things such as
the Marketplace, which is clearly in a different silo than the
developers. <br>
<br>
It's like a piston-driven internal combustion engine -- which is way
better than the horse drawn carts before it, but now that the market
has been developed, is seen to have no change of being "tweaked" to
match the new turbine-engined designs of next year with true
distributed intelligence and scalable growth without performance
disaster.<br>
<br>
In fact, if a single thing defines their limits, it's an
architecture where, the more servers are added to the mix, the
HARDER it becomes to operate at any kind of reasonable speed or
accuracy. Their help desk is massively overwhelmed already and must
pray for the number of users to stop growing. One can imagine an
architecture with the opposite property, where every new user and
server chips in a little more capacity and actually increases
performance and ability to do self-healing quality control. <br><span class="HOEnZb"><font color="#888888">
<br>
Wade</font></span><div><div class="h5"><br>
<br>
<br>
On 2/17/12 1:18 AM, Toni Alatalo wrote:
<blockquote type="cite">
<div>
<div>On Feb 17, 2012, at 9:00 AM, Drew Hart wrote:</div>
<blockquote type="cite">
<div><span style="line-height:20px;text-align:left;font-size:14px;font-family:helvetica,arial,clean,sans-serif">money.
The whole world is built on <b>old, inefficient code</b>,
and if Linden tries to update it those virtual objects can
break, triggering massive backlash from buyers and
sellers." (Emphasis mine)</span></div>
<div><span style="line-height:20px;text-align:left;font-size:14px;font-family:helvetica,arial,clean,sans-serif">I
am just curious - is this statement true? Is it true of
Open Sim? I feel like it's not true, but I am curious for
comment. And are we sacrificing quality to ensure
backwards compatibility? I guess this is a philosophy</span></div>
</blockquote>
<div><br>
</div>
<div>I'd dare to say: yes. With some reservations.</div>
<div><br>
</div>
<div>Rationale: for example LSL itself, at least the current
implementations of it, are AFAIK relatively inefficient. Not
to mention not the greatest nor best known language around,
with third party libraries etc. The LLUDP protocol is another
problem point, but I'll focus on the scripting here as that's
what your post seemed to refer to.</div>
<div><br>
</div>
<div>If you compare LSL with a completely from the scratch
approach, where you would drop all concerns for backwards
compatibility, you could use either Javascript and the
powerful optimized V8 engine for it (used in Chrome and in
many places that embed js now) or for example Lua which has
gotten really popular in games, and is fast and light.</div>
<div><br>
</div>
<div>The reservations: I'm sure both SL and Opensim backends
have done good things to optimize things e.g. in the script
engines. Linden has been working on their viewer too etc.
Usually it is possible to optimize, clean up implementations
etc. while still keeping backwards compatibility. I don't mean
to belittle that work nor say that it would be impossible.
There might be some weird things with LSL that prevent some
cleanup / optimization for backwards compatibility reasons but
I'd guess those points are rare.</div>
<div><br>
</div>
<div>Anyhow my bet is that LSL will never beat V8, with the huge
Google effort, nor Lua with the nice clean design that also
allows great speed (with LuaJIT2) , in quality -- considering
both the niceness of the langs and the efficiency of
execution.</div>
<div><br>
</div>
<div>C# scripting for SL seemed promising in Babbage's demo and
that would be plenty nice and fast, though. And with Opensim
you get that efficiency by writing region modules.</div>
<div><br>
</div>
<div>In realXtend with the Tundra SDK we've been now pursuing
the approach where dropped most our the legacy (slviewer and
opensim) alltogether, compatibility as well. So there at least
you have something to compare with: a nice clean efficient
system, but with no SL compatibility. If someone is interested
we can do benchmarks, just tell what to test & we'll
report :) We currently use JS for apps (not V8 now though but
there's a branch of qtscript with which we can get that) and
may test Lua too. My wish is that we are still a humble part
of the opensim community, even though use different
technologies -- alternative tools that suite different
purposes are good to have around.</div>
<div><br>
</div>
<div>And the fact that all you out there in the big world use
Opensim happily and can't e.g. switch to Tundra is a perfect
example why backwards compatibility is a big deal :) We here
just have often cases where legacy doesn't matter, some new
game or customer project where need to make a custom app,
perhaps with no SL like functionality at all, so in those
cases it's not a prob and we can pursue this route.</div>
<div><br>
</div>
<blockquote type="cite">
<div><span style="line-height:20px;text-align:left;font-size:14px;font-family:helvetica,arial,clean,sans-serif">Drew</span></div>
</blockquote>
<div><br>
</div>
<div>2cently yours,</div>
<div>~Toni</div>
<br>
<blockquote type="cite">
<div><a href="http://techcrunch.com/2012/02/16/littletextpeople/" target="_blank">http://techcrunch.com/2012/02/16/littletextpeople/</a>
</div>
_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
<pre>_______________________________________________
Opensim-users mailing list
<a href="mailto:Opensim-users@lists.berlios.de" target="_blank">Opensim-users@lists.berlios.de</a>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a>
</pre>
</blockquote>
<br>
</div></div></div>
<br>_______________________________________________<br>
Opensim-users mailing list<br>
<a href="mailto:Opensim-users@lists.berlios.de">Opensim-users@lists.berlios.de</a><br>
<a href="https://lists.berlios.de/mailman/listinfo/opensim-users" target="_blank">https://lists.berlios.de/mailman/listinfo/opensim-users</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><font color="#999999">'Consider how the lilies grow. They do not labor or spin.'</font><br><b>Rameshsharma Ramloll</b> PhD, <i>Research Associate Professor</i>, Idaho State University, Pocatello, ID 83209 Tel: 208-282-5333<br>
<div><a href="http://deepsemaphore.posterous.com/" target="_blank">Blog</a>, <a href="http://www.linkedin.com/in/rameshramloll" target="_blank">LinkedIn</a>, <a href="http://www.play2train.org" target="_blank">Play2Train</a></div>
<br>
</div>