Ever since we announced that we would be concentrating exclusively on Firestorm and ending work on Phoenix, back in 2011, there's been one group of users who have been complaining loud and long: users of the OTR instant message encryption facility. They've been demanding we port it to Firestorm ever since that day and refusing to migrate until we do.
There's one major problem: OTR, as implemented in Phoenix, is worse than useless. That's because there's a major flaw in how it handles the encryption key exchange: it does it in-band, over the same channel that's about to be encrypted. There's no reason to believe that LL didn't crack it within hours of it being released.
(There's another, smaller problem: The code itself is, to put it bluntly, unreadable crap. That can be cleaned up, though.)
Cryptography is incredibly hard to get right, and incredibly easy to almost get right. The difference is that almost right is worse than no encryption at all. It gives the users a false sense of security, so that they say things over the supposedly secured channel that they would not say if they knew it was insecure.
The OTR code in Phoenix is almost right. Because of the flaw in the way it handles the key exchange, anyone who can listen to the traffic can simply snag the key as it floats by and use it to decrypt the messages, undetectably.
There are well-designed protocols to handle key exchanges and the like, as well as well-designed cryptosystems that, when properly implemented, can provide reasonable security against real-time eavesdropping. Cinder Roxley is working on implementing such a system in Firestorm, to serve the folks who think they need to encrypt their messages. This is harder than it looks, because there are a couple of constraints that don't apply to the usual case. Not only do we need to make it work without using some sort of central service, but we also need to do it without revealing the user's IP address to his intended communication partner, which a direct key exchange would do. The problem's not insoluble, but it's not easy, either.
I don't know why people think they need to hide their IM traffic from LL. Really, now. If you don't trust LL, then why are you using SL in the first place? Use some other way of getting your messages through that don't involve a third party. Some folks argue that everyone should encrypt everything as a matter of course both to confound those who would look for encrypted traffic (usually, this is immediately followed by a rant against the surveillance state) and to remove the stigma associated with encryption. I'm not entirely unsympathetic to such an argument, but it smacks of paranoia.
Personally, I think the people complaining about a lack of OTR in Firestorm need to get a life, and assess the true risks of interception are, and the costs of having their traffic monitored by LL or others. Fundamentally, such an analysis would reveal a much simpler reason that neither LL nor anyone else is monitoring what they say: they just don't care. They've got much better things to do than listen in on your steamy gay furry BDSM scene. (And if that's truly what you're worried about, how about embracing it and being proud of it instead?)
We'll do OTR, or something secure, in Firestorm soon enough...but the kind of complaints we've been hearing are just simply out of proportion.
30 August 2013
29 August 2013
"Self-defeating, if not horribly unproductive"
(For reasons that will be obvious, this post, even more so than most on this blog, is explicitly my own personal opinion and not that of the Firestorm team as a whole.)
For a while now, the Firestorm default grid selection hasn't included InWorldz. The reasons for this are varied, but center on a series of changes IW made to their server software that had the effect of rendering it incompatible with Firestorm, as well as pretty much every other viewer that will run with Second Life or a stock OpenSim grid. Those bugs have been there for more than a year now. When we heard about them, we went to the IW folks and asked if we could help resolve them. We never heard back, so we assumed they weren't interested. That assumption was reinforced when we heard that the IW team had forked Firestorm for an IW-branded viewer.
Because of that, some folks had reached the conclusion that we weren't pro-IW, or even IW-friendly. I can see why; OTOH, I hope they can see why we thought they weren't exactly Firestorm-friendly, either.
There's another reason that some of us, I especially, aren't exactly fond of the InWorldz team. Their lead viewer developer - who, I'm told, gets paid something for the work - is McCabe Maxsted, formerly of Imprudence. At least at one point in the past, McCabe was on record as claiming that Phoenix was nothing more than a griefer viewer because of its Emerald heritage, and because some of the same people were involved in the project.
He made this accusation on an interview show with Paisley Beebe, with me in the audience. (I was there because of a preceding segment, where my good SL and RL friend Axi Kurmin was being interviewed about something or other.) This was nine days after the launch of Phoenix and shortly after the banning of Emerald. Essentially, he said that people shouldn't trust Phoenix, and should use Imprudence, because of its open nature and embrace of "free software". (My opinion of soi-disant "free software" is another rant.)
Needless to say, this offended most of the team.
Fast forward to a few days ago, when the subject of an InWorldz Viewer release that was pretty thoroughly broken came up on the IW forum. The general consensus was that it was best to roll back a release, but then the discussion turned to Firestorm and how we were supposedly anti-IW. Cinder Roxley posted what was really happening to the forum, and that got things out into the open, and hopefully resolved. But there's one loose thread, yet...
McCabe posted:
The Firestorm team is fully committed to supporting OpenSim grids into the future. We want to be the go-to viewer for OpenSim, as well as Second Life. That includes InWorldz. We'll be happy to make sure Firestorm works as well on IW as it does everywhere else, as long as the IW grid isn't gratuitously incompatible with OpenSim as a whole (or even if it is and the incompatibility doesn't require a pile of code to handle). I hope that IW does what it takes so there's no technical need for a separate viewer for their grid. I've been asked to bring one of my products, the Tonya's PASS skin management system for petite avatars, to IW. I'm considering it; one of the things getting in the way right now is that I have to run a specific viewer for IW. If that changes, I'd be a lot more inclined to do it.
The ball's in your court, IW.
For a while now, the Firestorm default grid selection hasn't included InWorldz. The reasons for this are varied, but center on a series of changes IW made to their server software that had the effect of rendering it incompatible with Firestorm, as well as pretty much every other viewer that will run with Second Life or a stock OpenSim grid. Those bugs have been there for more than a year now. When we heard about them, we went to the IW folks and asked if we could help resolve them. We never heard back, so we assumed they weren't interested. That assumption was reinforced when we heard that the IW team had forked Firestorm for an IW-branded viewer.
Because of that, some folks had reached the conclusion that we weren't pro-IW, or even IW-friendly. I can see why; OTOH, I hope they can see why we thought they weren't exactly Firestorm-friendly, either.
There's another reason that some of us, I especially, aren't exactly fond of the InWorldz team. Their lead viewer developer - who, I'm told, gets paid something for the work - is McCabe Maxsted, formerly of Imprudence. At least at one point in the past, McCabe was on record as claiming that Phoenix was nothing more than a griefer viewer because of its Emerald heritage, and because some of the same people were involved in the project.
He made this accusation on an interview show with Paisley Beebe, with me in the audience. (I was there because of a preceding segment, where my good SL and RL friend Axi Kurmin was being interviewed about something or other.) This was nine days after the launch of Phoenix and shortly after the banning of Emerald. Essentially, he said that people shouldn't trust Phoenix, and should use Imprudence, because of its open nature and embrace of "free software". (My opinion of soi-disant "free software" is another rant.)
Needless to say, this offended most of the team.
Fast forward to a few days ago, when the subject of an InWorldz Viewer release that was pretty thoroughly broken came up on the IW forum. The general consensus was that it was best to roll back a release, but then the discussion turned to Firestorm and how we were supposedly anti-IW. Cinder Roxley posted what was really happening to the forum, and that got things out into the open, and hopefully resolved. But there's one loose thread, yet...
McCabe posted:
I've said this elsewhere, but it bears repeating here: I have no interest in any kind of viewer wars, viewer blaming, or anything of that nature, and at best I'd call that kind of rhetoric self-defeating, if not horribly unproductive. We all care about the virtual world platform, and want to make it the best place possible for people. People should focus on that, instead.I'm happy to hear that. Now, how about apologizing for that slam you laid on the team for the world to see?
The Firestorm team is fully committed to supporting OpenSim grids into the future. We want to be the go-to viewer for OpenSim, as well as Second Life. That includes InWorldz. We'll be happy to make sure Firestorm works as well on IW as it does everywhere else, as long as the IW grid isn't gratuitously incompatible with OpenSim as a whole (or even if it is and the incompatibility doesn't require a pile of code to handle). I hope that IW does what it takes so there's no technical need for a separate viewer for their grid. I've been asked to bring one of my products, the Tonya's PASS skin management system for petite avatars, to IW. I'm considering it; one of the things getting in the way right now is that I have to run a specific viewer for IW. If that changes, I'd be a lot more inclined to do it.
The ball's in your court, IW.
27 August 2013
Exports and imports and permissions
Recently, there's been an increase in misinformation surrounding the export of objects from Second Life. Part of the upsurge is because the Singularity viewer's latest release includes the ability to export a linkset as a COLLADA .DAE or Wavefront .OBJ file, which can then be fed to things like Blender for hacking on and eventual reimport as mesh objects.
The baseline for this discussion is paragraph 2.b of the Third Party Viewer Policy, which says:
Exporters have been around for a very long time. They predate the Emerald viewer. The first copybot tools predate even the open-sourcing of the viewer code. LL had been trying unsuccessfully to get a handle on them for as long as they'd been around, and the Third Party Viewer Policy finally gave them some leverage.
Exporters are good things for some content. While any animations, textures, and the like you create, you should have on your local computer already, there are other things that get created that don't exist outside of SL unless you export them. Some, like scripts, are easy to export with a simple copy and paste. You can't copy and paste a prim, though, much less a full linkset (an object made out of multiple prims, from a chair to a full castle) with all of the complexity that goes with it (texture parameters, scripts, colors, you get the idea).
Emerald and Phoenix had an exporter. With their demise, though, there's a void in the content creator's toolset. We've been working for quite a while on adding export capability to Firestorm. Techwolf Lupindo has written an exporter, designed to be rigorously accurate and to honor the TPVP to the letter, while still giving meaningful capabilities to the user. There's a whole framework involved for selecting what's to be exported, checking the creator of every component and only exporting those components that are created by the user, and getting the data out and back in. The point is to allow a creator to back up and restore whole creations so that they could be replaced if an inventory corruption or account problem destroyed the originals, as well as permitting copying things to other grids.
It got disabled in Firestorm at the last minute because it didn't pass QA. Cinder Roxley is working hard on fixing the problems so we can enable it in 4.5.1.
Meanwhile, Singularity's Latif Khalifa wrote a function to export linksets to mesh files, and included it in the latest release. I haven't tried it myself, but I think it's a good thing overall. It lets a creator prototype in prims in SL and then refine the result into a nice mesh object. We've asked for, and gotten, permission to include it in Firestorm, though Cinder's reworked it a bit to integrate it seamlessly into the existing exporter framework.
There's been some confusion recently about having export capability and what it does to content security in SL. The biggest claim is that all it takes is removing two lines of code and it's a free-for-all. That's always, always been true in SL, ever since the viewer was open sourced. Textures, in particular, have always been vulnerable. Scripts aren't, simply because they're never sent to the viewer unless the user has the ability to edit them. (They execute on the sim host, not in the viewer.) The exporter doesn't add anything new here.
Another claim is that the mesh exporter will export any mesh object. I wish it did, actually; there's an item that's freely available and uploadable, but can't be edited in Blender, that I'd love to let SL export in a form that Blender can work on. (No, there are no licensing restrictions that would prohibit this.)But no, nobody's got an exporter that will do mesh objects. Edit: I was incorrect. Singularity's exporter, and therefore Firestorm's, will indeed export mesh objects. They will not export rigging information, however, so rigged mesh clothing and the like would have to be rerigged by any putative copybotter.
At one point, it was claimed that the Firestorm exporter was in violation of 2.b because it allowed export of a linkset that wasn't entirely created by the user. Siana Gearz even went to LL to complain about it. Since Firestorm does not export any component that was not created by the current user, and the policy says "the Third-Party Viewer must verify that the Second Life creator name for each and every content component to be exported", LL agreed that we're following the letter and spirit of the TPVP.
This is ironic, because Singularity's exporter will happily export a sculpted prim with a sculptmap that was not created by the current user. We will, of course, fix that in Firestorm.
So, to sum up, the exporters in Firestorm and Singularity don't add any ways to steal content that didn't already exist in other forms. (I'm certain Singularity will fix that one hole I just mentioned.) They do add capabilities for content creators, and that's a Good Thing. No need to get alarmed.
The baseline for this discussion is paragraph 2.b of the Third Party Viewer Policy, which says:
You must not use or provide any functionality that Linden Lab’s viewers do not have for exporting content from Second Life unless the functionality verifies that the content to be exported was created by the Second Life user who is using the Third-Party Viewer. Specifically, before allowing the user to export the content, the Third-Party Viewer must verify that the Second Life creator name for each and every content component to be exported, including each and every primitive or other content type, is the same as the Second Life name of the Third-Party Viewer user. This must be done for all content in Second Life, including content that may be set to "full permissions."That's pretty simple. If you didn't create it, you can't export it, even if it's full permissions. (Much full-permission content in SL is licensed only for use within SL.) This applies to prims, textures, scripts, and anything else.
Exporters have been around for a very long time. They predate the Emerald viewer. The first copybot tools predate even the open-sourcing of the viewer code. LL had been trying unsuccessfully to get a handle on them for as long as they'd been around, and the Third Party Viewer Policy finally gave them some leverage.
Exporters are good things for some content. While any animations, textures, and the like you create, you should have on your local computer already, there are other things that get created that don't exist outside of SL unless you export them. Some, like scripts, are easy to export with a simple copy and paste. You can't copy and paste a prim, though, much less a full linkset (an object made out of multiple prims, from a chair to a full castle) with all of the complexity that goes with it (texture parameters, scripts, colors, you get the idea).
Emerald and Phoenix had an exporter. With their demise, though, there's a void in the content creator's toolset. We've been working for quite a while on adding export capability to Firestorm. Techwolf Lupindo has written an exporter, designed to be rigorously accurate and to honor the TPVP to the letter, while still giving meaningful capabilities to the user. There's a whole framework involved for selecting what's to be exported, checking the creator of every component and only exporting those components that are created by the user, and getting the data out and back in. The point is to allow a creator to back up and restore whole creations so that they could be replaced if an inventory corruption or account problem destroyed the originals, as well as permitting copying things to other grids.
It got disabled in Firestorm at the last minute because it didn't pass QA. Cinder Roxley is working hard on fixing the problems so we can enable it in 4.5.1.
Meanwhile, Singularity's Latif Khalifa wrote a function to export linksets to mesh files, and included it in the latest release. I haven't tried it myself, but I think it's a good thing overall. It lets a creator prototype in prims in SL and then refine the result into a nice mesh object. We've asked for, and gotten, permission to include it in Firestorm, though Cinder's reworked it a bit to integrate it seamlessly into the existing exporter framework.
There's been some confusion recently about having export capability and what it does to content security in SL. The biggest claim is that all it takes is removing two lines of code and it's a free-for-all. That's always, always been true in SL, ever since the viewer was open sourced. Textures, in particular, have always been vulnerable. Scripts aren't, simply because they're never sent to the viewer unless the user has the ability to edit them. (They execute on the sim host, not in the viewer.) The exporter doesn't add anything new here.
Another claim is that the mesh exporter will export any mesh object. I wish it did, actually; there's an item that's freely available and uploadable, but can't be edited in Blender, that I'd love to let SL export in a form that Blender can work on. (No, there are no licensing restrictions that would prohibit this.)
At one point, it was claimed that the Firestorm exporter was in violation of 2.b because it allowed export of a linkset that wasn't entirely created by the user. Siana Gearz even went to LL to complain about it. Since Firestorm does not export any component that was not created by the current user, and the policy says "the Third-Party Viewer must verify that the Second Life creator name for each and every content component to be exported", LL agreed that we're following the letter and spirit of the TPVP.
This is ironic, because Singularity's exporter will happily export a sculpted prim with a sculptmap that was not created by the current user. We will, of course, fix that in Firestorm.
So, to sum up, the exporters in Firestorm and Singularity don't add any ways to steal content that didn't already exist in other forms. (I'm certain Singularity will fix that one hole I just mentioned.) They do add capabilities for content creators, and that's a Good Thing. No need to get alarmed.
24 August 2013
SSA is a success, first time out
We've all had reason to bitch at LL in the past for doing things that have, to be charitable, been less than successful in not royally screwing up the grid. To their credit, they've gotten things worked out and running well again, each time. Even so, the experience has been less than promising.
Eventually, you'd think they'd feel snakebit and shy away from big changes. Thankfully, they haven't. They took on one of the biggest problems in SL, bake fail, and seem to be well on the way to banishing it from the grid once and for all.
Oz Linden has said that SL is the only place where it's not unheard of for someone to go to a business meeting and ask, "Where did my pants go?". That's not a recommendation, folks. What it is is bake fail: your avatar's appearance doesn't turn out the way you'd intended it to from wearing clothing and such because some parts of it fail to be shown properly.
That's the whole idea behind server-side appearance. Its purpose is to fix bake fail once and for all.
The original way of doing avatar appearance, before multi-attach, was that your viewer would select the system clothing layers (shirt, underpants, skin, etcetera) to wear, either from your selection as you were putting things on or from a message from the server at login time. It would obtain the information from each piece and assemble them, then tell the server "all right, I'm wearing this list". Your viewer would then put them all together, make one texture for each major body section (head, upper torso/arms, and lower torso/legs), then upload that texture to the sim and let it pass that out to everyone to show on your avatar. That last process is called "baking".
The limitation is that the first way of doing it could only handle one attachment per attachment point. That was fine until you got to things like furry avatars who wanted to wear accessories and furry body parts on the same attachment point at the same time. The Emerald viewer came up with one way of addressing this problem, namely to define secondary attachment points at the same location as the primary; this worked, as long as the user looking at the avatar was running a compatible viewer. Needless to say, many weren't. Without server-side support, though, ti was the best that could be done.
LL added the server-side support to go along with an early release of Viewer 2. Part of that support was the Current Outfit folder (COF), which regularized and standardized handling outfits no matter how many things were attached on any given point or any clothing layer. Phoenix added proper multiattach support and dumped the old way quickly; everyone else added it as well except for the CoolVL Viewer, which did it its own, incompatible way. (But that's another flamewar we've already had.)
The Current Outfit folder and multiattach/multiwearables made life a lot simpler, but they didn't change how the avatar textures were baked. Things were still shipped back and forth between the SL servers and the viewer. Each time something was sent over the wire was an opportunity for things to screw up, and when they did, you saw the Ruth shape, or the infamous poo-colored cloud, or last week's outfit, or just plain gray. The same thing could happen for lots of different reasons on the user's computer, including things as prosaic as running the viewer on a secondary monitor. (The bake process actually used the normal viewer's avatar display routines to draw the various textures on the avatar, then read the texture back out of graphics memory. This didn't work on a secondary monitor.)
SSA (originally called server-side baking, and now you know why) is designed to eliminate that kind of error. The key is that, with the COF, everything needed to create the avatar's appearance is present at the SL servers. Since it's there, they can simply add another set of servers, called the "bake ovens", to bake the textures and ship them out. No need to traverse the Internet multiple times, each time risking the data getting lost by some $6 consumer-grade cable router that can't handle a real workload or having DNS croak in the middle of things or any of the myriad failure modes that make SL such joy to troubleshoot. Just look in the COF, tell the oven to bake the textures from this list of assets, get the baked texture back, boom, you're done.
Of course, it's not quite that simple in practice. Not only did the bake ovens have to be built from the ground up, but the viewer code had to be rewritten to deal with not having to do the pile of work needed to bake the texture and then upload it. There was a lot of code refactoring that went into the viewer side of SSA. You heard us talk about how it was a big change? This is why. This is also why we chose not to add it to Phoenix, because it would have been a lot of work we'd have had to largely pioneer.
LL did all this, and they did something unusual: they coordinated their SSA efforts closely, and carefully, with the TPV community. That's because this would not work unless the viewers were ready first, before the server components were turned on. Then they were careful to test thoroughly. And test. And test some more. Then they got the TPV community involved in testing. And we tested every way we could think of. Only then did they start rolling it out to the grid. Even that was done differently from normal. They rolled it out to one or two RC channels, from 5 to 15 percent of the grid, and left it that way for a few weeks, to get lots of experience with how it was working before they flipped the switch for everyone.
All that care paid off. Yes, there are a few problems, but those are of much lower magnitude and severity than those associated with other recent big server rollouts. There are some folks who are showing up as gray; those who are actually running SSA-capable viewers (yes, we do get complaints from folks who appear gray, only to be surprised when they get told that Firestorm 4.3 isn't going to work any more!) usually have other issues like inventory loading and such that aren't related to SSA.
Folks, LL got this one right. They took their time to test thoroughly, they coordinated with the TPV community before dropping it on the grid, they listened to feedback, and they introduced it slowly and carefully, measuring as they went.
Will this be the end of bake fail? There's still work left to do, but there's good reason to believe that yes, it really will be.
And people who complain about LL adding features before fixing basic problems: This is an example of fixing basic problems. Bake fail was the single biggest cause of support questions for the Firestorm support team. Nobody will be more happy than they are to see it go away.
We complain at LL when they screw up. Let's cheer them on when they get it right. This time, they got it right.
Eventually, you'd think they'd feel snakebit and shy away from big changes. Thankfully, they haven't. They took on one of the biggest problems in SL, bake fail, and seem to be well on the way to banishing it from the grid once and for all.
Oz Linden has said that SL is the only place where it's not unheard of for someone to go to a business meeting and ask, "Where did my pants go?". That's not a recommendation, folks. What it is is bake fail: your avatar's appearance doesn't turn out the way you'd intended it to from wearing clothing and such because some parts of it fail to be shown properly.
That's the whole idea behind server-side appearance. Its purpose is to fix bake fail once and for all.
The original way of doing avatar appearance, before multi-attach, was that your viewer would select the system clothing layers (shirt, underpants, skin, etcetera) to wear, either from your selection as you were putting things on or from a message from the server at login time. It would obtain the information from each piece and assemble them, then tell the server "all right, I'm wearing this list". Your viewer would then put them all together, make one texture for each major body section (head, upper torso/arms, and lower torso/legs), then upload that texture to the sim and let it pass that out to everyone to show on your avatar. That last process is called "baking".
The limitation is that the first way of doing it could only handle one attachment per attachment point. That was fine until you got to things like furry avatars who wanted to wear accessories and furry body parts on the same attachment point at the same time. The Emerald viewer came up with one way of addressing this problem, namely to define secondary attachment points at the same location as the primary; this worked, as long as the user looking at the avatar was running a compatible viewer. Needless to say, many weren't. Without server-side support, though, ti was the best that could be done.
LL added the server-side support to go along with an early release of Viewer 2. Part of that support was the Current Outfit folder (COF), which regularized and standardized handling outfits no matter how many things were attached on any given point or any clothing layer. Phoenix added proper multiattach support and dumped the old way quickly; everyone else added it as well except for the CoolVL Viewer, which did it its own, incompatible way. (But that's another flamewar we've already had.)
The Current Outfit folder and multiattach/multiwearables made life a lot simpler, but they didn't change how the avatar textures were baked. Things were still shipped back and forth between the SL servers and the viewer. Each time something was sent over the wire was an opportunity for things to screw up, and when they did, you saw the Ruth shape, or the infamous poo-colored cloud, or last week's outfit, or just plain gray. The same thing could happen for lots of different reasons on the user's computer, including things as prosaic as running the viewer on a secondary monitor. (The bake process actually used the normal viewer's avatar display routines to draw the various textures on the avatar, then read the texture back out of graphics memory. This didn't work on a secondary monitor.)
SSA (originally called server-side baking, and now you know why) is designed to eliminate that kind of error. The key is that, with the COF, everything needed to create the avatar's appearance is present at the SL servers. Since it's there, they can simply add another set of servers, called the "bake ovens", to bake the textures and ship them out. No need to traverse the Internet multiple times, each time risking the data getting lost by some $6 consumer-grade cable router that can't handle a real workload or having DNS croak in the middle of things or any of the myriad failure modes that make SL such joy to troubleshoot. Just look in the COF, tell the oven to bake the textures from this list of assets, get the baked texture back, boom, you're done.
Of course, it's not quite that simple in practice. Not only did the bake ovens have to be built from the ground up, but the viewer code had to be rewritten to deal with not having to do the pile of work needed to bake the texture and then upload it. There was a lot of code refactoring that went into the viewer side of SSA. You heard us talk about how it was a big change? This is why. This is also why we chose not to add it to Phoenix, because it would have been a lot of work we'd have had to largely pioneer.
LL did all this, and they did something unusual: they coordinated their SSA efforts closely, and carefully, with the TPV community. That's because this would not work unless the viewers were ready first, before the server components were turned on. Then they were careful to test thoroughly. And test. And test some more. Then they got the TPV community involved in testing. And we tested every way we could think of. Only then did they start rolling it out to the grid. Even that was done differently from normal. They rolled it out to one or two RC channels, from 5 to 15 percent of the grid, and left it that way for a few weeks, to get lots of experience with how it was working before they flipped the switch for everyone.
All that care paid off. Yes, there are a few problems, but those are of much lower magnitude and severity than those associated with other recent big server rollouts. There are some folks who are showing up as gray; those who are actually running SSA-capable viewers (yes, we do get complaints from folks who appear gray, only to be surprised when they get told that Firestorm 4.3 isn't going to work any more!) usually have other issues like inventory loading and such that aren't related to SSA.
Folks, LL got this one right. They took their time to test thoroughly, they coordinated with the TPV community before dropping it on the grid, they listened to feedback, and they introduced it slowly and carefully, measuring as they went.
Will this be the end of bake fail? There's still work left to do, but there's good reason to believe that yes, it really will be.
And people who complain about LL adding features before fixing basic problems: This is an example of fixing basic problems. Bake fail was the single biggest cause of support questions for the Firestorm support team. Nobody will be more happy than they are to see it go away.
We complain at LL when they screw up. Let's cheer them on when they get it right. This time, they got it right.
19 August 2013
Last call
Linden Lab has announced that server-side appearance will go live across the entire grid this week.
This is it, folks. No more dithering. No more procrastination. No more excuses.
Fish or cut bait. (I started to use an expression the second half of which is "or get off the pot", but decided to be a bit more civil.) This is a major change to Second Life, and your viewer has to keep up. If you don't run a SSA-capable viewer, you're going to be left behind. Over 85% of the users on Second Life are already on SSA-capable viewers. Nobody's going to be sympathetic to those who aren't.
I'm really hoping that older viewers will get flushed out of SL by this change. The platform needs to advance, and it can't as long as people cling to 4-year-old viewers running on 10-year-old computers. That does not mean that they need to change how they interact with their viewer. Don't like the V2 user interface? Run Firestorm in Phoenix mode. Not good enough? Kadah Coba's doing excellent work with his Latency skin to make it even closer; that should appear in Firestorm 4.5.1. Still not good enough? Get Singularity, or CoolVL Viewer (now that Henri seems to have straightened out the current outfit folder handling). There are plenty of choices to run a modern viewer.
Yes, you might have to upgrade your 2003-vintage PC. You've been uncommonly fortunate in being able to run it as long as you have on SL. There are myriad options to get a computer good enough to run any modern viewer - yes, even Firestorm - for not a lot of money these days.
But if you're waiting till you can't use SL any more to upgrade, your wait is over. The time to upgrade was a while ago, but now you're rushing headlong at the brick wall.
Upgrade. Now.
This is it, folks. No more dithering. No more procrastination. No more excuses.
Fish or cut bait. (I started to use an expression the second half of which is "or get off the pot", but decided to be a bit more civil.) This is a major change to Second Life, and your viewer has to keep up. If you don't run a SSA-capable viewer, you're going to be left behind. Over 85% of the users on Second Life are already on SSA-capable viewers. Nobody's going to be sympathetic to those who aren't.
I'm really hoping that older viewers will get flushed out of SL by this change. The platform needs to advance, and it can't as long as people cling to 4-year-old viewers running on 10-year-old computers. That does not mean that they need to change how they interact with their viewer. Don't like the V2 user interface? Run Firestorm in Phoenix mode. Not good enough? Kadah Coba's doing excellent work with his Latency skin to make it even closer; that should appear in Firestorm 4.5.1. Still not good enough? Get Singularity, or CoolVL Viewer (now that Henri seems to have straightened out the current outfit folder handling). There are plenty of choices to run a modern viewer.
Yes, you might have to upgrade your 2003-vintage PC. You've been uncommonly fortunate in being able to run it as long as you have on SL. There are myriad options to get a computer good enough to run any modern viewer - yes, even Firestorm - for not a lot of money these days.
But if you're waiting till you can't use SL any more to upgrade, your wait is over. The time to upgrade was a while ago, but now you're rushing headlong at the brick wall.
Upgrade. Now.
Subscribe to:
Posts (Atom)