tag:blogger.com,1999:blog-71151172880123444062024-02-20T13:45:21.384+01:00Daltonic GinAn attempt of an avatar from a virtual world at experimentally proving the infinite monkey theorem...Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.comBlogger293125tag:blogger.com,1999:blog-7115117288012344406.post-34004859953164659642008-12-28T21:48:00.004+01:002008-12-28T22:00:07.661+01:00Happy new year... and good bye.<a href="http://www.flickr.com/photos/8326674@N05/3145147920/" title="party by dalientalbot, on Flickr"><img src="http://farm4.static.flickr.com/3134/3145147920_926b44751c_m.jpg" alt="party" height="180" width="240" /></a><br /><br />I've long wanted to capture this - the social interactions between the cans of drink :-)<br /><br />I like the result.<br /><br />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.<br /><br />If you feel like some of the sketches that I make are fun - you're welcome to hang around at <a href="http://bnpcs.blogspot.com/">http://bnpcs.blogspot.com/</a>, which is devoted to adventures of the same avatar in a much more entertaining game of the First Life.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com1tag:blogger.com,1999:blog-7115117288012344406.post-85350446147428067712008-12-04T03:23:00.001+01:002008-12-04T03:25:07.120+01:00A wonderful article on concurrent programmingMostly as a bookmark for myself:<br /><br />http://portal.acm.org/citation.cfm?doid2=1454456.1454462Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-91015561667672435202008-12-01T02:12:00.003+01:002008-12-01T02:23:20.333+01:00My new blog about u-Simulator...For those of you who might have seen some strange posts with the tag "cosimus"...<br /><br />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/Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com2tag:blogger.com,1999:blog-7115117288012344406.post-39970909294538049812008-10-09T22:37:00.001+02:002008-10-09T22:39:06.152+02:00I still believe...While poking around with the matrix, stumbled across this piece. Wonderful.<br /><br /><a href="http://www.elmindreda.org/istillbelieve.html">Enjoy.</a>Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-79342072987262957862008-08-06T04:48:00.003+02:002008-08-06T05:10:28.441+02:00SL-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.<br /><br />One of these evenings I did not feel like doing anything productive, so I decided to hack up a prototype packetserver in ruby.<br /><br />So, the below set of files allows me to "login" (in quotes because the login info is not really checked :) with the viewer.<br /><br /><pre><br /><br /> $ ls -al<br />total 228<br />drwxr-xr-x 2 dalien dalien 4096 Aug 6 04:46 .<br />drwxr-xr-x 12 dalien dalien 4096 Jul 31 22:23 ..<br />-rw-r--r-- 1 dalien dalien 183208 Jul 28 17:44 1.18.3.5.txt<br />-rwxr-xr-x 1 dalien dalien 8629 Jul 28 17:36 login_server.rb<br />-rwxr-xr-x 1 dalien dalien 14901 Jul 29 04:27 parse_template.rb<br />-rw-r--r-- 1 dalien dalien 3710 Jul 31 22:27 pkt_server.rb<br />-rw-r--r-- 1 dalien dalien 1719 Jul 28 21:59 str_hex.rb<br /> $ <br /></pre><br /><br /><br />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:<br /><pre><br />t = SLPacketTemplateFile.new("1.18.3.5.txt");<br />t.pt.each { |x| SLMessage.register_message(x, eval(x.to_ruby)) }<br /></pre><br /><br />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:<br /><br /><pre><br /> def message(msg)<br /> send_packet_ack(@client_ip, @client_port, msg.sequence)<br /> handler = (msg.class.to_s + "_handler")<br /> if self.respond_to? handler<br /> send(handler, msg)<br /> else<br /> pp msg<br /> end<br /> end<br /></pre><br /><br />And, as soon as I define a "_handler" method within that class, it gets automagically hooked up! Cool, huh ?<br />For example, something like this:<br /><br /><pre><br /> def MoneyBalanceRequest_handler(msg)<br /> pkt = MoneyBalanceReply.new<br /> md = pkt.MoneyData[0]<br /> md.AgentID = msg.AgentData[0].AgentID<br /> md.TransactionID = msg.MoneyData[0].TransactionID<br /> md.TransactionSuccess = 1;<br /> md.Description = "Test\00"<br /> md.MoneyBalance = 1234;<br /><br /> send_to_client(pkt)<br /> end<br /></pre><br /><br />where "send_to_client" is again dead simple:<br /><br /><pre><br /> def send_to_client(pkt)<br /> @sock.send(pkt.to_bytes, 0, @client_ip, @client_port)<br /> end<br /></pre><br /><br />Oh, and you'll probably be amused with this totally stupid-looking message loop:<br /><br /><pre><br /><br /> def run<br /> print "Started server...\n"<br /> loop {<br /> data, from = @sock.recvfrom(8192)<br /> port = from[1]<br /> host = from[2]<br /> rdr = SLDataReader.new(data)<br /> msg = SLMessage.from_bytes(rdr)<br /> if msg.class == UseCircuitCode<br /> print "New client connection!\n"<br /> @clients[host.to_s + ":" + port.to_s] = ClientHandler.new(self, msg, host, port)<br /> else<br /> clt = @clients[host.to_s + ":" + port.to_s]<br /> if clt<br /> clt.message(msg)<br /> else<br /> print "Unknown client:\n";<br /> pp msg<br /> end<br /> end<br /> }<br /> end<br /><br /></pre><br /><br />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.<br /><br />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.<br /><br />There is one downside however, the debugging of the autogenerated code is a pain. I need to so how to do it better.<br /><br />Oh yes, and get rid of the braces in the loop {} construct, they do look ugly and out of place.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com2tag:blogger.com,1999:blog-7115117288012344406.post-77029369926251988582008-08-06T04:42:00.004+02:002008-08-06T04:45:18.903+02:00Dalien 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.<br /><br />The copies should be around, and if you apply a certain effort, you might find a free copy.<br /><br />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.<br /><br />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.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com6tag:blogger.com,1999:blog-7115117288012344406.post-89801920253281664532008-08-03T22:59:00.001+02:002008-08-03T23:00:38.301+02:00Videos in HDVideos in HD - and quite a lot of interesting ones. Probably good thing that HD has not hit the masses too much yet...<br /><br />Enjoy.<br /><br /><object width="400" height="292"> <param name="allowfullscreen" value="true"> <param name="allowscriptaccess" value="always"> <param name="movie" value="http://www.vimeo.com/moogaloop.swf?clip_id=866495&server=www.vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1"> <embed src="http://www.vimeo.com/moogaloop.swf?clip_id=866495&server=www.vimeo.com&show_title=1&show_byline=1&show_portrait=0&color=&fullscreen=1" type="application/x-shockwave-flash" allowfullscreen="true" allowscriptaccess="always" width="400" height="292"></embed></object><br /><a href="http://www.vimeo.com/866495?pg=embed&sec=866495">The glove</a> from <a href="http://www.vimeo.com/user384884?pg=embed&sec=866495">Bewegtbildarbeiter</a> on <a href="http://vimeo.com?pg=embed&sec=866495">Vimeo</a>.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-79851531794052542292008-07-21T00:07:00.003+02:002008-07-21T00:21:15.587+02:00Installing debian on eeepc instead of XandrosIt'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 :-)<br /><br />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.<br /><br />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.<br /><br />There was not much to an install - just follow the instructions <a href="http://wiki.debian.org/DebianEeePC/HowTo/Install">here</a> and I got a working system.<br /><br />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).<br /><br />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.<br /><br />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).<br /><br />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).Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-45312571540784990042008-05-21T03:23:00.000+02:002008-05-21T03:24:06.385+02:00GPU fun..<object width="425" height="355"><param name="movie" value="http://www.youtube.com/v/DPnQmdubYj0&hl=en"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/DPnQmdubYj0&hl=en" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object><br /><br />Quite impressive. Imagine the possibilities.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com1tag:blogger.com,1999:blog-7115117288012344406.post-63102801705048246362008-05-16T01:53:00.003+02:002008-05-16T02:49:51.719+02:007 habits of highly effective menI'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.<br /><br />So, about being a decent man... <a href="http://tiessam.blogspot.com/2008/05/7-skills-every-man-should-master.html">Tiessa writes about her opinion of 7 habits a man should have</a> - and i figured i'd take a note for myself as well as write some things on the side.<br /><br />7) Pick up the dirty socks off the bedroom floor.<br /><br />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. <br /><br />6) Put the cap back on the toothpaste tube.<br /><br />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.<br /><br />5) Clean the sink after shaving.<br /><br />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.<br /><br />4) Know how to use a mop.<br /><br /><a href="http://www.google.be/search?q=define:mop&hl=nl&oi=definel&defl=en">which one...</a>. note: educate myself on that part about the dice retrieval. looks pretty unuseful, but hey, who knows - maybe one day it saves the life...<br /><br />3) Carry shopping bags for more than 20 minutes without whining.<br /><br />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.<br /><br />2) Ask for directions before we are late for the event.<br /><br />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.<br />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.<br /><br />1) <a href="http://www.cunnilingustutor.com/">Cunnilingus</a><br /><br />the jury does not have any objections on this item and nods emphatically.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com4tag:blogger.com,1999:blog-7115117288012344406.post-76784551437070191212008-05-13T23:57:00.003+02:002008-05-14T00:06:54.943+02:00A 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.<br /><br />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.<br /><br />This behaviour indeed not anything of an invention, but feels quite funny to experience it consciously.<br /><br />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" ?Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-54151767155992960962008-05-13T01:55:00.002+02:002008-05-13T02:15:35.814+02:00Impressive 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 :)<br /><br /><object height="355" width="425"><param name="movie" value="http://www.youtube.com/v/Jd3-eiid-Uw"><param name="wmode" value="transparent"><embed src="http://www.youtube.com/v/Jd3-eiid-Uw" type="application/x-shockwave-flash" wmode="transparent" height="355" width="425"></embed><object width="425" height="355"><param name="movie" value="http://www.youtube.com/v/KyvIlKSA0BA&hl=en"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/KyvIlKSA0BA&hl=en" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object></object>Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-92160481185285519452008-05-12T18:50:00.002+02:002008-05-12T19:01:01.134+02:00The future of the internet and how to stop it<object height="355" width="425"><param name="movie" value="http://www.youtube.com/v/jAEMjD4J55E&hl=en"><param name="wmode" value="transparent"><embed src="http://www.youtube.com/v/jAEMjD4J55E&hl=en" type="application/x-shockwave-flash" wmode="transparent" height="355" width="425"></embed></object><br /><br />looks like a book worth reading.<br /><br />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.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-6851213842322992562008-05-12T15:53:00.002+02:002008-05-12T15:56:58.577+02:00Web3.0<a href="http://gpl.internetconnection.net/vi/">this is so web3.0!</a><br /><br />p.s. don't try :%d, afterwards it does not work very well.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-60984344429712670972008-05-12T15:47:00.001+02:002008-05-12T15:48:48.581+02:00The most clicked global warming story of the month<a href="http://news.bbc.co.uk/2/hi/science/nature/7390109.stm">Great tits cope well with warming</a><br /><br />sweet :-)Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-56266120780832859822008-05-04T02:49:00.003+02:002008-05-04T02:53:11.702+02:00character vs. token based parser in Parsec with haskellOk, the first parser did look *ugly*, so I wrote a bit less ugly one, using the token parser. It's not much shorter,<br />but runs two times faster!<br /><br /><pre><br />$ time ./packet_template_token >/dev/null<br /><br />real 0m0.138s<br />user 0m0.130s<br />sys 0m0.006s<br />$ time ./packet_template_char >/dev/null<br /><br />real 0m0.395s<br />user 0m0.388s<br />sys 0m0.005s<br />$<br /><br /></pre><br /><br />In case you are interested, both are <a href="http://opensim.be/dalien/haskell/">here</a>Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-6263340023116159742008-05-03T20:03:00.002+02:002008-05-03T20:07:09.591+02:00Packet template parser in HaskellAs part of the dive into Haskell, I've tried out <a href="http://www.haskell.org/haskellwiki/Parsec">Parsec</a>, which allows a pretty intuitive construction of parsers.<br /><br />The result is a parser that can consume the packet template file. It does not do anything smart with it beyond some printing.<br /><br />You can take a look at the two <a href="http://opensim.be/dalien/haskell/">here</a>.<br /><br />The code leaves a lot to be desired - as I've used the lowest-level character parser.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com1tag:blogger.com,1999:blog-7115117288012344406.post-38331337323369392102008-05-01T21:35:00.003+02:002008-05-01T21:37:44.463+02:00Geek humor in haskellLately I'm periodically flirting with Haskell - and today I've found an incredibly <a href="http://www.willamette.edu/~fruehr/haskell/evolution.html">funny page</a>, which at the same time offers an ample educational content.<br /><br />Enjoy.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-88278250924787699172008-04-29T22:43:00.003+02:002008-04-29T23:33:57.506+02:00Flying wooden cubes and the tree eclipse<a href="http://www.flickr.com/photos/8326674@N05/2453007272/" title="Flying cubes and the sun eclipse by a tree by dalientalbot, on Flickr"><img src="http://farm3.static.flickr.com/2036/2453007272_5b80718536_m.jpg" width="240" height="188" alt="Flying cubes and the sun eclipse by a tree" /></a><br /><br />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.<br /><br />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.<br /><br />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.<br /><br />This results in the corresponding slist entries being deleted and reinserted at the tail of the update slist.<br /><br />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.<br /><br />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.<br /><br />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...Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-60456117179675315812008-04-29T03:22:00.006+02:002008-04-29T03:39:35.257+02:00New 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 <a href="http://eeepc.asus.com/global/guide.htm">Eeepc</a>. 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.<br /><br />Now, here's the coolest part - <b>it comes with Xandros linux preinstalled</b>. 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)<br /><br />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.<br /><br />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.<br /><br />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.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-63028727061858260472008-04-14T04:14:00.002+02:002008-04-14T04:19:36.660+02:00Objects, updates, and iteratorsToday was the day of object updates. That is, writing the object updates.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />But there's one small detail - for this to work, the iterator implementation needs to be flawless. Which apparently is totally not the case :-)<br /><br />Looks like I need to sit and write what happens in each specific scenario - otherwise it is a very good recipe to spaghetti code.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-22971200827890112432008-04-13T19:35:00.004+02:002008-04-13T20:14:06.204+02:00What 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...<br /><br />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...<br /><br />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.<br /><br />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.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com3tag:blogger.com,1999:blog-7115117288012344406.post-44073643277094092072008-04-13T02:20:00.006+02:002008-04-13T20:35:44.974+02:00user database, activerecord, and extension to HTTPToday 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.<br /><br />As a result, I now have the module, that implements PKI in a way that allows to operate it without the major headache:<br /><br /><pre><br />uca = UCA::UCA.new([ ["CN", "Test CA" ] ],<br /> "Test CA", Proc.new { |flag| "test" })<br /><br />u = User.new<br />u.firstname = "Dalien"<br />u.lastname = "Talbot"<br />cn = [ ["CN", u.firstname + "_" +<br /> u.lastname + "@" + 'localhost' ] ]<br />rsa, csr = UCA::Utils::generate_csr(1024, cn)<br />cert = uca.sign_csr(csr)<br />u.rsa_cert = cert.to_pem<br />u.rsa_key = rsa.export(<br /> OpenSSL::Cipher::DES.new(:EDE3, :CBC), "test" )<br />u.save!<br /><br /></pre><br /><br />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.<br /><br />Now, in the <a href="http://daltonic.blogspot.com/2008/04/thoughts-on-presence-chat-and-groups.html">previous post about groups, presence, etc.</a> 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.<br /><br />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.<br />There's an <a href="http://www.web-cache.com/Writings/Internet-Drafts/draft-luotonen-web-proxy-tunneling-01.txt">old draft</a> 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).<br /><br />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).<br /><br />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.<br /><br />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.<br /><br />Also, the Ruby code got an <a href="http://blog.labnotes.org/2005/10/18/ruby-uuid-generator/">excellent UUID library</a>, so now both the C and Ruby can generate the mac-based UUIDs.<br /><br />Update:<br /><br />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.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-49577519296179243092008-04-12T01:25:00.003+02:002008-04-12T01:38:19.500+02:00New toysand the effects<a href="http://www.your2ndplace.com/node/1085">Ciaran</a> writes about the new toy in progress.<br /><br />I'll copy in the embedded Youtube video here, because it's pretty cool:<br /><br /><object width="425" height="355"><param name="movie" value="http://www.youtube.com/v/2t52gkAwJq8&hl=en"></param><param name="wmode" value="transparent"></param><embed src="http://www.youtube.com/v/2t52gkAwJq8&hl=en" type="application/x-shockwave-flash" wmode="transparent" width="425" height="355"></embed></object><br /><br />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 ?Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com0tag:blogger.com,1999:blog-7115117288012344406.post-72343373315604509472008-04-08T01:16:00.005+02:002008-04-08T01:52:52.378+02:00Thoughts 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.<br /><br />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".<br /><br />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.<br /><br />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<br />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.<br /><br />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.<br /><br />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.<br /><br />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.<br /><br />And again - the protection from the ill-behaved servers reduces to countering a DoS from an untrustworthy source.<br /><br />I'm pretty sure this is all doable with a little bit of PKI+shared secret+SSL woodoo.<br /><br />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.<br /><br />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.<br /><br />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.Dalienhttp://www.blogger.com/profile/16460776649089139090noreply@blogger.com4