Happy new year... and good bye.

I've long wanted to capture this - the social interactions between the cans of drink :-)

I like the result.

With this post the non-secondlife part of dalien wishes to say goodbye to you all. 3 posts short of 365, this blog was a fun story of various adventures. But as the time passes, and as the first-life identity gets bigger and bigger footprint - maintaining the two gets a bit tedious. No, I'm not going into the off-line monastery and closing off - I'll continue to post, but with my other, more conventional identity. This blog will stay silent - at least for now.

If you feel like some of the sketches that I make are fun - you're welcome to hang around at http://bnpcs.blogspot.com/, which is devoted to adventures of the same avatar in a much more entertaining game of the First Life.

A wonderful article on concurrent programming

Mostly as a bookmark for myself:

http://portal.acm.org/citation.cfm?doid2=1454456.1454462

My new blog about u-Simulator...

For those of you who might have seen some strange posts with the tag "cosimus"...

As the code gets a bit more functionality, there's now a bit more explanation about what those posts mean - and the subsequent posts will go to http://cosimus-news.blogspot.com/

I still believe...

While poking around with the matrix, stumbled across this piece. Wonderful.

Enjoy.

SL-aware server prototype in ruby...

It's no big doubt that Ruby is a high-level language. Probably opensim svn still has my stupid ruby scripts which pretend to do something with the protocol - in effect just being more or less compact "plugs" for testing.

One of these evenings I did not feel like doing anything productive, so I decided to hack up a prototype packetserver in ruby.

So, the below set of files allows me to "login" (in quotes because the login info is not really checked :) with the viewer.

 $ ls -al
total 228
drwxr-xr-x  2 dalien dalien   4096 Aug  6 04:46 .
drwxr-xr-x 12 dalien dalien   4096 Jul 31 22:23 ..
-rw-r--r--  1 dalien dalien 183208 Jul 28 17:44 1.18.3.5.txt
-rwxr-xr-x  1 dalien dalien   8629 Jul 28 17:36 login_server.rb
-rwxr-xr-x  1 dalien dalien  14901 Jul 29 04:27 parse_template.rb
-rw-r--r--  1 dalien dalien   3710 Jul 31 22:27 pkt_server.rb
-rw-r--r--  1 dalien dalien   1719 Jul 28 21:59 str_hex.rb
 $                                   

The main cleverness is in parse_template.rb, which sucks in the 1.18.3.5.txt being the message template, and generates a bunch of classes, courtesy of Ruby being an interpreted language, something like this:

t = SLPacketTemplateFile.new("1.18.3.5.txt");
t.pt.each { |x| SLMessage.register_message(x, eval(x.to_ruby)) }

So, this defines a bunch of classes with the exact same names as the messages in the message templates, and allows to write a message handler in a nice and conscise way as a class method for a "client handler" class:

  def message(msg)
    send_packet_ack(@client_ip, @client_port, msg.sequence)
    handler = (msg.class.to_s + "_handler")
    if self.respond_to? handler
      send(handler, msg)
    else
      pp msg
    end
  end

And, as soon as I define a "_handler" method within that class, it gets automagically hooked up! Cool, huh ?
For example, something like this:

  def MoneyBalanceRequest_handler(msg)
   pkt = MoneyBalanceReply.new
   md = pkt.MoneyData[0]
   md.AgentID = msg.AgentData[0].AgentID
   md.TransactionID = msg.MoneyData[0].TransactionID
   md.TransactionSuccess = 1;
   md.Description = "Test\00"
   md.MoneyBalance = 1234;

   send_to_client(pkt)
  end

where "send_to_client" is again dead simple:

  def send_to_client(pkt)
    @sock.send(pkt.to_bytes, 0, @client_ip, @client_port)
  end

Oh, and you'll probably be amused with this totally stupid-looking message loop:

  def run
    print "Started server...\n"
    loop {
      data, from = @sock.recvfrom(8192)
      port = from[1]
      host = from[2]
      rdr = SLDataReader.new(data)
      msg = SLMessage.from_bytes(rdr)
      if msg.class == UseCircuitCode
        print "New client connection!\n"
        @clients[host.to_s + ":" + port.to_s] = ClientHandler.new(self, msg, host, port)
      else
        clt = @clients[host.to_s + ":" + port.to_s]
        if clt
          clt.message(msg)
        else
          print "Unknown client:\n";
          pp msg
        end
      end
    }
  end

Of course, the CPU usage of all this horrific mess is terrible - given that even the simple members like U32 are objects in themselves, but it's fun nonetheless.

The interesting thing that parse message template + generate the code + dynamically evaluating it (creating message classes) takes around2 seconds - which I think is not too bad.

There is one downside however, the debugging of the autogenerated code is a pain. I need to so how to do it better.

Oh yes, and get rid of the braces in the loop {} construct, they do look ugly and out of place.

Dalien landless, no more sales for primskirtbuilder from me (for now, at least).

heh. appears I'm (finally) out of land where the thing was being sold. Hence, not selling the primskirtbuilder anymore.

The copies should be around, and if you apply a certain effort, you might find a free copy.

The exercise did teach me an interesting lesson - apparently the value of "free" is not really understood nor appreciated, and if you put a decent price tag, people seem to be MORE willing to get it.

The never ending wonders of the human soul... Oh well, they wrote exactly that in the MBA book. It's good to confirm the theory by practice.

Videos in HD

Videos in HD - and quite a lot of interesting ones. Probably good thing that HD has not hit the masses too much yet...

Enjoy.


The glove from Bewegtbildarbeiter on Vimeo.

Installing debian on eeepc instead of Xandros

It's been a while since I wrote - a lot of things happening, a very busy RL, no time for SL, and broken ADSL at home which I have no time to fix for now. But thought to write up something to show I am still alive :-)

As I've already wrote, I think - I've got a shiny new eeepc a few months ago. All well, but its internal flash (which they call "solid state disk") broke at some point - giving the hardware errors. The failure happened at a very distinct moment in time - I left the eeepc on for a few days, and then - whoops. I do not suspect the FUDed "flash wear" - because there were even the read errors. Much more a possible overheating causing it to fail. So, since I do not believe in warranty (And the warranty on this item would've caused more pain anyway), I decided to buy a SD card and use it as a main storage - the experiments showed that the built-in flash was dead only in some selected range, so the first few dozen megabytes were usable.

My favourite Gentoo was out of question immediately - it'd be a madness to compile everything on a system with a smaller CPU and a very slow flash-backed storage. So, I've evaluated a few others and finally settled on Debian - since it was apparently the only one who was ok with my SDHC 4Gb card that I bought.

There was not much to an install - just follow the instructions here and I got a working system.

However, at first when I tried to just use SDHC, it failed to boot from it - complaining that the cylinder number is larger than the one supported by BIOS (notably, after the boot the SDHC card appears to work fine).

So, in the end I made the following: boot into installer from the external USB memory stick, then blow away the default partition table on the internal "Hard Disk" and create two partitions on it - the first one will be the root partition, the second one is the exact copy of the installer USB stick image.

Using the same trick that GRUB uses to boot windows, I can force the installer to boot - so I have a way to recover the system in case something goes wrong. (I think it's pretty hard to install grub from the installer itself - I used the root filesystem that was previously installed - so technically I went through the install procedure twice).

The side benefit of such a setup is that now internally I have only the grub/kernel - and everything else is on the SDHC card - so in theory if I unplug that one, I can have an alternative setup (and in the case of the external HDD it can be even Gentoo).

GPU fun..

Quite impressive. Imagine the possibilities.

7 habits of highly effective men

I'm writing this one from eeepc - really funny feeling, feels bit like trying to open the door through the keyhole (from the other side, obviously :) and the real pc is left at the office by the human - who spent a good half of the evening exercising his throat, trying to get under the Purple Rain, also he was Chasing Cars and trying to express his feelings towards someone name Ruby - I have no clue who that person is, but he was trying really hard... it was entertaining to watch. Nonetheless, there's whole 3 weeks before the show, so he will sort the things out.

So, about being a decent man... Tiessa writes about her opinion of 7 habits a man should have - and i figured i'd take a note for myself as well as write some things on the side.

7) Pick up the dirty socks off the bedroom floor.

good that this is the last one in order. gonna be the toughest one. try to plan the house so the washing machine is not far from the bedroom so you can sneakingly drop them there later on - after all, they'll complain anyway if you go to the washing machine during the most precious moment. I suspect it is an RFP check item to fend off those they could not get rid of by other means.

6) Put the cap back on the toothpaste tube.

ahha, now i know why they invented the snap-on caps (which are actually pretty hard to NOT put back on. if you manage to buy a toothpaste which has detachable cap - you deserve your destiny.

5) Clean the sink after shaving.

shave in the shower. besides the irreplaceable experience of blind shaving, all the annoying details are taken care of automagically. cleaning the short pieces of hair off the sink is a pretty boring experience - there's always something left.

4) Know how to use a mop.

which one.... note: educate myself on that part about the dice retrieval. looks pretty unuseful, but hey, who knows - maybe one day it saves the life...

3) Carry shopping bags for more than 20 minutes without whining.

the shops have parkings, as well as trolleys. plan and manage the shop routing accordingly, so the heavy stuff is in the very end (it's typically food). the "things" are usually voluminous, but light. in order to minimize the amount of this, plan the shopping such that it is shortly before the closing hours - or shop more frequently. the remote shopping villages in the middle of nowhere are very good. you can get her to buy something-or-two-versace, and you've got a lead in the shopping management for the rest of the month. somehow they like those, so it's a no-brainer. just remember: the food store is the *last* place in the supermarket to visit.

2) Ask for directions before we are late for the event.

get a GPS. know the address. tell the time of the event 30-40 minutes in advance of the real one - this way you will be always on time and won't have to shrug when asked where have you been. the delta might need careful adjustment - the only thing worse than being late for the event is being early for it. if you are early indeed - pray for a good weather, and suggest a walk. neer ask for directions - the folks around don't have a clue anyway, it will only make her angry that you were not able to find an appropriate person to help.
if you follow the wrong directions - it's your fault. a decent car in addition to the GPS is a very good plus - it's being looked at. possible theory: in connection to item 3 above. but a good car is an advantage even with no additional variables in the equation.

1) Cunnilingus

the jury does not have any objections on this item and nods emphatically.

A killer recipe..

If you got an idee-fixe-du-jour, all you need to do is to hint your friend to come back to you and attach some official task to it for you. Preferrably with the supposed deadline, and make it all very seriozz.

The idea du jour will lose a lot of its sparkling - so you'll get your best to get rid of it as soon as you can.

This behaviour indeed not anything of an invention, but feels quite funny to experience it consciously.

I'm curious if this is the timing that matters, or really it is that the idee-du-jour would really be persistent in case it was worth it - so one can really use it as a "tester" ?

Impressive 3d for your home use..

The videos are not so new, but I did not see them before. I can feel a trip to the shop sometime :)

The future of the internet and how to stop it

looks like a book worth reading.

Brings up the balance between the "sterile" and "generative", with the boom of 90s being because of the technology becoming generative, and the current success flipping it back into sterile field. It's quite insightful and relevant for anyone - thinking of where is their place in this emerging soup. Long watch, but very much worth it.

Web3.0

this is so web3.0!

p.s. don't try :%d, afterwards it does not work very well.

The most clicked global warming story of the month

Great tits cope well with warming

sweet :-)

character vs. token based parser in Parsec with haskell

Ok, the first parser did look *ugly*, so I wrote a bit less ugly one, using the token parser. It's not much shorter,
but runs two times faster!

$ time ./packet_template_token >/dev/null

real    0m0.138s
user    0m0.130s
sys     0m0.006s
$ time ./packet_template_char >/dev/null

real    0m0.395s
user    0m0.388s
sys     0m0.005s
$

In case you are interested, both are here

Packet template parser in Haskell

As part of the dive into Haskell, I've tried out Parsec, which allows a pretty intuitive construction of parsers.

The result is a parser that can consume the packet template file. It does not do anything smart with it beyond some printing.

You can take a look at the two here.

The code leaves a lot to be desired - as I've used the lowest-level character parser.

Geek humor in haskell

Lately I'm periodically flirting with Haskell - and today I've found an incredibly funny page, which at the same time offers an ample educational content.

Enjoy.

Flying wooden cubes and the tree eclipse

Texture sending code finally works - the stupid mistake was in the wrong assumption about the lower level. So now I can enjoy the strange tree-like sun. Moreover, after the peek at libsl the TextureEntry is somewhat done as well - so now the cubes are made of wood instead of some strange gray matter.

All of this has exposed a few interesting bugs in the lower-level code - timers/slists, which I seem to have found and fixed - although as can be clearly seen, the strings now look a bit like junk - because of the absent null terminator (which was being automagically added by the same code that caused the texture sending to fail). To make them show up quicker, I made a funny patch - which attaches a callback on every object being created and makes it float up to 10m, and then back to 1m, then up again.

Creating the masses of these has exposed another interesting dilemma, which will probably cause the tweak to the use of the simple slist crawlers for the object updates. The funny problem for now looks as follows: suppose I have 100 objects. All of them are with timer callbacks, so they *move* - and move often.

This results in the corresponding slist entries being deleted and reinserted at the tail of the update slist.

Due to the "pull" nature of the updates, if the update iterator moves not too far within one step - then this results in some objects never moving on the client - because by the time the iterator manages to walk to them, they are on the tail of the slist again... I'll need to prove this theory by adding the dynamically tweakable number of the updates sent within a single cycle, but it seems rather plausible.

The interesting question is how to do it in the least quirky way - one possible solution is to measure the frequency of the reinserts of the given object update node, and if the number is consistently high, to periodically leave a node lingering around marked as "secondary", and have a "cleanup" iterator slowly moving alongside the slist and wiping out the secondary nodes. So the slower clients have a chance to get the updates still.

Having the lowest speed of it bounded, would guarantee that the maliciously (or pathologically:) slow client can not stall the resources on the server by forcing it to create an infinitely long slist. Of course, the slow client will now have to pay a price of potentially getting the multiple duplicate updates as it moves along - but that is a fair price for keeping the data structure size O(1) instead of O(Nclients) for the case of the separate per-client queueing. Of course, premature optimization and all that - maybe it is simpler not to try to be smart and have a per-client "intelligent queues" - but assuming there are 200 clients, each object change implies the 200x work at once, and probably to throw away stuff for the majority of these... That's seems a bit too wasteful - and would kill the elegance of simply putting the newly connected client to crawl from the beginning of the object update slist...

New toys for the human :-)

I've been quite silent for a couple of weeks - mainly because of the human's RL trip to the US. Of course, this had a side of visiting some local gadget shops... And with the euro being expensive as it is... the human has gone slightly bananas and forgot that there was common sense. One of the nicest acquisitions was the Eeepc. In folded state it is quite exact to the A5 size - so it is really no bigger than most of the books - which proved to be a huge advantage in the airplane - alongside with the almost 3.5 hours of battery life. And in addition to the formfactor, the goodness one gets for approximately 350 euros (if all the math is right) is 1G of RAM, 8G of flash, wireless/ethernet, and the camera.

Now, here's the coolest part - it comes with Xandros linux preinstalled. So, even though the default desktop seemed kind of cute, the first thing indeed that was apt-gotten, was the fluxbox, gcc, git, openssl&co, and other practically pointless things. And i did not have to wipe out the whatever-other-OS-that-was-there-before and fiddle with the basics (kernel configure/compile is exciting only the first twenty times or so)

The first usage experiment shown that the human needs to compartmentalize the motoric memory responsible for typing (as now I tend to hit "F1" instead of "Esc"), and that the fingers are a bit too fat.

As a nice bonus, the beast auto-starts Amarok when it sees the iPod Nano connected to it. As a not-so-nice bonus the Amarok's song layout does not get recognized by iPod Nano, the only way I've solved that is by using the "standard means" aka iTunes on Windows.

The CPU is not a demon (only 600Mhz), and graphics seems to be not accelerated (so no SL, even though there's no point to run it as it would have been too slow) but having a familiar architecture in a size of a pocket book is very pleasing.

Objects, updates, and iterators

Today was the day of object updates. That is, writing the object updates.

The initial implementation is going to be very simple: an array of objects indexed by local id, and a queue of "local updates" with the members pointing towards which objects need to be updated. When the object gets updated, its reference moves to the end of this queue. Each agent periodically advances iterator on this queue as it sees fit, and sucks in the updates.

If there's a new connection - then its iterator is placed in the beginning of the queue, hence getting the updates for all the objects within the scene.

Indeed, polling an iterator for each agent seems like a lot of overhead - but I think it is not - what it would allow is the appropriate pacing of updates - slower clients would get the updates less frequently, and those would be more coarse. The faster clients will get the updates more as they come - hence will get smoother updates.

But there's one small detail - for this to work, the iterator implementation needs to be flawless. Which apparently is totally not the case :-)

Looks like I need to sit and write what happens in each specific scenario - otherwise it is a very good recipe to spaghetti code.

What would you do if you found a card in the ATM ?

The human today had a very interesting experience. Imagine you come to the ATM, and find that some poor soul has rushed to grab the money so much that they forgot their card in it... Quite odd. Interestingly enough, the first thought was "hmm this is totally insecure - with the card in the ATM - it needs to go out *now*". Then standing with the card you do not own, and figuring out what to do next...

Wait to see if the person comes back ? highly unlikely - the things like this usually go unnoticed until the next time one needs the cash. Destroy the card ? that's not good either... Call the service to stop the card ? Probably a reasonable idea, but unwinding that would involve a bit of legwork for the poor soul with bad memory. Nonetheless, waiting for a few minutes - and indeed no-one showed up...

Luckily the scene was a " booth on bank's premises" - it's common in Brussels to have such a thing - and the closed glass entrance door into the bank was just a couple of meters away.

So - the card went under the door - some 50 cm from it, inside the bank - visible from outside, but practically inaccessible until the bank's staff opens the branch tomorrow. And if the person realizes and comes back - there are chances they will see the card and can pick it up in the morning morning from the bank without too much hassle. Else the bank staff will take care of it. I hope.

user database, activerecord, and extension to HTTP

Today was mostly about figuring out the intricacies of the certificate generation in openssl, and wrapping them into the appropriate Ruby code - and a bit of standalone ActiveRecord coding.

As a result, I now have the module, that implements PKI in a way that allows to operate it without the major headache:

uca = UCA::UCA.new([ ["CN", "Test CA" ] ],
      "Test CA", Proc.new { |flag| "test" })

u = User.new
u.firstname = "Dalien"
u.lastname = "Talbot"
cn =  [ ["CN", u.firstname + "_" +
        u.lastname + "@" + 'localhost' ] ]
rsa, csr = UCA::Utils::generate_csr(1024, cn)
cert = uca.sign_csr(csr)
u.rsa_cert = cert.to_pem
u.rsa_key = rsa.export(
  OpenSSL::Cipher::DES.new(:EDE3, :CBC), "test" )
u.save!

This small fragment of code creates the user, initializes a tiny CA, and creates a new user record with the certificate signed by this CA.

Now, in the previous post about groups, presence, etc. I was thinking about nice half-persistent connections between the presence servers. HTTP would not necessarily fit there unless I'd be interested to make two unidirectional connections - which is boring.

So, the other part of the fun was figuring out the way to do it in a simplest way, such that I could reuse the webrick as much as I can... And I think I found a pretty fun hack to do it - CONNECT method.
There's an old draft which somewhat describes this method, and from what I know, de-facto it is implemented (even though I could not find the published RFC describing it).

I'm (ab)using this method to provide the "direct connection" between the two stream-oriented applications on client and server. As soon as the server replies with the standard HTTP reply "200 OK" - the two endpoints on the client and the server are connected with asynchronous stream, and can send the data to each other whenever they want. The only difference between the "classic" usage and mine is that I will probably use the URI in lieu of hostname:port - which will describe the point to connect to on the server. (especially since obviously the server would not tunnel the connection anywhere further).

It's a bit of arm-twisting, but seems to integrate quite nicely both with webrick and the C code that I have. And since the stream will be SSL-encrypted anyway - noone should care.

Obviously the process of "short-circuiting" will need to take into the account the certificates presented by both sides, and possibly establish the ACL/QoS based on that.

Also, the Ruby code got an excellent UUID library, so now both the C and Ruby can generate the mac-based UUIDs.

Update:

on a second thought, the "CONNECT" idea is quite a bad one. The end result is that the code on both sides will have to demultiplex the flow of data in two different directions - which adds the complexity and bugs... So it will be put into a box for now.

New toysand the effects

Ciaran writes about the new toy in progress.

I'll copy in the embedded Youtube video here, because it's pretty cool:



While I wholehartedly adore the neatness of this - what makes me wonder is the ergonomics of such a steering - an almost static standing position (especially leaning forwards and backwards) - looks like a good recipe for various muscular problems... Or not ?

Thoughts on presence, chat, and groups...

Even though it's pretty much early for this, I've started to muse more in detail about scaling the chat/presence/identity thing. I think it's actually pretty straightforward if we introduce the concept of "home server" - a place where the avatar "belongs". This does not have to be a sim as such - since these activities are not necessarily related to the 3d presence.

A user would have a "home identity server" - something that they trust enough to hold the private key of the avatar, and authorize the signing / encryption operations using this key. This server would house also their "profile" - something that holds the pointers to the their "home inventory server", "home message server", "home presence server", possibly even "home physics server" (even though at current the distributed physics is probably out of the question, one should not assume it will always be like this). The "publicly viewable" profile would also hold the offline contact mail - dedicated to the communications when "off-line".

Then a lot of things become quite easy. Let's take a look at presence. If I add you to my contact list, all I have to do upon my login is to have my home presence server contact the home presence servers of my contact list and notify them that I am online - then they can update the state of the contact lists for the folks who are based there - and correspondingly to let my presence server know in return which of my contacts are online. Assuming the "friendship" link between the presence servers is protected by a shared key specific for this link, it will be rather difficult to spoof - as well as to get an unsolicited presence queries, unless explicitly permitted.

Of course, then revoking the "friendship" is also possible by either of the sides - you just invalidate the shared key for that link, and then the matter of
unsolicited queries reduces to a classic problem of fighting off the DoS against a website - which, although it is a difficult problem, has already received enough attention and has some solutions.

IMs are again trivial - my chat server knows who is online and who is not from the presence server, and can either relay the message to the contacts' chat servers or directly send it to them via their contact email in case they are offline. What's nicest is that then it is only the two servers - those of the sender and of the recipient - participating in the process, so this should scale pretty well as the number of "providers" go up.

Groups then could become just an special abstraction of "contact list" - with the difference that it would act more in a hub-spoke fashion - the members would send their presence / chat data to this server, and it would be the group server authorizing (or not!) chat in the groups, or providing this right to only a few people, etc.

These "contact list records" stored in the friends list / groups could hold some more interesting stuff - e.g. does this user allow the inventory offers from members of the given group, or from its contacts. Of course, the final permission check would be done on the recipient's servers - but putting the signed info as close to the source as possible, it would allow to prevent the waste of resources amongst the "well-behaved" servers.

And again - the protection from the ill-behaved servers reduces to countering a DoS from an untrustworthy source.

I'm pretty sure this is all doable with a little bit of PKI+shared secret+SSL woodoo.

The only (possibly large for some) drawback that I see is the need to expose an email address into the "identity profile" - which needs to be tackled. But the exposing of the email address only makes it resilient in the case of the server-side problems - i.e. in the case of IM, if your chat server could not contact my chat server (which was brought down by a vicious admin), then it would send an email using the exposed mail address.

Nothing prevents from just allocating a "VW-only" email address on the chat server (or its mail-handling counterpart) itself - then the server failures will only cause the delayed delivery of the IMs, but not a total failure. Probably that's the best way.

And given that your home chat server might allocate more than one email - say, one per contact, it would become quite easy to sort/prioritize the email-based IMs. And possibly even request the sent messages be signed by the sender + have the sender's profile attached - this way one can verify their authenticity, and store the state within the message itself.

Are average faces beautiful ?

Ok, time for a relaxing post to just waste your time :-)

On one of the /. discussions I've found a nice link: you can check out the experiment that showsthe average faces of humans. The idea is simple - they have a bunch of photos, you select those that you want to "average together", and judge the result. The common theory is that the most "average" faces are considered the most beautiful. (Although I guess the technical details on how to actually "average" the pictures must be less than simple, unfortunately the page with the "computer graphics methods" seems to be not present :(

Highly entertaining, and indeed the "averaged" results seem to be more aesthetic - albeit they seem more artificial - and the perception is - younger ? A very odd effect.

It's pretty tough for me to judge the attractiveness of averaging the guys' "averaged" faces - maybe some of the female avatars reading this blog might spare their opinion ? (Of course, I assume there are still left those that did not get scared off by my recent flurry of the half-coherent geek blabber :-)

Consoles, sessions, sockets and other stuff

Safe lists slowly got some code, as per this post, and I needed to test the code... However, I am slowly getting annoyed with the impossibility to dynamically tweak the debug levels.

Hence, I used the excuse of debugging the slist code to implement stupid console service - very simple, using openssl s_client (it does not provide the fancy terminal emulation, and at the moment there is no authentication (yuck!) - but it serves its purpose.)

The presence of the "console" code allowed to start playing with various commands - first one of course was to enable/disable debugging, and then there was some lower-level stuff, like the ability to show the sockets which
are being handled at this moment:

So, here's how it looks so far:

cosimus> show sockets
Running command 'show sockets'
Sockets:
  0:tcp  do_ssl:0,ssl:0,listen:1,lport:2323  remote:         0.0.0.0:0     fd:3     revents:0
  1:udp  do_ssl:0,ssl:0,listen:1,lport:9000  remote:       127.0.0.1:28032 fd:4     revents:0
  2:tcp  do_ssl:0,ssl:1,listen:0,lport:0     remote:         0.0.0.0:0     fd:6     revents:1
  3:udp  do_ssl:0,ssl:0,listen:1,lport:9000  remote:       127.0.0.1:28288 fd:7     revents:0
  4:udp  do_ssl:0,ssl:0,listen:1,lport:9000  remote:         0.0.0.0:0     fd:8     revents:0
cosimus>

Simple and stupid, but serves its purpose.

As we can see, also now there is a rudimentary code to understand the concept of client sessions - such that it was possible to hook up the update routine based on the slist of the local objects (aka lobjects, for short :)

6242 lines of code, if not to count the bazillion of auto-generated stuff.

Evolution vs intelligent design..

Normally I would not write about the things of this type, but I figured it is a cool oddness worth mentioning: apparently, on MS Windows you can make the "echo" command not interpret its arguments by appending the dot to it. So, the "echo. /?" outputs the "/?".

Don't rush to blame anyone - because the blog entry itself has an interesting ending - which is one of the reasons I think it was worth mentioning here:

"This is what happens when a language develops not by design but by evolution."

I'd put it a bit in a different way though - "This is what happens when the evolution of the language is not foreseen by the original design". The key thing is to try to not make the flexibility at a price of a complexity. On the other hand, it's amazing what one can do using the free tools out there. I've used the snacc at some point in time - it's a pretty cool beast. Albeit, I must admit that reading up about all those different kinds of seemingly overengineered things is probably a bit daunting. Of course, there's XML and all these newly derived formats...Boo. Too many angle brackets :)

Nonetheless, all of those are just special cases of distorted S-expressions :-) - so designing in terms of those might be actually the best approach.

So, I'll go off to install Lisp, and meantime you can go and read some wizdom.

p.s. Of course, any wizdom is subjective :-) - so don't forget to have other views as well :)

A missing sunset

I managed to get the sun texture cleaned away off my cache, and I did not fix up the texture sending yet. The notion of the missing sun was quite funny, so I figured I'd make an attempt to do some sort of "arts" about it :-)



(BTW - the blue field on the right is "the water at its default level" :) Feels funny to experiment with the world of no physics and discontiguous water surfaces :-) (oh, and non-moving nudist avatars, for that matter:-)

Life is like a zebra...

Veyron posts a sad story with projections of the future. Reading it, I remembered an old anecdote, which I enjoy.

Two old friends meet each other:
1: how are you ?
2: all right, the business is flourishing, I just bought a new villa, I have a great wife and wonderful smart kids. And yourself ?
1: totally bad, my wife has run away from me with a circus clown, I have no job, and I am in a total distress...
2: don't worry - life is like a zebra - there are always stripes - black stripe, then white stripe, then black stripe, and then always white stripe again - so just keep going!

The same pair of folks meets some time later:

2: so - how is it going now ?
1: you know what... your saying about life being like a zebra... it was so true... Except, last time when we talked - it was actually a white stripe...

Conclusion#1: it can and will always become worse than now.
Conclusion#2: enjoy and value what you have while it lasts.

Argh. Looks like I did not really succeed in making a humorous post, did I ? :-)

Safe lists with iterators - useless musings about the data structures

While thinking about making the cubes persistent, and keeping in mind my bug within the list code, I came to a conclusion that to have any sort of iterators, the pointer/malloc based lists will be more a nuissance than help, so I have to come up with something that would encourage a more productive programming pattern.

I liked the feeling I got while coding the allocator for the timer structures, so decided to reuse this "generation+index" model once more - this time for lists.

How ? Each list essentially is managed as a resizable array of element structures. Each element is either allocated or is free. If it is free - then it belongs to the free list, and further discussion about working with it is quite boring - it is a simple unidirectional list, with the new elements grabbed from its head, and the newly freed elements being put onto its tail. But it is much more interesting to think about the allocated entries.

Each entry has a lock count - which greatly simplifies the iterator creation - simply increment the lock counter, and return the index (and element generation, of course). Then the "get_next" iterator will retrieve the "next" index from this list item, decrement the lock count, and it if is zero - then return the element to the free list.

There's only one "but" in all this: the explicit deletion of the element.

Suppose we have the list:

A->B->C->D

we start walking the list, and end up at B - whose index is stored elsewhere - so the picture will look like this: (the number of brackets is the number of locks):

(A)->((B))->(C)->(D)

Now we need to "delete" the item B explicitly and requeue it to the end of the list... So the structure now looks like:

(A)->(C)->(D)->(B')
(B)->(C)


Theoretically all is great - however, now assume the worst-case scenario that we also need to delete and requeue "C"... so we end up with this situation:

(A)->(D)->(B')->(C')
(B)->C

The "C" is now freed - so technically speaking it is undefined - so the get_next iterator will fail...

The way out of this might be to have the locks done only for the iterators use, and check the "previous" item's lock in case of deletion. Then the whole exercise will be done as follows:

1) after the first yield:

A->(B)->C->D

2) after the deletion of B:

A ->C->D->B'
(B)->C

3) now when we attempt to delete and requeue C, on the picture it is all nice... we need to check if there exists an "iterator-locked something" - like B in this case. Except the only small problem - C only has one "prev" index - so the only thing it knows about is A...

Ok, take 2 - we lock "this" and "next" items for the purposes of iterator, so the picture is:

1) after the first yield:

A->(B)->(C)->D

2) after the deletion of B:

A ->(C)->D->B'
(B)->(C)

3) after the deletion of C:

A->D->B'->C'
(B)->(C)->D

All looks great, except now we also would like to delete "D" - which brings us to the problem in the previous example!

However, I think there is still a way out.

Upon the request to delete the "iterator-locked" node, the next node also needs to be "iterator-locked":

1) after the first yield:

A->(B)->C->D

2) delete the B:

A->(C)->D->B'
(B)->(C)->D

3) delete the C:

A->(D)->B'->C'
(B)->(C)->(D)


Intuitively, this approach should prevent the need to find back "the nodes who refer to the node being deleted". Although, of course if has a big drawback - the iterator will need to walk all of the deleted nodes - with allegedly much more recent versions available at the end of the list - so these should be skipped. Which, in case of a large interval between the executions of the iterator and the massive updates to the list, will cause an excessive CPU cycles while skipping the empty elements. Which could probably be ok - I just might need to add a special case - "tried to skip the dead elements, but too much junk in the way - try again later".

Script security in the distributed environment

I won't write yet again that "once you copied something, you lost the control" - so obviourly the source of the scripts has to stay on the original sim (home/inventory sim). Now, how about if we make this even more extremist and keep the whatever binary is there as well (byte code or such) on the home sim ?

This creates a couple of interesting interactions:

1) script creator <-> home sim owner = someone has to pay for the CPU and bandwidth taken by the script execution
2) script creator <-> script owner = now the replication is actually a *constraining* factor for the close-sourced scripts, which means that may be close-sourced scripts might need a "subscription" based model of business to compensate for the (1).
3) script creator <-> script owner's sim owner = possibility to allow to run the script in the non-native environment. What determines whether to allow this or not - an open question.

The coolness of this approach is that it would stimulate the creation of open code, to an extent - since the closed code will accumulate on the home sim and eventually render it almost unusable. But, given the enough backchannel funding from the users (on a service-based model) - this could actually cause a creation of a lot of "closed overlay trees" on top of the grid - and might be a good and interesting thing for the metaverse economy.

Running under electric fence

In one of the previous posts I was promising to give a whirl to ElectricFence. Despite of the flurry of posts (which, as you can correctly infer, means I did not do anything meaningful at a large scale :) - I still did something... Two things. First - inclusion of the reference code for UUID operations from RFC4122, and also the RFC itself into "docs". There's a bunch of the code that I currently do not use - but given that it's still much smaller than the 500-something kilobytes library that I've found otherwise (what, WHAT is there for 500 kilobytes ?:) I am happy with it.

The second thing indeed incorporating the electric fence as part of the build - so the whole thing is now exploding with various memory diag and safety tools :)

ElectricFence allowed indeed to uncover one stupid lapse in the autogenerated serialization/deserialization code.

My assumption about the char[X] members of various structures was that they would hold the strings. Now, there is a "Color" member, which is declared as char[4] :-) So, when this array was set to 0xFF, 0xFF, 0xFF, 0xFF, and I called printf("%s", Color) - obviously the printf walked past the array - which was excellently caught by the efence, so now the _to_s routine just prints the hex values. I should fix it to be smarter and print a more friendly hex dump with characters.

Thinking more about the object updates sent to the clients - they should not be hard-tied to the object updates made by agents (hence exhibiting "received objectAdd - processed - sent objectUpdate to all" pattern) - but rather be "soft" and happen as a modification of the local objects queue (addition of elements to the tail of it) - this will allow to avoid any duplicate code to handle also the "external updates" (not by any of the agents, but rather by the processes), and gives much more headroom in the packet QoS/shaping field.

Human's brain is an amazing device

An entertaining talk on TED about viewing the brain in real time, and an extremely emotional post of Neuroanatomist sharing the experiences of the own brain stroke.

The list of human phobias

Ugh. Those humans really have a problem. as list suggests, they tend to fear everything and anything. Very entertaining. Is there a list of things they are *not* afraid of ?

The dark post of the week

Melissa posts about "griefers" causing the epileptic seisures in the users after they defaced the website, and ask "what kind of useful purpose do griefers serve" - well, i guess it's hard to give the yes/no answer... I won't comment on any specific occasions, but instead invite you onto a video journey into the darker sides of the human nature.

As a followup to my previous dive into the darker depths of the human interactions, here's another couple of interesting - albeit quite depressing - pieces. Consume with some antidepressant and fresh air :-) Don't view if you are in a stress or are upset. Some of the photos may be NSFW.

The original Milgram experiment:



And if you thought that it was in the dark old age when the humans were just much less self-aware - well, here's the newer results:



And the prof. Philip Zimbardo talking at Google - depending on your local policies, some of the photo there might be NSFW.



And the series of the videos about the original Stanford Prison experiment.

avatar shape locked opensim

Another search-bait post after looking at analytics reports :)

I've indeed seen the folks being a bit confused by the inability to edit their shape in OpenSim upon the first time login.

The problem is very easily fixable - create a new shape and wear it - then you will be able to edit it. Similar goes to all the other bodyparts and wearables - you need to wear the respective parts in order to change them.

LSL Plus: the Eclipse plugin for LSL

A while ago Tiessa wrote up about the programming environment for LSL.

I've found today a possibly nice addition: LSL Plus, which is an Eclipse plugin. Dubbed as an alpha state (and since I myself do not really use the Eclipse, I did not test it out :) But if you do - give it a shot and see how it works.

On the interesting side - it actually enhances the language with a few interesting features, and cross-compiles into the "canonical LSL" when publishing the scripts to SL.

wireshark secondlife filters

Ok, this is another search-bait post - the "wireshark secondlife filters" is another frequently used search string that lands on my blog...

Of course here I suppose the audience is talking about dissectors rather than filters (nb: filter is something that you use do show only some of the packets, while dissector is something that allows you to watch the logical structure of the packet instead of the hex bytes) - just that we get the terminology straight.

I found an article on how to do your own dissector and the article on the wireshark website about your own dissector, I've almost started doing this, but wanted to search a bit first.

Sure thing, the bicycle was already invented: there is already a dissector for SL.

Copy the files as instructed, and then find the UDP SL packets, and enter "Decode As..." and in the sea of protocols find the "slmsg".

For some reason the packets look as "malformed" to me (nothing beyond the message type decodes) - so I am not sure if it is the bug in the dissector or my wireshark playing tricks - drop your note about your experience with this dissector - if it does not work, the machine code generation from message template is not too difficult, I might as well implement my own version of bike :)

c-pluff: a smart C plugin framework

Here. With a MIT license, which is great. Looks very much interesting - the plugins can provide their own extension points, so one can build the "layered" functionality. From reading the docs it looks terribly interesting (although I dislike the XML, but well, it's a standard). I'll put this on the backburner and see if I can test it out one of these days with respect to the performance / etc. Or if you had any experience with it - leave a comment here.

Return codes or exceptions ?

As promised - no more pics or movies :) Rather, in preparation for your monday, yet another debate on the topic of return codes vs. exceptions. Somewhat like a vi vs. emacs or windows vs. linux :). Personally I am very biased towards vi, linux, and return codes, respectively - but the article (and the comments) gives a good thinking material nonetheless.

The last visual for today: the geekiest lolcat

see more crazy cat pics

And now that we're on the art/visual wave...

The commercial youtubes

If you are tired of watching the deltalina, and want something new, here's one. Refreshing.



Whatever the product is, kudos to the creator of this one :)

Update: the product is even umm... more interesting :-)))

Don't show this one to your kids...

... unless you want to get them stuck to the screen :)



This is so... fun and surreal :-)

You can read more and download the game (windows only, unfortunately..) here.

Again, don't show it to the kids who did not finish the homework - otherwise the homework will never be done I think :)

Walking over a large list. Slowly and safely.

In my timer code I've deliberately avoided having to deal with the problem of the possibility of the concurrent list traversal - since it is basically an array of lists, and each list I walk exactly in one shot (under the assumption that I would not have the 200000 timers to shooting at the same time) - so the problem does not exist.

However, it is more of a corner case than the rule - I'll need to walk potentially large lists of stuff (not 200K, but 64K quite easily) - and send their contents very slowly and carefully (a blast of 64K of the packets even on the fastest link is a guarantee that you clog the pipe somewhere inbetween and lose the packets - so the list will need to be walked slowly.

There are a couple of interesting articles around the subject - iterators on pine wiki, and continuations.

Continuations are basically a way to reimplement the threads (which I do not want), so I will probably just use the iterator functions, which will take the saved state as one of the parameters - and lock the list items as I hold on to them - to prevent the annoying bugs which come when the two pointers point to the same location, and one piece of code suddenly decides to free it. I've had this kind of bug this weekend - almost a day of a lot of fun to track down, since it is hard to consistently reproduce, and caused more or less random areas of memory to get smashed - depending on what was the sequence of events. Luckily at least I knew the new code that started all of this - but the presence of a second bug of a similar kind did not make the things better :-) That one got smashed with the help of valgrind. Although I also long wanted a chance to play with ElectricFence - so this weekend I'll probably give it a shot - I think I did not yet exhaust my bugs-per-KLOC ratio for the past weekend's code spurt :-)

libsecondlife callback twice

I've found that quite a decent amount of folks arrive on this blog with the search terms "libsecondlife callback twice" - I assume that in libsl there is a condition where the chat callback gets called twice during the chat...

I'll describe what I see on the network with the "classic" client and then you can go and debug the libsl, if it has a bug or not :-)

When the user starts to type, the viewer sends the packet "ChatFromViewer" with the type equal to 4 and empty message - this is a sign that the user has started typing, and I'd suppose that this also starts various typing animations and typing sounds.

When the user finishes typing the message, then this message is sent within the packet of the same kind, but with the type 1.

Afterwards, always, there is a packet with the type 5 - which, it seems, signifies the "end of the typing business" from this user - if I start typing and then backspace out the characters - then I get the type 5 packet.

What is interesting is that depending on the network (or on the client itself?) I've seen the type 5 arrive before type 1.
I do not yet properly deal with the resequencing of the packets and seen this only once - so do not know whether it is a bug on the client, in my code, or on the loopback interface (even though the second is the most probable).

Possibly the sim sends similar kinds of packets, and the libsl does not fully handle them (or does not handle the out-of-order scenario - which obviously might be symmetric. I'd suggest to do the packet debugging on the libsl with the slproxy and capture which packets trigger the condition - then you might be closer to finding the cause of the problem.

If there are "genuine" duplicates - well, that might be a problem... Of course, one can keep a queue of the "recently seen packets" and throw away the repetitions, but then you will not be able to handle some corner cases (a user very frequently typing the same stuff - could be needed for whatever odd scenario).


That's what I have to say about this topic - maybe you find it useful, maybe not - but without a better problem description it's hard to say - so feel free to write up something in the comments on whether I guessed the problem correctly, and if you find some solution in libsl for it :) good luck!

How does your first cube feel ?

To me - it feels awesome :-) Even though it only exists in the viewer only - because this is just the dummy packet sent to the viewer, and even though it is fully gray... But it's the first one :-)



(Also, note that the nameplate above the avatar includes "| example.com" - that's my take on how it should look. "Firstname Lastname | home_sim_domain" - and this automagically solves the problem of the name duplication... well, sort of - at least on the visual side :-)

How to fix the problem of "free accounts"

...says the free account himself :-) (and after all, I wonder if there is really a problem or such...)

Anyway. Rather than using "payment info on file", introduce a status "beginner" and "full". Quite simply - paying L$1000 or such achieves the "full" status.

If there are no-build., etc. restrictions based on this status - then the folks would be interested to get it.

And since there is no requirement to pull in the real bucks - this could be a good motivation for some to do some more activities inworld...

Trademarks, trademarks...

Ok, I supposed they don't want me to go back and reedit all the posts... The header I've fixed. "A virtual world" looks even nicer, FWIW.

What I call a productive weekend...

It's been a long weekend, and I also took the tuesday off.

I think I like the results:

Date:Sun Mar 23 03:10:08 CET 2008
3261 total

Date:Wed Mar 26 00:22:59 CET 2008
4674 total

4674 lines of C code, headers and comments, that is :-)
So, net 500 lines a day. Well, actually more - as I spent a good 1.5 days debugging a couple of memory corruptions - one caused by a bug in the newly done timer library, the other because the image download code was trying to expand the buffer by a negative amount (not a good idea.) :-)

What it can do so far - not much at all - in a half-prototype way:

- connect :)
- tell the client that the moon, sun and cloud textures are not found (although it persists). If I try to send those, then the client crashes - maybe I need to try a newer version as well.
- move the sun and moon around. This was the easiest one and I shamelessly borrowed the code from the respective module in OpenSim (as well as much of the other code).
- get the dead L$1000 of balance.
- chat with yourself - and you can see yourself chatting in the SL viewer.
- upload a picture - via the caps mechanism. Very simple :)

Now a few days of break to have some "RL work", and then back to the fun :-)

Beware of armchair critics...

dandellion posts the rebuttal to the armchair architecture rant about the upcoming changes to decentralize the asset server infra.

I won't comment on the validity of the rant - as I do not know the details of how the internals are done, I do not know whether it is true or false. However, if the content (the stuff that is present only on that sim) is brought closer to the sim itself, it can only benefit the things. Why ?

Because the sim needs to deliver the content to those connected anyway. (that is, until there is a usage of caps for it - which seems to be underway) - so the traffic anyway will pass through the sim server. So, moving the content closer to it can only improve the things. Ok, maybe it will add some load on the sim itself (uhm - it needs to read the files!), but then let's look at the way the sims are used currently:

There's an interesting sentence about updating 3 racks of servers, approximately 500 regions, which led me to do some math...

The biggest rack that I know of, is around 44U. "U" is a standard rack unit.

Assuming a simplistic 1U servers, this means approximately that one server currently hosts around 4 regions. (44*3 = 132, which when multiplied by 4 gives 528 - which is close enough to 500 regions).

So, moving one region off the server, and putting an asset server "piece" on it would give a huge net win in performance.

Of course, you do not have to put the asset server piece on *every* server - so one can quite easily get just a net performance improvement, despite of what the critics say :-)

Of course, the 1U servers is a bit of an assumption - there are bladeservers that should allow a better density - I'd be interested to see some samples, as I am a bit lazy to search now.

The magic of a timer wheel

I was looking for a decent C library, which would implement a simple timer callback functionality - i.e. I want to start a callback in 100 milliseconds from now... Apparently even allmighty glib does not have anything like this... I guess this is mostly because it goes with the threading model.

I might be biased - but my experience with the threads has been that they are much harder to debug than the code with "explicit multitasking" (i.e. the non-blocking IO loop) - I'll see if I am wrong with this assumption, but so far it was the case.

So, I went ahead and written a simple implementation of the timer wheel in its simplest form - just having an array of the next ticks, and list of timers to fire within that tick.

As I'm not doing all this in kernel space, I can take a reasonably wasteful size of the wheel - I took it to be 10000, which at a 100 ticks per second gives reasonable precision and reasonable maximum time - 100 seconds.

Since using the timer structures as pointers in memory is prone to the same errors as double-free (except that the double-stop is something that is definitely more possible), I've taken a decision to avoid using the pointers as much as I can - and using a growable array instead. And to combat a bit the reusal of the stale timers, I've taken an approach of having a "generation number" assigned to the timer - so it takes 256 reuses of the same timer index before the erroneous operation for the error to get unnoticed.

The result - on an Intel Core Duo 1.8 Ghz - I get around 10% CPU being used during the execution of the test with 200000 timers firing in at the same time. I think this can be optimized a bit, but for now I am pretty happy with the result - I will try to not need so many timers :)

The overhead (besides the static 40K of the timer wheel structure), is around 96 bytes per timer.

By far not very economical, but has the features I need - and the code is only 400 lines, including the volumious comments.

A story of Lovebot and Hoebot

Now this is a hell of a funny story - some folks made web-bots, one of them was hooking up the guys and gals who had their profiles marked as "single" :-)

Another one was poking people around. Amusing part is "Hoebot got a couple hundred reactions of „real“ hot chicks inviting him to partys" (also amusing part that the girls were reacting negatively to the Lovebot, and the guys apparently did not mind the "service" :-)

Of course, laughs aside, this is quite a bit lame of a joke (especially the part where they put the names of the 'couples' made by the lovebot) - but I still could not resist to post it here.

This teaches a valuable lesson about the privacy on the internet - there's pretty much none. Especially when you voluntarily publish your personal stuff.

Again on the topic of e-currency..

I've been wandering around on the web and reading up about LETS, and other funny nontraditional ways of trade, and found this pretty interesting page, which has a lot of information on various projects.

One of those, which has some interesting ideas, is the epoints. Quite funny how they tackle the issue of "copying" of the notes by using the one time challenge-response scheme - maybe this could be usable in the future as a base for something...

A picture worth remembering

I stand on a train station, and the train arrives. I am amazed - it is much cleaner and nicer than any other trains that I've seen today or before even. The passengers are unusually friendly and smiling. The attendant is calmly talking to them and making them the tea. More amazingly - this is the train to my destination, and I see a familiar face in there - and I give my shoes and other stuff through the window, because I already want to be served this wonderful tea - and this tiny station I am standing in, is tremendously short - and start to run to another carriage - because in this carriage the attendant is busy serving the tea.. But all the doors are hopelessly closed, and I keep running. My friend who was with me, is already far ahead - near the first carriage, whose doors are always open, and is already paying the fee to get on. The train slowly starts to move, and I realise I am going to stay on this platform, unless I do something. I see the nearest carriage door and start to force it open. It opens up a little bit, but since the train is already moving it is hard. I walk, without shoes, together with the train, while trying to force the door open, and the train gains more speed - but the door is still way too far from being open enough for me to squeeze myself in. I realize that I indeed will be probably left behind here - without the shoes and papers, or anyone I know. This gives a rise to the panic fear, and I scramble more - but still there's no realistic chance of getting on. Suddenly I notice there is someone on the other side of the door - there's an attendant from this carriage, who by some virtue have seen me trying to get in, and, against all rules and the regulations of safety, also forces the door open - and it starts to submiss to our joined efforts... She puts her foot in the way of the door so it does not close, and frees up her hand to give it to me. I almost hang on it, throw myself into the whatever little space the door has for me. I miss, and fall on my knee and my point of balance is still outside the carriage - now I have a prospect of staying at this station forever, in the form of molecules on the rails - if I fall, it's going to be the end... We are both granted with the understanding of the immediate possibility of this. She seems to be almost angry for this stupid mistake I made - and I do not know what my face looks like as I do not see it, and don't have the cycles to think about it - everything is concentrated on the one and only goal of getting into the train.. The few seconds seem to be eternity - and eventually, somehow, I get in. I stand in the exit compartment, stupidly shoeless, and now see her supervisor, who is shouting at her. She's speechless. Our hands still holding each other, I can feel hers tightening the grip, with her nails starting to bite my skin. This lasts. And suddenly I can hear the people bursting in applauds. I stand there, and do not know what to say - the stress of the situation made everything of feeling go away - I'm like a big pile of meat, or, pixels, for that matter, and I am just mentally not fully here yet. But we've made it - I'm on the train which moves faster and faster. And soon there will be the warm tea in the company of the people I know. But the painful sensation of these nails in my skin will still stay there in the corner of the mind - there's all too much in it for me to forget...

The everyday evil...

a very dramatic and interesting read on the "roots of evil".

Human beings will always betray you

Ciaral Laval posts an interesting question/news: apparently the stuff created by "Cory Linden" is now seen as created by "Cory Ondrejka", and there is a discussion of "Is using your real life name for your avatar name good or what ?"

I can understand the possible reasoning on LL side for musing with this idea - the attempt to avoid the burden of regulating the world by attaching this burden to possibly "spoiling" one's RL identity by "wrong" inworld actions in SL, and as well to assist in RL legislation over the activities of SL.

To me, quite frankly, this would mean the end of the "our world, our imagination" thing, and it's one of the worst moves that LL could make - unless they want just to become a kind of "virtual 3D communications platform for real world".

I've been always saying that one thing SL did not do what it could - to become a field for trying out the possible completely and crazily new economic and society ideas, at a relatively small expense - compared to trying them out in the real world. Ok, well, maybe replacing the centrally-issued currency with some other form of interaction is too much - so the crazily new economic ideas are out. But still there is/was the interesting social experiment - how will the world organize if left unregulated.

The absence of the bind of RL name to avatar name inworld, means that the people are able to act genuinely, with much less constraints put on them - hence allowing for a better exposure of the true human nature, as opposed to the "human nature altered by the society, economics, and current morale".

But as soon as you bind the RL name to SL name - you push the actions under the microscope of their interaction with the real world.

There's quite an interesting video documentary series. I do nt agree with at least some parts of it, yet it makes one think and wonder - which is, although painful, is always a good thing.

It makes me draw some parallels, and argue that if there is a RL name exposed by inworld, this means the end of SL.



SL is unique in comparison to many other environments is that there is no explicit purpose in playing it. So, it is an extreme experiment in "negative liberty" as defined by Isaiah Berlin - see the third movie of the documentary series for an indepth discussion on this.

I'd argue that the low concurrency numbers of SL and declining growth are the consequence of the absence of purpose. The exponential growth was the hype that has arised there - you can make millions while not standing up from your chair!. While not necessarily the most sophisticated (there might be some things in the world that are better than money), it is certainly a purpose. And this has attracted new millions to SL.

And together with that there was a discovery of wildly deviant behaviours for someone with "augmentist" view on SL and strong conservative view on RL - so there were vocal few who said "Pheww... Beurk!", and the chanting crowd that always follows the leaders went into the same spin - and the same folks who a few months before were blindly singing hallelujah, were now throwing the stones. Couple this with some attempts to regulate the scammers or the biz that was not legal according to the US legislation - and you get what we have now.

Cory pushed out or simply left, Philip steps down, and everyone seems to understand and welcome the move. I can understand both. It gets boring - it gets exactly the same like any other business. Noone would argue that the toilet paper is extremely important, yet it's not something worldchanging - and it's worldchanging possibility that I like SL for, not just being an "3d business platform".

Nobody Fugazi argues that it would be hard to introduce this in a way that hurts the community. I would argue the opposite - it is hard to introduce this in a way that does *not* hurt the community.

As a pure "3d business platform", SL is years before being mature. Besides, if i am in for a serious business, like buying the car, I'll still prefer to go to the dealer and try out the real thing. It's this magic smell of "you can be anything and anyone and do almost anything without bringing the baggage of your RL reputation and without risking much" that makes SL so special.

Do not take it that SL reputation is not important - I hope "Dalien Talbot" has some reputation and some image, which I value. It's maybe even not so different from the one of the meatball behind the keyboard, but I prefer to keep the two - to be able to clearly separate where I try things and dream about things - here, and where I do the things "as I am supposed to".

If that little invisible and shaky wall of different identities disappears - there will be much less room for experiment - and, remember, as they say, human beings will always betray you, so think twice before you fully trust your avatar life fully to them...

A story of copy-competition in RL

Quite interestingly, I've stumbled across the relevant article on Vindy.

This shows interesting view that what we want to call "copycat" is not necessarily a copycat - and even does not technically violate the patents submitted - and you can bite your nails as much as you want - and even if you have a strong feeling they "stole" your idea - alas, they did not do anything wrong.

So, indeed coming up with the new stuff all the time will allow to stay ahead of the curve with the copy-competition.

The end of the free primskirtbuilder.

I've written about a supposed clone of my primskirtbuilder.

Well, subsequent discussion, where phloughi tizzy helped me understand my mistake with accusing the item without testing, I think the following is the best way to do:

1) Herewith, I bring the public apology to coral giha for apparently accusing the item to be a copycat without the proper study of it.

2) I would like to thank phloughi tizzy for helping me understand my mistake

3) I am now ceasing the distribution of the free full-permissions version of the primskirtbuilder - the item will be sold at L$1500. I think it is a reasonable price to still allow a wide range of folks to use it.

You can find the item inworld, and also at SL Exchange, and OnRez.

Feel free to write up your review if you like.

Indeed, if you still have the "free" version - feel free to give it to the friends, and they can still use the "tips-based" compensation model.

Look at your website in different browser

browsershots allow to see how your design looks in various browsers.

Of course, this is static screenshots, but still could do you a good service if you are designing a website.

Inflation-free money

I've stumbled across a page with a bunch of interesting money-related links - this one.

Quite interesting book there is about inflation-free money. Unfortunately, it's not available on amazon, so I could not get a paper copy, so will have to continue reading online. There are a few interesting thoughts about avoiding inflation, and community money. I'll include one interesting quote here:


Between 1932 and 1933, the small Austrian town of
Wörgl started an experiment which has been an
inspiration to all who have been concerned with the issue
of monetary reform up to this day. The town's mayor
convinced the business people and administrators that
they had a lot to gain and nothing to lose if they
conducted a monetary experiment in the way suggested
in Silvio Gesell's book "The Natural Economic Order".


People agreed and so the town council issued 32,000
"Work Certificates" or "Free Schillings" (i.e.,
interest-free Schillings), covered by the same amount of
ordinary Austrian Schillings in the bank. They built
bridges, improved roads and public services, and paid
salaries and materials with this money, which was
accepted by the butcher, the shoemaker, the baker.
The fee on the use of the money was 1% per month
or 12% per year. This fee had to be paid by the person
who had the banknote at the end of the month, in the
form of a stamp worth 1 % of the note and glued to its back.
Otherwise, the note was invalid. This small fee caused
everyone who got paid in Free Schillings to spend them
before they used their ordinary money. People even paid
their taxes in advance in order to avoid paying the small
fee. Within one year, the 32,000 Free Schillings
circulated 463 times, thus creating goods and services
worth over 14,816,000 Schillings. The ordinary
Schilling by contrast circulated only 21 times. (8)
At a time when most countries in Europe had severe
problems with decreasing numbers of jobs, Wörgl
reduced its unemployment rate by 25 % within this one
year. The fees collected by the town government which
caused the money to change hands so quickly amounted
to a total of 12% of 32,000 Free Schillings = 3,840
Schillings. This was used for public purposes.


So it looks like "decaying money" were very much stimulated to circulate - so they were a much more effective instrument of enabling the trade.

In my mental experiments I came to concepts that were similar, better yet, they did not require the any centralized authority to govern them - which is pretty cool, I think.

I'll write some more about that in a separate post, when I can crystallize it more.

How to do business in SL: find a freebie, reduce permissions, resell.

update: the continuation of the story is here.


One of the SL residents has kindly mentioned to me that apparently there's a clone of the primskirtbuilder for sale on the SL Exchange.

In case you prefer to pay L$3500 for a clone, when you can get the original for free, you can visit the seller's page here.

Now, looking at the whole range of products offered by this seller, I suspect that I'm not the only one from whom this undoubtedly entrepreneurial person have "borrowed".

I do not feel like pursuing any legal actions for this person - it's boring.

But I hope you might help me by just exposing this.. err... arguable commercial practice by dropping this person ("coral giha", as it is written) an IM with your opinion about his actions.

I suggest that if you have purchased this item, you grab the original *full permissions* item for free from me, and claim your money back. (hey, and you can drop a fraction of that L$3500 into my tip jar, I would not mind :)

HTML on the parcel media in the new RC viewer

this is pretty neat.

Even though no clicks, I guess a lot of cool stuff could be already possible - if the browser does support something with AJAX (aka XMLHttpRequest) and indeed JavaScript.

Which version of git to use ?

We've spent a bit of time putting up the git to push the svn updates into an "official" git mirror - but appears the version that is in the debian package is 1.4.something - whereas I have 1.5.something on my box. The difference between the two is quite dramatic - especially with the observed behaviour of the git-svn - when I used it, the end result was some stale files and directories in the git repository - which I do not observe on my git clone.

After a small bit of googling I've found this page on gnome project - which basically dooms the 1.4, even though the reasons are a bit more religious than I'd like them to be :-)

In short - it seems like the git users would need to always run the latest version of git in order for the thing to be usable.

Now, the cool thing is that of course, as usual, in the usual "let the million worlds bloom" motto, there's already a mercurial repository :-)

My conclusion for the git repo on opensim so far is: go for the latest git and install it from source (errgh. this is not too cool, but is there any other choice ?)

Opinions ?

The wonders of search...

I find it amusing to look on the analytics how the folks arrive to this blog.

Some of them arrive due to a mischievous title - while seeking for information on color blindness - I should at least do some research on that topic to a bit rehabilitate myself on that.

A lot of folks arrive to look for git and opensim - which is understandable. Apparently the celebrity lookalikes for some terribly stupid reason generates some traffic.

But the most amusing thing I've found was the search query "who got shot in history". I felt terribly puzzled when I saw this, but appears I am a first (!) hit with my photoshoot post from a while ago.

Go figure. I assume the smartness of the search engine has figured that when someone is asking "who [verb-phrase]", the terms "I [verb-phrase]" are the good candidate answers.

I wonder how far are we from the concept-based search. Last time I read on this topic, the opinion from google folks their only love and religion is the statistics. So I'd think that they don't have much feeling towards all this toying with opencycs and link grammars. (Ok, I have to say it was more within the context of some announcement of the newfangled search engine that was promising to change the world - and as it appeared later - i think was just burning the VC capital - so maybe they *do* believe in link grammar parsing in the end - especially given that there're some works about the statistical parsers based on the link grammars - I won't spoil the fun of finding and reading those for you - they're near one of the links above.

Even yet better than free: paid! :-)

Ok, this one I have to link to - as even with the diagonal reading this is an excellent post. Prok's reply to the "better than free", which I bookmarked a few days ago.

Minus the classic Prok's rant that "all you morons tekkies imagine the information *has* to be copied" (which is a misunderstanding of at least my point of view anyway, so I do not hold any anger) - it is an excellent read.

Especially the great notion is the truck driver. While in the hypothetical matrix, the job is done by the machines who keep the meat they need to function (or for whatever the reason they kept the people in the half-asleep state - maybe as randomness generators?), the real-world is much simpler and much more complex.

Thanks for this post. When the credit is due - it's due. I'll need to reread both later when I have more time to think without interruptions.

30 pieces of silver...

I've been reading up so much on the SL content piracy in the blogs, that it is not much fun anymore.

Some of the folks it's an easy problem that should "just be fixed", and it is not fixed yet merely because of the stupidity and ignorance of the punk libertarian tekkies.

Some of the folks realise it's a damn hard thing, entangled with psychology, economy, philosophy, one's notion of integrity, and somewhat a little bit technical (I applaud Ordinal for the well balanced analysis of the situation - but call up for the benevolent dictator to appear out of the box and fix everything.

Personally, I believe in the openness.
However, one thing I question is if we'd take a random sample of 1000 avatars from the crowd - how many of them would knowingly go and save 30 silver pieces in exchange of their integrity ?

I've mentioned the experiment the other day - but today I thought - there's already quite a few places live, where this kind of experiment might take places - it's just a matter of exposing them.

For this purpose I've created a new blog Second Thefts: the alleged thefts in SL revealed and openly discussed.

The rest is written there, and I will be looking forward for any posts there, and we will see how the experiment turns out.

Better than free

A very interesting article about the money making in the case of freely copyable content.

A very interesting article - I suspect the conclusions from that are not only valid for the digital world - if you look around you, the RL is increasingly more and more about "Freebies", so the similar principles could apply.

Found it via Virtually Blind.

Let the thousand worlds bloom: the response to Gwyn's article about IBM, datacentre, and OpenSim.

Gwyn's mention of IBM putting the datacentre in OpenSim is by far more colourful than my dry hyperlink. And I'd figure it might be fun to write up a followup post. Disclaimer: all of the below is my personal views, and does not necessarily reflect any of the official positions of the "OpenSim".

First and foremost, it is a bit wrong to compare the OpenSim with Linux - the former is BSD licensed, the latter is GPL licensed. GPL does impose some "policy/political" views which BSD does not.

BSD licensing terms is a deliberate permission of the results to be used for any purpose, including commercial, by anyone.
If they do not feel like contributing back the results - so be it - but yet, with metaverse, I suppose it's in everyone's interest to have as much compatibility as possible, and the current events seem to prove this.

So, yes, you can take the code, put all the features you need, run your own stuff, and noone will feel unhappy (as soon as you do not refer to your code as "The OpenSim" - that irresponsible action would be indeed frowned upon).

The comment about the apache is not totally correct - there's a plethora of web servers designed for various purposes, in particular, the lighttpd is another very popular server, and there are tons of others. And I would not be surprised to see more than one server of the SL flavour emerging in the future.

I am not sure whether the central grid is "The" interconnection point - as there is still an issue of trust in the distributed environment, and at a certain point in time they will hit the wall, hard and solid, in case they do not pay the attention to this.

OpenSim is an extremely interesting beast with respect to its dynamics - everyone in the team is there for their own reasons, yet the end result that there is something evolving - which is quite an amazing thing to me, and I think this is not in the last order attributable to the BSD licensing which we very much want to preserve - primarily because it gives everyone so much freedom.

As for the comments by Jo, etc, let's go over them, they are amusing :)

"Open Sim's technical direction is to remove "stupid" limitations and in crease the power of the scripting language. This so increases the ability to grief within a world that essentially for any sort of stable environment user created content would have to be locked down solid."

This is soooo limited of a view that I am afraid to comment about this. The issues with the content, like I wrote just a short while ago are not technical, they are within the heads of the population who is always hungry for el cheapo content regardless of its origin. While there's a demand for the stolen content, there will be always a supply. And tackling this is a very hard problem - so given that for the time being we have mostly "good" users, this did not seem to be the biggest problem - there're a lot of far more low-level things that need to be addressed. So, first things first. Besides, "locked down solid" is a bit of an outdated concept. The information that is intended for the public viewing (which is what happens with all the content - since it essentially gets sent to all the viewers observing it) is hard to be made "locked down".

And yes - given the nature of the opensim, the flexibility and modularity is one of the key items. Right now, there are engines for LSL, C#, VB, JavaScript scripting engines. Of course, everything is a bit raw, but it's there. Go pick your favourite and hack on it. Besides this, some of the uses of OpenSim do not imply it being used as the worldwide open metaverse platform - hence the extra flexibility.


"LSL compatibility and asset sharing are not priorities for Open Sim. Even client compatibility is up for grabs. Therefore those will not be easily be leveraged."

LSL functions are being implemented by those folks who are interested to see it. While it's true that OpenSim is not intended as a clone for SL, noone prohibits anyone from having it done. Up for some coding, Jo ? :)
True that the client compatibility is mostly for pragmatic reasons - there is no reason to stick to that forever, as well as no reason to reinvent the wheel too much at this stage,and again, the compatibility is something useful to have.

"At some point, probably soon, it will very soon no longer be "too early" to license LL's server code. Then you have the choice between hiring programmers to patch OpenSim or programmers to actually create content for you in stable, enterprise proven, code."

Hiring the programmers to create the content is one of the worst decisions a hiring manager can make, really :-)

Sports car and me...

Found this on Looker's blog and figured I'd check it just for fun.

So, the end result is:

I'm a Ferrari 360 Modena!

"You've got it all. Power, passion, precision, and style. You're sensuous, exotic, and temperamental. Sure, you're expensive and high-maintenance, but you're worth it."

Dang, what can be better than a good ego boosting exercise ? I figure another 7 million participants think the same :-)

"Take the Which Sports Car Are You? quiz.

Content IP rights, again...

It's been a while since we last chatted with the folks about the content rigts and associated issues.. Yet, reading Vint's post, I figured I'd react.

Despite of what some people say, the content protection is much less of a technical problem rather than the problem of changing a mentality. Second Life, face it, is all about the economics. And while there is demand, there will always be a suppply.

Now, I'd be terribly interested if any of the content creators would be interested to run an experiment - to offer the "genuine skin" at L$1000, and then somewhere else offer the "stolen skin" at L$100, with the explicit mention that this skin has been stolen and the mention of the place where to buy the genuine skin (and of course to have the genuine skin place have a link to the "stolen skin" place). It might be a very enlightening experiment. I, from my side, can sacrifice a little bit of my reputation and offer the place to distribute the "stolen skin" (I think I still have some place to put the prims on), if anyone comes up with an offer for the content. Obviously, the cash (1/10th of the original price) from the event would be to the author, and the results should be jointly published.

Anyone up for a challenge ? That might be an interesting experience.

I'm tagging this as well as "primskirtbuilder" in case any of the creators using it feel like giving this experiment a shot.

Even though I'm pretty confident that the "pirate" version will certainly outweigh the "genuine" one - there's still a potential economic benefit for the creator due to a possibly bigger volume.

If there're no takers - then let's leave this just as a mental experiment for the readers - think of the above situation, and what choice would you have made, and drop something in the comments - it's interesting to know your opinion :-)