02 July 2014

Finally, 64-bit Firestorm for OS X

One of the requests we get a lot from folks is for a 64-bit version of Firestorm for Mac users. There have been a few Firestorm releases in 64-bit versions for Windows, and a couple for Linux, but OS X has been a tougher nut to crack. The big problem has been the stack of libraries that needed to be rebuilt for the Mac.

Cinder Roxley took up that challenge about a month ago. There were some universal (64- and 32-bit combined) libraries already, but she went through and redid the rest, and published the results. She also made the necessary changes to Firestorm itself. That was a pile of work, and I'm thankful she did it.

This past week or so, I went through and reproduced her results. The goal here was to make sure everything would build and run on OS X 10.7, the Lion release. In several cases, I had to redo how the libraries were built. There were a couple where the programmer who wrote the library was just too damned smart and checked at the time the library was used in an application that the library was built for the same architecture as the source code used in the application. (Yes, curl and c-ares, I'm looking at you.) That broke rather badly for a universal library.

The biggest headache was in the apr (Apache Portable Runtime) library. I spent two days trying to figure out why it would simply hang at login time, with no error messages or any other indication of a problem. It turns out that, while the library is supposed to work when built as a universal binary, it's subtly broken. I wound up using the same trick I'd used on curl to make that work.

I had to rearrange a couple of things. curl also required a copy of libidn, so I sucked that down, made an autobuild package out of it, and built it. There's also a change in how the colladaom library is packaged: it used to include a binary blob of libminizip, but LL has recently changed the package to build it as part of zlib, instead. I tracked that change.

Many libraries would not build as universal easily. For those, I built 32- and 64-bit versions separately, and used the lipo tool to glue them together. If you want to see how that worked, check out my Bitbucket repositories; everything I did for the libraries is there.

With all that done, I went through, looked over the changes to Firestorm itself, and then pushed them to the master repository. The result builds properly in either 32- or 64-bit versions. (To build a 64-bit binary, you need to use Nicky Dasmijn's version of the autobuild tool and specify the -m64 switch; nothing else changes.) If you're switching from building a 32-bit Firestorm to building a 64-bit version, you should probably specify --clean to make sure you start fresh with everything at 64 bits. You also need to do a --clean when building for OS X from repository revisions after the change (revision 42327 or higher) if you've previously built for revisions before the change (42298 and lower).

It should be noted that with this change, Firestorm no longer supports OS X 10.6 (the Snow Leopard release). LL dropped support for that back in April, and we're following suit. There will be no SL-specific version of this package, like there is no SL-specific version of Firestorm for Linux and Windows. The reason is the same: the SL-specific version includes the Havok library we get from LL, and they have not provided a 64-bit version of that. When they do, we will think hard about dropping the 32-bit OS X version entirely, since any machine that can run Lion can run a 64-bit program.

Unless something breaks badly, this will be part of the next release of Firestorm. We have no plans to release anything before then. There's still a whole lotta debugging goin' on.

Still, i'm happy to have that chore out of the way. it will be interesting to see what difference it makes for users.

24 June 2014

The new SL announcement is not the end of the world

I can't recall the last time I saw as big an earthquake roll through the SL community as the one that hit last Friday with Ebbe Linden's off-the-cuff comment about LL developing a next-generation SL that would not be constrained by compatibility with the existing one. Ever since the story broke, there's been a lot of panic and a lot of misinformation floating around.

Folks, SL is not in any danger of disappearing any time in the near future.

To begin with, the timeline is well out there. LL is just now ramping up hiring to develop SLTNG, as I'll call it (by analogy to Star Trek: The Next Generation, commonly referred to as STTNG). It will take those new folks a fair amount of time simply to learn where the bathrooms are, never mind become truly productive in building a new platform. The estimate I've seen is beta in late 2015, and release sometime in 2016. I think this is optimistic.

Then there's the time it'll take to ramp up the new service and get people to join and make things and in general make it a viable, going concern. This will not be trivial; I wouldn't be surprised if it wasn't really viable until Christmas 2017.

Until that happens, LL will need money. Guess where they're going to get it?

If you guessed SL, you're right. They have no other real source of income. Their other products either withered to begin with or else were killed outright. Oh, there's a possibility they may raise some venture capital, though I'm skeptical. Given LL's trajectory, that would be a risky play for a VC, and they're not looking for risk. They're looking for the next sure thing.

So this means that LL will continue to support and, where appropriate, enhance SL. SLTNG is a bet-the-company proposition. They're hiring a nontrivial bunch of people to take on a big challenge that will take years to pay off, and whether it will pay off at all is very much an open question. SL is profitable, and they need those profits to keep the doors open while they develop SLTNG.

This isn't the first time that a company has pre-announced a new product while depending on the original. The standard business-school example of this is referred to as the Osborne Effect, after Osborne Computer Corporation, which went bankrupt in 1983 after pre-announcing new computers sent sales of the existing machine into the tank.

I don't know if this is a case where Ebbe's comments were a slip of the tongue - though one doesn't get to be CEO of a corporation, especially one with as much social media experience as Ebbe, without understanding exactly how widely his words would be reported - or if this was a calculated announcement before a carefully selected audience. Either way, he's running the risk of triggering the Osborne Effect.

Folks, this is a bad thing for LL. The only thing that could make it worse is the user community bailing prematurely. Guess what's happening? You're doing exactly that!

LL's not about to kill off, or even cut back on, SL any time soon. They can't afford to. And there's another reason, too. His (SL) name is Oz Linden.

Yeah, people love to bash Oz, but I'm very happy that he was chosen as the technical director for SL. Folks, he believes in Second Life. Disagree with his approach all you want to, but you have to admit that everything he's done has been with the best interests of SL at the forefront of his mind. Further, he's a long-time advocate of open source, well before he ever got on SL, and SL needs open source now more than ever: if the technical team for SL is being pared back, they have to leverage the efforts of other folks even more now than they used to. That means working with TPV developers closely.

Oz is sticking his neck out one hell of a long way by taking this position. If SL goes in the tank, his job goes with it.

All of this means that the sky is not falling. It's not even clouding up. SLTNG won't even be anything to take a sneak peek at for at least another year, and that's highly optimistic. It won't be a serious competitor to SL for two years at an absolute minimum, three more realistically, and four is not outside the realm of possibility. It's also possible that SLTNG will flame out and not work at all, or not achieve the desired results.

Now, this does not mean that there's nothing to be done to help SL and its users in the meantime. SL's not the perfect service, as many (including I) have argued. But it's still the same great place to be it was Friday morning, before Ebbe teleported into Hippotropolis. It's still worthy of the same care, and the same effort, and the same support, that it was then.

Jess asked, in a post to the official Firestorm blog, for ideas for one big change that would help SL not only stay around, but grow and thrive. Everyone's got their own thoughts on the subject; here's mine.

Before we think about what needs fixing, we first need to define the problem. The biggest problem SL faces is a simple one: what's there to do inworld? Personally, I think the reason that people join SL, log in a few times, and then go away and do something else is that there's nothing interesting to do. The platform is interesting in and of itself for about 15 minutes. Then the user is going to want to do something fun.

There used to be lots of fun places to go and do things. They've steadily dropped from sight, one by one. It's not that their makers lost interest; rather, it's that they couldn't afford to keep them running. Big, fun builds, testing the limits of the capability of the platform, are expensive to run - because the price of sims in SL is high. Even folks who have full sims at a grandfathered US$195 a month each are still laying out a significant chunk of change for the privilege. I am at a total loss as to how the folks behind Calas Galadhon afford their 10 sims (or is it 8 now?). Most of these things are a labor of love, and that kind of love gets hideously expensive. It's still worse for folks who can't get the grandfather deal.

This also raises the barrier to entry for new folks with new experiences to build. Even a homestead at US$125 a month is expensive for what you get, and you have to either have a friend with a full sim to hang it off of or else rent from a land baron, as I do, and he has to make his money, driving the cost up further.

The long and the short of it is that tier is a major issue, if not the major issue. Everything else comes back to it. Yes, it's LL's major income (at least I'm pretty sure it is, though exchange fees on L$ purchases and Marketplace commissions can't be trivial). Cutting tier would represent a major hit to LL's bottom line. The flip side of it is that a sim just isn't that expensive for LL any more. Hardware power has gone up as costs have gone down, and they can run more full sims on a physical box than they could five years ago when the current prices were set. The $1000 setup fee is ridiculous, as well: if it takes more than one person filling in one web form and clicking OK to provision a new sim, I'll be stunned. So LL's costs have to have gone down, but tier has remained the same as content providers and folks who give SL the richness that makes it the place to be wither up and blow away.

LL needs to lower tier. Now. Especially now, as a statement that SL is here to stay.

Meanwhile, there's one other aspect of this whole business that troubles me more than a little bit. Ebbe has very carefully not said that there's a place for open source in SLTNG. I've asked repeatedly, in channels I know he's reading, and he hasn't said word one to even acknowledge my existence, let alone answer the question.

I think this says it all, really. There is no place for open source in SLTNG.

I can understand why LL might reach this conclusion. From their point of view, it has to be frustrating as hell to roll out a new feature and then have to depend on a volunteer team of open source programmers to update their software to make the feature have a decent chance of being used by the SL user community. In a real sense, they've lost a big measure of control over their platform. That's a situation no business wants to be in.

Still, this ignores the simple fact that, by and large, Lindens don't understand how the platform is really used by the folks who pay the money. If you need an example, you need look no farther than Viewer 2. $DEITY, what a hideous mess that was. It took us a solid year of effort to de-suck that. LL adopted a lot of our ideas, but their viewer is still a pain to use for anyone who's become accustomed to Firestorm.

TPV developers have expanded the platform in many ways, all of which have kept users around on the platform. I personally would not be here if not for RLV, and that's entirely an open source effort. (At least I can't see LL adopting it as part of the standard platform!) Throwing us under the bus cuts off an important source of improvements.

I'm not aware of any company that's made the transition from open source to closed source and survived. LL may be between a rock and a hard place, but keeping SLTNG closed source would be a big "fuck you" to a large part of the user community - and community is what LL has to have above all. Communities form around the places I discussed earlier, and communities are what keep people coming back even when they've explored all the fun places.

So far, what I'm seeing is that LL doesn't want communities, but disconnected consumers. That, more than anything, will kill SLTNG, and SL, and LL as a company.

No, the sky's not falling yet. It could, though, if LL doesn't handle this right. Fortunately, there's lots of time between now and then.

17 June 2014

Kludges in the name of compatibility

The verdict is in, and server-side appearance is a big win all around. Bake fails have dropped to being very rare and fairly easy to fix. One whole class of copybots has been rendered much less useful (those that copied system clothing). Rezzing is much faster, as are outfit changes.

Nevertheless, not all is rosy in SSA-land. Before SSA, the viewer had the ability to set the avatar's bounding box height. The bounding box is the box the server's physics engine uses to decide when the avatar is going to collide with something and take appropriate action. Adjusting the height had the effect of changing the center point of the avatar, and thus making it rise or sink vertically.

SSA changed that. Since all of the parts of the avatar's bounding box are determined by the shape and attachments the avatar's wearing, the SSA bake oven can figure it out all by itself. So it does. Since it's being done server-side, the viewer now has no ability to control it.

This removed a useful and popular feature. Many pre-SSA viewers had a control, like the one Firestorm called Z-offset, that let the user move her avatar up or down. This was useful for mundane things like not sinking into a chair, as well as compensating for some rather extreme clothing and the like.

It was also widely used to compensate for animations that were set up for one height of avatar, making them lift smaller avatars into the air and sinking larger avatars into the ground. This capability was automated in the RLV specification with the @adjustheight command.

When it was discovered during SSA testing that the Z-offset feature no longer worked, we raised the issue with the folks at LL. Nyx Linden went out of his way to implement a fix on his own time: the hover attribute on an avatar's shape layer. The fix works well for what it does, but it doesn't cover all of the use cases - and arguably the ones it doesn't cover are the most common ones.

Henri Beauchamp fixed the omission. Unfortunately, he did it in a really hackish way: he took the Z-offset specified with the control, or @adjustheight, and modified the shape the user is wearing. It works, to be sure, but it's a real kludge.

There are several problems, most notably that the shape must have modify permissions for the feature to work at all (else the SL permissions system is violated, a strict TPVP violation) and adjusting the height results in modifying an asset on the SL asset server. I find the latter most curious, since Henri resisted implementing the current outfit folder in CoolVL Viewer based on his unwillingness to depend on automatic asset updates from the viewer.

The Firestorm team discussed it internally, and decided not to implement this kludge. We felt it was just too problem-prone, as well as either being limited by the permissions system or else requiring a violation of it to be useful in many cases where the user has purchased a no-mod shape. As it happens, LL has said that shapes are not intellectual property and therefore not protected by the permissions system...but bypassing it on this basis makes us vaguely uncomfortable. (And yes, allowing shape import/export makes us a bit uncomfortable as well, but since the LL viewer does exporting without considering permissions...)

Marine Kelley now has a product, the Pretty Mummy set, that depends on @adjustheight to work properly. It looks really nifty, with several components, both fitted and unfitted rigged mesh, and has a lot of capability and a lot of complexity. However, it apparently does not work well if @adjustheight is broken. Marine's answer is to tell people to use her viewer or CoolVL Viewer, which have Henri's kludge in them. (She also tells people to use Singularity, but according to one developer, that viewer doesn't have the kludge - and won't implement it either, for the same reasons we won't. We're not sure why Singularity users can see the item properly, if in fact they can.) Further, the product seems to issue @adjustheight whenever the avatar is moving - several times a second. This is a recipe for corruption.

The right answer is not to kludge around the lack as Henri did, but rather to implement a proper Z-offset mechanism in SL that propagates through the SSA bake process. This will require LL to help out. What we don't know is why Nyx did it the way he did. We suspect, but do not know for sure, that a real fix was suggested and turned down internal to LL. If that's the case, then we may not be able to convince LL to implement it properly.

Until this is fixed right, we see no reason to implement Henri's kludge. We've come up with a tiny bit less kludgy solution internally, and may implement it if nothing better is possible (involving physics layers, which aren't protected assets). Still, the right answer is to get LL to do it right.

We're especially not going to implement Henri's kludge for the sake of compatibility with one product. Sorry, Marine.

17 November 2013

Some Mistresses are more equal than others

For a couple of years, I was a member of the Sisterhood of the Latex Dolls. The Sisterhood is a society devoted to the love of latex and BDSM in Second Life. As the name implies, it is a Sisterhood: male avatars may apply, but must be transformed to female before they begin the path to becoming a Sister.

To become a Sister, an applicant must pass an interview that's designed to see if she's interested in what the Sisterhood is. She then must spend at least one month as a Potential Latex Doll. During that month, she spends some amount of time bound to racks in public view at the Sisterhood's home, at Latexia in the Fetish VooDoo region, naked except for collar and cuffs. She gets a series of lessons about the Sisterhood's history and principles, and at the end of that course, she is given an examination by specially selected Sisters and, if she passes, granted the right to become a Sister herself.

Being a BDSM-based organization, there are Mistresses (in two flavors, Mistress and Switch) and Slaves, as well as Trainee Dommes (in training to become a Mistress or Switch). The uniforms are different among the ranks. in theory, Mistresses and Switches can give orders to Slaves and Potentials, though there are limits: the Sisterhood as a whole operates on the SSC (safe, sane, and consensual) principle, and limits and safewords are strictly observed.

Every Sister is identified by an ID designator. I was known as M12, holding the rank of Mistress, as well as being a Priestess of the Latex (qualified to preside at ceremonies and give final exams to Potentials), Senior Teacher, and (possibly ex-) co-Head of BDSM. I put in a lot of time and effort in the Sisterhood, and it, for quite a while, was a second home for me in SL, as well as for several of the subs in my family. My SL wife, Chibi Souther, was M924; Bridget Pobieski was 218; AliceTheKitty was 531; Molly (Molly808) was 509. Other Sisters passed through our family as well.

The Sisterhood has eight core principles, known as the Eight Obediences. In theory, every Sister, from the newest Slave to the two HeadMistresses, is equally bound by them. In fact, one of the Obediences is Obedience to Equality. The Sisterhood teaches that Obedience to Equality means that, while there is a hierarchy, every Sister is equally valuable and equally bound by her duty to the Sisterhood and to the other Sisters, and to society as a whole. No Sister is better or more important than any other.

Unfortunately, this is only true if you're not a HeadMistress. If you are, Obedience to Equality does not apply to you.

Alice was a controversial Sister. She did a lot to alienate people during her time as a Potential. After becoming a Sister, though, she settled down and worked hard, doing a lot to revive the weekly dance parties at Latexia and being there for people who had questions. There were a few who refused to accept her, but for the most part, she was doing well.

Then one day, she organized a play party. At that party, Riona inion an Bandia (Becky Baroque), M37, and Alice got into a disagreement about Riona not following SSC. Edit: Alice has since corrected me. The disagreement was about Riona monopolizing the available time and play resources. (Considering the serious nature of a violation of SSC, I needed to correct the record here.) Now, Riona is a proud, haughty Mistress who does not take any sort of backtalk from Slaves, no matter what the cause, good or not. (Remember Obedience to Equality? This is not the last time you will see it mentioned in this tale.) She objected strenuously. The dispute simmered for a few days, and wound up in a meeting in the office of one of the HeadMistresses, Lara Boyle (LatexGirlLara Boyle), M85. At that meeting, Lara and Riona hounded Alice mercilessly, to the point that other Sisters present were objecting. I certainly did, and got a warning from Lara for my pains.

Alice, not to put too fine a point on it, snapped. She made a very ill-advised comment about car bombings. For reasons that are not mine to disclose here, that struck a very personal nerve in Lara. Her response was to summarily eject Alice from the Sisterhood. The other HeadMistress, Kiriko Kiama, M829, intervened, and M85 reduced it to a suspension. At that point, Alice's temper got the better of her, and she made another ill-advised comment - and this time, Lara ejected her and Kiri backed her up.

The problem is that Alice's second comment was that she was being punished for doing the same thing Lara had also done, in public. And she was completely correct. Lara had publicly commented that the Boston Marathon bombing was deserved because of Boston's prior support for the IRA.

Now, to me, Obedience to Equality means that the HeadMistresses are subject to the same rules as every other Sister. This was a blatant violation of that principle. Further, the HeadMistresses must not only be unbiased, but must be seen to be unbiased. Lara is anything but.

Lara and I had had other problems in the not too distant past. I had done a lot of work making Sisterhood uniforms for use on OpenSim grids, especially LFGrid, where Dolma Dollinger, M30, had set up a Fetish VooDoo sim as a test and possible refuge in case Second Life became unusable for some reason. We set up an organized visit, known as a dollwalk, there one Sunday afternoon. Kiri attended it; Lara objected to it, for reasons I'm still not sure I understand. In the process, Lara accused me officially and publicly of acting in bad faith. She'd later apologized to me in private, but refused to do so in public.

Even so, I was prepared to continue until she showed that she does not consider herself bound by the Obediences. That was the final straw. I left the Sisterhood, publicly and finally.

After I did, I got notecards from a few Sisters and former Sisters. A couple of former Sisters who had gone on to do other things in the SL BDSM world told me privately that they agreed with my reasoning and similar experiences had run them off as well. Several Sisters said that my departure saddened them, and they hoped to remain friends. I still consider many Sisters friends, even though I don't see much of them any more.

I have a lot of respect for Lara when it comes to BDSM. In RL, she's a former professional domme, and her methods and understanding of BDSM are quite good and largely track my own. That's what attracted me to the Sisterhood in the first place. But when it comes to the Sisterhood, I just can't accept what she's done and how she's done it.

Dolma spoke to me the other day about what it would take to get me to come back. Put simply, I won't return until the HeadMistresses operate with all of the Obediences - including Obedience to Equality - firmly at the forefront of all they do. That includes Lara formally recognizing that she punished Alice for doing something she did herself and that doing so was wrong. I realize there might be other issues about reinstating Alice as a Sister, but that's what fairness demands - unless Lara is prepared to accept the same punishment herself, instead.

Sisters are taught that the Obediences are at the center of the Sisterhood. That, to put it simply, is a lie, and a repellent one. I can't condone such with my work and my presence.

Edit, 21 November: This was Kiri's response to seeing this post:
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:15:45 2013)You have been ejected from 'The Latex Dolls' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:16:14 2013)You have been ejected from 'Latex Sisterhood' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:16:34 2013)You have been ejected from 'Latex Doll in Training' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:17:18 2013)You have been ejected from 'Latex Sisterhood Teachers' by Kiriko Kiama.
[2013/11/18 21:57] Kiriko Kiama: (Saved Mon Nov 18 10:18:21 2013)You have been ejected from 'Latexia Mall Merchants' by Kiriko Kiama.
She missed a couple, but I left them myself when I saw this.

28 September 2013

*!:{[%CuteStoreName%]}:!* and other annoyances

I was digging through my inventory a while ago looking for some clothes I'd picked up. I knew what the store name and item name was, but I couldn't find the item itself. I had to resort to slogging through a stack of results returned by inventory search.

I have no idea why vendors insist on giving their items in inventory cute names with all sorts of special characters around them. It makes life more difficult for their customers. Yes, I know organizing one's inventory is a tedious chore. I know that damned few people do it, especially when compared to the large number of people who say they're going to do it or need to do it or get halfway through ti and quit doing it.

But making it basically impossible to find the vendor's name without knowing which sets of cute special characters they wrapped their store name in this week (yes, they do change, which just makes the problem worse) doesn't help. It just means that you have to look and look and look, manually.

Lokii Violet is a good friend (even if she does have an unhealthy attachment to flamingos! :3 ) who owns a store named Malfean Visions. Good stuff, and reasonably priced. But I sincerely wish she'd not gone with :{MV}: as her store tag. Gah.

To make matters worse, Jaimie Earst turns things around. At least if the store name comes first, once you find it, you've found everything else that vendor makes...but not Jaimie. Her stuff is named *item by Jaimie Earst. That means that it's scattered around everything else where the vendor used a * for decoration.

Why do vendors feel the need to get cute like this? I wish they'd stop.

30 August 2013

Worse than useless

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.

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:
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.