Showing posts with label Henri Beauchamp. Show all posts
Showing posts with label Henri Beauchamp. Show all posts

Monday, April 8, 2013

Jessica Lyin' to Firestorm users: Don't Expect Working Update Any Time Soon

Well, at least she's not springing any big surprises on anyone.  Jessica Lyin' posted an entry on her blog April 5th stating flat out that there will be no usable update to Firestorm any time soon.  With server side baking coming at some undisclosed date in the near or not-so-near future, disgruntled users asking questions but receiving no honest or real answers, and as usual, Ms. Lyin' is, well, lying.

On the one hand, she says that the "coming Firestorm release DOES support Server Side Baking."  Then she turns around and says that she and her team of suckups won't release the new viewer now "[b]ecause Linden Lab has not released their viewer with Server Side Baking yet. And if we release Firestorm now, and then LL realizes there needs to be more code changes for Server Side Baking that will affect both their viewer and ours, then we will have to do yet another release immediately after."

Okay, so where, you might be asking, is the lie?  In the first sentence of the blog entry, Lyin' says flat out "that the release is quickly approaching."  Define "quickly."  If we go by the timeline Linden Lab has traditionally adopted, "quickly" could be six months or a year from now, or two years from now, or maybe never.  That's not what any reasonable person would call "quick".

So basically, Jessica Lyin' is telling Firestorm users that although the next update will be ready to roll out very soon, if not now, they're going to wait to release it until Linden Lab officially rolls out Server Side Baking, which could be a while in coming.

Commenter Bear Silvershade rightly called B.S. on this one, stating:

I had to think about responding to this thread, because invariably, the small number of people who voice an opposing view get bashed or labelled a troll. Sadly, that is likely to happen to me, but I am so frustrated.
So let me see if I have this right. You are not releasing a version of Firestorm you have, that you feel is stable, and would likely include the long awaited snapshot tiling fix, because… you don’t think it would be cool to have to release an update a few days to a few weeks after this one?
I admit I am not a loyal firestorm user. Though I think it is one of the best viewers available, the infrequency of updates to take advantage of newer code or newer features has always been a concern. That came to a head in December when the tiling bug fix came out. Since one of my main activities in SL is making images, that was a major fix, and one that many others had been waiting for as well.
That’s when Firestorm lost me completely. It’s now four months without that fix being implemented. The absurdity of including William Weaver’s phototools to make this an ideal viewer for image makers, even starting a flickr group to show off images made with it, but not getting out the tiling fix as soon as possible still has me shaking my head.
Other viewers, including LL, release regularly. Are you saying that you can’t even come close to living up to that standard?
More annoying, it appears from one blogger’s comments that there was a stable beta available some weeks ago, apparently only available to a select few.
Now we have to keep waiting, even though you have something you feel is releasable? I am sure I am not alone in being willing to update my viewer a few days after a release. It happens with all kinds of software.
Now, before the putdowns start, you really want users avoiding posting for fear of retaliation or otherwise being shut down or disregarded? Or would you rather have an inclusive group where users feel like they are contributing and their concerns are honestly being listened to.
I will likely try the new viewer when it comes out, hoping that it lives up to the wait, though I have some concern that it won’t.
But that’s as may be. The fact is, in the end, there are other viewers out there, including the Lab’s, that do offer regular updates, so problems are dealt with and new features/fixes are available.
Jessica, I applaud your and the team’s commitment to quality. But it’s time to leave this no beta model/favoured few model behind and show a little more respect for your user base.
Naturally, Lyin' went on the attack with her patented brand of lies combined with condescension and dismissal.  Bear replied:
Perhaps you could try not trying to pack so many changes into each release? You will always be chasing the next feature, and if you are waiting till a whole bunch is perfect, well this is the result, that needed working features aren’t released, because you are waiting on something else.
As to regular releases, well, I am not worried about how popular the viewer is. Exodus, like Zen, appears to have ceased development, though while they were developing, offered nightly builds. Singularity, when the tiling fix and others features/patches came out, got a baseline viewer out that they plan to build on, in a reasonable time frame.
But Dolphin releases regularly, usually every two weeks or so. Niran, while I think it goes too far wit UI changes, also releases regularly.
But as to “irresponsibly releasing a build” that’s what a system of development and beta releases are for… let us decide, instead of adopting this paternalistic and, frankly, somewhat condescending attitude. If I am trying a LL dev build, as I often do, and it has a problem, I don’t get angry at them, it was my choice. I’ve never got to report a bug, since others usually find them before me.
Though you say you are not dismissing my concerns, frankly, that is exactly what you are saying in your final sentence. “We have reasons, you just don’t understand” is how that comes across to me.
Maybe if I say it more clearly.
1) It is disrespectful of your larger user base to release betas to a special few so they can enjoy the benefits (and, yes take the risks)
2) It is a poor model that ends up with four months between releases, leaving users without fixes that are ready to go.
3) Incremental releases allow us to decide what level of chance we are willing to take.
4) Contrary to your comments, many viewers, including LL and TPVs, release more regularly, getting improvements into the stream as they are available.
More lies, condescension, and dismissal from Jessica Lyin', followed by a disheartened final response from Bear.  Again, no big surprise there.  The baseline response from Ms. Lyin' and her merry band of suckups is always to go on the attack, dismiss any and all criticisms no matter how legitimate, and engage in rampant dishonesty.

User Sorrow made the following observation:
Only issue is they generally don’t screw up either. Every CoolVL weekly patch has worked flawlessly, every Singularity Alpha build aren’t problematic, same as Nirans, etc.
Only up to date released problematic and buggy viewer is Firestorm.
With firestorm updates being so slow, by the time this next version is released, it will already fallen 1-2 months behind the Official, CoolVL, Singularity Alpha, etc as the other viewers are already far ahead in development with the next batch of LL Patches, code, and new features..
It’s almost like, instead of thinking ahead like other 3rd party developers and working with LL developmental code and beginning to code and enact their own version of the LL future development, instead you wait until the official LL viewer to implement it, then barely start working on it, while on the other hand, the other 3rd party viewers have already released their own updates as they already completed development of the new features.
Sorta like this Server Side baking.. it’s been talked about for months and months, implemented on the developmental viewer then beta viewer for months as well, however it doesn’t seem like the FS team bothered* to begin working on it during this time (like the other developers), instead waited all the way when LL was ready to roll it out on the official viewer, thus months behind everyone else.
“viewers with such a small user base can afford to screw up where we cannot.”
you should follow CoolVL’s or Singularity’s model, have weekly or bi-weekly (even monthly would be better than nothing) releases labeled as “Alpha (Use At Your Own Risk)” no matter how small the patch, having regular releases, even if they are alpha or beta versions, this will more likely keep everyone satisfied, plus help your team locate and identify bugs if you have an alpha version JIRA rather than previously where the bugs end up being located within the official major releases (much better idea than this “Preview Idea” as a few days probably isn’t enough to locate all problems in a viewer.
I put the key parts in bold-type. *: I corrected a grammatical error so the sentence conveys the writer's meaning.  Anyway, Sorrow makes a very good point: Henri Beauchamp and Siana Gearz update their viewers much more frequently than Jessica Lyin's team does, and their crews are smaller.  They do, however, have the benefit of being more talented programmers, and they stay ahead on the updates.  Lyin' is basically dismissing these and other TPV developers as being too small and insignificant to emulate so as to better serve her users.  Do you feel insulted by that attitude?  I am, and I don't even use Firestorm.

So there you have it.  Jessica Lyin' has what she claims (probably falsely, as usual) is a workable update to her crappy viewer, but won't release it until after Linden Lab rolls out Server Side Baking, which means it could be any time between now and never.

Oh well.

By the way, for any of you programming wizards out there who might be interested, I managed to download the code for Phoenix Viewer (not Firestorm), so that it can be updated and resurrected under a different title.  I have no programming skills, but I can pass on the files for you to work with.  What you do with them is up to you.  Send me an e-mail or reply in the comments to let me know if you're interested and I'll find a way to share the files with you.

Friday, October 7, 2011

Viewer Snobbery

The latest gripe fest on the Phoenix Viewer blog demonstrates just how out of touch the development team is with reality.  Now, don't get me wrong; I prefer Phoenix, which is still much more stable than, say Singularity, even though I believe Singularity will eventually supplant Phoenix as that development team ceases to update their viewer.  But the attitude coming from Jessica Lyon and her supporters is downright puzzling, not to mention irritating.

Lyon and her supporters are making the argument that trying to backport Viewer 2 and Viewer 3 features into Viewer 1 interface is like "taking a diesel engine from a school bus and fitting it into a ford pinto".  But Henri Beauchamp, the developer of Cool VL Viewer and whose code the Phoenix team used to bring mesh capability to Phoenix, cleared up a number of exaggerated claims by Lyon.  Far from taking "many" months of work, it only took Beauchamp two, two and a half at most, albeit with him working overtime in his spare hours to get the work done.  And contrary to the diesel engine metaphor, Beauchamp stated on his forum, "It's more like replacing the battery and alternator of the car engine with newer, more powerful ones (ll* libraries), replacing the mechanical injection with an electronic one to make for the increased mechanical power demand from the alternator (v2 classes in the viewer code) then adding air conditioning to the car (mesh renderer). Nothing that would make the poor car into a weird hybrid vehicle."

So it really isn't that difficult to backport the Viewer 2-Viewer 3 code into the Viewer 1 interface, contrary to what Jessica Lyon and her supporters claim.

I get the impression that the Phoenix Development Team decided to follow Linden Lab's lead and go with the crappy, bug-ridden, crashtastic, user-unfriendly, outsourced viewer that most Second Life users can't stand and would prefer not to use.  That's why so many people refuse to use the default SL viewer, and instead go with third party viewers such as Phoenix, Singularity, Cool VL, Rainbow, and others.  That's bad enough.  Literally adding insult to injury, however, was the condescending dismissal of legitimate criticisms that Viewer 2 and its clones (including Firestorm) are highly unstable, have a tendency to gobble inventory -- say goodbye to no-copy items forever -- eat up loads and loads of memory even on newer computers, and tend to crash said computers when the viewers alone aren't crashing, by telling disgruntled users to buy new computers instead of the decade-old ones we're allegedly clinging to.

This is a false assumption on the part of the Phoenix Development team, for many if not most users are not on ten-year-old computers.  I, for example, am on a computer that is less than a year old, has a monster graphics card, and is built for gaming purposes.  Yet the Viewer 2 and Firestorm beta I tried kept crashing on me, and often crash my computer altogether (even Phoenix and Singularity crash my comp).  Another dismissive claim is that users only tried Firestorm for a few minutes before giving up on it, despite people complaining that they spent hours on Firestorm only to have the same problems.  Simply put, people don't like the user interface no matter how much the Phoenix team tries to gussy it up, and the viewer itself is a bug-infested resource hog just like Viewer 2.  It's not a matter of people clinging to old technology, rather, they simply don't like the craptastic interface of a product that messes up their newer computers.

I think what's really driving the outright hostility coming from the Phoenix team and its supporters is simple snobbery.  They hopped on board a product that someone told them was the latest rage, and they genuinely don't seem to accept the legitimate reasons most people don't like it.  What if Coca Cola had stubbornly stuck by its "New Coke" product even after the massive customer backlash?  That company would now be out of business.  Instead, Coca Cola wised up, came out with "Classic Coke", and remained competitive with Pepsi, its closest competitor.  That was honest of them to do, and they survived by accepting and acknowledging their business mistake and correcting it.  If Phoenix developers want their viewer to remain the preferred one used by SL members, they will have to accept and acknowledge their mistakes, make the necessary apologies for their attitudes, and keep working to correct their mistake by continuing support for Phoenix Viewer.  it's what more of their user base seem to want anyway, and it makes better business sense.