SSA Context

The week of May 26 to June 1 Oz Linden checked and reported that 1,665 different viewer versions that logged into Second Life™. That is an approximation of the number of different viewers in use. The SL system records viewer version strings. Each version of a viewer is to have a unique ID string. But, this is open source and people do whatever they do. So, there is a probability some ID strings don’t get changed. Thus I say approximate.

Viewer Production

Viewer Production

Some of these versions are one user only viewers, meaning: someone compiles a viewer for their own amusement and use. They never distribute the version. They may or may not change the version string.

Then there are the griefer viewers. They try to imitate other viewers and may duplicate another viewer’s version string to hide.

The result is going to be more viewer versions than the system recognizes. 

What This Means

When the Lab makes a change like Server Side Appearance (SSA) they test it for compatibility with the viewers the Lab plans to be in use; the current Release Viewer, the Beta Viewers, the Project Viewers, and Development Viewers not yet public.

That leaves about 1,661 viewers untested. There isn’t enough staff at the Lab to test all those older versions, much less fix the code to be compatible with all of them. Of course third party developers test their current work. But, they too do not have the people or time to test all their versions. So, this is going to leave something like 1,600+ viewers that will never be tested with the SSA corruption problem. (See: SSA Coming Not Too Soon)

That means whatever viewer you are using has about a 65 in 1,665 chance of being tested. Or 1 in 26 or 4% chance of being tested.

Solution

Update your viewer.

What is being done?

The charts show Linden production of viewer builds. My assumption is that the build number is sort of a count of the number of builds. Even if the assumption is right, the data is not very accurate nor do the charts accurately portray how many iterations of the viewer are being built. But, I think they are a rough measure of what is going on.

We can see that during the later part of 2012 while the Lindens struggled to find a memory leak that was crashing the viewer the build rate went down. That probably signifies more time thinking, researching, experimenting, and writing code than actually compiling viewers.

Each minute that the Lab would spend resolving this problem delays a feature or bug fix. If everyone just updated their viewer, they would not need to worry about the asset corruption problem. With refurbished computers on eBay and Geeks.com it isn’t that expensive. But, with 5 million people having dropped out of the US labor force (which lowers the unemployment rate making it look better)  and welfare payments becoming the largest item in the Federal budget with 1 in 3 Americans now getting some type of assistance, there are people that have enough of a problem buying food much less spending $100 for a refurbished Core2 computer. I skip seniors and fixed budgets and their increasing medical costs.

So, the problem of old computers and viewers is not going to go away. That means the Lab has to make a call to fix the asset corruption problem and burn time needed for other projects or hope everyone will update and keep moving forward.

It’s not an easy decision… way too many factors to consider. A major factor being whether or not the corruption problem can be fixed. As yet they don’t know that it can. While with infinite resources and time anything can be fixed, the Lab doesn’t have the luxury of infinite resources.

I think that the Lab is going do all it can to fix the problem. Oz says they will do all they can. I read into that the words ‘within reason.’ That will create lots of drama as people will have a different sense of what’s in reason. But, it is a significant problem that they cannot find a way to reproduce the problem reliably. That means it will be hard, if not impossible, to try and fix the problem.

That this problem will affect so few people is also a criteria. There are other problems that are affecting large numbers of people. How much time does one spend on a rare but painful problem? Especially when there is a simple fix available; update to a newer SSA enabled viewer. It’s a judgment call and people will disagree with whatever the Lab decides.

For now the Lab is trying to find a way the reliably reproduce the problem and then move on to a fix. They are very concerned about asset corruption. But, even if they do find a fix of which they are 100% certain is ‘the fix’, they still won’t know if the fix works for all 1,665 viewers. So, they are not going to spend months waiting for a fix. I’m guessing there may be a week or two window then the Lab will move on.

The concern is so high in the Phoenix-Firestorm team that they are discussing blocking the Phoenix viewers. That is pretty much a lose-lose proposition for the FS team. But, if the Lab cannot find a fix, I think it is likely the viewer will be blocked by the FS-Team. It isn’t their first choice. But, what does one do?

Remember. There are large numbers of people that just log into SL and never pay any attention to what is going on. Only when they have a problem do they look to see what is up. Does the FS-Team let the oblivious walk into a situation where they corrupt their assets? I doubt the team will take that path.

It will be interesting

Summary

Mitigate the problem.

Update to an SSA enabled viewer.

6 thoughts on “SSA Context

  1. “That means whatever viewer you are using has about a 65 in 1,665 chance of being tested. Or 1 in 26 or 4% chance of being tested.”

    The situation is a lot better than that. Most of the residents use one of the last two or three versions of an official viewer or TPV. And if you take Phoenix users out of the equation it is even better odds. Linden Lab have blocked all except half a dozen versions of their release viewer, so that just leaves private versions of it, project viewers and old dev viewers – generally the stuff used by people like me who are fully aware of all this SSA stuff.

    Incidentally I believe the 1665 versions referred to by Oz referred to versions of the Linden Lab produced viewer – not versions of TPVs, so there are many more. The bigger problem may be with users of these older TPV versions, because they are not blocked and the nagging/forcing to update your viewer is not as strong.

  2. I am not sure why the lab is investing a minute of time to fix and issue in Phoenix. The viewer is not supported by its own development team. The Phoenix/Firestorm team needs to step up and use the tool they already have in Phoenix to block the viewer from connecting to Second Life. Its time to enable SSB, and its time leave the older viewers behind.

  3. I see a problem. SSA should not write back to the actual asset, even if mod is enabled. It’s not worth it to fix things for ancient viewers that should be retired; it is worth it if SSA is writing to things it should not, which could lead to assets being damaged when using up-to-date viewers.

    • As I understand it. the SSA doesn’t rewrite the assets. Something in the viewer does. But, it is something in the new process that triggers the viewer to think it should rewrite the asset and the asset server allows it.

  4. “If everyone just updated their viewer, they would not need to worry about the asset corruption problem.”

    Wouldn’t that be nice ? Some of the people still relying on Phoenix would love to update to a V2/V3 viewer, either official or 3rd party. But they can’t because Linden Labs has produced a viewer that is unusable by visually handicapped people and thus far TPV developers have simply failed to make up for this discrimination by the lab, even though they tried.

    • There are other choices that are SSA capable. Singularity and Cool VL Viewer both provide the ability and have a V1 type user interface. So, yours is not a valid excuse.

Leave a Reply

Your email address will not be published. Required fields are marked *