Your2ndPlace

After Konner posted on the halt of the Exchanges, Ciaran hit the nail on the head about the silence of Linden Lab on the topic. I've been following it with interest, trying to nail down exactly how the exploit occurred, when I found it in my email - I'm withholding the person's name at this point, but I can share that the information has been disseminated to the exchanges.

Basically, how the exploit worked was through fooling the simulator into allowing someone to rez something of the same Object ID - or key. Allegedly, this exploit affects Second Life Server 1.22.4.90499, and a rolling restart will solve it once the server software is updated. It appears that this has already begun. It should be noted that this exploit required a special tool from LibSecondLife, one that was kept quiet but which someone (obviously) leaked. For the more technical folks, a modification to SLProxy made this possible.

In all, Linden Lab probably should have said something but didn't - something that is par for the course when it comes to the virtual world of Second Life. It did not just affect ATMs, it also affected other objects as well. The good news is that even with the exploit, items received through the exploit got the same permissions as the owner dictated - thus, a no copy/no mod/no transfer item would remain a no copy/no mod/no transfer item, with only the person who used the exploit getting a copy.

Konner McDonnell was kind enough to email me a few links to look at regarding yesterday's news of the successful teleportation between Second Life and OpenSim. While, at a simple technical level, this is no big deal - logging an avatar onto a secondary grid - the architecture cooperation is noteworthy.

One can log in to multiple websites on the Internet with the same username; it stands to reason that the same should be true of virtual worlds. The difference, of course, is in the assets - something which was apparently not addressed in the teleportation... yet. Basically, IBM and Linden Lab had a handshake across their virtual worlds to verify that the systems could communicate. While the technical details require more digging to understand how this happened, the week old Linden Lab blog entry pretty much explains that this is only for logging in and teleportation. The real test will be the asset server.

And so, one's avatar will be hopping grids in the not too distant future. That sounds fun and interesting on the surface, but it also brings with it new problems that have to be looked into:

• Security: Soon, your password for your avatar will become that much more important as it leaves the Second Life sandbox and goes forth to brave new virtual worlds.
• Names: Naming limitations in one world may not exist in another. While this may not be a big deal for some, it can be a very big deal for others. Like Pighed.

As a few people within the virtual world of Second Life know, I've been busy in the real world dealing with real land - running roads into otherwise accessible property, planting trees and so on, dealing with the mess of the legalities and procedures of real land. One thing I have learned is that real estate in Second Life is much more easier to contend with.

The other thing I have learned, having been logging in less, is that I don't want to have to download a full client every time I want to log in - and that seems to be par for my log ins these days. Sure, it may be relatively fast but come on... - Second Life, as a virtual world, has reached a point where downloading an entire client to log in is not only a pain, it's... avoidable.

Consider patches. I'm not saying that downloading patches is a silver bullet, but it would probably help a lot with server loading as well as the annoyance I feel when I encounter the 'download new client' dialog when I'm logging in. It annoys me enough to write about it, so I wonder how even more casual users than I feel about it. I imagine it's less than pleasant.

As a software developer with a reasonable amount of experience, I think it's time for the update process to grow up. As a user, I think it's time for Linden Lab to recognize that the issue itself is something that might actually keep people from popping into Second Life. I mean - every time I turn around, I'm piping 30 megs of data down through about 10 servers.

I had said that I would be upgrading the site around the middle of the month, but I have found a few issues in the code that I need to address prior to a switchover - and real life has me a bit fragmented right now.

For now, I'm putting all the upgrades on hold because I am awaiting some dependencies to be updated (and may be helping with that). I won't promise a date, but I will say that I am expecting the changes to happen before the end of this month - and with sufficient quality assurance I'll toss the upgrades on to the site quite quickly.

Humble apologies - this is really on me; I tripped over some things that I should have planned for. Lesson learned. :-) Please bear with me, I do have a froody new look and feel to Your2ndPlace.com that does work very nicely, but to implement it will take a little more time.

I probably missed this being scribbled on a bathroom wall somewhere in <insert someone with Linden Lab hookups>'s house, but... I just went nuts looking for the 'send movie to disk' option. I searched high and low, since I actually wanted to catch something on video - machinima - and it wasn't there.

After about 15 minutes, I ended up at JIRA VWR-2096, more descriptively titled Movie to disk causes crash. Why did I get there? Because of what is written here:

...We've decided (see VWR-2096^[c] for details) to remove the built-in movie recorder in favor of numerous, better 3rd-party tools...

Argh. So, I guess I'll be using Taksi.

But guess what? Now the viewer is crashing for me when it never did with the Second Life viewer. And I'm not sure which codecs give the best compression.

*sigh*

Update: It's all settled down and features are back online, but the article remains the same...

While the temporarily reduced services within Second Life are just a bit inconvenient, but 2 things impress me about it:

1. They decided to scale things down to make things more stable. That's progress.
2. They wrote about it on the blog.

Sure, it isn't something to write home about, but throttling functionality like that is pretty old school - under heavy load, any decent website throttles functionality to assure the site doesn't crash. It makes sense to do it in Second Life - frankly, I'm surprised it isn't automated. That way they could scale down things, send out system announcements like a weather report, and people would get used to it. Granted, people may not like it but then it s a bit like the weather: there are good days and bad days.

I'm interested to see if they do decide to put some throttle functionality in the server code. It just makes sense.

I am considering how to give Second Life 'weather reports'. Heh.

Update: SLPics is back up. Post them pics!

Sarah got me hooked on SLPics a while back, and it has been working for me during that time quite well. Unfortunately, today it wasn't posting images so I decided to go have a look at the site and found a database error.

For those of you who look at it and don't have a clue what you're staring at, here's what all of that means: The database is not accessible right now. A lot of websites have their databases on separate web servers; this allows hosting providers to have servers specifically for databases.

Granted, I don't think that Microsoft SQL Server is worth spit (I prefer MySQL for most web related stuff and PostGreSQL for the harder stuff), but it does usually work and it doesn't seem that the name Microsoft has much to do with the fault at SLPics.com. It's a hosting issue.

I'm sure it is only temporary, but if you're using SLPics with Flickr, as I do, you might want to go back to saving your screenshots to your hard drive and uploading them to Flickr manually.

It's the internet. We just route around problems. ;-)