Kategorie: Programming

Second Life und die höhere Mathematik

Second Life selber ist schön bunt anzusehen, ein netter Zeitvertreib und macht vielen einfach Spaß. Wer sich in Second Life begibt und dort bewegt, der hat sicherlich alles andere am Hut, als sich mit Mathematik zu beschäftigen, und doch ist höhere Mathematik in Second Life allgegenwärtig, man muss nur einmal genauer hinschauen, um es zu begreifen. Mehr noch: ohne Mathematik wäre eine Welt wie Second Life gar nicht möglich!

Geometrie allüberall
Das beginnt schon mit den Prims: diese sind nichts anderes als einfache, geometrische Formen. Damit man sich in Second Life bewegen kann, wird jedem Punkt in einer Sim eine eindeutige Koordinate zugeteilt, das ist nichts anderes als ein dreidimensionales, kartesisches Koordinatensystem.

Nun bewegt man sich aber auch in Second Life oder gewisse Objekte bewegen sich, und damit kommt schon höhere Mathematik ins Spiel, denn um genau solche Effekte zu beschreiben, benötigt man Vektoren. Vektoren selber sind Bestandteil der sog. linearen Algebra, und mit diesen kann allerhand angestellt werden.

Wer also irgendwann mal mit Rotationen arbeitet oder Objekte skriptgesteuert irgendwelche Bewegungen vollführen lassen will, der kommt nicht wirklich darum herum. Gleiches gilt für das Partikelsystem und vieles, vieles mehr…

Das Geburtstagsparadoxon
Eine weitere Sache, die in Second Life täglich Anwendung findet, ist die Wahrscheinlichkeitsrechnung. Genauer gesagt geht es dabei um das sog. Geburtstagsparadoxon, welches ein altbekanntes und gut diskutiertes Problem der Mathematik darstellt.

Angenommen, in einem Raum befinden sich 23 Personen. Wie hoch ist dann die Wahrscheinlichkeit, dass mindestens zwei von ihnen ohne Berücksichtigung des Jahrgangs am selben Tag Geburtstag haben?

Die Antwort selber ist überraschend: die Wahrscheinlichkeit liegt höher als 50%, bei 36 Personen ist sie sogar bei 83%. (Eine genauere, mathematische Erklärung befindet sich hier in diesem PDF).

Nun möchte man aber fragen: was bitte hat das Geburtstagsparadoxon denn mit Second Life zu tun? Sehr viel, sogar sehr sehr viel, man nutzt es ständig, und die Form der Anwendung ist zum Beispiel solch eine Zahl: 5fe9759e-03e2-4268-8af0-ed165a158df1.

Das ist nichts anderes als die altbekannte UUID (128 bit breit), also der fundamentale Bestandteil aller Assets. Die Sache bei der UUID ist diese, dass diese rein zufällig innerhalb eines gewissen Namensraumes vergeben wird und man mit Hilfe des Geburtstagsparadoxon abschätzen kann, wie hoch denn die Wahrscheinlichkeit einer Kollision (die Vergabe derselben UUID zweimal also) innerhalb dieses Namensraums ist.

Diese ist trotz der stetigen Vergabe von UUIDs so gering, dass sich das System noch auf lange Zeit halten wird.

Nirans Viewer – nicht tot!

Ist Nirans Viewer tot? Zumindest gerüchtet das gerade der selbsternannte „Secondlife Technologist“ JayR Cela.

Nach seinen Worten habe Nirans Viewer ins Gras gebissen, da Nirans Rechner einen Festplattenschaden erlitten habe und – wie leider so oft üblich – es kein Backup gäbe. Es sei kein großer Verlust, da ohnehin niemand den Trumm hätte laufen lassen können.

A-ha. Was daran wohl nun wahr ist? Keine Ahnung. In Nirans Blog steht nichts, in Sluniverse auch nichts weiter, im offiziellen Forum zum Viewer ist nichts zu finden und der Sourcecode ist nach wie vor auf Sourceforge.net verfügbar. Wenn, dann fehlen bestenfalls einige Tage an Neuerungen, das dürfte es gewesen sein und den Rest kann man sich wieder flott unter Windoof zusammenbasteln.

Dazu kommt – und das ist noch wichtiger – dass die letzten Commits am Code von Niran selber auf der Projektseite bei Bitbucket gerade mal 21 Stunden zurück liegen. 21 Stunden! Ein totes Projekt sieht für mich nun wirklich anders aus, ich halte die Meldung daher für substanzlosen Müll und Panikmache. Mehr dürfte da auch nicht dran sein!

Update: so, ich bin nun auf Sluniverse.com doch noch fündig geworden. Zuerst einmal kann man hier nachlesen, das NiranV tatsächlich folgendes schrieb und zwar bereits vor sechs Tagen:

HD suddenly crashed , first whole Windows began to freeze , then after restart HD was gone…nice 2 TB of Data gone , with it my compiling Windows , all my Snapshots , Videos , programs , sourcecode and everything else… i hate self destruction HD…. will probably take many days to get my Windows back up to the point at which it is able to compile…

Sprich: es gab einen Festplattenschaden und alles war weg. So. Aber das ist ja kein Problem, wenn man seinen Sourcecode wie NiranV es tat auch bei Sourceforge.net hostet, und so gab es dann schon nach einigen Stunden folgende Statusmeldung:

good news , everything went ok… downloaded my source and compiled instantly without any error

Was nichts anderes heißt als dass es weitergeht, und man kann auch schon die nächsten, kommenden Fixes dann im Thread lesen. Hätte JayR Cela da ein wenig weiter gelesen, dann wäre es zu seiner komischen Meldung da erst gar nicht gekommen.

Ich verabschiede mich von hier mit einem aktuellen Video von NiranV, das die neuen Voreinstellungen für die Kamera zeigt, bitte sehr:

HJXxXYkPBA4

Movable Type oder: der Verlierer der Blogengine-Wars

Alle Welt nutzt ja heutzutage mehr oder minder WordPress als Blogengine, es ist der 800-Pfund-Gorilla der Szene und nicht mehr wegzudenken. Was nicht allzu viele wissen ist aber, dass das am Anfang der Entstehung von WordPress sehr wohl anders gewesen ist. WordPress war am Anfang seiner Entstehung der Underdog, der daherkam dem damaligen Platzhirschen Movable Type der Firma Six Apart Ldt. sein Revier streitig zu machen – und letzten Endes gewann.

Früher war alles besser… oder?
Movable Type war früher das, was WordPress heute ist – der Marktführer im Bereich der Blogengines.  Das war im Jahr 2004 gewesen. Movable Type ist bis heute in Perl geschrieben, und war einen ganzen Tacken statischer als WordPress. Man darf sich das so vorstellen: Movable Type ist eine Ansammlung von Skripten, die wenn ein neuer Post geschrieben wird, einen Haufen von statischen Seiten neu erstellt und auf dem Webserver anlegt. Solange nichts neues dazu kommt, werden nur die Seiten statisch geliefert, wenn jemand Kommentare schreibt, werden sie neu geschrieben. Das funktionierte anfangs ganz gut, bis es denn die ersten Blogs mit einigen Tausenden Postings und zigtausenden Kommentaren gab, da wurde die damalige Version von Movable Type dann mitunter sehr, sehr langsam. Inzwischen ist das aber kein Thema mehr.

Gleichwohl ist es eben so: wenn es dem Esel zu gut geht, dann geht er aufs Glatteis. Movable Type war früher in der Nutzung kostenlos, aber mit der Einführung der Version 3.0 dann wurde es auf einmal je nach Nutzungsart kostenpflichtig. Das führte dazu, dass eine Menge Benutzer sich auf einmal nach einer Alternative umschauten, weil sie die Kosten nicht zahlen konnten oder wollten für ein Hobby, mit dem sie kein Geld verdienen. Andere wiederum waren der Meinung, was gut ist dürfe ruhig etwas kosten – und blieben.

Enter: Cafelog!
Es war schon damals so gewesen, dass es im Bereich der Blogs eine aktive Programmiererszene gab, und ein recht erfolgversprechendes Skript namens Cafelog. Das kennt heutzutage keiner mehr, weil es nicht mehr weiter entwickelt wird, aber bildete die Grundlage für die Entwicklung von WordPress. Anders ausgedrückt: WordPress ist ursprünglich ein Fork von Cafelog. Eine weitere Entwicklung ist B2evolution.

Die Version WordPress 1.0 erschien dann am 3. Januar 2004, enthielt unter anderem einen Importer für Movable Type Blogs und war für alle Nutzungsarten kostenlos. Bis heute ist das so geblieben. Recht bald kam die Unterstützung für Plugins und statische Seiten dazu, so dass sehr viele ihre Blogs dann von Movable Type auf WordPress umzustellen begannen und Movable Type massiv an Marktanteilen verlor.

Es kam dabei dann so, wie es kommen musste: Six Apart hatte seine Community nicht richtig eingeschätzt, sie machten zwar auch weiterhin Umsätze und Gewinn, aber WordPress zog an ihnen sehr schnell weit und groß vorbei. Im Jahr 2007 entschied man dann, dass man nicht mehr auf die bisherige Weise mit WordPress konkurrieren könne, und Movable Type wurde zu Opensource. Das ist es bis heute geblieben, 2011 wurde die Firma an eine japanische Unternehmung verkauft.

Wie es sich übrigens gehört, betreibt auch Six Apart einen professionellen Bloggingdienst. Wer also die Mühen einer Installation von Movable Type nicht selber auf sich nehmen will, der wird bei Typepad fündig. Dabei ist es hier auch wie sonst überall, dass die Basisfunktionen kostenlos sind, wer mehr will der zahlt entsprechend.

Der bekannteste bei Typepad gehostete Blog zu Second Life ist „Second Thoughts“ von Prokofy Neva.

Fazit
Movable Type ist eine ausgereifte Blogengine, die durchaus ihre eigene Stärken und Schwächen hat. Heutzutage spielt sie kaum noch eine wirkliche Rolle, da WordPress einfach zu dominierend ist, aber wer eine Blogengine will, die vor allem von Haus aus schon statische Seiten generiert, ist mit ihr nach wie vor sehr gut bedient.

Vollkorn

Weil mir ein wenig langweilig gewesen ist und ich mal schauen wollte, was man noch so alles aus WordPress heraus holen kann, habe ich mit dem Blogdesign heute massiv gespielt. Das Ergebnis ist kurz und gut, dass das Basistemplate weiterhin „Weaver II Basic“ ist, allerdings mit anderen Grundeinstellungen, ich mag einfach Weiß als Hintergrund für Schrift nun einmal lieber als irgendwelche komischen Grautöne.

Auch wurde die Avatargrösse in den Kommentaren verdoppelt und als grundlegende Schrift für den Fließtext habe ich hier nun Vollkorn von Friedrich Althausen in Verwendung, ganz einfach weil mir diese Schriftart im Moment sehr gut gefällt. Es gibt ja schon lange die Möglichkeit, sein Design mittels Webfonts aufzupeppen und bei Google eine nette Auswahl ans kostenlos verfügbaren Schriftarten, also wieso sollte man diese nicht mal nutzen?

Google Web Fonts nennt sich das Verzeichnis, wo man zwischen 501 Schriftarten bisher auswählen kann, und das werden sicherlich noch mehr werden. Man kann diese bequem per Javascript oder CSS in sein Template einbinden – fertig.

Slurp

Ivy Sunkiller entwickelt seit einiger Zeit eine python-ähnliche Skriptsprache namens slurp, deren Ziel es ist, die Programmierung mit LSL zu vereinfachen. Slurp dabei selber ist in Second Life nicht lauffähig, sondern wird durch einen Übersetzer nach LSL konvertiert. Die Idee dahinter ist dabei dieselbe wie Coffeescript, welches nach Javascript umgewandelt wird: man kapselt Teile der Syntax von LSL sowie der Komplexität vom Benutzer ab, dadurch soll das reine Programmieren einfacher und schneller von der Hand gehen. So fehlen in Slurp zum Beispiel die Strichpunke am Ende jeder Zeile und die geschwungenen Klammern völlig, die in LSL ja überall Standard sind, und auch will Ivy einige fortgeschrittene Datentypen bereitstellen, die LSL von Haus aus nicht bietet – was nichts anderes bedeute, als dass sie diese in LSL selber programmieren werden muss.

Eine Demoimplementierung des Projektes ist hier zu finden, da sieht man auch den bisherigen Stand recht gut. Eigentlich wollte er schon längst eine lauffähige Beta veröffentlicht haben, warten wir einmal ab, wann diese kommen wird.

Die Hintergründe zu dem Projekt sind dabei im Post „Fixing LSL – one step at a time!“ zu finden. Alles in allem bin ich auf die Beta gespannt, wenn diese denn mal verfügbar ist.