Dorktastically Delicious

Second Life Computer Guide

Mon, 10 Oct 2011 00:10:00 GMT

Every so often I see someone on plurk ask about what makes a good computer for Second Life. I try to answer when I can but feel like I'm often saying the same things over and over again. So, I figured I'd sit down and write it all down as best I could so I can just link to the post from now on.

General Guidelines

I'm pretty sure that most computers on the market now can run Second Life, since they are better than the minimum requirements listed on the official page. In fact, you can run SL on a netbook -- I've run both Snowglobe and Viewer 2 on mine. But there's a difference between running and running well.

While we may not consider SL a game, it certainly looks like one to a computer. As a result, its no surprise that the recommended system specs are similar to those for a gaming rig. That doesn't mean you need a top of line gaming monstrosity to run Second Life though.

Video Card

This is probably the most important of your Second Life experience. Sure, you need the rest of your computer working too but the choice of graphics card can make or break your SL experience.

A key thing to realize is that I'm talking about a discrete graphics card. Many computers come with integrated graphics "solutions". These aren't good for 3D applications like Second Life -- they are slower and generally less powerful than discrete cards.

There is really only one type of card to get for Second Life: NVIDIA Geforce.

NVIDIA does make other types of cards, such as the NVIDIA Quadro line. Quadro cards have different drivers that are not optimized for games and (more importantly) these cards are not supported by Linden Lab.

The other big player in the dedicated graphics card realm is AMD (formerly known as ATI). Simply put, AMD drivers don't support SL very well.

The longer, more technical explanation is that the Second Life client is written using OpenGL, a cross-language, cross-platform API for computer graphics. While OpenGL can be done purely in software, putting all the graphics work on the CPU, good graphics card drivers move more and more of that burden onto the GPU, the processor on the graphics card. Historically, ATI's implementation of OpenGL has been very poor. It has gotten better recently, but the situation is a case of too little, too late -- NVIDIA does it better and offers better extensions. For the record, if the Lab had gone with OpenGL's main competitor, DirectX, Second Life would be limited to Windows users only.

Back on topic. You want an NVIDIA Geforce card. But which one? Modern day Geforce cards follow a specific naming pattern: an optional prefix followed by a three digit number.

The prefixes are really useful. They're the easiest way to distinguish the intent of a card. The GTX prefix designates the high end, meant for gamers who want the best. These are the most expensive but basically always guarantee a good experience in SL. The GTS and GT prefixes indicate that the card was intended for media and mid-level gaming. These cards will work with SL, but don't expect to run around on ultra all the time (especially with a GT card). The G prefix or no prefix at all means that card was meant for business machines or low power machines. Don't expect much from these. Sometimes (especially in laptops) these are integrated solutions, making them even less powerful.

While the prefix is useful, the three digit number is what really matters. Unfortunately, a bigger three digit number is not always better. The latter two digits indicate power. GTX cards are generally 60 or higher. GT and GTS cards are generally between 30 and 60, while the G cards are usually less than 30. The first digit is indicates the family. For most part, a newer family (with a higher first digit) is more powerful than an older family (with a lower first digit). That is to say, the Geforce 400 family is better than the Geforce 200 family. But, a GTS 450 is less powerful than a GTX 280 and both of those cards are less powerful than a GTX 475.

It is worth mentioning that AMD video cards are generally cheaper than NVIDIA ones and currently (mid-2011) more plentiful, since NVIDIA has had some manufacturing trouble. As a result, many off the shelf laptops and desktops (Apple included) currently have AMD video cards. I have heard both success and nightmare stories about AMD cards in SL so I find it hard to recommend them.

On the other hand, NVIDIA's current laptops with Optimus can be pretty frustrating. Optimus switches between Intel onboard graphics and the NVIDIA card based on need, which is great on paper but in practice doesn't work with OpenGL applications like SL. Whether or not your laptop uses its full potential will be luck of draw, specially since companies like Dell offer no option to turn Optimus off.

I guess that means that in the desktop world NVIDIA is a clear winner but with laptops it's a complete crap shoot.

Memory

Video cards are very important for Second Life. Thus the huge section above. But they're not the only important piece.

You'll want 64bit operating system and at least 4GB of RAM. While both are relatively standard nowadays, it's worth keeping an eye out. 32bit operating systems can only use 4GB of RAM so adding any beyond that to a 32bit machine is useless. 64bit operating systems can support a lot more memory (TB, if not PB) so you can use 6GB, 8GB, or even 12GB if you really want to splurge. It's worth noting that Second Life is still a 32bit application and as such it can only use 4GB of memory at any given time. The extra RAM, however, can be used by other programs while running SL.

One thing to watch out for with memory is that it is often sold "paired". That is, you buy multiple (usually 2 or 3) sticks of the same size use them together in "dual channel" or "triple channel" mode. Breaking pairs is not a bad thing but not ideal either. You can read more on the FAQ from Crucial.

Of course, the faster your memory is the better. But for most intents and purposes, your memory will not be the bottleneck in your system. Generally its your disk drives but sometimes PEBKAC.

Other Computer Parts

Once you have a powerful graphics card and plenty of memory, you're basically set. But, here's a quick list of things to keep an eye out for.

Processors

Standard desktop processors and standard laptop processors are generally more than plenty for running SL. However, keep in mind that your processor has to pick up the slack if your video card isn't quite up to snuff.

The things to look for in a processor are:

Company
Cores
Clockspeed

The two big players in the CPU realm are Intel and AMD. Generally speaking, Intel processors are "better" than AMD but AMD processors are cheaper than Intel ones. For a while this wasn't quite true (AMD spanked Intel with 64bit processors) but Intel regained its throne with the introduction of Core processors a few years back. This doesn't mean that AMD processors are bad, but if you have the money it won't hurt to get an Intel.

Next up are cores. Basically, Intel and AMD realized they were having trouble making processors faster. We've had ~3.0 GHz computers since 2000 or so. Apparently going faster made things melt. They decided to scale by adding more processors instead. If you have one processor at 3.0 GHz, two of them is even better! Each of these "processors" is a core.

It's worth noting that having more cores doesn't automatically make your computer faster. Many programs don't take advantage of more than one core, though this is slowly changing. Instead, more cores allow your computer to multitask better. Programs (like SL, Photoshop, etc.) can hog a single core and avoid competing with other programs for processing time.

Finally, let's talk clock speed. A computer can flip a bit from 1 to 0 or 0 to 1 once per "cycle." If you speed up the frequency of the cycles, the computer becomes faster. That frequency is the clock speed. As I mentioned above, processors have sort of topped out around 3.5 GHz. Instead of increasing the clock rate, Intel and AMD now focus on doing more tasks per clock cycle via strategies like multiple cores.

Most mere humans (myself included) usually cannot tell the difference between a 2.6 GHz and 2.8 GHz machine unless we're actually reading a CPU speed output. Therefore, the absolute fastest processors are generally a huge rip off. For example, Intel's current top of the line (i7-990X, since its successor i7-3960X won't be out till the fall) is $1000. It is a 3.46 GHz 6 core beast. The next step down (i7-970) is also six cores, but "only" 3.2 GHz. It's also a bit over half as much at $550.

I've found the sweet spot for best bang per buck sits somewhere around 2.4 - 2.8 GHz for desktops and 2.0 - 2.2 GHz for laptops. Quadcore is pretty standard in the desktop arena and most laptops are following suit. In mid 2011, just about any Intel Core processor (from the high end i7s to the low end i3s) should serve you well. On the AMD side, you'll probably want to stick to Phenom II X6 processors from the last year or two or one of upcoming high-end Bulldozer processors.

Hard Drive

As I mentioned before, a mechanical disk drives are basically the slowest parts of a computer. Spinning magnetic disks are slower than memory chips and there's not much you can do about it. However, this really shouldn't affect SL performance. We're talking maybe a few more fps going from the slowest drives to the absolute fastest. If you really want to know about the fastest hard dives, keep reading. If you just want a guideline, skip to the last paragraph before the next section.

The way gamers used to solve this "problem" of a "horribly slow" hard drive was to:

get drives that spin faster
run a bunch of drives in parallel

The latter is what I like to call "a bad idea." If one of those multiple drives ever fails, all of the data is inaccessible. It's a lot of complexity for not that much reward. However, if you are interested, go read up on RAID0.

As for spinning faster, standard desktop drives today run at 7200 rpm. Green power storage drives are usually 5400 rpm. 5400 is kinda slow, but 7200 is what most of us are used to. Gamers, though, would often look at WD Raptors and Velociraptors that run at 10,000 rpm. For comparison, high end storage drives used to top out at 15,000 rpm.

However, spinning discs cannot compete with memory chips like the ones in USB flash drives. So why not use a giant flash drive inside your computer? That's the basic premise of solid state drives. The average solid state drive (SSD) blows even the fastest mechanical hard disk drives (HDD) out of the water.

SSDs come at a price. A really really huge price. While the cost has dropped over the last few years, you're still looking at $1.50-$2 minimum per GB in mid 2011. HDDs, on the other had, are currently somewhere around $0.10/GB.

On top of that, SSDs are often smaller than your average HDD. While you can find 2TB SSDs, average consumer ones are usually between 32GB to 256GB. HDDs on the other hand, go all the way to 3TB right now.

For what its worth, I currently don't use SSDs in any of my computers, but will probably switch when I buy my next one in a year or two. I'll run my operating system and programs off an SSD and keep all my data (music, movies, pictures, etc.) on a storage HDD.

Basically, if you're getting a mechanical drive, make sure its at least 7200 rpm. That is the standard desktop speed. If you are getting a solid state drive, make sure you do you your research and have enough storage space. It's up to you to determine your storage needs.

Network Cards

Really, your ISP will be the limiting factor here. Having a good connection really helps with all sorts of internet things.

However, if you are worried about your computer's network capabilities, keep reading.

In general, faster is better (and usually more expensive).

For wired network cards, 10GbE (10 Gbit/s) > 1GbE (1 Gbit/s) > 100 Mbit/s > 10 Mbit/s.

For wireless network cards, Dual 802.11n (600 Mbit/s) > 802.11n (300 Mbit/s)> 802.11g (4 Mbit/s)> 802.11b (11 Mbit/s) .

Keep in mind that every part of the connection is as fast as the weakest link. Most residential internet connections are under 100 Mbit/s. The faster specifications could help inside the house though. If you have two 802.11n laptops and an 802.11n router, you could possibly transfer files at speeds over 100 Mbit/s despite only having a 15Mbit/s internet connection outside the house.

Most current desktops support 1GbE. More and more laptops are offering 802.11n wireless cards every day. However, many of the routers I've gotten from ISPs in the last two years (a Comcast cable modem/router and a Verizon FIOS router the year before) only support 100 Mbit/s wired 802.11g wireless.

Other Stuff

The following is a list of other stuff I can think of in or around computers:

Monitor
Keyboard
Mouse
Sound card
Mic and/or Webcam
Card reader and/or media drives (Blu-ray, DVD, CD)
External hard drive
TV tuner

None of these should have an effect on your SL performance. A lot of these could affect your SL (screen size, ergonomic comfort, being that guy or girl with the static on voice) but will mostly come down to personal needs and preferences.

Laptops vs Desktops

Most of what I've said thus far applies to both laptops and desktops. Again, which you choose will probably come down to personal preference and needs.

Laptops were made to be portable. This makes them more expensive than desktops with an equivalent feature set. If you aren't planning on moving your computer around a lot, getting a desktop will probably get you more bang for your buck. If size is a huge concern, then a laptop might be better for you. That said, there are rather small desktop cases out there nowadays like the Sugo SG07 mentioned in this small form factor gaming guide.

For what its worth, I run SL on a laptop most of the time. When I blogged and took a lot of photographs in SL, I did most of it on a desktop.

Apple

This guide is aimed towards people running Windows or Linux. Ironically, I use my Apple laptop most of the time. Most of the general recommendations and guidelines still apply to Apple machines. However, Apple only supports a limited set of hardware so some of the details may not apply.

Thanks to the way that Apple segments its markets, it's actually pretty easy to recommend Apple products for Second Life. If you want a desktop, a recent iMac works pretty well and would probably serve you well for a year or two. A Mac Pro might last you twice as long but will probably cost you more than twice as much.

On the laptop front, you want a Macbook Pro.

Summary

So here's a recap:

Graphics Card: Desktops: NVIDIA. Laptops: a crap shoot.
Operating System: 64bit OS
Memory: 4GB at least
Processor: Quadcore, at least 2.0GHz. Intel or AMD.
Hard Drive: Don’t do 5400 RPM unless its for storage. Anything else should work.
Network Card: Just make sure you’re online.

Get Your Legacy Names

Wed, 19 Jan 2011 00:01:00 GMT

Update: A year or so later, these don't work very reliably. Just get a username. Upgrade to Viewer 3.

I'm pretty sure that everyone knows about the new username system by now.

But what you might not know is that older "legacy" names are still available too.

I mentioned in the PS section of my last post about usernames that you can still get legacy names from SLNameWatch. Unfortunately, most of the portals that used to be listed there are no longer listed. As of last weekend, though, the following three portals still work for me:

I'm honestly not sure why RegAPI still works. When usernames rolled out, it was indicated the the RegAPI was going to be turned off soon. However, a few other things (merging the TeenGrid, for example) were also mentioned as coming soon but haven't gone live yet. I'm guessing that RegAPI owners wanted the API upgraded for usernames, since they probably invested heavily in their welcome area and SL-related infrastructure.

In the meanwhile, you can still get your legacy names and snag that silly alt name you've always wanted.

expressRez

Sat, 25 Dec 2010 00:12:00 GMT

I just released my first opensource project ever, expressRez. It's a tool for builders that allows them to package and re-rez large builds that can't be linked together into a single piece.

I know that products like it exist, but why spend $2 when you can write your own? Actually, I didn't think it'd be very difficult and I really didn't need much functionality, at first. Then I realized I need a little more, and a little more, and two days later expressRez came together.

The thing is, I haven't really tested expressRez much. It works for the builds I made it for, and it does what I want. I don't really need any more functionality and don't plan on adding to it unless I find something that is broken.

As a result, I decided to open source it under the GNU GPL. This way I can share it, and give it others, but in a somewhat manageable way. I considered a variety of licenses and settled on GPL because of the strict copyleft. I release it under the GPL, so any derived works also need to released under the GPL.

What does that mean in simple terms?

You'll need to attribute the script somehow and make an option to provide source if you pass the script on to to others.

The easiest way to do that is to just leave the scripts modifiable. There's a copyright message at the top of scripts, and since they are modifiable anyone can click and see. This works regardless of whether you've made any modifications to the script (short of removing the copyright info -- that's just bad).

If you're uncomfortable with that, you can use a notecard that attributes the script to me and provides a link to the github repository for others to get the code themselves. This, however, only works if you are using the scripts without modification. If you pass on the script (regardless of wether this is part of a product or just giving it to a friend), the next person should be able to get the source of what they're receiving. So if you've made modifications, you'll need to offer the modified source on request.

The only thing is, I unfortunately don't have the time to offer support for these scripts. Beyond the instructions, you're on your own. I will offer paid support, but even that is a on a case by case basis.

At the end of the day, I hope I help a few builders out. Merry Christmas.

two365 post

Sat, 18 Dec 2010 00:12:00 GMT

Just wanted to point y'all over to my twothreesixfive post over at twothreesixfive.wordpress.com. It was hard to put all my thoughts in 365 words or fewer.

Viewers Redux

Mon, 06 Dec 2010 00:12:00 GMT

So it turns out that my last post about Linden Lab viewers has become outdated thanks to updates the Lab. Snowstorm is in, Snowglobe is out.

And now that I have a bit of time on my hands (and some work to blow off), I figured I'd work on an update.

Viewers from Linden Lab

Official Viewer Types

Before getting to the viewers, there is a wiki page devoted purely to types of viewers from Linden Lab. Here's my quick summary, in order of relative stability (from least to most):

Alpha/Nightly: builds straight from whatever is latest in the code repository. may (in fact, probably) will not work well.
Development: builds from Project Snowstorm, ideally consisting of working features but many new features will be in an alpha state.
Project: builds focusing on a very specific set of features, generally meant to preview a new feature before it hits the main grid. often connect to the beta grid.
Beta: builds contain code that is on track for the next release. may contain bugs, bug fixes, and new features but not yet ready for primetime. for usage with the main grid.
Release Candidate (RC): beta builds that are almost ready for primetime. the final release candidate is rarely very different from the release that follows.
Release: an official release

Official Viewer

Still available at get.secondlife.com.

Viewer 1.23.5 is still on the supported viewers list. I still think it's the worst option out there, not counting malicious viewers. But it is there.

For the more adventurous types, there's always the beta viewer lower down on the downloads page. Currently, the beta builds are one subversion ahead of stable (2.4.x vs 2.3.x).

Of course, one can also use the latest project viewers, but those are mostly meant for the beta grid.

Snowglobe

Is dead. Cue Chopin's Funeral March.

Snowstorm

Is not dead.

Project Snowstorm provides two sets of downloadable viewers. The first is what most people refer to as the Snowstorm viewer - the latest Snowstorm development build. These are compiled from the latest code in Linden Lab's Viewer Development repository and are currently tagged as two sub-versions ahead of stable (2.5.x vs 2.3.x), putting them one sub-version past the beta viewer.

Development builds are for those you who want the bleeding edge.

The Snowstorm wiki also contains links to "developer builds", which are feature-specific builds. They're very similar in concept to project builds, but before the feature is considered ready for any sort of public consumption.

Pick Your Poison

I still use the current release of Viewer 2 most of the time, and sometimes use the beta viewer. If and when I cannot do something in Viewer 2 (temp uploads, etc.), I generally use Imprudence/Kokua.

As always, make sure you are getting your viewer from an official source. In the case of Linden Lab, that'd be from secondlife.com. For a given third party viewer, that'd be their official download site. A little safety can go a long way.

Whats in a Name?

Fri, 19 Nov 2010 00:11:00 GMT

Linden Lab has rolled out the new username system this week. What does that mean for you? Probably not that much, but I'll tell you what I've found out with the hope that it'll offer some clarity.

What are Usernames?

There are now two types of accounts in Second Life -- new accounts and legacy accounts. Those of us who were on the grid before the new naming system are legacy accounts. We chose two names, and we get to keep them. Our usernames are created by putting our two names together with a period. The new accounts are, well, new. New accounts choose only one name, which is their username.

There's a few different ways to format names, so here's a little table stolen shamelessly from the the SL wiki.

Name Formats
	New	Legacy
User Name	username	firstname.lastname
Legacy Name	username Resident	FirstName LastName
Default Display	username	FirstName LastName

Pretty simple. The one extra thing worth noting is that firstnamelastname (without the period) has been marked as taken for all legacy accounts.

Why Usernames?

Usernames act as a way to uniquely identify any given avatar, sorta like UUIDS but human readable. Why is LL ditching the old two name format? I'm not sure, but probably because having a fixed pool of last names kinda sucks. Offering a single username is simpler and offers a lot more flexibility. Most other social media use a single login name. Twitter, Tumblr, Plurk, Wordpress, Facebook, all give you a single username. Even older things like Google, MSN, Yahoo, and AIM -- single username. So why should SL be any different?

All the Scary Things

So what happens to your existing Second Life name? Absolutely nothing. No one else can claim it as a username, because of the check mentioned above. Simple as that.

Why the Fuss?

For some reason, the loss of last names has prompted a huge username grab by existing users, sorta like domain parking without the selling the domain for profit bit.

I can understand why people might be concerned. If anyone has established a brand name in Second Life, it would be nice to snag the username that matches the brand (or more importantly, prevent others from snagging the username). In fact, I'm guilty of that doing exactly that and snagging a few usernames I consider important.

But, on the flipside, someone has always been able to register a Second Life name with the name of your store and try to pretend to be you. Whats the difference between someone trying to be YourBrandName Resident and YourBrandName Mananguinne or YourBrandName Jolifaunt? At the end of the day, the person they're trying to trick has to be smart enough to figure out the actual owner of the brand. If the victim is new, naive, or just plain gullible, you can't really win that battle.

So the mad rush for usernames seems a little silly, unless of course you went and registered YourBrandName LastName for every single last name available. If you did that, you just have too much time on your hands.

The one thing I can think of is that usernames might come up first in search results (the way profiles do now). So an alt with a pick pointing to your store might not be that bad of an idea. However, trying to use usernames as generic search keywords goes a bit too far. Would you click on the user than comes up for the search "houses" or "clothes"?

Related to Display Names

As a side note, the switch to usernames goes hand in hand with the new display name concept. You can register with boring old firstnamebirthyear like every other place (e.g. johndoe1950) but call yourself whatever you want (perhaps "Sir Bedevere the Wise"). And, just like any other place on the internet, someone can pretend to be someone they are not. Welcome to the interhighway. We have Nigerian prisoners and lotteries that want to give you money. Really.

P.S. If you still want old fashioned dual names, the RegAPI seems to still work. Check out http://slnamewatch.com.

P.P.S. While on the topic of names, there's only one lab. Linden Lab, that is. Not "Linden Labs". Get it right.

I Feel Sorry for Lindens

Wed, 20 Oct 2010 00:10:00 GMT

I really do. Because we, as a community, treat them like shit.

We want others to treat us like human beings. We remind them that there is a human on the other side of the internet, a real living human being with emotions an want others to treat us with at least some bit of decency as a result.

But when it comes to Lindens, somehow the same rule doesn't apply. We hold them to different standards. Every Linden, regardless of their position, occupation, and expertise, is responsible for making sure all of Second Life works perfectly the exact way we want it to. We want that Linden in customer service to switch everything back to Viewer 1.x as much as we expect that Linden who works on inworld rendering to fix search so that our store is the first result in search (as opposed to every other store that wants to be first).

How often have you heard that "Linden Lab can't do _______ right?" Every little thing from grid stability to which features are implemented in the viewer to whether or not a Linden can dress themselves -- the universal assumption is that Linden Lab is slow, bumbling, and inept. Never mind the fact that they, you know, created this huge virtual world that many of like to use daily. How has SL survived as long as it has while so many "Second Life killers" have failed? Because nobody else has been able to do it better yet.

The fact of the matter is: Linden Lab has made a lot of good stuff and done a lot of hard work. Without LL, there would be no SL. If it were easy to make a virtual world that supports as many users and does as much as SL, all of those competitors would have succeeded. OpenSimulator came about by reverse engineering Second Life -- yes its a clean room and yes it has lots of fancy things that SL doesn't -- but it wouldn't have come about on its own. Similarly, most of the popular third party viewers are based on code from Linden Lab.

Is the Lab perfect? Of course not, but they're human. Yes, they've taken missteps and made mistakes. And yes, some of their decisions may not have been so popular. Linden Lab is a business. They must do what the board of directors wants. They have to abide by the laws of the countries they reside in. And (arguably) more importantly, they must make a profit in order to continue their growth.

At the end of the day, though, every Linden is a regular human, just like you and me. Do you really think Lindens are going out of their way to make you crash? That they're going out of their way to cripple their own virtual world? That they have so little pride in their work that everything they put out is half-assed crap? What may seem like a little feature may have taken months it implement. And of course, like any other humans, they can make mistakes. In time, they often attempt to rectify their mistakes as well.

So next time you curse at the Lab or deride any given Linden, try to take a walk in their shoes. You just spent the last few months pouring your heart and soul into a project that will be inspected, critiqued, and ridiculed for everything from cosmetic issues to the technology it runs on. Much of your user base, despite clamoring for the project's completion, will resist using it because it is not what they are used to. A portion of those that do test your project will try it within the first 24 hours after beta release, find a flaw or experience an incompatibility, and then join that group of naysayers who decry the project. On top of that, they won't report the issue in the bug tracker, leaving you in the dark as they spread word of the issue to their friends and social network. A smaller portion of extremely vocal opponents will claim they could do it better, citing their degree in something or another that is comparable to your degree. They'll say that if you truly knew what you were doing the product would have had x, y, and z, all features that are in the pipeline but were deemed not quite stable enough for the first public launch. And every time you fix something, they'll criticize the architecture of your product and demand you start the entire project from scratch.

It's a thankless job, and nobody has to do it for us.

Setting Up OpenSimulator on Ubuntu

Sat, 02 Oct 2010 00:10:00 GMT

I'm not a third party grid fan, I but I do like the ability to have my own sandbox sim. I can build or try to make content here, exporting backups as I work. When I'm done I can just export the final version and import it to Second Life. Figured I'd share how I set this all up for those who want a similar sandbox.

I used a fresh install of the 32bit server edition of Ubuntu 10.04.1. I used 32bit since I am actually running OpenSimulator in a virtual machine with only 2GB of memory. No need for 64bit with that little memory. Also, OpenSimulator has (had?) a few issues with 64bit hardware so I figured I could sidestep those. If you want to install in a VM as well, try using VirtualBox and make sure you set up a VM to use bridged networking or host-only networking so it has its own discrete IP for access.

The first thing I did was to change my APT settings so that I don't install suggested or required packages. Suggested packages are sometimes useful, but I find that recommended packages are often unecessary. I actually make this change on every Debian-based machine I run.

So I added an extra file 11lean to /etc/apt/apt.conf.d/:

// Recommends are as of now still abused in many packages
APT::Install-Recommends "0";
APT::Install-Suggests "0";`

I decided to compile myself, just to see what it was like. Surprisingly, it wasn't actually that difficult nor long, even in a virtual machine. However, if compiling isn't your cup of tea you can grab various binaries from their official download page. The official download page also has links to third party builds so you can install the whole thing via apt if you want.

Before I built I needed the prerequisites.

sudo aptitude install git-core nant libmono-system-runtime2.0-cil \
libmono-microsoft8.0-cil

Git is not necessary, but the project uses a git repository. If you ever want to install the latest source you can use

git clone git://opensimulator.org/git/opensim

But, the wiki says not to use the head revision since they can be unstable. So I used the latest source release instead. For the record, I probably should have used /usr/src/local but I was lazy and did all this from my user's home directory.

wget http://dist.opensimulator.org/opensim-0.7.0.2-source.tar.gz
tar xzf opensim-0.7.0.2-source.tar.gz
cd opensim-0.7.0.2-source/
./runprebuild.sh
nant

And that was it. Had no errors while building. Before running I made a few changes.

First I installed mysql (to use that instead of sqlite) because that's easy enough to do.

sudo aptitude install mysql-server

Then I ran mysql and created a db for OpenSimulator. Make sure you actually choose your own password for the user

mysql -u root -p -h localhost
mysql> create database opensim;
mysql> use opensim;
mysql> create user 'opensim'@'localhost' identified by 'password';
mysql> grant all on *.* to 'opensim'@'localhost';
mysql> quit

Then I had to set up a few configuration files.

cd bin/
cp OpenSim.ini.example OpenSim.ini

Inside OpenSim.ini I commented out the sqlite lines with a ';' and uncommented the mySQL lines. I also set the password I chose above in the connection line. Turns out there's a separate config file for standalones, so I changed similar lines in that file too.

cp config-include/StandaloneCommon.ini.example config-include/StandaloneCommon.ini

Finally, I installed screen so I could "hide away" the process in a lazy way and finally ran the thing.

sudo aptitude install screen
screen
mono OpenSim.32BitLaunch.exe

When I ran that for the first time, it asked me a few things about the region and my first avatar. It all worked and it said the region was up.

Next up was accessing the sim. I used Imprudence, my current (and long-time) favorite third party viewer. I don't use TPVs often, but when I do I use Imprudence.

Had I set this up on my Linux desktop, I could have used the localhost grid but since I have a dedicated VM, I had to set up my own grid entry in the grid manager. Login is on port 9000 by default, so it was just http://test-vm-ip:9000. Selected my grid, entered the avatar name and password, and voila:

Look at that Ruth.

As a disclaimer: I'm not an OpenSimulator developer, and what worked for me might not work for you. I probably can't help you set up OpenSimulator - I used a combination of google and the official wiki to do what I did. I've never set up a third party grid, nor do I plan to anytime soon. I also have never set up OpenSimulator on Windows and the only time I tried on OS X I used a pre-packaged dmg from the download page.

Suggestions and improvements to this guide are definitely welcome, though this quick and dirty install worked just fine for me.

Other Grids

Sat, 02 Oct 2010 00:10:00 GMT

I like OpenSimulator but grids running on OpenSimulator aren't for me.

OpenSimulator is Cool

That might seem contradictory at first. If you like OpenSimulator, why wouldn't you like OpenSimulator grids? The answer is quite simple -- I like the ideas and goals of OpenSimulator. I like the potential, and I like the innovation. In fact, I installed OpenSimulator on my desktop within minutes of finding the project and remember grinning like an idiot standing there ruthed on my own standalone sim. In fact, I'll probably make a quick post about how to set up your own standalone OpenSimulator soon.

But notice that I said a standalone sim. That means that I was running a 1x1 grid of my own, managing (amongst other things) the list of users, the assets, messaging between users, and of course the simulator region all on the same machine. When you connect an OpenSimulator region to a grid, you rely on the userlist, assets, messaging system, and grid management provided by the grid's host. When connecting a region to OSGrid, for example, you use osgrid.org to provide that functionality.

Who is Accountable?

And there-in lies my problem. I need to trust the grid owner to keep my content safe and not misuse it. If a grid owner accidentally sets up their asset server without enough protection, or a grid owner purposefully opens up security on certain assets, the content is free game. Or hey, what if the owner decides to just log in as me, give half of my inventory full perms to a random account, then wipe it from the logs?

If that happened in SL, I could hold Linden Lab responsible. But who can I hold accountable for an OpenSimulator grid? You can't hold the OpenSimulator project responsible, due to their licensing policy. The grid owners, perhaps? Lets try to figure out who that is for OSGrid. I don't want to pick on them, but they claim to be the largest OpenSimulator grid on their front page and according to the OpenSimulator wiki they are the second oldest. If the OSGrid team can't be found or held responsible in any way, how could I expect to track down a smaller and less known grid's owner?

As a start, OSGrid Inc. is a California non-profit organization. So there must be a board of directors of some sort, but I'm not sure where to find that. On top of that, the Terms of Service, About, and Privacy pages are all empty. For the record, they were that way when I checked three months ago (mid June 2010) as well. My next step would be to check a who-is, which came up with a name. A quick google check verified that he was indeed the guy behind OSGrid.

The thing is, I was able to find a name to pin after a bit of searching. But what if a hypothetical grid owner covered his tracks, living outside the US and hiding his domain information. *If* I were able to find proof that he had misused my content, how would I track him down? Linden Lab has a lot to lose if this sort of scandal erupted -- whether or not LL actually did it. But this grid owner can just up and walk away.

Paranoia?

You might say I'm being paranoid. That no grid owner has stolen information yet. Does anyone remember Legend City Online? LCO was a grid that popped up in late 2008, back when the Lab announced the sim price hike and few other unpleasant changes. Many words were said about how great and how awful LCO was, how it would scare LL as worthy competition and how it would relieve LL by proving OpenSim grids aren't competition.

Well, the owner of Legend City Online supposedly banned Simone Stern (of Simone! Design) because of a dispute over a contract! As a side note, yes I did just link to Prok. Regardless, it is conceivable to locked out and seperated from your content in Second Life as well, but a Linden could not take your data and move it elsewhere. A third party grid owner could take your content and move it to SL.

So You Don't Like OpenSimulator?

I like OpenSimulator a lot. As an open source alternative to Linden Lab's grid and simulator software, it provides Second Life-like functionality to people who don't want to be constrained by Linden Lab or connected to the rest of the Second Life grid. And of top of that, usage is free. That makes it perfect for most academic and corporate use.

OpenSimulator is also good for personal use. Designers and builders can work in the privacy of their own space, creating backups whenever they want, and then export and import into Second Life when they are done.

In fact, to the average, residential Second Life user, an OpenSimulator grid could be a viable alternative to Second Life. Sure, the software is not as stable, and all of the latest and greatest from Second Life might not be available.

But, as a content creator, I am not sure I can trust a third party grid owner. Linden Lab, as a corporation, can barely protect my intellectual property and does so simply because it must. Will I receive the same protection, if any, from a grid run by a few individuals in their spare time? Could I accidentally give up all of my creations full perm by teleporting to rogue sim run by a hacker?

To be honest, IP is not really the issue. The bigger concern is whether or not someone else can use my IP and gain revenue at my expense. If I were just donating my skills and work, not expecting any revenue, OpenSimulator would be wonderful and amazing. But as long as I want to derive income from my work, OpenSimulator is worrisome to me.

Linden Lab Isn't So Bad

OpenSimulator offers many configuration options. Not just how a given simulator is configured, but even the grids themselves. There are multiple options for voice servers and money/transaction servers. While this flexibility is good for grid owners, it provides more unknowns for me as a content creator. In contrast, Linden Lab's walled garden provides a sort of comfort that is appealing.

We all know how well that walled garden attitude worked for AOL, but Second Life is not the same as the internet. Maybe, in a few years, when a "Second Life" protocol is put forth that binds Linden Lab and all other simulator software, which has content security built in from the ground up, then I'll trust OpenSimulator grids. But until then, those grids are as appealing as a sketchy site that tells me that my Linux based laptop needs to run their VirusScan.exe.

Linden Lab Viewer(s)

Wed, 08 Sep 2010 00:09:00 GMT

Times are a'changing in the world of SL viewers. Many people are searching for a new viewer, desperately trying various ones before throwing their hands up into the air and blaming Linden Lab for everything. Quite a few folks have written guides to help those displaced residents find a new viewer. Hey, I even started one, but then I got bored. So I figured instead of a giant viewer vs viewer post I'd mention something most folks seem to forget: Linden Lab had made and currently supports more than one viewer.

You might be staring slack-jawed wondering why I'm recommending something from Linden Lab. So I'll enumerate my reasons briefly and then expand on them a bit later.

Linden Lab makes Second Life.

No really. That's about it.

The Goods

Of course, you can get Viewer 2. That one's easy: get.secondlife.com.

Linden Lab still supports Viewer 1.x as well, at least for now. If you want any older official release just go to the old versions page on the wiki. One caveat, though, is that older releases may have security flaws and issues connecting to the grid. Also (imho) the official Viewer 1.x is just about the worst option out there for viewers nowadays.

The reason why it sucks is Snowglobe. Amongst other things, Snowglobe made it easier to submit, commit, and test patches that might eventually end up in the core viewer. So Snowglobe viewers have everything the regular viewers have plus a few extra features that havent't been as thoroughly tested.

Snowglobe is available in both 1.x and 2.x flavors, and still seems to be going under active development (albeit at a somewhat slower pace than last year).

It's worth noting that the Lab recently announced Project Snowstorm. Snowstorm seems to be very much like a Snowglobe 2.0, for Viewer 2.x, taking the best parts of the Snowglobe project and reworking the bits that didn't work. There's already been dev builds released from Snowstorm but I haven't tried them since they are dev/alpha builds.

The Pros

Snowglobe rezzes faster. This probably has to do with getting textures using http, but I'm not sure. Before Viewer 2, Snowglobe 1.x was my preferred viewer purely for its speed. The extra features were just icing on the cake.

Linden Lab open-sourced their viewer code. This allowed people to improve and extend the viewer. In fact, a good number of JIRA tickets were closed thanks to contributions from residents based on that open code. Despite that, most of the code in both the official viewers and thirty party viewers (based on the opensourced viewer code) was written by a Linden. So it has to be a pretty good base.

Related to that, Linden Lab doesn't have the resources to code check every line in a third party viewer. The Viewer Directory is "self-certified", meaning the developers are attesting that their viewer is TOS/TPV compliant. The onus of determining each viewer's safety is on the resident, not Linden Lab. You can download hundreds of applications (legally and illegally) from the internet, and just about every one of those apps could potentially contain viruses, trojans, spyware, etc. Even if you have the latest antivirus definitions and malware detection, would those tools be able to tell the difference between an encrypted packet being sent to Linden Lab and an encrypted packet going some shady developer's server?

I'm not trying to spread FUD about third party viewers -- they just require a bit more research to make sure they are safe. Regardless of your operating system, you as the user are the first line of defense for your computer. Assuming you trust Linden Lab (because you want to be on their grid), they're probably the safest place to get a Second Life viewer. For lack of a better analogy coming to mind, using an LL viewer is kinda like abstinence instead of using a contraceptive.

The Cons

The older official viewer is, as mentioned above, probably the lamest viewer around -- third party viewers included. That's because its sort of the "lowest common denominator" for all viewers. Every other viewer has its features and it has nothing on them. That's why you'll probably want to pick one of the other options from the Lab.

In general, though, viewers from Linden Lab are designed for the widest user base, leading to fewer optimizations. For example, the viewer is able to run on Pentium III processors, so it is not compiled with SSE2 support (which would make 3D computations marginally faster). Most of these kinds of computational advantages are barely noticeable in day to day usage, though, so I don't consider that a very large con.

What few optimizations are in place lead to "exclusion" of a section of the market. The best example I can think of is the way Second Life has favored NVIDIA graphics cards over ATI graphics cards. I don't know if Linden Lab actually had some sort of exclusion agreement in place with NVIDIA, but at the end of the day their favoring NVIDIA often leaves ATI users feeling left out and frustrated by the official viewers, especially since ATI has enjoyed a resurgence in popularity these last few years.

The fault, however, is not completely Linden Lab's. Linden Lab relies on OpenGL, a cross-language, cross-platform API for computer graphics. ATI didn't implement OpenGL very well in the past, so it made sense to optimize for NVIDIA. Now that ATI has (to some extent) caught up, it would probably be nice to see feature parity between the two vendors. Maybe that's why shadows are still in alpha?

The biggest con, however, is that development of the official viewer is a slow moving beast. The Lab's QA cycle is long, and new features and improvements take a while to roll out. That's where I see Snowglobe/storm stepping in to pick up the pace.

In the End

I use Viewer 2.1 as my main viewer. It works well enough for my needs on my two computers. Both of my machines were purchased with Second Life in mind, so I did my best to make sure I had hardware that worked. For me, that meant getting mid to high end NVIDIA graphics cards (8600M GT & GTX 260) and having at least 4GB of system RAM. I generally run Medium graphics on my laptop and Ultra on my desktop. Thus far, I haven't crashed very often (maybe once or twice a month?)

Once Snowstorm brings Snowglobe 2.x up to parity with Viewer 2.1 and Snowglobe 1.4, I 'll probably switch to that. Linden Lab has made it clear the future is Viewer 2.x and to be honest, I kinda like the interface.

If I ever need a version 1.x Viewer, I go back to Snowglobe. Sure, I may be missing a few fancy bells and whistles from third party viewers, but I almost never need them so I didn't mind. When I do, I use the viewer with the feature I need.

As always, your mileage may vary. Just don't discount any viewers on account of their coming from the Lab.