Category: News

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.

Going social: increasing the relevancy of web Profiles?

Posted on by Inara Pey

According to Frederick Linden, we’re about to see a series of “cool social tools” and a web Profile tools released over summer (and possibly beyond) that will enhance “social networking” capabilities within Second Life.

Precisely what is coming down the line is unclear – Frederick was somewhat vague in the meeting where these tools were mentioned. However it would appear that we can expect:

  • The ability to manage Friends lists directly from web profiles (found at my.secondlife.com/first.last)
  • An ability to issue in-world, location-based status updates” from Second Life to your web profile
  • The development of a “Profile API” that will enable the functionality of web Profiles to be more easily extended in the future
  • Other undefined “cool tools”.

The first three items are particularly intriguing, and may potentially add a lot of benefits to using web-based profiles. The “location-based status updates” is somewhat eye-catching, as it comes close to describing a Twitter-like feed capability from in-world to people’s Profile pages – assuming I’m understanding Frederick’s broad hints correctly. Given that many of the SL-to-Twitter HUDs that are available have been broken as a result of changes to the server-side of Twitter, the provision of such an update capability might be seen by LL as a means of providing a reasonable alternative – although most people who use Twitter (like me) will probably want a more direct means of updating followers and friends as to what they are doing in-world.

The ability to manage Friends could be seen a boon as well – while it is nice to see your friends listed on your Dashboard, the fact that there is next to nothing you can do with the information (other than see where those who allow you Map might be in-world) tends to negate any real value in having the list visible.

However, given there is already an Action button on web Profiles, were the new API and Friends management tools to allow you to say, pay a Friend directly from your web Profile or IM them, then the value of web Profiles dramatically increases and would help them overshadow the static list presented in the Dashboard.

In fact, looking at the rough outline supplied by Frederick, one cannot help but wonder if we might not be seeing the first steps towards doing away with the Dashboard completely (which has become increasingly irrelevant since the launch of the Lithium-based Community Platform) and replacing it with our web Profile pages. Providing feeds to things like the Grid Status pages and to Events can be supplied the web Profiles, then the Dashboard becomes somewhat redundant.

Certainly, we’ve recently seen LL move positively to address privacy concerns surrounding web Profiles, actions which have clearly been intended to allay fears and increase the popularity of web Profiles. As such, making them more central to our SL lives would seem to be a direction LL would wish to move, and this would further marginalise the value of the Dashboard.

It’s going to be interesting to see what precisely emerges from Frederick’s broad hints in the coming months – and just how far things go in the other direction (an API can, after all, open up web Profiles for others to use…and possibly mine…). As such, this could well be the topic to watch between now and the end of the year.

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.

Sign-up pages and Basic mode of Viewer – working well

Posted on by Inara Pey

Figures collated by Tateru Nino (see below) show that the new Basic Mode of the Viewer have had a positive impact on user sign-ups, with a dramatic upward trend since its introduction at the end of March. The new sign-up pages, reported on yesterday, have had an even bigger impact, it would seem – and despite teething problems. The latter point was hinted at by Rodvik yesterday when he commented in a Tweet to myself:

 Thanks, yeah should be fixed quickly. Even with those the results have been amazing.

This is a positive thing, and shouldn’t be dismissed as it demonstrates that without additional marketing and promotion, SL can generate user interest.

What remains unclear at present is how well the new Basic mode does at retaining users – and as Rodvik rightly points out, it’s going to be a few weeks before the figures on user retention become clear. Certainly, I’d still be somewhat concerned, as the “new user experience” leaves a lot to be desired, as Theia Magic and others have commented upon.

Rodvik has also indicated that the Basic Mode is to be enhanced over time; as I’ve previously mentioned, while some additional functionality would benefit the Basic mode, there is a risk that add too much, and the line between Basic and Advanced becomes so blurred as to be non-existent. Given this, I still hold to my position that it is the Viewer HELP functions that need to be overhauled, rather than simply dropping more and more into Basic (unless said “more” is modular in format and can be activated at a time of the user’s own choosing).

I’m really hoping that ears at LL are receptive to the idea of a more integrated HELP for Basic / Advanced modes; it would get a lot of people “over the wall” in terms of transitioning from one to the other a lot quicker.

Beyond this, the issue of orienting users once they are in SL does remain a problem. Some have called for a reinstatement of the mentors; others have called for a revamp of the welcome islands, etc., in line with some of the privately run welcome areas. From Theia’s reports, it would seem a degree of policing of the LL-run welcome points needs attention. It is a little ironic that the Lab is paranoid about adult language getting into the forums and the like – but anyone with Voice enabled can be immediately verbally abused on arriving in-world for the first time.

Personally, I’m confident that Rodvik is more than aware of what needs to be done – as does Bagman Linden. That the Basic mode has had such a positive impact is good news, and I cannot see anything other than it being capitalised upon in the coming weeks and months as more of the initial user experience is brought into focus and revised / improved.

(with thanks to Tateru Nino by way of Rodvik Linden)

Sign-up pages overhauled

Posted on by Inara Pey

Linden lab, as pointed to by Daniel Voyager, has overhauled the new user sign-up pages, making them cleaner and more direct. Gone are the old static pages, instead, a newcomer clicking on JOIN NOW is taken to a page that displays the new default avatars, which can be previewed in motion (to some extent) prior to selecting the most preferred one.

Once selected, the avatar slides over to a page requesting you assign it a user name, before sliding over to a third screen where the rest of the default information required to create an account is displayed (password, e-mail addy, etc. – all of which are mandatory).

Michelle Leckrone has produced a nice little video of these initial steps, which can be seen below.

Following these screens, you’re given the option of going for a free account, or a Premium, as shown on the left; once selected, you reach a screen inviting you to download and install the Viewer, as “Your avatar is awaiting you!”

Overall, it is a clean, slick approach to the sign-up process, although it does have a few teething troubles right now, and it again demonstrates the mistake LL made in doing away with the first name / last name format for avatar names.

The problems are in the fact that – once again – Linden Lab seem to have shot themselves in the foot when it comes to testing and QA: many users are reporting issues with the new sign-up system across all flavours of browsers. These are as minor as the selection bar on the first screen appearing OVER the avatars themselves, right up to the screen failing to load any avatars at all.

This isn’t really very clever, and needs fixing quickly. For my part I rant the process on the latest Chrome and Opera iterations, and found the selector bar issue in Opera, while Chrome displayed everything faultlessly.

The loss of a last name for an avatar is more of an issue inasmuch as it severely limits the choices available to users – hence the massive rise in names like “Jodie1234 Resident”. While it can be argued that the use of Display Names overcomes this limitation, the removal of the last name option – even when using a pre-selected list – has potentially lessened the external view of Second Life as being a digital “reality” and moved it closer to being viewed as just another game.

That said, this is overall a good move in cleaning up the user sign-up process – assuming the idiotic browser compatibility issues are rapidly sorted out (and for which there is simply no excuse). I certainly hope that the rest of the sign-up process is similarly revamped in a positive manner. As it stands, it still suffers from the bland (and misleading) videos and slide shows that do very little to entice new users or offer an actual meaningful explanation as to what SL is and what people can do within it. Hopefully, these will be addressed in the near future, and replaced with something more vibrant an appealing.