tonyagudo.net

If you've been around Second Life long enough, chances are you've come across a"Stargate(TM)". Based on the TV show of the same name, they are networked teleportation devices that take you to any other place where another stargate is. In my early days of SL, I was even friends with the creator of a Stargate network. The other day, I had gotten a copy of Doran Zemlja's "OpenGate", which is an open source Stargate network licensed under the GNU GPL. I had put up an OpenGate right at my store's front door, hopefully to help bring in more customers. Today I had an interesting idea: Why not make a triangular Stargate? It shouldn't be too hard to do.

Boy, was I wrong. I did make a simple prototype, no problem. But when I moved all the appropriate objects, textures and scripts over, the shape reverted to a regular gate. WTF? "Ok, no problem, just find the script the function call that reverts the shape, and comment it out". The only problem? ALL the scripts are virtually unreadable to a mortal's eyeballs. I complained about it on the OpenGate network group, and I was told to look on the OpenGate website for why Doran did this. What i found made absolutely no sense at all:

People who've looked at the source code in-world have noticed that is pretty much unreadable. The first question I'm asked is "why the obfuscated code?"

During development of the first gate network, I would often succumb to the temptation of modifying the code in world to fix bugs. The result was that the online tarball would become out of sync with what was actually in use, and I lost much time scratching my head over which version was correct. Obfuscating the in world code forces me to do development out of world.
There is a fair amount of shared code between the different scripts. On several occasions I found that I had different versions of key algorithms in different scripts, and this caused many headaches. To avoid this, I wanted to use C/C++ style #includes and #define macros, and that necessitated moving to a development platform with real development tools.
To some degree, obfuscated code is a natural result of using #include and #define macros.
Often people would make changes on their objects and submit them back to me for inclusion in the project. Such code had often gone through several iterations of copying and pasting in different tools, and it was often difficult to get a clean diff to figure out what had changed.
Obfuscating the in world code should help reduce this problem. I will no longer accept contributions that do not diff cleanly against the code in the distribution.
Many well meaning people who used the objects in world took them apart, picked a single script, and found their favorite nit to pick in the name of readability, efficiency, reduced memory, or reduced lag, and "fixed" them. They often did this without understanding the complete design, especially without understanding how the different scripts interoperated with each other, how the different objects interacted within a single gate, or how the individual gates interacted with each other in the gate network as a whole. On a few occasions this led to disruptions of the gate network. Now that the distributed chord algorithm is in use, these problems are magnified.
Obfuscating the in world code increases the level of effort required to make changes, and should reduce the number of frivilous unconsidered changes.

That last sentence and paragraph burned me up. She's obfuscating the code to actively discourage other people from making changes. While this doesn't technically violate the GPL's terms, it's actually a way of trying to be cute with it. Whenever I make a project, I always try to keep the code as neat and easily readable as possible, not just for me, but for anybody who wants to study it, modify it, and even sell their own modifications. That's the nature of the GPL at work. If Doran doesn't want other people to make changes and submit them for inclusion, she should have chosen a different license.

Yes, you read that last sentence right. It seems to me that Doran doesn't totally grok the GPL. A good GPL project doesn't put up obstacles to code changes, it removes as many as possible. So what can be done about a poor GPL project like this one?

Answer: Fork it and do it better!

I had just added a listing enhancement to one of my items on SL Exchange when a new customer teleported in. His name is Kermit(I can't remember his last name) and he found my shop through my listings. It turns out he's trying to figure out how he can start creating stuff in SL and he can't decide what to specialize in. I told him building is the easiest skill for most people to pick up. We chatted for a while, eventually talking about having original sports leagues in SL, particularly football and soccer. It turns out that faithfully recreating such a game would require a really big undertaking, with a lot of scripts, animations, HUDs for the players, coaches, referees, and of course scripts for the field too.

After we were done talking, I gave him a free copy of my Green Android Warrior avatar as something to cut his teeth with avatar creating, on the condition that if he makes an interesting mod of it he lets me know about it.

Yesterday I got curious about a virtual world competitor to Second Life(R), known simply as "There". After perusing the FAQ and Developer FAQ, I'm convinced that I chose the right virtual world. Here's why:

First off, it's Windows-only. No Mac or Linux client at all, so you know it's already a small world. Secondly, by default you can't build anything at all. You need to join a "developer's program", where your creation is subject to approval by a staff. Also, many features that you get in Second Life such as Voice Chat, landmarks and others that you get for free, aren't available to basic members. But the biggest dealbreaker for me(and certainly a lot of other people), is that There charges money for creating stuff, and you won't turn a profit until you sell the item at least ten times.

It's not all bad for There, though. They have a fixed offline schedule, so no unexpected outages. Plus you can join up to fifty groups, twice as many as in SL. And for teens, they're not relegated to a "teen grid". However the inclusion of teens is a big reason why There has such rigorous restrictions, which actually makes me glad SL did make the teen grid. Heck, the teen grid is actually better than There.

So in conclusion, I can't recommend There as a good virtual world for anybody. It's a Second Life look-alike on the surface, but it's too PG-13 to be a Second Life competitor. Perhaps I'll start searching around for other virtual worlds and see what's good and what's not. Don't get me wrong, I still love SL but I think it would be a good idea to see what else is out there. Maybe I'll make my search into a blog category.

Today I came across a very thoughtful article/rant on Linux.com about the trend of Linux reviews measuring this or that distro release against a supposed goal of being "ready for the desktop", when the actual definition of a "desktop-ready" OS isn't actually defintive, but rather subjective.

Jeremy LaCroix goes into two main variations on this trend and exposes the inherent objectivity problems with it. First up is comparing Linux to Windows, as if Windows is the reference for "desktop-ready" for everyone. The problem with this is that no OS is "desktop-ready" for everyone. Windows tries to be everything for everyone, but that's it's biggest weakness. It's strength is it's large collection of commercial apps, and plays to that. That makes it favored for business and office use. Macs focus on multimedia creation, tight hardware integration and different usability concepts. Linux is renowned for it's total customization, portability, development base and stability(ditto for Unix). So each OS is tailored for different audiences, and judging one or more OSes against a percieved "perfect" OS robs objectivity out of a review.

The other variation is the "let's sit a non computer-savvy person down and see how he/she gets along on this distro". Think about that scenario for a second. That's like putting a jet pilot in front of a tank's cockpit and seeing how he does with it. No matter what the distro or OS, that person may get some of the easy basics in a few minutes, but it will take at least a week of regular use to seriously learn how to use it. And a reviewer using this variation won't realize that and simply judge based on the first use. So again, objectivity is thrown out the window in favor of an attention-grabbing "review".

I know if I were forced to work on Windows or Mac OS X for a day, I would have quite a few problems. There's no one-stop package manager like Synaptic on Windows, and the UI differences on Mac OS X would clash with my navigation habits. So if I reviewed both OSes like that, they would both recieve an F, and I would rightly catch a lot of flak for it. So, for the sake of objectivity and preventing flame wars, let's replace "Is it ready for the desktop?" with "Is it ready for your desktop?", okay?

Well, the conversion back to PCLOS went a lot smoother than I thought, thanks to a remaster of PCLOS dubbed "TinyMe". TinyMe is a very lightweight version of PCLOS, using Openbox as a window manager, PCManFM as file manager, and LXDE to round off the desktop experience. With TinyMe, I no longer had to fiddle with the GRUB boot options to make sure bootup actually went beyond GRUB(as it did with PCLOS 2007). So now I have a fairly lightweight environment, but I can also play SL thanks to Synaptic. But again, I'm not giving up on SliTaz. I may decide to buy an Eee PC laptop for my birthday coming up and plop SliTaz on it until they do get Nvidia packages made.

Recently on DistroWatch I heard about SliTaz GNU/Linux, a new distro that may very well be the smallest desktop distro ever(a 25MB LiveCD image). I had the chance to try out this little wonder on my PC, since PCLinuxOS updates weren't coming down the pipe for a long while(that's changed now), and I'm pleasantly surprised with it.

Overview

Currently Slitaz comes in two forms: Stable and Cooking. The Stable release features the JWM window manager, emelfm2 file manager, Firefox, AlsaPlayer, mtPaint, LightTPD web server, SQLite, and many other packages via the simple but effective package manager tazpkg. The Cooking release is what will eventually become the next stable release, replacing JWM with the much better Openbox window manager, PCManFM file manager, HardInfo system information tool, SearchMonkey and more tools to come. Plus you can create your own customized version of SliTaz using the Tazlito LiveCD creation tool.

I am actually writing up this post in SliTaz right now, which says a lot about how I'm really liking this little powerhouse distro. The only thing keeping me from permanently switching to SliTaz is that there are no proper Nvidia or ATI 3D acceleration packages available yet, so I could play Second Life(TM). But then again SliTaz is meant for use on old hardware, so I could be putting an unrealistic expectation on it. I will be sticking with SliTaz for a while, then migrate back to PCLOS(which now sadly looks quite bloated for my needs) as I need to keep up with my store and friends in SL.