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?
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.
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.
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.
Still, all of the above problems could be fixed and redesigned away
without having to break anything at the user's level.
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.
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.
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.
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.
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.
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.
Wade
On 2/17/12 1:18 AM, Toni Alatalo wrote:
On Feb 17, 2012, at 9:00 AM, Drew Hart wrote:
money. The whole world is built on *old, inefficient code*, and if
Linden tries to update it those virtual objects can break, triggering
massive backlash from buyers and sellers." (Emphasis mine)
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
I'd dare to say: yes. With some reservations.
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.
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.
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.
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.
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.
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.
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.
Drew
2cently yours,
~Toni
http://techcrunch.com/2012/02/16/littletextpeople/
_______________________________________________
Opensim-users mailing list
[email protected] <mailto:[email protected]>
https://lists.berlios.de/mailman/listinfo/opensim-users
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
_______________________________________________
Opensim-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/opensim-users
