Ever since we announced the end of Phoenix support, people have been bitching and moaning about it. As I said previously, this should be a surprise to nobody. We've been saying this is what we'd do for a solid year. We told everyone right up front that our development efforts on Phoenix have ended and that we would make no more changes.
Well, it's now come to pass. If you ask a Phoenix question in the support group that isn't related to migrating to Firestorm, you'll politely be told that we cannot answer your questions any more and directed to the self-help group. The support team was very happy when midnight SLT came around last night so they didn't have to deal with Phoenix any more.
There have been a few comments recently from folks claiming to fork - or even "take over" - the development of the Phoenix viewer. While it's not available for a takeover, a fork is entirely possible. Forking is inherent in open source development; indeed, nearly all experts in the field of open source development claim that the freedom to fork is at the very foundation of what makes open source successful. I have no particular problem with this view.
However, I think forking Phoenix to keep it running in SL is a very bad idea, for the same reasons we stopped developing on it. There will be a lot of work that needs doing in a very short time just to get the ability to deal with server-side baking into it. You might be able to piggyback off of Henri Beauchamp's work - as we did to get mesh into Phoenix - but that will only be the beginning of your problems.
You'll have a fair amount of work on your hands just to bring the mesh renderer up to speed. The one in Phoenix 1691 is based off of the LL 2.8 viewer. Every other one is based off of at least 3.3, if not 3.4 (I think CoolVL's current version is 3.4, for one example). You'll likely need to roll that work in to be able to use the other code that's floating around.
There are other things people have been screaming for and we haven't done. Multiwearables and RLV 2.7 are the two biggest, and neither one is going to be trivial. There are many others.
This is going to be an immense amount of work. Anyone who's not already intimately familiar with the code will have a steep learning curve, as well; Phoenix was hacked on by a cast of thousands, with decidedly varying levels of competence at programming and at C++ (and those are two independent variables). I'm not kidding when I say it's an unmaintainable tissue of hacks held together by spit, chewing gum, duct tape, and baling wire.
One thing I don't understand is the fetish some of our haters have for accusing us of lying. We don't lie. We tell the truth as we see it. That's exactly what I've done in every posting I've made publicly, both here, on Google+, on SLUniverse, and on the LL forums. I've been wrong sometimes. I'm not perfect. Even so, it's still the truth as best I can say it. Just because you don't like the answer doesn't make it incorrect, far less a lie.
And we're doing exactly what we said we'd be doing. Don't like it? Fine. Go right ahead and fork Phoenix. I double-dog dare you. Go ahead and prove me wrong.
But somehow, I don't think that someone who just today picks up the code and gathers programmers who know what they're doing will be able to have it working before LL breaks Phoenix. Anyone who claims that without some serious achievements under their belt to back up the bluster is just blowing smoke.
01 January 2013
15 December 2012
The clock is officially ticking
At yesterday's TPV meeting, Oz Linden gave TPV developers notice: the server-side baking code is now in the queue to be rolled out to the grid. Here's the announcement he sent to the TPV developers list:
Why are they being so solicitous? Because this will break every existing viewer. Any viewer that does not have the new code in it will see every avatar that connects to Second Life through a simulator running the new code as either a cloud or as a gray shape. This means you will have to upgrade your viewer sometime in February or early March. No exceptions.
This is not news. Oz first told us of this change back in July. I said then that that put Viewer 1 on borrowed time, and I meant it. The loan is about to come due.
There have been a lot of vocal folks telling me I was lying about Viewer 1 being a dying codebase. Well, folks, you've been wrong all this time, and now it's time to shut up. These changes will be extremely difficult to backport to version 1 viewers, because LL refactored most of the avatar appearance code to let them split out the parts that do the baking. It's not a drop-in replacement.
Siana Gearz yells at me whenever I speculate about the maintenance load of Singularity. Still, I think they've got quite a substantial amount of work ahead of them. Henri Beauchamp did recently implement the Current Outfit folder in CoolVL, so he's at least got that work behind him.
And Phoenix? Stick a fork in it. It's done.
We've been saying for a year that we will not put any more significant effort into Phoenix. Adding the server-side baking code to it is a significant effort. We've got our hands full with Firestorm, and none of the developers has any desire to take time away from that and update Phoenix.
That's why we announced at today's Phoenix Firestorm Office Hour that we are ending support for Phoenix at the end of the year. The support team doesn't run it or know it very well any more, and the development team is heartily sick of patching it together one more time.
LL is not going to block older viewers. As Oz said at the meeting, "if you want to live in a world of gray, cloudy avatars, that's your choice - if a weird one - and we're not going to stop you." Similarly, we are not going to block Phoenix, or even remove the download. If you want to stick with it, go ahead - but don't complain to us when you can't see your friends.
If you want to still see everyone else, you will have to upgrade. There are folks who will be diehard V1 users and not even consider Firestorm or any other V3-based viewer. There are V1-based options for them; Phoenix will simply not be one of them any longer. For the rest of you, I strongly recommend you switch to Firestorm now so you can learn its ins and outs at your leisure instead of having to do it under the pressure of not being able to do anything on Second Life, period.
And for those of you whose computers are so old you can only run 1.23 or older Phoenix? Sorry, folks, but you will have to spend some money. There's no way around it. It doesn't take all that modern a computer to run Firestorm, but it does take one that's newer than 2003. If you can't swing that, then I'm sorry, but the platform has moved on and left you behind.
We've known this day was coming for a long time. So has anyone who was not willfully blind to it. I have no sympathy for the latter. Upgrade or leave, your call.
We have now made available the code for our upcoming server side baking changes - you will need to update to be compatible with this in order for users to see avatars correctly once the server side change is rolled out to the main grid (some time > 8 weeks from now, but no date has been set yet).
See https://wiki.secondlife.com/wiki/Project_Sunshine-Server_Side_Appearance for information on this new code, and watch it for updates.As Oz said in the meeting, the clock is now ticking. We asked for at least two months' notice, and yesterday we got that. LL would like to roll the code out to the grid in February, but they'll work with TPV developers to make sure we all have had the code and a good chance to implement it before they actually roll it out.
Why are they being so solicitous? Because this will break every existing viewer. Any viewer that does not have the new code in it will see every avatar that connects to Second Life through a simulator running the new code as either a cloud or as a gray shape. This means you will have to upgrade your viewer sometime in February or early March. No exceptions.
This is not news. Oz first told us of this change back in July. I said then that that put Viewer 1 on borrowed time, and I meant it. The loan is about to come due.
There have been a lot of vocal folks telling me I was lying about Viewer 1 being a dying codebase. Well, folks, you've been wrong all this time, and now it's time to shut up. These changes will be extremely difficult to backport to version 1 viewers, because LL refactored most of the avatar appearance code to let them split out the parts that do the baking. It's not a drop-in replacement.
Siana Gearz yells at me whenever I speculate about the maintenance load of Singularity. Still, I think they've got quite a substantial amount of work ahead of them. Henri Beauchamp did recently implement the Current Outfit folder in CoolVL, so he's at least got that work behind him.
And Phoenix? Stick a fork in it. It's done.
We've been saying for a year that we will not put any more significant effort into Phoenix. Adding the server-side baking code to it is a significant effort. We've got our hands full with Firestorm, and none of the developers has any desire to take time away from that and update Phoenix.
That's why we announced at today's Phoenix Firestorm Office Hour that we are ending support for Phoenix at the end of the year. The support team doesn't run it or know it very well any more, and the development team is heartily sick of patching it together one more time.
LL is not going to block older viewers. As Oz said at the meeting, "if you want to live in a world of gray, cloudy avatars, that's your choice - if a weird one - and we're not going to stop you." Similarly, we are not going to block Phoenix, or even remove the download. If you want to stick with it, go ahead - but don't complain to us when you can't see your friends.
If you want to still see everyone else, you will have to upgrade. There are folks who will be diehard V1 users and not even consider Firestorm or any other V3-based viewer. There are V1-based options for them; Phoenix will simply not be one of them any longer. For the rest of you, I strongly recommend you switch to Firestorm now so you can learn its ins and outs at your leisure instead of having to do it under the pressure of not being able to do anything on Second Life, period.
And for those of you whose computers are so old you can only run 1.23 or older Phoenix? Sorry, folks, but you will have to spend some money. There's no way around it. It doesn't take all that modern a computer to run Firestorm, but it does take one that's newer than 2003. If you can't swing that, then I'm sorry, but the platform has moved on and left you behind.
We've known this day was coming for a long time. So has anyone who was not willfully blind to it. I have no sympathy for the latter. Upgrade or leave, your call.
06 September 2012
LL shoots itself in the ass again: public JIRA is closed
Today, Linden Lab closed access to their JIRA. Anyone can still file bug reports, but only the one who filed the bug can see it outside of LL. This has always been the case for a few JIRAs, such as the ones in the SECurity category, but now it applies to all of them.
This is only going to hurt LL. It will cause many, many more duplicate JIRAs for them to sort through. Right now, it's common and good practice to search for an existing JIRA to make sure that the problem you're about to report isn't known. That will go away.
There's also a bunch of people who watch the LL JIRA and help with triaging, work with reporters to make sure the needed information it present, and suggest fixes without ever writing a line of code. Those folks just got the finger.
And, as I said in my last post here, having the JIRAs be secret hurts TPVs, too. It makes it much harder for us to know whether the bug we're hunting is a LL bug. It also makes it harder for us to realize that we just fixed an LL bug and contribute the fix back to them. They spend a lot of time assuring us they want our contributions. This change makes that much more questionable.
The stated reason is that the change will make the process easier for reporters. My guess is that it will: it'll be so much easier when bug reporters give up because their bug reports get ignored in the flood of duplicates and support requests that aren't bug reports and anything else.
I've heard speculation that this change is because the online games don't have publicly accessible bug trackers. Given Rod Humble's background, this reasoning certainly is plausible. The problem is that Second Life, fundamentally, isn't a game. It's a community. The more LL forgets that, the more they alienate users.
This is a poorly-thought-out change. It needs to be reversed, ASAP.
This is only going to hurt LL. It will cause many, many more duplicate JIRAs for them to sort through. Right now, it's common and good practice to search for an existing JIRA to make sure that the problem you're about to report isn't known. That will go away.
There's also a bunch of people who watch the LL JIRA and help with triaging, work with reporters to make sure the needed information it present, and suggest fixes without ever writing a line of code. Those folks just got the finger.
And, as I said in my last post here, having the JIRAs be secret hurts TPVs, too. It makes it much harder for us to know whether the bug we're hunting is a LL bug. It also makes it harder for us to realize that we just fixed an LL bug and contribute the fix back to them. They spend a lot of time assuring us they want our contributions. This change makes that much more questionable.
The stated reason is that the change will make the process easier for reporters. My guess is that it will: it'll be so much easier when bug reporters give up because their bug reports get ignored in the flood of duplicates and support requests that aren't bug reports and anything else.
I've heard speculation that this change is because the online games don't have publicly accessible bug trackers. Given Rod Humble's background, this reasoning certainly is plausible. The problem is that Second Life, fundamentally, isn't a game. It's a community. The more LL forgets that, the more they alienate users.
This is a poorly-thought-out change. It needs to be reversed, ASAP.
27 August 2012
How to screw up a release
As I write this, the QA group is beta testing Firestorm 4.2.2.29837. This has been one hell of a long day.
Yesterday, we were all hopeful and happy that we'd gotten 4.2.1 the hell out the door. We'd been beating on it to get the pathfinding tools in, and a bunch of crash fixes and translation updates and a few very highly requested features (control-shift-E for Edit Linked Parts being my primary original contribution, though I also ported the Flickr snapshot upload from Exodus) as well. We QAd it, we beat on it, everything looked good. We pushed all the needed changes to the various repositories, told the users to grab it and have fun, and went to bed.
I got up about 5:40 AM my time (US Central, GMT-6/SLT+2). When I sat down in front of the computer, I saw in the support chat that there was a problem. It turned out that 4.2.1 has a bug in it that makes most swinging doors not look like they act correctly (though they actually do). They appear to swing normally, then jump ahead, swinging farther all at once.
You can guess how many swinging doors there are in SL. You'll probably guess low. No, I don't have a number, but it's gotta be astronomical.
The thing that annoyed me especially: The front doors on my own house showed the bug! Worse, I'd noticed the issue a week or so ago, and blown it off!
Fortunately, our ace support person and walking JIRA encyclopedia, Whirly Fizzle, had already found the changesets that caused the issue. I whipped up a quick build and saw that yes, backing them out did fix the problem. A bit more jockeying, and I had a recommended course of action: back out three changesets directly in the release branch of the repository, bump the version number to 4.2.2, and ship it.
Oh, if it were that simple.
First, the build servers were behind a fiber cut as a result of an automobile accident in Boston. That delayed spinning the new release builds.
Then, while we were waiting on that, we discovered another problem, with another patch: some spinning objects stuttered and didn't show correctly if they updated while spinning. This is the problem that the patches we backed out were supposed to fix. We found the changeset that caused that and backed it out, and it seemed to fix the problem, with no side effects.
But we couldn't be sure. The LL JIRA that that changeset was reported to fix, PATH-542, was (and still is) secret. So how the hell do we decide? Have we reached the end of the string, or are there nasty side effects of not fixing that one? Without knowing what the problem is, we can't make an intelligent decision on what to do with it.
We spent a large chunk of the afternoon trying to figure out what to do next. This time was completely wasted because of the JIRA being kept secret. Finally, about dinnertime, we got enough of a hint as to what the problem was that we were able to exercise it - and decide that not only was the original behavior not a bug, at least at the level of the Firestorm codebase (LL 3.3.3), it was actually the way things should behave.
So we declared it fixed and built release binaries. That's what QA's poking at now.
Jessica Lyon is not at all happy that we had to back out a release. I'm not either. Worse, I feel some responsibility for not saying anything.
Where did we screw up? To examine this, we need to detour for a moment into the world of fail that's been the LL pathfinding release. The pathfinding code has been rather epically broken at just about every step of the way. The problems ranged from broken physics to sitting on the ground failing in rather entertaining ways to the world and minimaps being mis-scaled to the toolset in the viewer being very, very unstable. (This is the reason that LL 3.4.0 is taking so long. It's really, really not pretty.)
We fought a lot of this while putting the pathfinding tools into Firestorm. We saw the effects of a whole bunch of these problems, to the point we got to thinking "Oh, something else broke? Must be pathfinding fail." That is exactly what I thought when I saw my front doors broken a week or so ago...and it cost us.
I'm not the only one. More than a few of the support folks and beta testers report the same thinking.
The lesson is obvious: Even - no, especially - when dealing with known LL fail, we need to investigate every problem we see. No matter how much it seems that it's just another LL screwup. Every problem. Period.
There's another lesson, and that's that LL's entirely too secretive when it comes to many bugs. Yes, I can see keeping details of LL's infrastructure secret, and it goes without saying that SECurity JIRAs need to be secret. There's simply no good reason for the others, though, especially once they've been fixed. The only reason is to keep TPV developers in the dark and make us reinvent wheels.
I hate reinventing wheels. If you're lucky, you end up with a pentagon.
So here we are; before I go to bed, 4.2.2 will be released, full of goodness. But a lot of us wasted a lot of time because nobody said anything about a bug many of us saw. That's gotta stop. It will stop.
Yesterday, we were all hopeful and happy that we'd gotten 4.2.1 the hell out the door. We'd been beating on it to get the pathfinding tools in, and a bunch of crash fixes and translation updates and a few very highly requested features (control-shift-E for Edit Linked Parts being my primary original contribution, though I also ported the Flickr snapshot upload from Exodus) as well. We QAd it, we beat on it, everything looked good. We pushed all the needed changes to the various repositories, told the users to grab it and have fun, and went to bed.
I got up about 5:40 AM my time (US Central, GMT-6/SLT+2). When I sat down in front of the computer, I saw in the support chat that there was a problem. It turned out that 4.2.1 has a bug in it that makes most swinging doors not look like they act correctly (though they actually do). They appear to swing normally, then jump ahead, swinging farther all at once.
You can guess how many swinging doors there are in SL. You'll probably guess low. No, I don't have a number, but it's gotta be astronomical.
The thing that annoyed me especially: The front doors on my own house showed the bug! Worse, I'd noticed the issue a week or so ago, and blown it off!
Fortunately, our ace support person and walking JIRA encyclopedia, Whirly Fizzle, had already found the changesets that caused the issue. I whipped up a quick build and saw that yes, backing them out did fix the problem. A bit more jockeying, and I had a recommended course of action: back out three changesets directly in the release branch of the repository, bump the version number to 4.2.2, and ship it.
Oh, if it were that simple.
First, the build servers were behind a fiber cut as a result of an automobile accident in Boston. That delayed spinning the new release builds.
Then, while we were waiting on that, we discovered another problem, with another patch: some spinning objects stuttered and didn't show correctly if they updated while spinning. This is the problem that the patches we backed out were supposed to fix. We found the changeset that caused that and backed it out, and it seemed to fix the problem, with no side effects.
But we couldn't be sure. The LL JIRA that that changeset was reported to fix, PATH-542, was (and still is) secret. So how the hell do we decide? Have we reached the end of the string, or are there nasty side effects of not fixing that one? Without knowing what the problem is, we can't make an intelligent decision on what to do with it.
We spent a large chunk of the afternoon trying to figure out what to do next. This time was completely wasted because of the JIRA being kept secret. Finally, about dinnertime, we got enough of a hint as to what the problem was that we were able to exercise it - and decide that not only was the original behavior not a bug, at least at the level of the Firestorm codebase (LL 3.3.3), it was actually the way things should behave.
So we declared it fixed and built release binaries. That's what QA's poking at now.
Jessica Lyon is not at all happy that we had to back out a release. I'm not either. Worse, I feel some responsibility for not saying anything.
Where did we screw up? To examine this, we need to detour for a moment into the world of fail that's been the LL pathfinding release. The pathfinding code has been rather epically broken at just about every step of the way. The problems ranged from broken physics to sitting on the ground failing in rather entertaining ways to the world and minimaps being mis-scaled to the toolset in the viewer being very, very unstable. (This is the reason that LL 3.4.0 is taking so long. It's really, really not pretty.)
We fought a lot of this while putting the pathfinding tools into Firestorm. We saw the effects of a whole bunch of these problems, to the point we got to thinking "Oh, something else broke? Must be pathfinding fail." That is exactly what I thought when I saw my front doors broken a week or so ago...and it cost us.
I'm not the only one. More than a few of the support folks and beta testers report the same thinking.
The lesson is obvious: Even - no, especially - when dealing with known LL fail, we need to investigate every problem we see. No matter how much it seems that it's just another LL screwup. Every problem. Period.
There's another lesson, and that's that LL's entirely too secretive when it comes to many bugs. Yes, I can see keeping details of LL's infrastructure secret, and it goes without saying that SECurity JIRAs need to be secret. There's simply no good reason for the others, though, especially once they've been fixed. The only reason is to keep TPV developers in the dark and make us reinvent wheels.
I hate reinventing wheels. If you're lucky, you end up with a pentagon.
So here we are; before I go to bed, 4.2.2 will be released, full of goodness. But a lot of us wasted a lot of time because nobody said anything about a bug many of us saw. That's gotta stop. It will stop.
13 July 2012
Viewer 1 is officially on borrowed time
At today's Third Party Viewer Developers meeting, Oz Linden announced three upcoming changes. (The audio recording of the meeting can be heard from the archive here.)
1) Pathfinding. The pathfinding code has been rolled out on the Magnum RC channel, after a few false starts, and seems to be running well. The pathfinding tools will soon be released in source form for integration into other viewers. They'll be needed to edit the pathfinding properties of objects, and to trigger a rebuild of the navigation mesh that pathfinding objects use to move around.
2) From the Shining Project, an overhaul of the HTTP interface in the viewer. The code has been completely reworked. The new code fixes many, many HTTP bugs in the current viewers - but it's incompatible. It'll go on a new TCP port. It'll also not work very well with older consumer WiFi or DSL routers.
3) Also from the Shining Project, server-side baking. Currently, your shape and hair and system-based (but not prim-based) clothing are all initialized and merged together by your viewer and then uploaded to the servers. This is known as baking, and when it doesn't work, you get bake fail. That's what produces the orange clouds you see when someone logs in sometimes. The new code will have your viewer attach whatever, update the Current Outfit folder, and then notify the server - which will then turn around and notify an internal server that does the actual baking. This should eliminate bake fail. However, once again, it is incompatible with current viewers.
The second and third changes are longer-term. Oz said that we should plan for two to six months; I don't know if that estimate is better than Linden Lab's historic estimates (which tend to be optimistic), but we should plan on their being accurate.
The result of the final cutover to the new HTTP library is that the viewer won't be able to communicate. The result of the server-side bake is that viewers that don't handle it will simply see gray avatars, with no way to fix them.
Needless to say, there will be plenty of warning before the switch gets flipped. Oz committed to giving us at least two months' notice, unless he is unable to convince higher ups that they need to give us that after making a decision to switch faster. There's not a lot he can do in that case.
When it does, though, viewers that have not been updated will simply refuse to work. 1.23 will not be updated, and this will spell the end of it on Second Life. Older versions of all other viewers will also stop working. Viewers that are not actively maintained will die off.
We will, of course, be fully ready with Firestorm, assuming that Linden Lab gives us enough lead-time to actually integrate the code and release with it before they flip the switch.
Phoenix is a more interesting question. Just in case there's any doubt, what I'm about to say is my own personal opinion, and not that of the Phoenix Viewer Project. The group has not made any decisions yet.
To me, it's time to say that we are not going to put any more effort into Phoenix.
Yes, that's right. As far as I'm concerned, it's time to put Phoenix to rest. The developers don't like working in the codebase, as in many ways it's an unmaintainable tissue of hacks, the support team barely remembers how to run it, and Firestorm now provides essentially all of the function Phoenix has and much more besides. There's even a selectable interface that caters to Phoenix users. (If you are one of those, select Phoenix mode at the login screen. Have fun.)
I realize this will be an unpopular change, especially for folks who refuse to run Firestorm or any other V2/V3 viewer. However, there comes a point when making an old program run in a new environment simply isn't feasible. We're a volunteer project. There's essentially nobody here who wants to keep putting effort into Phoenix any more. Firestorm does everything that Phoenix does. (Two exceptions: OTR IM encryption, which a small but very loud fraction of users want, and object import/export and some build tools that depend on it. I expect both to be in Firestorm by the time the incompatibility switches get flipped.)
There are some folks whose creaky old computers won't run Firestorm. Guess what, folks? It's time to upgrade. Past time. If your computer isn't hopelessly low-end and was built in the last 4 years or so, it'll run Firestorm. If not, then it's past time to upgrade anyway. Yes, I know this is hard-hearted sounding. It's also simple reality.
There are other folks who swear up and down they'l never run Viewer 2 or its descendants. Well, folks, your bluff is being called. You've been saying you'll leave SL before you'll run Viewer 2. It's time to shit or get off the pot.
Me? I'll be happily running Firestorm 5. (Or whatever we choose to call it.)
1) Pathfinding. The pathfinding code has been rolled out on the Magnum RC channel, after a few false starts, and seems to be running well. The pathfinding tools will soon be released in source form for integration into other viewers. They'll be needed to edit the pathfinding properties of objects, and to trigger a rebuild of the navigation mesh that pathfinding objects use to move around.
2) From the Shining Project, an overhaul of the HTTP interface in the viewer. The code has been completely reworked. The new code fixes many, many HTTP bugs in the current viewers - but it's incompatible. It'll go on a new TCP port. It'll also not work very well with older consumer WiFi or DSL routers.
3) Also from the Shining Project, server-side baking. Currently, your shape and hair and system-based (but not prim-based) clothing are all initialized and merged together by your viewer and then uploaded to the servers. This is known as baking, and when it doesn't work, you get bake fail. That's what produces the orange clouds you see when someone logs in sometimes. The new code will have your viewer attach whatever, update the Current Outfit folder, and then notify the server - which will then turn around and notify an internal server that does the actual baking. This should eliminate bake fail. However, once again, it is incompatible with current viewers.
The second and third changes are longer-term. Oz said that we should plan for two to six months; I don't know if that estimate is better than Linden Lab's historic estimates (which tend to be optimistic), but we should plan on their being accurate.
The result of the final cutover to the new HTTP library is that the viewer won't be able to communicate. The result of the server-side bake is that viewers that don't handle it will simply see gray avatars, with no way to fix them.
Needless to say, there will be plenty of warning before the switch gets flipped. Oz committed to giving us at least two months' notice, unless he is unable to convince higher ups that they need to give us that after making a decision to switch faster. There's not a lot he can do in that case.
When it does, though, viewers that have not been updated will simply refuse to work. 1.23 will not be updated, and this will spell the end of it on Second Life. Older versions of all other viewers will also stop working. Viewers that are not actively maintained will die off.
We will, of course, be fully ready with Firestorm, assuming that Linden Lab gives us enough lead-time to actually integrate the code and release with it before they flip the switch.
Other folks may choose to make the necessary adaptations to work in the new environment. It will be interesting to see whether Henri Beauchamp implements the new bake, since he doesn't like the Current Outfit folder and went to some lengths in CoolVL to avoid having to use it. Some viewers are in active development, and I expect them to continue. However, the only V1-based viewer that will survive is Singularity, I expect, with the possible exception of CoolVL. I expect Siana Gearz to do the needed work as soon as the code's available. Nobody else is developing a V1 viewer any more.
To me, it's time to say that we are not going to put any more effort into Phoenix.
Yes, that's right. As far as I'm concerned, it's time to put Phoenix to rest. The developers don't like working in the codebase, as in many ways it's an unmaintainable tissue of hacks, the support team barely remembers how to run it, and Firestorm now provides essentially all of the function Phoenix has and much more besides. There's even a selectable interface that caters to Phoenix users. (If you are one of those, select Phoenix mode at the login screen. Have fun.)
I realize this will be an unpopular change, especially for folks who refuse to run Firestorm or any other V2/V3 viewer. However, there comes a point when making an old program run in a new environment simply isn't feasible. We're a volunteer project. There's essentially nobody here who wants to keep putting effort into Phoenix any more. Firestorm does everything that Phoenix does. (Two exceptions: OTR IM encryption, which a small but very loud fraction of users want, and object import/export and some build tools that depend on it. I expect both to be in Firestorm by the time the incompatibility switches get flipped.)
There are some folks whose creaky old computers won't run Firestorm. Guess what, folks? It's time to upgrade. Past time. If your computer isn't hopelessly low-end and was built in the last 4 years or so, it'll run Firestorm. If not, then it's past time to upgrade anyway. Yes, I know this is hard-hearted sounding. It's also simple reality.
There are other folks who swear up and down they'l never run Viewer 2 or its descendants. Well, folks, your bluff is being called. You've been saying you'll leave SL before you'll run Viewer 2. It's time to shit or get off the pot.
Me? I'll be happily running Firestorm 5. (Or whatever we choose to call it.)
07 June 2012
A gorgeous necklace
Just gotta show off a lovely necklace Axi Kurmin gave me. It's from her jewelry store, House of Rain, and it's called - you guessed it - Phoenix. This one's in gold with onyx and citrine inset in it. Perfect colors for a tigress.
Thanks!
03 June 2012
How to be an open source asshole
Not too long ago, a couple of folks have released forks of Firestorm, taking the source we've put a year of hard work into, making their own changes in it, and releasing it under a new name.
There's nothing wrong with that. It's an essential part of the open source software model.
What is wrong is that, in both cases, they did the open source equivalent of filing off the serial number: they removed any credit to Firestorm and its contributors. In essence, they claimed credit for the work themselves.
That's beyond the pale.
There are three main reasons people work on open source software: scratching their own itches, helping others, and gaining a good reputation in the community. The first two are obvious. Every Firestorm developer has added features or fixed code to do something they personally want to see done; the best examples are Zi Ree's Phoenix emulation and animation overrider, and Tozh Taurog's LSL bridge. The second underlies what all of us get out of it, to one degree or another. It's not entirely altruistic. We get warm fuzzes from people thanking us for the work.
The third one is what the two forks have destroyed. As much an economy as open source has is based on credit for work: not monetary credit, but reputation credit. I've cited open source guru Eric Raymond's essay Homesteading the Noosphere here before. In it, Eric describes what drives open source developers as a gift economy: people give away their work in return for credit, thereby enhancing their reputation in the community.
That means that removing credit for work is as close to theft as you can come in the open source world.
There have been complaints in the past that we have not properly credited others for their own work. This has been unintentional, and rectified as soon as the issue was raised. We proudly and happily acknowledge the work of others that makes its way into Phoenix and Firestorm to the best of our ability.
I don't know if the offenders have put the credits back. I suspect one has not; she has shown an ongoing pattern of taking others' work and removing credits before distributing it. The other is reported to have taken down his entire codebase, or at least have made it inaccessible.
One of the two claims that some developers asked him to remove their credits in his codebase. If someone asks that their credits be removed, that is their right, and he would be right to comply. I find the claim difficult to believe, however.
I would personally not consider using either viewer, myself. If they're willing to steal credit for others' work and break the norms of accepted behavior in that way, what else are they breaking?
I considered naming the two viewers and their developers. I decided not to. They have a tiny number of users, and I decided that naming them here might induce others to try them. If you encounter a viewer that looks a lot like Firestorm, though, I would strongly recommend checking the credits section first, and if the Firestorm team isn't credited, run the other way fast.
There's nothing wrong with that. It's an essential part of the open source software model.
What is wrong is that, in both cases, they did the open source equivalent of filing off the serial number: they removed any credit to Firestorm and its contributors. In essence, they claimed credit for the work themselves.
That's beyond the pale.
There are three main reasons people work on open source software: scratching their own itches, helping others, and gaining a good reputation in the community. The first two are obvious. Every Firestorm developer has added features or fixed code to do something they personally want to see done; the best examples are Zi Ree's Phoenix emulation and animation overrider, and Tozh Taurog's LSL bridge. The second underlies what all of us get out of it, to one degree or another. It's not entirely altruistic. We get warm fuzzes from people thanking us for the work.
The third one is what the two forks have destroyed. As much an economy as open source has is based on credit for work: not monetary credit, but reputation credit. I've cited open source guru Eric Raymond's essay Homesteading the Noosphere here before. In it, Eric describes what drives open source developers as a gift economy: people give away their work in return for credit, thereby enhancing their reputation in the community.
That means that removing credit for work is as close to theft as you can come in the open source world.
There have been complaints in the past that we have not properly credited others for their own work. This has been unintentional, and rectified as soon as the issue was raised. We proudly and happily acknowledge the work of others that makes its way into Phoenix and Firestorm to the best of our ability.
I don't know if the offenders have put the credits back. I suspect one has not; she has shown an ongoing pattern of taking others' work and removing credits before distributing it. The other is reported to have taken down his entire codebase, or at least have made it inaccessible.
One of the two claims that some developers asked him to remove their credits in his codebase. If someone asks that their credits be removed, that is their right, and he would be right to comply. I find the claim difficult to believe, however.
I would personally not consider using either viewer, myself. If they're willing to steal credit for others' work and break the norms of accepted behavior in that way, what else are they breaking?
I considered naming the two viewers and their developers. I decided not to. They have a tiny number of users, and I decided that naming them here might induce others to try them. If you encounter a viewer that looks a lot like Firestorm, though, I would strongly recommend checking the credits section first, and if the Firestorm team isn't credited, run the other way fast.
Subscribe to:
Posts (Atom)