Personal media in Second Life

January 26, 2007

Social Autopoiesis

Filed under: Artificial Intelligence, Avatars, Snapshots — Signore Iredell @ 10:51 pm

Social Autopoiesis is a Chatbot running with libsecondlife and AIML (Artificial Intelligence Markup Language)





January 14, 2007

My system specs

Filed under: Linux — Signore Iredell @ 2:00 pm


  • Ubuntu Edgy Feisty
  • GNOME (sometimes KDE or XFCE)
  • 2.6.17-10-generic 2.6.20-15-generic Ubuntu kernel


  • “nvidia” proprietary kernel module
  • X.Org 7.1.1 7.2.0
  • server glx vendor: NVIDIA Corporation
  • server glx version: 1.4
  • OpenGL vendor: NVIDIA Corporation
  • OpenGL renderer: unknown board/AGP/SSE/3DNOW!
  • OpenGL version: 2.1.0 NVIDIA 96.25 97.55
  • glu version: 1.3


  • NVidia GEForce 6200
  • AMD Athlon XP 1600+
  • Mem: 775580k
  • Swap: 1951856k

January 13, 2007

Compiling the Second Life Viewer source code on Ubuntu Edgy – 2

Filed under: Linux — Signore Iredell @ 1:15 pm

my system specs – hardware and software i use.

if you need info about the debian packages installed on my Ubuntu Edgy system, see precedent post or leave a comment.

unpacked (grabbed from here. see also the source archive):

  • tar xzf slviewer-src-20070112c.tar.gz
  • tar xzf slviewer-linux-libs-20070112c.tar.gz
  • tar xzf fmodapi375linux.tar.gz

copied required FMOD headers and libraries into the Second Life Viewer source tree:

  • cd into the FMOD directory
  • cp api/inc/* ../linden/libraries/i686-linux/include/
  • cp api/ ../linden/libraries/i686-linux/lib_release_client/

copied other headers:

  • export SLSRC=…/linden/
  • cp -a /usr/include/atk-1.0 ${SLSRC}/libraries/i686-linux/include/
  • cp -a /usr/include/gtk-2.0 ${SLSRC}/libraries/i686-linux/include/
  • cp -a /usr/lib/gtk-2.0/include/* ${SLSRC}/libraries/i686-linux/include/gtk-2.0/
  • cp -a /usr/include/glib-2.0 ${SLSRC}/libraries/i686-linux/include/
  • cp -a /usr/lib/glib-2.0/include/* ${SLSRC}/libraries/i686-linux/include/glib-2.0/
  • cp -a /usr/include/pango-1.0 ${SLSRC}/libraries/i686-linux/include/

i’m using slviewer-linux-libs so i don’t need other headers or libs

i edited the client-manifest-i686 file in indra/newview/linux_tools decommenting two kdu-related lines

at 1st try i got an error about cairo not found, so i also did:

  • cp -a /usr/include/cairo/* ${SLSRC}/libraries/i686-linux/include/

note: the leading spaces from the 6 ‘ ../libraries/’ strings from around line 187 onwards were already the removed for me in the indra/SConstruct file

then i get into the indra directory and start building (15.00 italian time):

  • scons DISTCC=no BTARGET=client BUILD=releasefordownload

two hours and half later, the build is complete.

i extract the resulting bz2 archive, but app_settings lacks lots of files.
i made some mistake but i don’t know what.

instead, i can succesfully run the client from the source tree. veery slow. so i try

  • cp “$SLSRC/libraries/i686-linux/lib_release_client/” “$SLSRC/indra/newview/”
  • mkdir “$SLSRC/indra/lib”
  • cp “$SLSRC/libraries/i686-linux/lib_release_client/” “$SLSRC/indra/lib/” -i

and then it runs good!
complete build output follows.


January 8, 2007

Compiling the Second Life Viewer source code on Ubuntu Edgy

Filed under: Linux — Signore Iredell @ 7:05 pm

my system specs – hardware and software i use.


  • tar xzf slviewer-src-20070108c.tar.gz
  • tar xzf slviewer-linux-libs-20070108c.tar.gz
  • tar xzf fmodapi375linux.tar.gz

copied required FMOD headers and libraries into the Second Life Viewer source tree:

  • cd into the FMOD directory
  • cp api/inc/* ../linden/libraries/i686-linux/include/
  • cp api/ ../linden/libraries/i686-linux/lib_release_client/

installed via Synaptic:

  • gcc-3.4 gcc-3.4-base g++-3.4 scons

Now, I am new to scons, and since I’m on Ubuntu Edgy -that uses gcc-4.1- I thought I had to do something like this (not sure this is right, I got the idea reading here), but actually we don’t need it:

  • export CC=’/usr/bin/gcc-3.4′

after I learnt this in the Linux Client Users group chat (thanks you all guys!), I went to Maryport and enjoyed a compile’n’dance party while giving the magic command:

  • scons DISTCC=no BTARGET=client BUILD=release

Then I got some errors, asked help to Linux Client fellows, then I installed:

  • libglu1-mesa-dev libgl1-mesa-dev mesa-commons-dev
  • flex bison

I tried again running scons, and as described here, compiler couldn’t find gtk/gtk.h
So I edited the indra/SConstruct file removing the leading spaces from the 6 ‘ ../libraries/’ strings from around line 187 onwards.

A couple of hours later…
…scons: done building targets.
One step further!

Then I ran it:

  • ( cd newview && LD_LIBRARY_PATH=../../libraries/i686-linux/lib_release_client:${LD_LIBRARY_PATH}:/usr/local/lib  ./secondlife-i686-bin )

And it started! But it is “unable to initialize communications”:

The login page of the open-sourced client, showing a dumb error

My fault! I’m running it from inside the tree but I forgot to do this from the indra directory:

  • $ cp ../scripts/messages/message_template.msg newview/app_settings/

And then it works! I’m in world!

A snapshot taken with the open-sourced client on Linux

A snapshot in the same location with the usual binary client

I am happy!

Next step:

packaging the client, substituting ‘BUILD=release’ with ‘BUILD=releasefordownload’ in the ‘Compiling’ section, in order to use the faster and libraries.
…or maybe better, I’m going tryng to symlink the *kdu*.so’s into newview/ too so I shouldn’t need releasefordownload

Second Life client is Free Software now!

Filed under: Free / Libre, Politics — Signore Iredell @ 5:30 pm


Open Source Portal
Open Source: Overview
Bug Tracker

Interesting posts on

Excerpts from comments to the official blog announcement

  • Peer review is what makes applications secure.
  • Security by obscurity is no security, and just imagine the countless people submitting bug reports and diffs improving on the code base to LL in the near and intermediate future. And new LSL and Prim editing tools will shoot out of the ground like mushrooms.
  • Localized versions in all sorts of languages will appear
  • Firefox is open source and it’s way more secure than IE and anyone can download the code but you don’t hear all kinds of nightmare stories about Firefox being hacked. I don’t think there’s any reason to worry about SL being hacked any more than before. In fact, with more eyes on the code, security will likely tighten up.
  • Some people don’t like open source (or, as in the case of the use of the GPL, Free Software), which is acceptable. Thinking that open sourcing the *client* will adversely affect the economy is somewhat alarmist – certainly, bad things *could* be done, but more likely bad things will be *patched* before they are done.
  • The client is what you connect to SecondLife with. The server code isn’t publicly available, though from what I understand much of the infrastructure is based on open source code.
  • Open Source/Free Software has a demonstrated track record in this regard – projects such as Linux, Apache, Mozilla… to name some… have already demonstrated the benefit of code as a commons.
  • Proprietary code, on the other hand – well, we’ll see how many patches Microsoft releases tomorrow.
  • If you are just a regular user, this probably won’t affect you – except, perhaps, give a more stable client with less LL resources.
  • Opening this source to the development community will do:
    1. Improve the quality (stability & performance) of the client app in the long run
    2. Generate some excellent utilities and spin-off applications from SL
    3. Shut alot of ppl up about the amount of work Lindens have to do
  • this is what the folks at OpenSSL do with their code – the benefits of having so many eyes look over it to find and fix its flaws far outweigh the costs of having unscrupulous eyes able to see it.
  • Linden Lab maintains a large portion of their control over the content in Second Life by keeping the server side closed. Indeed, expect to see script decompilers, just don’t expect them to decompile scripts the client otherwise wouldn’t have access to. Releasing the client’s source is not an all-expense-paid ticket to do everything. The servers can and do deny access to certain content if the content is locked, regardless of the way the client requests the content. This means that the permissions system does provide protection to notecards and scripts and that this protection is in no way impinged upon by the releasing of the client’s source.
  • that privacy or security which was “granted” viewer-side was largely illusory anyway. It is good that the view is now open, so that everyone knows the weaknesses. The LL servers are our “trusted computing base”, that’s where privacy and security need to be dealt with.
  • The copybot, I think, was and is inevitable. Textures and other “content-y” stuff that are downloaded to the client are and have been always copyable – it was security-by-obscurity at best. The open source code will make this eminently clear (if Copybot didn’t already do that) and people will have a harder time making money with “content”. However, “services” – scripts that stay server-side, real-life services, etcetera, will always be unique and value-adding. I expect a shift in the marketplace towards this end. Content = commodity so either you grab free stuff or pay for bespoke work, services = value-adding so you’ll keep paying for them. Is that good or bad? I don’t know. Just a fact waiting to happen. The WWW seems to have happily survived the exact predicament, so I’m optimistic here.
  • While it’s appropriate to worry about the hackers and griefers having access to client-side source code, don’t forget that the public security experts will also have access to it. Maybe we’ll see a McAfee or Symantec or AVG plug-in for the SL client to secure all that precious content. Or maybe secure certificates for content transactions. It’s not just the bad guys who will be playing with the code.

Smart answers

– I expect to see LSL script decompilers/rippers, object duplicators ala CopyBot and much more in the coming months.
I already have a script disassembler. Of course, since there’s no way of getting the compiled version of a script from the server (the only way of getting it is to snag it as it goes out to the server when you save it), it’s pretty much useless for content theft and hacking. The source is actually easier to obtain – and even that requires you to have the correct permissions.

– The silliest decision ever. We knew it was coming, but there is absolutely no security right now in the SL protocols. Once again LL is making the right decisions at the wrong time.
– Errm… yes there is. The server won’t just blindly do anything the client tells it; most of the security restrictions are already implemented server-side and have been for a while, barring a few mistakes and things that can only be done on the client (e.g. blocking texture/prim shape copying).

– You thought copybot was bad ? Wait until someone comes up with a free L$ generator, a sim/grid nuker or a permission modifier. I’m pretty sure the server side of SL is creaking with the security holes that allowed that kind of hack in the past.
– If there were any holes like this, most of them probably got found and fixed already (thanks either to libsecondlife or malicious hackers – I’m not sure how many security holes libsecondlife has reported, since neither they nor Linden Labs like to talk about it, but I’ve heard there were some.)

– I predict that in the next couple of weeks we shall see at least one “universal object replicator” and one “grid nuker”. I sure hope I’ll be proved wrong
– Predicting security problems/sim crashers is like predicting the sun rising tomorrow — source code or not.

January 6, 2007

Linux/WP test with BlogHUD

Filed under: Uncategorized — Signore Iredell @ 3:24 pm

posted by Signore Iredell on Hwaegi using a blogHUD : [blogHUD permalink]

Blog at