When Linden Lab released SL Viewer 3.0.3, I was dreading the worst. During the 3.0.0 “final release” cycle, I spent uncountable hours sending debugging reports for the crash-on-login bug which plagued certain hardware configurations. Linden Lab correctly tracked down the bug and fixed it; one developer mumbled something about “fast timers” and promised it would be released on the next development cycle.
But after seven years of dealing with Linden Lab, and in spite of o many changes at the development team, I was not completely at ease. While the development version I was using definitely fixed whatever bug was causing the crash-on-login, there was no guarantee that this “fix” would actually be part of whatever version LL would release next.
And, indeed, it wasn’t. SL 3.0.3 has precisely the same bug as 3.0.0 had, and added a new one: the inventory does not get sorted by “most recent date”. This is an intermittent bug: Linden Lab swears that the bug does not exist, that it’s actually caused by a racing condition happening when the SL Viewer starts with a clear cache and no objects are in the inventory cache, and thus sorting by “most recent date” becomes impossible — waiting for the inventory to fully download, according to LL, is supposed to fix the problem for the handful of users who ever complained about that. But, alas, that’s just theory —plausible theory, true, but one which does not hold in practice.
Similarly, the bug on the “fast timers” which caused the crash-on-login error pop up now and then. No matter how much LL promises to “fix” it, the truth is, 3.0.3 is unusable for me right now. And the worse thing is that the development version that did fix the bug and did have a working inventory was trashed and replaced by newer versions on all versions of LL’s viewers. Not a single one fixes the bug that had been fixed just after 3.0.0 was released. Linden Lab thinks the bug is fixed — they have internal reports saying so! — but it is not.
Now, you might never have experienced any of these two bugs. Be content! In fact, the major problem in software development, when hunting bugs, is to reproduce them. There are uncountable different hardware platforms running different software, and when all these interfere with each other, unless a developer happens to be very lucky, they might never be able to reproduce a bug, and thus, from their perspective of reality, the bug does not exist. Without having a clue why a bug seems to be fixed in one version, but pops up again in the next, even though all internal reports show otherwise, it’s truly very hard for the LL developers to actually know if they have fixed something for everybody or not.