Reno/Tahoe area resident here. Oh yeah, +1 for Reno :-)
While there has long been a surprisingly sizable population of engineering professionals living in and working OUT of the area, over the last few years an enthusiastic startup business culture has emerged.
There are multiple incubator / co-working facilities, a convenient airport, beautiful environment and as you note, a favorable tax structure.
Tesla, along with the gaming and defense industries, should really be just anchor businesses in a much deeper technology ecosystem. Reno very much has this potential.
The SUN workstation-wielding guy in the lab next door to me got hit by this, though we were unscathed. Periodically you could hear him yelling through the wall.
Amusingly (in hindsight), I had recently cleaned up a bunch of virus-choked PCs in some student labs and because of this fell under departmental suspicion (very briefly) of having something to do with these new problems. From then on I left such thankless scut work to someone else.
Another interesting -though brief- account appears in the epilogue of Cliff Stoll's "Cuckoo's Egg" (itself a classic tale from the early Internet days).
Ah, but that would require support for mesh-built objects, no? Second Life mesh support is promised RSN.
OpenSim has some mesh support, but is I think, somewhat hobbled by SL compatibility concerns.
I've never tried Second Life, but I'd be very surprised if they're not representing shapes internally as some kind of 3D mesh: it's an important technique for getting decent performance on modern graphics cards. If they are doing that, then that's sufficient for them to be able to do automatic LOD calculations too.
Maybe not failed as such, but I'd agree with the author that SL tech has suffered an apparent stagnation for a quite a while now. Indeed there has been a long festering complaint on SecondLife forums that Linden Lab has added various sugary features without addressing core performance concerns. This may or may not be fair, but that seems to be the general impression.
Large draw distances, high particle & script counts and more than a few dozen avatars in a single region all tend to result in poor performance and user experience. And the platform appears to be quite sensitive to the usual concerns of bandwidth and GPU. As a longtime SL user I'm not surprised at the issues described by the author.
Linden Lab itself has seen a number of shaky management changes (founder + CTO out, new CEO, founder back, founder out again, etc) and this may have taken some toll on engineering efficacy.
That being said, I think that innovation on the SecondLife platform will be forced by pressure from the furiously advancing OpenSim project, an open source, reverse-engineered version of the SL "backend" that is usually described as "the Apache of the open metaverse".
http://opensimulator.org/
Basically, SecondLife, though filled with an amazing amount of wonderful art, code and creativity, won't last another 8 years without somehow opening up and keeping up with the explosion happening just outside its walled garden.
I've found the key value-based redis to be very easy to use, powerful and well-documented. Redis also seems to fit in well with the async nature of node.js apps.
While it's mostly known as an in-memory store, redis also has a virtual-memory option which can be useful when you have a (relatively) small number of keys -all of which can fit into memory- that are associated with much larger values which cannot fit into memory. Sure, there is a swap cost, etc, but I found this to be quite acceptable for a small sync server app I'm building (after prototyping with MongoDB and SQLite).
