DISQUS

Yay! Does this mean we get a raise? ;-D

I'm thoroughly unconvinced that Linden Lab's lengthy QA process is working. Or if it is working (i.e. it's reducing the number of bugs introduced), it's a poor trade-off: the effect is disproportionately small to the amount of time they seem to put into it. There are still many bugs being introduced all the time, and even very obvious and visible ones often make it past QA and into the releases.

As one example of many, consider local ruler mode being oriented incorrectly, a bug which had plagued builders for a long time. I supplied a patch to fix it, but LL decided (after a long delay) to fix it their own way. Their fix, however, broke building in an even worse way: objects would spin wildly out of control when trying to rotate them! Somehow, this extreme and obvious new bug introduced by LL's fix was not detected by QA.

LL's response to the new bug was to comment out the fix for the old bug, which meant that things were now broken again in the old way. This re-introduced bug was also not detected by QA. Or, if it was, LL didn't bother to try to fix it again -- even though I had long ago supplied them with a patch that I had tested thoroughly and which has no apparent side-effects.

So, I am left to wonder: how can these two very obvious bugs -- not to mention all the other bugs thare are constantly introduced -- pass through the QA system, when LL supposedly goes to great effort to screen out such bugs? The only conclusion I can come to is that their process is ineffective, and that they are just slowing down progress with no real improvement in quality to show for it.

This is why I'm sure community-based viewers will always outpace LL's own viewer. A programmer on a community viewer might introduce just as many bugs as an LL programmer does, but the testing on these viewers (which often simply involves people using the software) detects the bugs just as well or better than LL's QA process, and the bugs get fixed in a hundredth or thousandth of the time it takes LL.

------

P.S. A correction regarding Imprudence: we are not planning a completely new UI, as you say we are. However, we are planning a plugin engine, which would allow for other applications (plugins) to interface with the viewer. That will enable people to make detached UI widgets, but that's just one of many things that will be possible.

I'm no cryptoanalyst, but your plug still seems to have some big holes in it.

As you say, the viewer's simple string signature can be forged. I could, in theory, make a viewer filled with all sorts of nasty things, and make it report itself as "Second Life Release 1.21.6". Currently, LL's servers would be fooled.

But I don't see how that issue could be corrected with certificates. If the certificate is a file on the computer, it could be copied from a legitimate installation (even an installation of LL's own viewer!) and used to "verify" another viewer. Even if the certificate is embedded in the viewer executable (either as part of the source code, or as a separate file that is linked in), it could still be decompiled or extracted.

And of course, if it were part of the source code, LL would have to withold that part of the source from its open source releases, as would any open source viewer that applied and got a legitimate certificate from LL. Compile-your-own viewers would be crippled, and open source development drastically stifled.

As for using a checksum of the binary, I doubt that would work. Unless you're going to send all 50MB or so of the program over the internet at every login so that LL could do the checksum in a clean environment,the checksum can be forged, too. One could simply design the evil viewer to report a checksum generated from the good viewer instead of its own. (In fact, even sending the binary over the internet wouldn't work; the evil viewer could just send the good viewer instead, like a creepy old man saying "Here's a picture of a sexy 18-year-old girl. Yes, this is really me!")

And further: even if all these things actually worked, the analogue hole is still open. Content thieves could still decode textures from the cache, or use OGLE to extract the textures directly from memory, or simply press the "Print Screen" button. Prim parameters, avatar shapes, and more could still be intercepted with a packet sniffer on their way between LL's server and LL's "trusted" viewer.

So, I'm sorry to say, all the thought and time you put into this idea, but it seems like just another flawed DRM idea that would not stop actual content theft, and would instead only stifle legitimate use and open source development. I certainly won't be voting for that JIRA issue.

Excellent article for understanding why accessibility is so important. I think it just doesn't occur to many able-bodied people that not everyone has the luxury of perfect vision, hearing, full use of their body, the manual dexterity to use a mouse, etc. It takes education, reminders, and a conscious effort for software developers to think beyond their own needs and usage patterns, and consider those of other people.

But don't think that serving the needs of disabled users is something you should only bother with to appear "sensitive" and "caring", or that disabled users are somehow second rate and won't offer any value as users! Many of the most brilliant, passionate people I have met in Second Life live with some sort of disability in real life. For most of them, I didn't even know at first that were disabled -- I just knew that they were interesting people who were a joy to chat and interact with.

My own life is considerably richer for having met them. How many other wonderful people are out there, but unable to use the software because of some condition or another? How much richer would their lives be, and mine, and yours, if they weren't held back by thoughtless, inaccessible software design?

Linden Lab's trademark guidelines cover second-level domains (foo.com), subdomains (foo.reuters.com), and paths (reuters.com/foo/), but make no mention of top-level domains. (By the way, that means gwynethllewelyn.sl.tm would, in LL's eyes, be infringing.)

So, they haven't granted permission to use SL in the top-level domain, but it would be laughable in the extreme for them to try to enforce such a thing.

Besides which, the trademark guidelines seem to be yet another policy which LL either has no interest or no resources to enforce. At least not for the small players like us.

I cried myself to sleep the night I found out that I didn't make the FIC list /again/ this year. Srsly. *dramatic sniffle*

I guess he either thinks I'm not kool-kid-jock-cheerleader-insider-dope enough, or else that I didn't get to my oh-so-lofty position by pulling strings and banging Lindens left and right.

Oh well, there's always next year...

I disagree that most of these are useless. "Useless" implies that they are ineffective or serve no purpose, when most of them (esp. #1-4) act as useful social lubricant and help make your audience more receptive.

Without them, one is prone to be interpreted as being abrasive, stubborn, or overly assertive, and thereby put your audience on the defensive. This is especially true with written word, where body language and tone of voice aren't available to convey your emotional state.

Of course, if you are trying to be assertive, then don't use them.

It's true that they can seem annoying or condescending when used in excess, but they can be very useful when used in moderation.

O_O .... So creepy... DUCKAYYY!

In the interest of accuracy, I'll point out that the new trademark policy only explicitly forbids using a Linden Lab trademark in _second level domains_, not in subdomains (like secondlife.reuters.com) or in paths (like http://www.massively.com/category/second-life).

(That's not to say that domain registration laws for any given jurisdiction don't have additional restrictions about using others' trademarks in registered domains.)

And for a bit of humour: it also doesn't forbid using sl in the top level domain -- so if you can get a domain name in Sierra Leone, go for it! "www.ilove.sl", anyone?

Anyway, the guidelines do explicitly permit using SL in subdomains (e.g. SL.Dell.com) or in paths (Dell.com/SL), so that would be the safer way to go. But that's only if your domain contains the name of your organization, or an abbreviation of it (as is true for both Massively and Reuters).

Of course, this topic is all very confusing, and we graciously thank our trademarked overlords for giving us 90 days to have the oracles interpret their demands.

Gwyneth Llewelyn officially wins at April Fool's Day. XD

Waaaoooo! That's cah-razy cool!

Great, now we have to worry about the terrorist furry age-playing Gorean gambling bankers. (It's getting hard to remember all the imagined threats these days. I hope I didn't miss any.)

That's no ocean -- that's the drool of ten thousand Residents ogling these screenshots! :-O~

So sad and beautiful... absolutely enchanting. Loved them.

Any chance of getting audio downloads of these?

Soooo pretty! Genius! I love the idea that all the color in the world comes from the sun - let's get out of the cubicles and frolic 'neath the big blue sky!

Keep it as a collection of vignettes. Some can be erotic, some can be sci-fi, some can be both; it's all good!

Cool beans! Welcome to the smooth and compact world of vector art! ^_^

I was writing a big ol' comment for you, Torley, but then it got so big I just made it into a blog post instead! But the trackback didn't seem to work, so I get to make a comment to tell you about a blog post that started as a comment to this blog post!

Executive summary: texture adjustment could be done on-the-fly by the viewer (we have the technology!), so the server would only have to send 1 texture plus a little bit of text, instead of a many versions of the same texture. However, right now there's no good way to save settings for features that the sim doesn't know about, which means you couldn't share the love with anyone else. But if each prim had a little bit of extra space to save some text to pass along to other viewers, everybody could be happy!