Facebook wipes Second Life

I’m going to go out on something of a limb here. Just why are people getting so worked up about having their “SL Accounts” on Facebook deleted?

Over the last 24 hours, FB have been mass deleting accounts linked to SL avatars (and no doubt other accounts that are “not linked” to “real information”), and people have been shouting about it across blogs, Twitter and Plurk as if it is so kind of outrage.

Well, sorry, it isn’t. I’m not Facebook fan; I wouldn’t even use it – but the Facebook Terms and Conditions of use are clear: only “real life” account information should be used on Facebook accounts. Quote:

“Registration and Account Security

Facebook users provide their real names and information, and we need your help to keep it that way. Here are some commitments you make to us relating to registering and maintaining the security of your account:

  1. You will not provide any false personal information on Facebook, or create an account for anyone other than yourself without permission.
  2. You will not create more than one personal profile.

However fond we are of our Avatars, the fact remains that they don’t fall under the classification of “real names and information”; ergo, however much it hurts, creating a Facebook account using avatar information has always been a recipe for disaster. Given this, it’s hard to see how anyone can be outraged when Facebook seek to enforce their rules; it is their playground, after all.

I appreciate this may come across as a cold reaction, especially to those who have invested many hours in developing their Facebook presence, but it is honestly hard to be anything else. Had it been a case of FB suddenly changing their policy and wiping out accounts as a result, it would be a very different matter, one that would call for more sympathy for those affected by the move.

But it is not. As quoted above, the rules are clear. Foolish is the person who gambles against the house odds in matter like this.

However, there is another side to this situation. Leave us not forget that for well over a year now Linden Lab have been actively encouraging people to flip over to Facebook and join things over there. For example, we’ve had:

  • The 2010 Valentine scavenger hunt, the top prize for which could only be won by those registering with Facebook
  • The 2010 advertising campaign that (at the least) required SL users to connect their Avatars with their RL identity on Facebook
  • Wallace Linden’s heavy-handed FB push that marked his one (and only?) attempt to “start a conversation”
  • Amanda’s Linden’s own clumsy juxtaposition of announcing a forthcoming new “community platform” for “better communications” while at the same time telling people that “the” place to find out about SL is….Facebook…

While it might be argued that few / none of these initiatives have required people to sign-up to Facebook using their Avatar details, such arguments entirely miss the point. Facebook and Second Life are – for the vast majority of SL users – simply a bad fit, precisely because of FB’s “no ‘fake’ information policy.

Of course, there are those who don’t mind linking RL and SL identities: those operating a RL business with SL ties; those working in education in RL and SL, those operating non-profits, etc., may have few qualms in linking one to the other – and are excellently placed to use the likes of FB and services such as LindedIn to help promote themselves and their activities.

But for the vast majority of SL users, making FB a bedfellow has not been in our interests. Some at Linden Lab (/me waves to Amanda) have been using a form marketing kung-fu that can only be described as kicking oneself in the head, in that they seem to be of the opinion that pushing SL users to FB will be reciprocated in a flow of FB users to SL. This clearly is flawed in so many ways, it’s not worth rehashing all the reasons why, especially given they’ve been pointed out time and again by so many SL bloggers.

Hopefully, this latest move from Facebook will convince TPTB at the Lab that it really isn’t in their best interests to be so cosy with FB. In the meantime, for those who want an SL-related social network, why not give 2ndhub a try?


Tony’s return

It’s no secret I love music. My tastes are wide and varied – eclectic would very much be the word – ranging from classical (including modern composers such as Karl Jenkins), jazz, new age and film soundtrack composers. One of my particular favourites – thanks again to paternal influences (and he inherited it from his Dad) – has always been the Great American Songbook; a theme that is very popular within Second Life as well, where it features at many a jazz-oriented club and ballroom.

From the end of this week, there will be a new name to add to the list of such venues; well new in a very familiar way, because it is really the return of an old favourite in a new location. This is because on Friday May 20th, Tony’s Jazz lounge re-opens in Second Life.

For those unfamiliar with the jazz / club scene in Second Life, Tony’s Jazz Lounge and Piano Bar was run by Absolut Smirnov, who was also responsible for the romantic Rivers of Venus club before that (which is where I first got to know her well over three years ago). The “old” Tony’s was one of the venues that hosted the Martini Lunches, featuring music from the Martini in the Morning radio station during a two-hour session hosted live and on-air by MTIM’s own Brad Chambers (Martini Philbin in-world).

The new Tony’s is located in a slick skybox build above Chindo.  In keeping with the original Tony’s, the club provides an intimate environment well-suited to a romantic evening’s dancing, with a dance floor backed by a bar area and galleried lounge.

The bar and dance floor

The ambience of the club is enhanced by the careful use of colours – a deep blue used on the wall, and bar-area furnishings, dark stonework walls, a rich wooden floor, black ceilings and a very atmospheric cityscape backdrop along one wall.

The dance floor is spacious and flows around a central stage that is ready for live performances and which is itself framed by blood red drapes that further enhance the intimacy of the place.

The gallery lounge

The bar area offers a mix of barstool and armchair seating, and is slightly elevated above the dance floor to provide a good view of it for those coming to the club to enjoy a chat and take in the atmosphere. Upstairs, the gallery lounge provides further seating and the homely touch of a stone fireplace.

Lighting throughout is unobtrusive, and the pictures and wall hangings all contribute to the ambience, creating a friendly, cosy environment – which is precisely what Absolut wanted. “My aim is to create a place where you can come to listen to good music, relax, meet friends, see incredible live acts, have a laugh when we have our comedy nights,” she explains, “And just generally get a feeling like Cheers – where everybody knows your name!” She certainly intends for the club to buzz, “I plan on having comedy nights once a month, or weekly as Tony’s grows,” she continued, “Plus weekly blues DJ, and a live musician/jam session weekly, and who knows what else!”

So why is Tony’s back after what has been an extended break? “It was something that was really just beginning to take off when I had to take a leave of absence from SL,” Absolut comments, “It had become a popular spot, and had the ‘right’ feel I think, for everyone who frequented it; I wanted to bring a bit of that back.”

Absolut’s enthusiasm is as infectious as it is genuine; her passion for creating a stylish venue with good music was the key ingredient that made Rivers of Venus an outstanding success, and helped to establish the original Tony’s.

With a relaxed dress code, centred around semi-formal wear, although Absolut admits to liking styles from the 1920s and 30s, couple with a warm, friendly atmosphere, the club looks set to establish itself as a very special place within Second Life.

Why not discover Tony’s Jazz Lounge and Piano Bar for yourself? The club is holding an opening event on Friday 20th May at 5-6pm SLT. The Surl is listed below, so why not slip into your best dancing shoes and grab a limo to what promises to be the coolest place in town?

Surls and Links

Breaking the Viewers

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

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

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.

Phoenix gets jiggly

In something of a surprise move, Phoenix have released version 1102 of the Viewer. While an update was anticipated following the Ogg Vorbis Library files issue, the extent of this update took many by surprise, including as it does the Viewer 2 Avatar Physics code.

Yes, bouncing bewbs (and bums and bellies) using the official Linden code within Phoenix.

However, this isn’t a fad release: there have been reports that Viewers not using the LL Avatar Physics code are failing to render avatars that are using the Physics Layer correct (remember, Avatar Physics is a worn layer, like clothing, Alpha and Tattoo layers). So this inclusion of the code is as much about fixing this issue within Phoenix as it is about giving people bouncy bits.

To further encourage people to upgrade to 1102, the Phoenix team are including a set of pre-defined Physics Layers, each created by a different member of the team, which are ready-to-wear for both male and female avatars (yes, men can have wobbly bits as well!). For that want to make their own, there is an easy-to-follow tutorial from Phoenix.

Other fixes with the release include:

  • Removal of old Breast physics code as it is now obsolete and no longer compatible
  • Addition of further user-created WL Presets
  • Set “Let Scripts Control My Play Button” to OFF by default. Prefs> Audio & Video>
  • Fixed local lights issue for Mac users (could only see 2 local lights rather than the default 6)
  • Security fix with OGG Vorbis Library (see above)
  • Addition of Linden chat color options in Prefs>Text Chat>“Color text for linden text chat”
  • Open buttons for logfiles, Chat logs etc on Linux and Mac fixed. Prefs> Network & Folder>
  • Further sculpt fixes
  • TP Failure crash fix
  • Blank media texture crash fix.

Performance on this release (for me) appears somewhat better than 1050, and on a par with 977 Beta (which I had to roll back to following the 1050 release). However, given the Ogg and Avatar Physics “fixes” this is really a necessary upgrade than an optional one.