Tools and Technology

Hi! I’m a member of the Second Life operations team, and I was the primary on-call systems engineer this past weekend. We had a very difficult weekend, so I wanted to take a few minutes to share what happened.

We had a series of independent failures happen that produced the rough waters Residents experienced inworld.

Shortly after midnight Pacific time on January 9th (Saturday) we had the master node of one of the central databases crash. The central database that happened to go down was one the most  used databases in Second Life. Without it Residents are unable to log in, or do, well, a lot of important things.

This sort of failure is something my team is good at handling, but it takes time for us to promote a replica up the chain to ultimately become the new master node. While we’re doing this we block logins and close other inworld services to help take the pressure off the newly promoted master node when it starts taking queries. (We reopen the grid slowly, turning on services one at a time, as the database is able to handle it.) The promotion process took about an hour and a half, and the grid returned to normal by 1:30am.

After this promotion took place the grid was stable the rest of the day on Saturday, and that evening.

That brings us to Sunday morning.

Around 8:00am Pacific on January 10th (Sunday), one of our providers start experiencing issues, which resulted in very poor performance in loading assets inworld. I very quickly got on the phone with them as they tracked down the source of the issue. With my team and the remote team working together we were able to spot the problem, and get it resolved by early afternoon. All of our metrics looked good, and I and my colleagues were able to rez assets inworld just fine. It was at this point that we posted the first “All Clear” on the blog, because it appeared that things were back to normal.

It didn’t take us long to realize that things were about to get interesting again, however.

Shortly after we declared all clear, Residents rushed to return to the grid. (Sunday afternoon is a very busy time inworld, even under normal circumstances!) The rush of Residents returning to Second Life (a lot of whom now had empty caches that needed to be re-filled) at a time when our concurrency is the highest put many other subsystems under several times their normal load.

Rezzing assets was now fine, but we had other issues to figure out. It took us a few more hours after the first all clear for us to be able to stabilize our other services. As some folks noticed, the system that was under the highest load was the one that does what we call “baking” - it’s what makes the texture you see on your avatar - thus we had a large number of Residents that either appeared gray, or as clouds. (It was still trying to get caught up from the asset loading outage earlier!) By Sunday evening we were able to re-stabilize the grid, and Second Life returned to normal for real.

One of the things I like about my job is that Second Life is a totally unique and fun environment! (The infrastructure of a virtual world is amazing to me!) This is both good and bad. It’s good because we’re often challenged to come up with a solution to a problem that’s new and unique, but the flip side of this is that sometimes things can break in unexpected ways because we’re doing things that no one else does.

I’m really sorry for how rough things were inworld this weekend. My team takes the stability of the grid extremely seriously, and no one dislikes downtime more than us. Either one of these failures happening independently is bad enough, but having them occur in a series like that is fairly miserable.

See you inworld (after I get some sleep!),

April Linden

Hi! I wanted to take a moment to share why we had to do a full grid roll on a Friday. We know that Friday grid rolls are super disruptive, and we felt it was important to explain why this one was timed the way it was.

Second Life is run on a collection of thousands of Linux servers, which we call the “grid.” This week there was a critical security warning issued for one of the core system libraries (glibc), that we use on our version of Linux. This security vulnerability is known as CVE-2015-7547.

Since then we’ve been working around-the-clock to make sure Second Life is secure.

The issue came to light on Tuesday morning, and the various Linux distributions made patches for the issue available shortly afterwards. Our security team quickly took a look at it, and assessed the impact it might have on the grid. They were able to determine that under certain situations this might impact Second Life, so we sprang into action to get the grid fully patched. They were able to make this determination shortly after lunch time on Tuesday.

The security team then handed the issue over to the Operations team, who worked to make the updates needed to the machine images we use. They finished in the middle of the night on Tuesday (which was actually early Wednesday morning).

Once the updates were available, the development and release teams sprung into action, and pulled the updates into the Second Life Server machine image. This took until Wednesday afternoon to get the Second Life Server code built, tested, and the security team confirmed that any potential risk had been taken care of.

After this, the updates were sent to the Quality Assurance (QA) team to make sure that Second Life still functioned as it should, and they finished up in the middle of the night on Wednesday.

At this point we had a decision to make - do we want to roll the code to the full grid at once? We decided that since the updates were to one of the most core libraries, we should be extra careful, and decided to roll the updates to the Release Candidate (RC) channels first. That happened on Thursday morning.

We took Thursday to watch the RC channels and make sure they were still performing well, and then went ahead and rolled the security update to the rest of the grid on Friday.

Just to make it clear, we saw no evidence that there was any attempt to use this security issue against Second Life. It was our mission to make sure it stayed that way!

The reason there was little notice for the roll on Thursday is two fold. First, we were moving very quickly, and second because the roll was to mitigate a security issue, we didn’t want to tip our hand and show what was going on until after the issue had been fully resolved.

We know how disruptive full grid rolls are, and we know how busy Friday is for Residents inworld. The timing was terrible, but we felt it was important to get the security update on the full grid as quickly as we could.

Thank you for your patience, and we’re sorry for the bumpy ride on a Friday.

April Linden

Hi Residents!

We rolled out some changes to how region crossings work this week, and I want to explain a little about why and what we changed.

Please note that this blog post is gonna be a bunch more technical than my normal posts, because this is a tricky technical thing. Here’s a really quick summary, however: As part of moving regions to the cloud we discovered that region crossings between the cloud and our data center were terrible. Since we now had an easy way to reproduce the issue, we dug into it, and were able to find some really old bugs, and fixed them. Hooray!

And now for a fuller description!

The process of crossing from one region to another when you’re riding in a vehicle is pretty involved. The region you’re leaving needs to be able to tell the region where you’re arriving  everything it knows about the vehicle, and has to do it really quickly. That includes all of the scripts in the vehicle, everything that’s attached to it, the direction and how fast it’s going, and lots of other stuff.

To make this happen quickly, early on in Second Life’s history we made some assumptions about our network, including things like how big a packet can be. Those assumptions generally worked okay on our own network, but not outside it.

When you crossed from one region to another, the regions were putting a lot of information into large packets and sending them across our network. This was usually okay because our network was purposefully built to run Second Life. Then, as soon we tried to do this on someone else’s network (in the cloud), things didn’t work quite right. The problem was most noticeable when crossing from a region in our data center to one in the cloud.

The first thing our engineering teams tried was breaking those large packets up into smaller ones, but that actually made the problem worse. Rather than send one big packet and wait for the other side to say it received the data, with smaller packets, it had to repeat that bunch of times for each packet. (Send, get an acknowledgement, send another piece, get an acknowledgement, etc.) It was still mostly okay across our network, but way worse when a region in our network was talking to one in the cloud. We now knew this code would never work well, so we needed a different approach.

Next, our engineering team decided to use another way to send the data across the network, using the same protocol and method we use for other types of data. Most importantly, it is faster and more reliable. That did the trick! We’re still collecting statistics on the impact this change has, but things are looking very positive.

Once this new code was written, the performance when going  from region to region got a lot better, and it worked between our data center and the cloud! The improvement was so dramatic that we decided to not make our Residents wait for uplifted simulators, and rolled the changes out right away. That code is what rolled out to the grid this week.

It’s really exciting that the cloud migration is helping us find really old bugs and make Second Life better as we go.

A gridbun that’s really ready to hop among the clouds,
April Linden
 

We recently made changes to the Marketplace that had some results that our community was not expecting. So we want to clear up confusion about the Marketplace and go over our current and upcoming changes.  

Recently we made a change to the default sort for merchant stores to "newest first" instead of "relevance." This was done to prevent old or outdated products from being the first thing shoppers see when visiting a merchant store, and we have seen increased sales across the Marketplace as a result. 

This is just one of the tweaks we have made to the Marketplace and we have plans for further updates in the near future that we hope will continue to improve the Marketplace experience for both shoppers and creators. 

To clear up some of the confusion around how the Marketplace works and give more insight on how to best use the Marketplace, we have put together some answers to frequently asked questions. 

When using product search 

Your product may not be appearing in the same position as it used to in relevance sort for product search for a number of reasons.

1. Titles matter. The title of your product needs to contain the search terms that have been entered into search.
2. How well it sells matters. This looks at the number of sales over a given period of time. 
3. Keywords included in the product listing. Keywords need to contain the search terms that have been entered into search. 
4. What features you have matters. Features need to contain the search terms that have been entered into search. 

We have adjusted the weighting of each of these factors with the last search upgrade. This is something we actively monitor and adjust and your product may have ranked higher in relevance under the previous weighting. 

When viewing a merchant store

Relevance sort requires a search term to really function in the way it is intended. When viewing a Marketplace store page or the product search with relevance sort enabled and no search term, you will get unexpected results. 

Prior to the Marketplace search upgrade, when viewing a merchant store with no search term, relevance sort used to take into account the number of sales of your items over periods of time. So high selling items used to sort to the top even if there was no search term applied. Now when viewing a merchant store with no search term the relevance sort will function the same as best selling sort (not the best selling merchant report). Since best selling only indexes the top 50k best selling items across the entire Marketplace, best selling sort will only look up data from that index. If your items do not fall into the top 50k they will all be ranked the same. This is why your best selling sort may not match your best selling reports. In short, your items will only have a sales rank if they fall into the top 50k. Best selling sort has always functioned this way and has not changed. 

With that in mind, we are currently working on a change to allow best selling to now index each merchant’s store individually instead of just the top 50k items. This will allow shoppers to see any creator’s best selling items when viewing a store page. We hope this will be a better long-term solution than the previous relevance sort and clearly communicate to shoppers what are the most popular products in a creator’s store. 

As always, we are also continuing maintenance and have a planned release Monday April 10th to fix a bug impacting merchant product listing enhancements. 

We have seen good sales results with our current changes and are very excited for our upcoming improvements. As is the industry standard for online marketplaces we will continue to improve and make changes based on our own internal data and community feedback. Our top priority is the best experience for our Marketplace creators and shoppers and we hope these changes will bring us closer to that goal. As always, if you find that Marketplace isn’t working the way you’d expect, please let us know!

Happy shopping and selling!

As part of launching our new more open viewer development process, we changed the open source license for the new viewer code base from the GPL with an exception to allow use with certain other open source licenses (the "FLOSS Exception") to the LGPL.  Some people have been asking about what this change means, and what our intentions are in making it.  In particular, the LGPL requires that the code first be compiled into a library and then may be used in an application.  Since the open source we make available does not directly provide for building this way, some people have speculated that the new license may actually be a barrier to other viewer developers.  I'll try to answer this as clearly as I can.

At Linden Lab, our intent is to enable the development of third party viewers and the improvement of our own viewer through mutual sharing of the requisite common technology.  We think that LGPL is a better license to accomplish that sharing. Even though it was originally written to apply only to libraries, there is significant room for interpretation when using it.

Our interpretation is this: modifying the build procedures provided in the source code to produce a library containing a subset of the licensed code is a minor programming exercise.  The result of linking that library (which may be either a static library or a shared one, and either is allowed) with whatever other code is used to build a viewer is again a minor problem. The results are essentially indistinguishable from those in which the developer just modified the build procedures in place to produce an executable application.  Essentially, the details of the linkage procedures used are a matter of packaging and have no end user effect.  In practical programming terms, a library is just a convenient package - the requirement in the LGPL is like requiring that a grocery store sell a product only if it is first placed into a shopping cart while inside the store.  Essentially a library is just that - a shopping cart full of individually compiled modules, so there's no real difference between using a library and just using the modules separately (one could build a library containing exactly one module, or build an application that had only one module and one library).

It is our intent that developers be able to use the components that we have licensed under the LGPL to produce viewer applications, regardless of the linkage procedures used, so long as they make available any changes to those components as specified in the license.

Residents on our Release Candidate Regions got an extra bonus Region restart today. We apologize if this extra restart disrupted your Second Life fun, so we want to explain what happened.

The Release Candidate channels exist so that we can try new server versions under live conditions to discover problems that our extensive internal testing and trials on the Beta Grid don't uncover. Unfortunately, it's not nearly possible for us to simulate the tremendous variety of content and activities that are found on the main Grid. We appreciate that Region owners are willing to be a part of that process, and regret those occasions when a bug gets past us and disrupts those Regions.

Normally, Region state is saved periodically many times a day as well as when the Region is being shut down for a restart. The most recent Region state is restored when a Region restarts.

The extra roll today was needed because we found a problem that could have caused long-running Regions to fail to save that state.  Without the roll, there would be a significant chance that changes made to those regions might not be there following the regularly scheduled roll because the save data would be out of date. Good news! It’s been fixed, and today's roll applies that fix.  The roll took a little longer than usual because we took extra care to ensure that the Region saves would work normally for this roll.

We apologize for any disruption to your Second Life today, but at least you can rest assured that  Second Life saves!

Good morning everyone,

At the end of last year we began the task of moving Marketplace search to an up-to-date version of ElasticSearch, the application we use to do full text searches.  We apologize for some of the bumps you may have experienced in the last few weeks as we make this transition.

The Marketplace search backend was showing its age. We’ve upgraded the technology and we’ve dusted off both our indexing and searching filters. We were running ElasticSearch version 2.3 and needed to update to ElasticSearch version 8.4.  Our goal was to bring Marketplace search results closer to web search and make page loads faster, in order to improve your shopping and selling experience.

In practical terms this means:

• Merchant and store names won’t be included in product-specific searches anymore, increasing the number of relevant results
• We’ve added the ability to do exact matches with quotes around a word or phrase
• You can do asterisk(*) wildcard searches
• Fuzzy matching will help with misspelled words and typos
• Search operators AND, OR, NOT will still work as before. (Note that they must be capitalized. Consult the tooltip next to keyword search for more information.)

We received a number of reports about these issues:

• A bug with how relevance of search results is determined. This bug has been fixed.
• The search results page was displaying an inaccurate count of matching items. Search is returning the same number of matching item as before, but the count may say “10,000+”

We hope this ElasticSearch upgrade will improve everyone’s Marketplace experience. However, we are continuing to fine-tune. If you find that Marketplace search isn’t working the way you’d expect, please let us know! We may very well be able to address your issue.

An example of specific, helpful reporting might be, “I searched for ‘unicorn’, I expected ‘unicorn unicorn unicorn’ in the first page of results, but instead I got ‘horse costumes’.”

From all of us on the Second Life Web team, thank you for your patience and understanding. Happy shopping and selling!

With our latest release we’d like to welcome back Viewer Profiles! The Second Life viewer has made the transition back to an integrated Profile floater. This is the place to find more information about any Resident including a bio, picks, and more!

Residents may still use web-based profiles in a web browser. However this change brings back a more responsive experience in the Viewer as well as giving you the information you’re most interested in seeing on the first page. 

As part of this change, Groups now moves to the main tab.  This change also means that hiding Groups no longer requires opening and viewing each one.  Just click on the eye next to the group to hide or show.  

A big thank you to the Firestorm Viewer team for your contribution!

How things have changed

The viewer Profile, as opposed to the web Profile, shows all of your Second Life Bio, Feed, Picks, Classifieds and Real Life bio when viewed by other residents logged in to Second Life.

The Feed will remain a web property displayed in the Profile floater in its own tab.

Interests are accessible on the old web Profiles but will no longer be included in the viewer Profile.

Today we launched Viewer 2.5, now out of Beta. The most significant update is a new, web-based profile system, which allows profiles to be viewed and edited both on the web and in the Viewer. For example, here's mine. Please note this is just a starting point for the web-based profiles; we’ll be doing a lot of work to refine the usability and make them richer over time.

In response to your feedback from the early beta versions of Viewer 2.5, we've added some privacy settings that will allow you to control just how public your profile is. Once you’ve logged in, click on “Privacy Settings” in the upper right corner of your profile. Group settings set in the Viewer will be overridden by these group privacy settings.

• "Everyone" means that the information is available to the whole Internet and can be picked up by search engines.
• "Second Life" means that the information is available to all Second Life Residents who are logged into the website or inworld. This is the default for all existing Residents using Viewer 2.5.
• "Friends" means that only your Second Life friends can see the information on the web and inworld.

This is why we have a beta process--to address concerns and improve your user experience. We will continue to iterate as we get more feedback. Thank you for all your help and comments. Please attend the Viewer 2 User Group meetings if you would like to share your thoughts and feedback directly with me and the Snowstorm team.

Viewer 2.5 also has some other new features. The one I like best is that you can now have your Favorite landmarks also appear on the login screen, so that you can log directly into your favorite locations. Torley made a video about this, so check it out! We've also improved some texturing performance and fixed another batch of bugs. Watching the internal data, we've already seen a noticeable improvement in stability and performance--on par with Viewer 1.23.

Download Viewer 2.5, try it out, and keep the feedback coming! And, if you Twitter, please use the hashtag #slviewer2.

Helpful Links

• Download Viewer 2.5:
  • Windows | Mac | Linux
• Viewer 2.5 Release Notes
• SL Forum on Viewer 2
• SL Answers on Viewer 2

In addition to many grid enhancements that FJ shared last week in his technology update blog post, the Viewer 2.5 beta cycle begins today. Viewer 2.5 Beta 1 is now available and includes several new features, usability improvements, and bug fixes.

Improved Web and Viewer Resident Profiles
The biggest change in Viewer 2.5 Beta 1 is that we've replaced the Viewer-based profiles with web-based profiles. You can access the redesigned profiles on the web using your Second Life user id and in the Viewer itself. For example, here’s mine. In the Viewer, profiles now open in a web browser and you can open as many profiles as you like at the same time. And, if you wish, you can even connect other social identities from Twitter, Facebook, and LinkedIn to your profile.

Logging In to your Favorite Locations
A long-standing feature request has been the ability to access some of  your favorite Landmarks from the login screen, so you can quickly teleport to places inworld. In the Viewer 2.5 Beta, we've added a preference that gives you access to the Landmarks on your Favorites Bar from the Login Screen. To use this feature, go to Preferences > Privacy and select the check box labeled, "Show my Favorite Landmarks at Login." If you log off and then restart your Viewer, then you'll see a list of your Favorite Landmarks in the "Start At" drop-down box on the login screen. Also, when this feature is enabled and you share a computer account (login) with other people, they will see your list of Favorites if they run the Viewer 2.5 Beta.

Decompression Performance Improvements
For a long time, we’ve used an older version of the Kakadu library known as KDU to load textures and images in the Viewer. The KDU Library has been updated to version 6.4 in the Viewer 2.5 Beta, which allows the Viewer to take advantage of significant decompression performance gains; our preliminary measurements gauge the performance gain at 30% for decoding images, which should translate to a visible improvement in rezzing time for complex scenes.

Please note that per our support policy, we’re also deprecating Viewer 2.1.1 today. If you’ve been running Viewer 2.1.1, you’ll be prompted to download the latest Viewer release. To stay up to date on future deprecation announcements, please subscribe to @secondlife on Twitter.

As  always, we want to know what you think of the latest beta so please keep that feedback coming. Share your impressions with us on Twitter and use the hashtag #SLViewer2.

Helpful Links

• Download Viewer 2.5 Beta 1:
  • Windows | Mac | Linux
• Viewer 2.5 Beta Release Notes
• SL Forum on Viewer 2

As of today, SL Viewer 2.4 is the default Second Life Viewer download for new Residents! As was mentioned in the Viewer 2.4 Beta blog post, this is largely a maintenance release focused on improving user experience, stability, and performance. This release does, however, have a few important changes and additions, including the following:

A Cleaner User Experience and More Customization Options in Preferences

Throughout 2010, we’ve added many new Preferences to the Viewer and it was time to not only reorganize and clean up the layout, but also add popular customization options, such as:

• Color and transparency options that allow you to change the look of Viewer windows
• Options to easily enable the Advanced and Developer menus
• A new preference that you can use to turn group and IM chat pop-ups on or off whenever you like

Support for External Text Editors when Working with LSL

Here’s a good one for content creators and developers. Now, you can use your favorite script editor to edit LSL scripts outside of the Viewer. In  Viewer 2.4, enabling the new ‘ExternalEditor’ debug setting will allow you to specify the path to your own text editor (for example: /Applications/TextMate.app/Contents/MacOS/TextMate). When the setting is enabled, just open the Script Editor in the Viewer and click the “Edit” button, and the text editor you specified in debug settings will then open with the script you have open in the Viewer. Any changes you make and save in the text editor will automatically appear in the Script window in the Viewer.

Graphics Improvements

We continue to make numerous improvements to Viewer graphics as we move closer to integrating Mesh Import into Viewer 2. You can see more detail in the Release Notes, but we’ve improved antialiasing, anisotropic filtering, snapshots, and we’ll see even more in upcoming releases.

Performance Improvements

Viewer 2 performance is improving, as shown by steadily decreasing crash rates that are now close to those for Viewer 1.23, but we know there’s still more to do. So if you do crash, please be sure to send us a crash  report, as they are essential to helping us understand where issues occur, which allows us to better prioritize our work.

An Auto-Updater Tool

We now have an auto-updater for Viewer 2! This means that whenever a new Viewer is released, the next one being Viewer 2.5, it automatically  downloads the newest software in the background and offers you the  ability to upgrade when it’s ready. You can still decide whether you want to install the new version or not, but the auto-updater will help ensure that you’re always using the most up-to-date version of the SL Viewer. Keep in mind, the auto-updater will only work with optional updates. Mandatory updates will continue to work as they have in the past.

Finally, to those of you who gave us feedback on previous versions of Viewer 2, we offer a heartfelt thank you for all your bug reports, forum and blog comments, and Tweets using the #slviewer2 hashtag. Your input is invaluable as we continue to prioritize our 2011 Viewer 2 roadmap.

So download Viewer 2.4 -- and keep that feedback coming!

Helpful Links

• Download Viewer 2.4:
  • Windows | Mac | Linux
• Viewer 2.4 Release Notes
• SL Forum on Viewer 2
• SL Answers on Viewer 2.4

Today, we are excited to launch the latest version of Viewer 2 -- Viewer 2.3 Beta -- that makes it even easier to connect to friends and relevant experiences in Second Life. We’ve come a long way since we first launched the first Viewer 2 Beta in February. We’ve dramatically increased performance and stability while adding cool new features like Shared Media. We’ve also made many usability improvements, based on your feedback, that make it easier for content creators and developers to build in Second Life.

With the Version 2.3 Beta, Viewer 2 takes another big leap forward. This Beta not only includes many performance enhancements and bug fixes, but it also allows you to more freely express your inworld identity with Display Names, introduces helpful pop-up hints to make it easier to learn Viewer 2, and gives group owners more control of SL Events.

Display Names Arrives on the Main Grid

Display Names, as you know, gives all Residents two names: a unique username and an optional Display Name that you can change on a weekly basis. Display Names gives you the ability to use Unicode characters and multiple words so you can use your current SL Name, your real name, a pseudonym, or a gamer tag. It’s your choice!

Since we originally blogged about Display Names, and subsequently launched the Display Names Project Viewer on the test grid, we’ve made a range of changes to the feature that address the Resident concerns and feedback we received around impersonation and griefing. If you want to learn more, there’s a video below showcasing the enhancements and a full list detailing each change. We have also compiled a Frequently Asked Questions wiki page and two Knowledge Base articles, one on Display Names and another on usernames, complete with video tutorials from Torley that show you how to use this new feature.

Check out this video to see Display Names in action:

Because we need to ensure that Display Names operates correctly, we will not enable Display Names for the entire grid immediately. Today, it will work in a few thousand regions; once we see how it performs,  we will dial that up over the next few weeks until the whole grid is enabled. If you want to try using Display Names, then head to Blake Sea and Bay City, as those areas will be enabled first.

Group Owners Can Now Control Event Scheduling

The Viewer 2.3 Beta now allows group owners to control events scheduling on group-owned land. Please read more and see our step-by-step instructions on the SL Events wiki pages.

Viewer Hints Make the Switch to Viewer 2 Easy

We understand that there’s a bit of a learning curve when you make the switch from Viewer 1.23 to Viewer 2. So, we have added helpful pop-up hints for newer users around commonly used features, such as walk and chat. These disappear when the user takes the appropriate action, or dismisses the hint, and then you’ll never see them again.

Download the Viewer 2.3 Beta today, try it out, and Twitter your thoughts using the #slviewer2 hashtag.

Helpful Links

• Download Viewer 2.3 Beta (Version 2.3.0, Beta 1)
  • Windows | Mac | Linux
• Viewer 2.3 Beta Release Notes
• Display Names FAQs
• Changes to Display Names Based on Your Feedback with Video
• Display Names Knowledge Base Article with Instructional Video
• Usernames Knowledge Base Article with Instructional Video
• SL Events Wiki
• SL Answers on Display Names
• SL Forum on Viewer 2

Today, we’re releasing Viewer 2 (Version 2.2.0 Beta) on our Beta release channel. This is an exciting release for us for two reasons. First, this release marks the first Viewer download since we announced the Snowstorm Team at SLCC in August. The Snowstorm Team has been working in the open to share our design and development process and directly engage with open source developers. Second, this beta release also marks the beginning of a new approach to our release process. Since we kicked off Project Snowstorm, we’ve made the latest Development Viewer available to Residents nightly so they can see our day to day progress and try out new things as soon as they’re in a build.

In our Beta and Release channels, we will make Viewers available to you more frequently. Our plan is to update Betas weekly with new official releases happening every 3-4 weeks. This lets us get new ideas and features into your hands faster and it gives us the ability to react to your feedback more quickly.

This latest beta release of Viewer 2 (Version 2.2.0 Beta), is mostly focused on bug fixes, but also includes some great user interface customization options. Here’s a quick run-down of what you’ll find in this release:

Many of these features came to the official Viewer through resident contributions, both directly by way of the Snowstorm team, as well as indirectly through past contributions to the Snowglobe project. Thank you to all of you who have contributed code, testing, and commentary. Please keep it up!

To view a full list of changes, see the Release Notes.

Download the Beta Viewer : Windows | Mac | Linux

Please note that, as always on the beta channel, we only support one beta viewer at a time. If you’re using an older Beta Viewer, then you will be asked to upgrade on your next login.

Thank you!

Viewer 2 (Version 2.2.0) has been released today as the main Second Life Viewer! This is an important release for us because it marks the first big release using the Snowstorm process. A few months ago, we formed the Snowstorm Team as a dedicated Viewer team who works with the open source community and entirely in the open to make user experience improvements to the Viewer. We've been holding almost all our meetings in public, working with open source developers to integrate their work, sharing our backlog with the community, and releasing daily development Viewers which are available for anyone to download.

Over the last few months, we've improved the velocity of our teams and shortened the release cycle. The Version 2.2.0 release today comes after a three-week beta cycle during which we released Betas weekly and focused on stabilization and crash fixes on the Beta Viewer. Your feedback, crash, and bug reports during our beta cycles are crucial - so thank you to all who participated in that process.

Version 2.2.0 introduces some new features, usability enhancements, and crash fixes. Here are a few highlights:

• Sidebar Panels can now be undocked and turned into regular floating windows: Simply click on a Sidebar Tab and drag it away from the Sidebar to undock it. You can also click the undock icon in the top right of a panel. To redock a sidebar panel, click the redock icon in the top right of the panel. Once sidebar panels are undocked, they behave like any other floating window in the Viewer.
  
  
• Buttons on the Bottom Bar can now be reordered: In the last Viewer release, we added a few optional buttons to the Bottom Bar. In the 2.2.0 release, you can now reorder buttons on the Bottom Bar, so they’re arranged just the way you like them.
  
  
• Right-click on your avatar and select “Sit Down” to sit anywhere: A great feature that came to the Viewer, by way of Snowglobe, allows you to right-click on yourself and select “Sit Down” from the context menu to make your avatar sit anywhere. To stand back up, just click the “Stand Up” button or right-click on yourself again and select “Stand Up” from the context menu.
  
  
• Parcel Property Icons are now on by default: Parcel property icons indicate what users can, or can’t, do on a particular parcel. The icons can be found in the Location Bar and are now on by default. If you’d like to turn them off, you can do so by right-clicking the Location Bar and unchecking “Show Parcel Properties” from the context menu.
  
  
• Selection Beams are working again: In Viewer 2, there was a bug that hid selection beams. This made it hard for people to see when you were building or the object you were currently editing. This has been corrected!
  
  
• Language translations in local chat (via Google Translate API): Another great feature that came to the Viewer via Snowglobe is local chat translation. Simply click the “Translate chat” check box in the upper left hand corner of the local chat window. Language preferences can be set at the bottom of the Chat tab in the Preference window.
  
  
• Group permissions now work in Snapshots: This corrected a bug in Snapshots which prevented you from sharing a Snapshot texture with a Group.
  
  
• Turn off scripted particles and lights: This feature allows photographers and machinemists to turn off scripted lights by accessing the Debug Setting, “EffectScriptChatParticles” and setting it to FALSE. To turn scripted particles and lights back on, simply go to the Debug Setting window again and set “EffectScriptChatParticles” to TRUE.
  
  
• Builders can more easily align textures across linked prims using planar mapping: This feature allows builders to align textures across faces so that several prims can look like a single prim. Simply select the faces of a set of linked prims, then open the Textures tab of the Build tool, make sure your Mapping setting is set to “Planar”, then click the checkbox labeled “Align planar faces.”
  
  
• View profile inspectors via the Mini Map: When you hover over the little dots (people indicators) on the Mini-Map, you’ll see the familiar “i” icon pop open with a user’s name. Clicking the inspector allows you to view that user’s Mini Profile.
  
  
• Pan the Mini-Map with shift-drag: If you hold down the <SHIFT> key and then click and drag on the Mini-map, you can now pan the map to view other areas.

As I mentioned in the blog post announcing the Version 2.2 beta, many of the features included in this release come directly from Resident contributions - via the Snowstorm process, as well as through past contributions to the Snowglobe project. Thank you to all of you who have contributed code, testing, and commentary. Please keep it up!

The Viewer 2 (Version 2.2.0) release is not a mandatory upgrade at this time, but will be the default download for the Second Life Viewer on the downloads page.

You can view the full release notes for Viewer 2 (Version 2.2.0) here.

Download Viewer 2 (Version 2.2.0)
Win | Mac | Linux

We've been working hard on the Uplift of Second Life. If you have not been following this project, that's what we're calling the migration of our Second Life simulators, services, and websites from a private datacenter to hosting in The Cloud (Amazon Web Services). It's a massive, complicated project that I've previously compared to converting a steam-driven railroad to a maglev monorail -- without ever stopping the train. This undertaking has at times been smooth sailing, at other times a very bumpy ride. We wanted to share some more of the story with you.

Our goal has been to move SL incrementally to give ourselves the best chance of minimizing awareness among the residents that these changes were happening. We feel we’ve done better than we expected, but of course it’s the bumps in the road that are most noticeable to our residents. We apologize for recent service disruptions, although what’s perhaps not apparent is the progress we’ve made -- and the improvements in performance that have quietly taken place.

First, the rough spots:

• Region Crossings
  One of the first troubles we found was that region crossings were significantly worse between a cloud region and a datacenter region. We did a deep dive into the code for objects (boats, cars, planes, etc) and produced an improvement that made them significantly faster and more reliable even within the datacenter. This has been applied to all regions already and was a good step forward.
• Group Chat stalls
  Many users have reported that they are not able to get messages in some of their groups; we're very much aware of the problem. The start of those problems does coincide with when the chat service was uplifted; unfortunately the problems did not become clear until moving that service back to the datacenter was not an option. We haven’t been able to get that fixed as quickly as we would like, but the good news is that we have some changes nearly ready that we think may improve the service and will certainly provide us with better information to diagnose it if it isn't fixed. Those changes are live on the Beta grid now and should move to the main grid very soon.
• Bake Failures
  Wednesday and especially Thursday of this past week were bad days for avatar appearance, and we're very much aware of how important that is. The avatar bake service has actually been uplifted for some time - it wasn't moving it that caused the problem, but another change to a related service. The good news is that thanks to a great cross-team effort during those two days we were able to determine why an apparently unrelated simulator update triggered the problem and got a fix deployed Thursday night. 
• Increased Teleport Failures
  We have seen a slight increase in the frequency of teleport failures. I know that if it's happened to you it probably doesn't feel like a "slight" problem, especially since it appears to be true that if it's happened to someone once, it tends to keep happening for a while. Measured over the entire grid, it's just under two percentage points, but even that is unacceptable. We're less sure of the specific causes for this (including whether or not it's Uplift related), but are improving our ability to collect data on it and are very much focused on finding and fixing the problem whatever it is.
• Marketplace & Stipend Glitches
  We've had some challenges related to uplift for both the Marketplace and the service that pays Premium Stipends. Marketplace had to be returned to the datacenter yesterday, but we'll correct the problems that required the rollback and get it done soon. The Stipends issues were both good and bad for users; there were some delays, but on the other hand we sent some users extra stipends (our fault, you win - we aren't taking them back); those problems are, we believe, solved now.

Perhaps the above makes it sound as though Uplift is in trouble. While this week in particular has seen some bumps in the road, it's actually going well overall. Lots of the infrastructure you don't interact with directly, and some you do, has been uplifted and has worked smoothly.

For a few weeks, almost all of the regions on the Beta grid have been running in the cloud, and over the last couple of weeks we've uplifted around a hundred regions on the main grid. Performance of those regions has been very very good, and stability has been excellent. We expect to be uplifting more regions in the next few working days (if you own a region you'd like included, submit a Support Ticket and we'll make it happen). Uplift of the Release Candidate regions, which will bring the count into the thousands, will begin soon. When we're confident that uplifted regions are working well at that larger scale, we'll be in a position to resume region sales, so if you've been waiting - the wait is almost over.

Overall, the Uplift project is on track to be complete or very nearly so by the end of this year (yes, 2020… I know I've said "fall" before and people have noted that I didn't say what year 🙂 ; the leaves haven't finished falling at my house yet…). It's likely that there will be other (hopefully small) temporary disruptions during this process, but we promise we'll do all we can to avoid them and fix them as fast as we can. This migration sets the stage for some significant improvements to Second Life and positions us to be able to grow the world well into the future.
 

UPDATE: 04.24.2015 - For an update on how the Tool Viewer Release affects these systems, visit this blog.

We have made some changes to the Second Life System Requirements to bring them more up to date, and are making some related changes to the Viewer:

• 
  
• 
  

  We have removed Windows XP and Mac OSX 10.6 from the list of supported operating systems. Microsoft has announced the end of support for XP, and it has been some time since Apple has released updates for 10.6. For some time now, the Viewer has been significantly less stable on these older systems, and the lack of security updates to them make them more hazardous to use.
  We have no plans to actually block those systems, but problems reported on them that cannot be reproduced on supported systems will not likely be fixed.

  
  
  
• 
  

  The Windows installer has been modified to verify that the system has been updated with the most recent Service Packs from Microsoft. While we will not block installation on Windows 8 at this time, we strongly recommend upgrading to 8.1 for greater stability. Our data shows that the Viewer is significantly less stable on systems that have not been kept up to date, so the installer will now block installation until the updates have been applied. This change will be effective in a Viewer version to be released in the next few weeks, so it would be a good idea to get your system up to date before then. You can find information on how to install the latest updates at the Microsoft Windows Update page.

  
  
  

Last week we blogged about moving to an updated version of ElasticSearch, the application we use to do full-text searches on Marketplace. After successfully upgrading from 2.3 to 8.4 we have been closely monitoring usage and feedback from our merchants and Residents. This has led us to make a few tweaks to how our new search system works.   

In the coming days we will be changing the following:

• A bug where featured listings are not being updated properly.
• We have removed the 50-page cap on search results. Our statistics showed that few people look at higher-numbered pages. In addition, page load time is increased by loading more result pages into memory. But you have spoken, and we’re removing the cap.
• A search string such as “blue shirt” will return results that contain both the term “blue” and “shirt” instead of including results that contain “blue” or “shirt.” This behavior is changed if you use advanced features such as quotes, boolean operators (AND, OR, NOT), or asterisks. Make sure to check the tooltip next to the search field for help with boolean operators.
  
  For example:
  
  
  
  
  The above search term will now return results in the center of the diagram.

We hope these changes will improve everyone’s Marketplace experience while also enjoying the advantages of ElasticSearch. We continue to monitor how search performs for everyone. If you find that after these changes, Marketplace search still isn’t working the way you’d expect, please let us know! We value everyone’s thoughts and we thank you for your patience as we continue to make search better. 

Happy shopping and selling!

Hello Residents!

If you run an inworld service that logs in as a scripted agent (aka, a bot), or maintain a Third Party Viewer, please pay attention. This blog post is for you.

We are making some changes to improve the security of Second Life!

On November 1st, 2021 we are going to be discontinuing the use of two older security protocols, TLS 1.0 and TLS 1.1, on our login services. We’re doing this to increase the security of everyone on the grid.

In March of 2021 the Internet Engineering Task Force (IETF) officially deprecated these two older protocols, and now we’re gonna do the same. TLS 1.0 was released in 1999, and TLS 1.1 was released in 2006, and while they’ve had a good run, it’s time for them to enjoy a nice retirement into Internet history.

On Wednesday afternoon this week we inadvertently turned off TLS 1.0 and TLS 1.1, and we received reports that several inworld services (such as older bots and some very old Third Party Viewers) were unable to log in. Since we hadn’t given Residents any warning this was going to happen, we turned them back on this morning. We want to make sure folks have a chance to update their services before we turn them off again permanently on November 1st, 2021.

If you were impacted by the sudden removal of these older security types this week, we’re sorry they were turned off without warning. We should have communicated it better. We also want to thank you for taking the time to improve the security of your service! The grid will be safer for us all as a result.

For everyone else, you have nothing to do! Our viewer, and almost all of the popular Third Party Viewers have been using the latest versions of TLS for years. You’re all set!

Looking forward to a more secure Second Life,
April Linden, Gridbun

Hello amazing Residents of Second Life!

A few days ago (on Sunday, October 28th, 2018) we had a really rough day on the grid. For a few hours it was nearly impossible to be connected to Second Life at all, and this repeated several times during the day.

The reason this happened is that Second Life was being DDoSed.

Attacks of this type are pretty common. We’re able to handle nearly all of them without any Resident-visible impact to the grid, but the attacks on Sunday were particularly severe. The folks whothat were on call this weekend did their best to keep the grid stable during this time, and I’m grateful they did.

Sunday is our busiest day in Second Life each week, and we know there’s lot of events folks plan during it. We’re sorry those plans got interrupted. Like most of y’all, I too have an active life as a Resident, and my group had to work around the downtime as well. It was super frustrating.

As always, the place to stay informed of what’s going on is the Second Life Grid Status Blog. We do our best to keep it updated during periods of trouble on the grid.

Thanks for listening. I’ll see you inworld!

April Linden
Second Life Operations Team Lead

Hi everyone.

As I’m sure most of y’all have noticed, Second Life has had a rough 24 hours. We’re experiencing outages unlike any in recent history, and I wanted to take a moment and explain what’s going on.

The grid is currently undergoing a large DDoS (Distributed Denial of Service) attack. Second Life being hit with a DDoS attack is pretty routine. It happens quite a bit, and we’re good at handling it without a large number of Residents noticing. However, the current DDoS attacks are at a level that we rarely see, and are impacting the entire grid at once.

My team (the Second Life Operations Team) is working as hard as we can to mitigate these attacks. We’ve had people working round-the-clock since they started, and will continue to do so until they settle down. (I had a very late night, myself!)

Second Life is not the only Internet service that’s been targeted today. My sister and brother opsen at other companies across the country are fighting the same battle we are. It’s been a rough few days on much of the Internet.

We’re really sorry that access to Second Life has been so sporadic over the last day. Trying to combat these attacks has the full attention of my team, and we’re working as hard as we can on it. We’ll keep posting on the Second Life Status Blog as we have new updates.

See you inworld!

April Linden
Second Life Operations Team Lead

As we continue to work on improving the Second Life experience, one challenge we’ve been tackling is the length of the Viewer installation process. No one likes waiting, and now with Project Zipper, you don’t have to!

With the project Viewer available today, there’s really only one thing different - the installation is super fast. Rather than waiting for install to complete, you’ll quickly be in Second Life doing what you love.

Try out Project Zipper with the project Viewer here.

This is still a project Viewer, and if you find bugs while testing it out, please let us know by filing them in BUG project in JIRA.

Today we’re making available the first beta release of Viewer 2.4. We’ve done a great deal of maintenance work for this release, with significant help from the Second Life open-source community, including fixing a number of interface problems, hunting down and eliminating some key crash bugs, and making several performance improvements.

A number of features and changes are worth noting with this release. For the most part, we consider the work we're releasing today to be intermediate steps on the way to a better future:

• A new auto-updater: Whenever there’s a new viewer release, the viewer will now download the new installer automatically in the background, and offer to install an upgrade when you next log in. You still control whether you want the new version, of course. We’ll continue to improve the auto-updater experience in future releases.
• Clearer preferences: We’ve reorganised several of the preferences tabs to make them more understandable (and to make it easier for us to create new preferences, should the need arise). We've added some colour and transparency options, and fixed some bugs too. There will be more work to come in this area as we strive to make the viewer more customisable.
• External text editor support: This is one we’re extremely happy about, as it's something Residents have wanted for a long time. If you’re a scripter, then you can now use your own text editor for scripting. The feature still needs a lot of user interface work, but as we work more on build tools in coming months, it will keep getting better and easier to use.
• Graphics improvements: We’ve also integrated some graphics improvements as we work towards integrating mesh import into Viewer 2. Our graphics systems are undergoing major renovation, and there have been improvements to anti-aliasing, anisotropic filtering, and snapshots, with more to come in future releases.

So, although Viewer 2.4 is fundamentally a maintenance release, it has a lot of great stuff in it. Please give it a try and give us your feedback!

Download the Viewer 2.4 Beta today, try it out, and Twitter your thoughts using the #slviewer2 hashtag.

Helpful Links

• Download the Viewer 2.4 Beta (Version 2.4.0, Beta 1)
  • Windows | Mac | Linux
• Viewer 2.4 Beta Release Notes
• SL Forum on Viewer 2

Last week, we made a new page available as a replacement for the old Transaction History page. Due to your feedback, we rolled back the changes to this page to allow us to gather more feedback, and we are now providing this new page for review, without removing the old Transaction History page.

We have not yet made any changes to the new page, because we would like time to collect your feedback and review it. We have created a wiki page giving background on why changes were made to this page, where the new page is, and how to provide feedback. We will be closing feedback on April 30, 2014, so please take a look before then.

A new set of Materials work has become a Release Candidate Viewer. This Viewer includes support for Materials underwater, render support for impostors, and fixes that will address issues with transparency and alpha layers. See the Release Notes for full details.

A quick coral study with Normal and Specular maps shown underwater. Land Impact is 14.

As of today, approximately one fifth of the regions in Second Life have at least one object using Materials, and this is increasing at a rate of about 2% per week. Users with high-end graphics cards are seeing a significant increase in frames per second when Advanced Lighting Model (ALM) is turned on -- we highly recommend that those users turn ALM on. In addition, we will be updating the GPU tables to include newer graphics cards, allowing more users to take advantage of advanced graphics features like Materials.

Thanks to those who have already tried out Materials and submitted a bug report to the MATBUG JIRA project! Once this release candidate has completed the release process, we will be moving any active MATBUGs to the BUG project and track any future issues from the BUG project.

If you’d like to experiment with Materials, download the Materials Release Candidate Viewer today. And don’t forget to check the Good Building Practices wiki for more tips and tricks and the Knowledge Base for updated user documentation.

Yesterday, with much rejoicing, we promoted Viewer 3.7.28.300918 (Tools Update) to release. While this Viewer doesn’t have a shiny new featureset on the surface (other than reverting to a single-button login), it’s what’s inside that really matters - we’ve updated the numerous tools used to build the Viewer. The immediate expected effect of this is performance stability and a decreased crash rate.

We go to great lengths to maintain backwards compatibility in Second Life, both to never break users’ creations and to support the wide range of systems our Residents use to log in. However, sometimes we have to make the hard decisions: a year ago we announced that we were dropping support for Windows XP and Mac OSX 10.5 & 10.6 (a complete list of current system requirements is available here). Today, with the Tools Update release, the Viewer will no longer run on those systems. You will still be able to log in with an older Viewer until it is aged out based on our deprecation policy, however we strongly recommend updating your system.

It's unfortunate that we have to stop supporting some older systems, but upgrading the tools we use to build the viewer will help us to bring you other improvements to your Second Life experience more quickly and reliably.