Tag: SL News

Breaking the Viewers

Posted on by Inara Pey

As Tateru Nino points out, Oz Linden issued a stark warning yesterday when commenting on third-party Viewers (TPVs): “[A]ny Viewer that isn’t being actively maintained is going to start having fairly serious problems over the next months. We’re making a lot of changes… if viewers don’t keep up, things will break.” 

Now, Oz isn’t the most diplomatic of individuals, it has to be said; but a lot of people seem to be getting unnecessarily bent out of shape in response to his comments, apparently reading them as “You must swap to Viewer 2!” – which is certainly not what is being said.

Rather, he is pointing to the fact that with all that is coming down the line, there is a risk that some Viewer devs (particularly those working with the Viewer 1 / Snowglobe code who have to backport everything) may find their Viewers becoming obsolete. And his comment may well have merit.

While it is true that much of what has been developed for Viewer 2 has been backported to Viewer 1 TPVs (Display Names, multiple clothing layers, Avatar Physics, etc.), it is by no means certain that this will be possible going forward. for example, LL have already stated that Mesh objects will not render in Viewer 1, so it’s by no means clear if the code required to enable meshes to be visible can be integrated into the older Viewers. Similarly, they’ve also stated that the “Search 1” used by Viewer 1 is to be turned off at some point this year – leaving TPVs based on the code either without a search engine or needing to try to integrate with the Search used by Viewer 2. Therefore, there is a risk associated in staying with the Viewer 1 code base.

The Popularity Stakes

In the same meeting, Oz went on to say, “[T]that being said, we’re looking hard at what motivates people to stay on a 1.x viewer so that we can try to address those issues too,” a comment that was also met with a certain amount of derision, with people pointing to things like “usability”, performance and features as the major reasons why Viewer 2 “isn’t working”.

Much has been made of the Viewer 2 UI being “unusable”. At the risk of offending some, I think it fair to say this view is more reflective of people’s unwillingness to accept Viewer 2’s UI than it is of the usability of the interface.

Yes, there are quirks, annoyances, and things within the UI that could be a better than currently implemented – but none of them render the UI “unusable”. The fact is that *if* the Viewer 2 UI had been the de facto  UI for the last 4 or 5 years, and was now being replaced by the Viewer 1.x UI, many of those decrying the Viewer 2 UI to be “unusable” would be making the very same claim against the “new” V1 interface. I’m not being snide in saying this: I’m simply pointing to a reality of human nature; Viewer 1 is in our comfort zone, and it is naturally more attractive.

Performance has been an issue with Viewer 2. Many report tremendous downturns in performance when swapping to it; I’ve experienced it myself in the past. However, today I carried out a couple of (admittedly simple) tests*, measuring FPS rates and rezzing times for the four Viewers I routinely use together with the “official” Viewer 2 and the Kokua development viewer (more out of curiosity with the latter than an attempt to measure its actual performance). The results were surprising, as this table on average frame rates on sims occupied by 2 avatars and 12 avatars respectively demonstrates:

Viewer frame rates on sims occupied by 2 and 12 avatars respectively

In terms of rezzing (using a mall as my baseline), Viewer 2 again performed well. The fastest Viewer for rezzing was, unsurprisingly, Kirstenlee’s S21 (The KLee Viewers have always preformed pretty well on my PC), with Viewer 2 running it a close second. Again, given the use of the JPG2000 library with the official Viewer, this might not be so surprising, but it does perhaps point to Viewer 2 not being as slouchy as its reputation suggests.

Obviously, the test is entirely subjective; what works for me, may not work for you. But its interesting that the overall performance of the Viewer 2 is not so much an issue as it may have been just a few releases ago (when things like frame rates did have me grinding my teeth in frustration).

Giving People What They Want

Truth be told, if Oz wants to understand why people stick with Viewer 1.23.5-based Viewers (or for that matter prefer the likes of Firestorm over Viewer 2), then he only need to really consider one thing: features.

Firestorm in-world Profile display: fast, easy, fun

simply put: TPV developers give users the tools they want: client-side AOs, radar, massive improvements to the Windlight engine and sharable presets, and so on. All these have served to keep Viewer 1-based Viewers at the forefront of popularity.

In the Viewer 2 department, TPV developers are being as equally accommodating, providing features and options users are requesting while LL turn a deaf ear: in-world Profile viewing that avoids the use of the Web Profiles, inclusion of the Media Filter, options to replace the context menus with pie menus, and so on.

As TPVs based on the Viewer 2 / Snowstorm code base mature and inherit features from Viewer 1 TPVs, people will migrate to them and overcome their bias towards the UI.

When that happens, perhaps the only question that will be asked within Linden Lab will be, “Why is Viewer 2 still the minority Viewer?”  In reply to which, I can only say “check back here guys, and read that last few paragraphs…”

* Test information:

  • Hardware: Intel Q6600 Quad Core CPU, 2.6MHz, 4Gb RAM 320 GB hard drive @ 7200rpm
  • Graphics: GeForce Ge9800GT with 1Gb.
  • Viewer settings: Bandwidth 1500kbps; cache size 1024Mb; Draw distance: 384 metres; multi-threading enabled.
  • Sims used: 2-avatar test: Qiu Xiang; 12-avatar test: Mesmerize Dungeon.

Advertising Beta to end

Posted on by Inara Pey

In December 2010 Nelson Linden announced the Second Life Advertising Beta, a programme by which merchants could, for a fee or two, enjoy wider advertising exposure through various Second Life “properties” (or “websites” as we call them elsewhere) such as the SL Marketplace, the SL Land Auction site, and (I assume, as it came along later) within the advertising spaces of Web Profiles.

Essentially, the programme allowed merchants to target niche markets, thus allowing them to have their products advertised directly to those with a specific interest in that market. So, for example, a merchant selling animals could set-up their ads to appear on SL Marketplace pages displayed to those people searching for animals. Prices were based on a number of impressions per month for the add, the size of the ad itself and a minimum purchase amount of some $10.00 USD.

While payments could initially only be made in USD (i.e. via credit / debit card), the basic idea seemed sound enough, and it seems that a number of merchants did sign-up to the programme.

But not enough, it seems, as the programme has now been cancelled, and will formally close on May 31st.

There has been no official announcement of the programme ending; all that has happened is that merchants who did sign-up received the following e-mail yesterday:

“Hello,

“Thank you for participating in the Second Life Advertising Beta program. Based on our evaluation of the SL Advertising Beta during the last six months, we have decided to discontinue the program on May 31, 2011. Access to advertise.secondlife.com for performance information and data downloads will remain open until June 7, 2011. For those that have active campaigns, we will ensure that all of the impressions that you’ve already paid for are delivered prior to closing the program.

“Thanks to all of the Merchants who have helped us test this display advertising beta and for all of your helpful feedback. Your participation and insights will help us drive our ongoing efforts to help you promote your products and services to Second Life shoppers. We look forward to partnering with you on future promotional endeavors.

“If you have any questions regarding this announcement, please email sladsbeta@lindenlab.com and we’ll get back to you as soon as possible.

“Signed,

“The Second Life Advertising Team”

In addition, if you try to reach the advertising site, you’ll simply get this message.

Precisely why the programme is closing remains unclear. Whether it proved difficult to maintain or whether too few merchants signed-up to make it viable long-term as a revenue generator for LL is simply anyone’s guess. It might even conceivably be because LL are planning to replace it with something more refined – although one would have thought those that had made the effort to participate would be given some indication that this was the case, if so.

As it stands the cancellation of the programme, coupled with what appears to be an attempt to quietly sweep it under the carpet does suggest the performance of the programme was less than stellar. If this is the case, then there is a question as to why it didn’t – and forgive the unintentional pun – make the desired impression.

Certainly those merchants that did participate had a favourable view of the programme and tended to find it did help boost sales. But if we’re honest, it wasn’t exactly the most well-supported initiative where LL is concerned: after the initial launch announcement from Nelson, and the video tutorial from Torley, the programme was never given another mention. During the six months it was operating, LL didn’t seek to promote it, report on it or give any further encouragement for merchants to sign-up.

Which is a shame, as with more participation and the promised means of paying via Linden Dollars, the scheme could have become very popular.

Of channels and restarts

Posted on by Inara Pey

Once upon a time server roll-outs for Second Life were handled in what, on the surface, would seem a fairly straightforward manner:

  • New code would be tested on the Beta Grid, with users reporting any bugs or issues to LL for fixing
  • When considered relatively stable, the code would be rolled out on a limited basis to the Main Grid (affecting around 20% of the grid in total) for further “testing”; if major problems were found, the limited roll-out (or “pilot”), would be rolled back
  • If considered stable, the code would be rolled out to the remaining 80% of the grid, generally around 24 hours after the pilot.

The system wasn’t flawless; the complexity of the server code meant that many small (and one would guess conflicting) updates would be “rolled-up” into a single release, often with unpredictable results, despite testing on the Beta Grid. This would result in what I call the “tidal effect”: a change would be rolled out as a pilot, then rolled back for fixing, then rolled out before being rolled back for further fixing, and then rolled out once more, then rolled out again to the entire Main Grid. Sometimes even then, it would go through one more rollback / rollout.

As we’re all only too aware, this approach meant fairly large and constant upheavals for just about everyone concerned, and the cause of much gnashing of teeth and dark mutterings towards Linden Lab.

To try and minimise the overall impact of server code updates and roll-outs, Linden Lab switched over to a “channel” system. Under this system, server code is operated across four channels: the Release Channel, with the latest “release version” of the server code (and supposedly the most stable), and three “Release Candidate” channels, code-named Blue Steel, Magnum and Le Tigre.

Each of the RC channels comprises about 10% of the total Main Grid, and is used to roll-out a “beta” of a specific server code package. This might be a series of bug fixes (e.g. specific SVC JIRA fixes), it might be a general maintenance release (e.g. security updates, etc.), or it may be related to a specific, on-going project (such as display Names, the “Fast Assets” project, the “Inventory Capabilities” project, and so on). Broadly speaking, specific projects tend to be rolled out through specific channels (The Inventory Capabilities project tends to rollout via Blue Steel, for example, as do changes related to the forthcoming arrival of Mesh) – although this is not a hard and fast rule. General maintenance releases, on the other hand, are distributed between all three channels, depending on which has the capacity at the time a release package is ready for beta testing.

So, at any one point in time, some 30% of the grid is hosting what is effectively “beta” software, but in very discrete “chunks”, so to speak, confined to known sets of simulators. The releases themselves are also smaller and more easily managed / identifiable, making everything that much easier to manage and, in theory at least, making issues that much easier to identify and correct.

Broadly speaking, this is how it works:

  • An update (be it bug fixes or whatever) is readied for release as a “beta”. If it is related to a specific project it may be targeted at a specific RC channel (Blue Steel, Magnum or le Tigre)
  •  On the Wednesday of each week, the Release Candidates for each channel are rolled out to their respective 10% of the Grid; if a specific channel doesn’t have a candidate waiting, this obviously, nothing is rolled out
  • Over the course of the next week, the candidate’s performance and impact on the Main Grid is monitored (and the channel servers may be subjected to numerous restarts. If the candidate proves particularly problematic, it may even be rolled back
  • If the candidate appears to be stable after 6 days, then it is (together with any candidates from the other two channels) rolled out to the entire Main Grid the following Tuesday
  • The cycle then repeats with the next RC in the channel dropping into its assigned servers on Wednesday.

If a specific RC causes problems, then the cycle for a specific channel may be broken for a week while the issue is worked on (for example, if a candidate on Le Tigre, say, proves that it is not ready for release as scheduled on a Wednesday, it will be “held over” for a week and made ready for release the next Wednesday).

There is one other channel worth mentioning that doesn’t get a lot of publicity: the “Snack” channel which handles releases related to (among other things) Mono-2 updates and various script monitoring tools. These are known to behave unpredictably, and so are initially rolled out to a very limited number of sims for testing. I understand that once tested, the fixes then go on for wider testing via (usually) Magnum prior to a full rollout.

The benefits of this system are obvious: if there is a major problem with a Release Candidate, it will only affect 10% of the Main Grid (rather than 20% with the old system); the releases are less complex, making it easier for the root cause of specific problems to be identified and corrected. Overall, the process means that there is less widespread upheaval across the Main Grid than tended to be the case with the old, larger-scale releases. There are many examples of these advantages; when a recent change impacted breedable horses, for example, it only affected a small percentage of horses on the grid (only those present on servers running the specific release channel software).

Of course, there are what appear to be downsides to the new system: the release channels (particularly, it would seem, Le Tigre), can be in a state of flux when problems do occur; and the weekly rollouts, with their need for sim restarts, on both Tuesday and Wednesday has been the topic of many a complaint. A minor irritant is the pop-up that comes up when moving between sims running different server releases, be they a release channel or the “full” release – it would be nice if these could be turned off by those who have no interest in what software is being run on a given simulator, just as other pop-ups can be user-disabled through the Viewer.

But, these grumbles aside, it has to be said the new system works. While it does cause a degree of pain for those “stuck” on simulators running one of the release channels, the vast majority of the grid has seen far less upset and upheaval when things have gone wrong. Certainly, the “tidal effect” of gird-wide rollouts/rollbacks has become largely a thing of the past, and while the rolling restarts associated with Tuesdays and Wednesdays might seem inconvenient when they begin, the truth is they’re probably less so than they were under the old system.

Viewer security exploit revealed

Posted on by Inara Pey

Nalates Urriah reports that Linden Lab have confirmed there is a security exploit involving a flaw in the Ogg Vorbis library could lead to Viewer crash issues. It’s not thought that the exploit can either perform privilege-escalation or arbitrary code-execution on users’ systems.

The flaw has been known about since 2009, but the exploit is fairly recent. Ogg files are in widespread use, so this is not an issue specific to the Viewer code. Linden lab has responded to the situation by issuing a patch and an advisory for all TPVs to recompile their binaries for all TPV viewers.

At the time from writing, updating executables for Kirstenlee’s Viewer (S21 7a) and the Firestorm Previews have been released.  Links for the Firestorm downloads (which do not appear to be available on the Phoenix website) are available as follows:

Note that all of the above three releases of Firestorm should be clean installations, not installed over any previous release (which should be removed first).

Other TPVs will doubtless follow, and users are advised to keep an eye on the various Viewer-related blogs and update as required.

Addendum May 16th

Phoenix have released an update that fixes this issue (and others). Find it here.

Local payments update

Posted on by Inara Pey

Frank Ambrose – FJ Linden – is an unsung hero of Linden Lab and Second Life. Since he’s been a part of Linden Lab, he has worked hard to communicate openly and directly with users in a manner that really cannot be faulted – and which should be taken as the standard be which others in the Lab should communicate.

Changes in the way non-US users can make payments has been the source of much controversy of late. Overseas Paypal payments were no longer acceptable, and the new local currency system has been less than confidence-inspiring.

These issues have lead to concerns among users as to what happens if payments fail – as has been the case – and Frank’s latest post on the subject is clear and concise on matters, and provides precisely the required level of reassurance on matters that is needed.

It’s also good to see that it actually shows up on the Featured News list on the Dashboard for once. Is this a sign that that particular problem is being fixed?

Another Alt detector surfaces

Posted on by Inara Pey

It seems there is another Alt detector on the loose. This one is a little less noxious than RedZone, and the speculation is that it is a variation on the previously banned Quickware scripts – although the author denies this.

As with all these things, it requires media streaming to be enabled on the target avatar’s Viewer – if they don’t have media enabled (or run Sione’s excellent Media Filter available in most Viewers) then the tool is a useless box of hot air. If one can talk favourably of the device, one has to say that the author is up front on this fact. Indeed, reading the advertising blurb gives reasons enough not to part with even L$250. I quote:

“* This method only works on Viewers having media enabled, there are no scripts or filters to stop it (NO THERE ARE NONE!) but simply deselecting media in preference is however an effective way to protect yourself from this and these kinds of devices. 
* This method is not 100 % reliable in any way and alot can go wrong. Actual detection means nothing more then that the target and detected share the same way into secondlife as in PROXY,Public Wifi-points (like mac Donald) etc. So take this into account when a positve match has been made !” [sic]

There is also mention of the detection method being flustered by dynamic IP addresses, which concludes, “It is important that the target ‘visits’ you often” in order to avoid the device being fooled by Dynamic IPs.

More interestingly, the author intimates that the tool is “safe” as it does not actually reveal IP addresses, nor does it collect or save them in any way. Technically, this would seem to bring the tool within the letter of the revised Community Standards, which restricts itself to the sharing of private information. However, whether this remains the case or not remains to be seen; if nothing else the tool does stand against Rod Humble’s own comments (to Dusan Writer) on people’s right to privacy where their alts are concerned – and it is really time that LL indicated they are prepared to stand behind Rod’s comments rather than staying silence on the matter of privacy, for reasons I’ve gone into elsewhere.

Overall, this new device is clearly intended to feed of Drama: it’s a one-avatar-per-box solution – that is, each purchased unit can only detect one designated target Avatar’s alts (allowing for all the caveats as to why it most likely won’t work).  This means that mass bans aren’t possible (unless one is willing to part with considerably more than L$250 in order to “protect” one’s venue).

But again, this isn’t really the point; if this tool is allowed to stay, there will doubtless be some 14-carat blockhead out there who will take it as a sign that they can make something even more intrusive, and we’ll be back on the merry-go-round once more.