Second Life und die höhere Mathematik

Bartholomew Gallacher 21. April 2012 2 Kommentare

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!

Bartholomew Gallacher 21. April 2012 12 Kommentare

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

Bartholomew Gallacher 20. April 2012 0 Kommentare

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

Bartholomew Gallacher 14. April 2012 5 Kommentare

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

Bartholomew Gallacher 7. April 2012 0 Kommentare

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.

The power of Linux

Bartholomew Gallacher 5. April 2012 0 Kommentare

Heute mal etwas völlig anderes: man kennt das ja, da hat man eine externe Festplatte, die man unbedingt frei haben muss, um sie mit neuem Zeug zu füllen und muss sie mindestens für ein, zwei Tage auf dem eigenen Rechner speichern können. Auf der externen Festplatte sind vielleicht 300 GB an Daten und auf dem eigenen Rechner sind noch 350 GB an Plattenplatz frei. Dumm nur, dass sich diese 350 GB auf drei Festplatten verteilen und auf der ersten 200 GB frei sind, auf der zweiten 100 und der dritten ebenfalls.

Was also tun? Man könnte versuchen, den Inhalt von einer Platte auf die andere interne zu kopieren, um so zumindest auf einer genügend freien Platz zu schaffen – aber das dauert und besonders einfach ist das auch nicht immer. Nein.

Praktischer ist es dabei, sich ein billiges Raid-0 (Striping) über Loop-Devices zu basteln, deren Imagedateien auf den drei Festplatten liegen, das man dann mit einem beliebigen, geeigneten Dateisystem formatiert und die externe Festplatte wird darauf gesichert. Das geht standardmässig mit jedem einigermaßen, aktuellen Linux recht einfach.

Zuerst einmal fängt der Spaß damit an, dass man die Imagefiles auf den jeweiligen Festplatten als sog. Sparse File anlegt. Dies macht man praktischerweise mit dem netten Befehl dd:

dd if=/dev/zero of=file1.img bs=1k seek=128M

Das legt ein Sparsefile an, welches maximal 128 GB an Inhalt fasst. Man lege also so drei Sparse-Files auf den verschiedenen Festplatten an, nenne sie meinetwegen file1.img, file2.img und file3.img und passe natürlich auch die Größe an, meinetwegen 150 GB, 100 GB und 50 GB.

Als nächstes muss man dann Linux sagen, dass es diese Image-Files als Loopback-Device zur Verfügung stellt. Wer ein Loopback-Device nicht kennen sollte: damit tut der Kernel so, als sei das Image-File ein weiteres, physikalisches Gerät. Man kann diese Devices also z.B. nutzen, um ISO-Images direkt von der Festplatte zu mounten und auszulesen, eine praktische Sache.

Der Befehl, den wir dazu brauchen, ist losetup, und so sieht das dann auf:

losetup /dev/loop0 /file1.img
losetup /dev/loop1 /mnt/bla/file2.img
losetup /dev/loop2 /mnt/bla2/file3.img

Damit wird dem Device /dev/loop0 die Datei file1.img zugewiesen usw.

Als nächstes müssen wir dann aus den drei Devices ein Raid-0 basteln, was nichts anderes bedeutet als dass der Kernel aus dem Speicherplatz der drei Dateien einen einzigen, zusammenhängenden Bereich generiert, und das geht so:

md-adm --create /dev/md0 --level=0 --raid-devices=3 /dev/loop0 /dev/loop1 /dev/loop2

Damit wird der Kernel angewiesen, mit der Datei /dev/md0 ein Raid-0 zur Verfügung zu stellen, welches sich genau über die drei Loop-Devices erstreckt.

Als letztes formatiere man dann das Raid-Device md0 noch mit einem Dateisystem (hier: Ext4) seiner Wahl, beispielsweise so:

mkfs.ext4 /dev/md0

Und mounte es:

mount /dev/md0 /mnt/backup

Wenn man dann später das Backup nicht mehr braucht, kann man die Imagedateien einfach löschen und der Platz ist wieder frei, und fertig ist die Laube. Schön, nicht wahr?

Ach ja, und wenn man später mal die Dateien doch noch mal zusammen bauen will zum Raid-0, um nach einem Neustart wieder darauf zuzugreifen, muss man nur den Schritt mit losetup ausführen und danach das hier eintippen:

md-adm --assemble /dev/md0 /dev/loop0 /dev/loop1 /dev/loop2

Das ist alles.

PS: Für wen Linux und dessen Kommandozeile ein böhmisches Dorf ist, der sollte besser die Finger davon lassen, bevor er sich noch wichtige Daten zerschießt und ohnehin ist es sinnvoll, immer mindestens ein aktuelles Backup zur Hand zu haben! Ihr seid gewarnt!

Hypergrid 2.0: die Zukunft ist jetzt!

Bartholomew Gallacher 5. April 2012 0 Kommentare

Diva Canto (bürgerlicher Name Crista Lopes), die Erfinderin des Hypergrids, erklärt in einem ihrer seltenen Blogposts bei sich, was für die Version 2.0 des Hypergrid-Protokolls geplant ist und wie es funktionieren soll.

Zunächst geht sie dabei ein wenig auf die Geschichte der verschiedenen Versionen ein: so war HG 1.0 ausschließlich als „proof of concept“ gedacht gewesen, um zu testen, ob das Konzept überhaupt funktionieren könnte, nicht mehr aber auch nicht weniger. Die Implementierung irgendwelcher Sicherheitsmaßnahmen stand dabei noch nicht zur Debatte, es ging ausschließlich darum, ob man dem Viewer glauben machen könnte, dass er sich noch im selben Grid bewege – und man konnte. Das Hauptziel zu testen, ob und wie man den Viewer für Zwecke mißbrauchen könne, für die er niemals gedacht gewesen war, war erfolgreich erreicht.

Als nächstes Ziel mit HG 1.5 ging es darum, erste einfache Sicherheitsmaßnahmen zu etablieren. Mit dieser Version wurde eine fälschungssichere Identität eingeführt, ein etwas sicherer Zugriff auf das Inventar und gridübergreifende IMs sowie Freundeslisten. Das ist der aktuelle Stand der Dinge, für den große Teile von Opensimulator umgeschrieben werden mussten, damit es überhaupt funktionierte.

Also was wird mit Hypergrid 2.0 kommen, was sind die Ziele?

Inventar
Zuerst einmal  soll das Inventar zu 100% abgesichert werden und der Ordner „My Suitcase“ wird endlich ohne externe Webapplikationen benutzbar sein [Anm.: 100% Sicherheit kann und wird es niemals geben, bei solchen vollmundigen Claims werde ich immer skeptisch!]. Wenn ein Benutzer in ein anderes Grid teleportiert, dann hat das Grid nur noch Zugriff auf den Ordner „My Suitcase“ und der Rest ist nicht sichtbar. Teleportiert der Benutzer dann zurück, wird der Ordner „My Suitcase“ wieder durch den echten Root-Ordner ersetzt und fertig.

Ob und wie der Ordner genau genutzt werden kann, wird dabei konfigurierbar sein. Es kann beispielsweise sein, das manche Grids den Export ihrer Assets mit diesem Ordner nicht erlauben wollen, und so wird der Benutzer dann extern leicht anders ausseehen.

Zugriffskontrolle auf Benutzerebene
Es werden verschiedene Richtlinien an Zugriffskontrollen implementiert werden: wer teleportieren kann und wie, wer zu einem teleportieren kann und von wo. Diese Kontrollen werden auf verschiedenen Richtlinien basieren, die die Information über die Benutzer selber als auch deren Herkunftsgrids berücksichtigen werden.

So wird es beispielsweise möglich sein, dass nur Benutzer ab einem bestimmten Level über das Hypergrid andere Grids besuchen können werden, während andere unterhalb dieses Levels es nicht können – das ist ein Wunsch, den gerade Bildungseinrichtungen häufig fordern. Es wird möglich sein, eine Liste an Grids festzulegen, die die Benutzer besuchen dürfen – oder nicht.

Für mögliche Gäste ist es ebenfalls analog möglich zu bestimmen, von welchen Grids Besucher erlaubt sind und für welche nicht – oder es ganz einfach ganz abzuschalten.

Zugriffskontrolle auf Asset-Ebene
Es wird eine Möglichkeit geben um einzustellen, ob das Grid Assets exportieren darf und wenn ja, zu welchen Grids oder generell. HG 2.0 wird dabei allerdings keine feinere Einstellungsmöglichkeit unterstützen, man wird also nicht sagen einstellen können, das ein bestimmtes Set an Assets exportiert werden darf und das andere nicht. Dies benötigt eine Möglichkeit, so etwas einzustellen und bisher ist diese noch nicht existent.

Jaja, die Ewiggestrigen 1er-Viewer-Benutzer – mal historisch aufgedröselt

Bartholomew Gallacher 27. März 2012 14 Kommentare

Zasta hat es heute mal wieder in seinem Blog mit den Leuten hat, die noch die 1er-Viewer wie Phoenix und dergleichen benutzen und nicht mehr versteht, wieso man diese Viewer noch freiwillig einsetzen kann, wo ihnen doch z.B. ganz einfach die multiplen Tattoolayer fehlen und der aktuelle Lindenviewer mit Abkömmlingen wie Firestorm inzwischen um einiges weiter ist. Dabei ist die Antwort darauf recht einfach, wenn auch vielschichtig.

Die wichtigste Erkenntnis dabei ist diese: der Viewer ist für die Bewohner von Second Life das Tor nach SL, damit ihr Werkzeug und wichtigstes Programm zur Nutzung von Second Life überhaupt.

Machen wir uns dabei ruhig nichts vor: der 1er-Viewer war und ist von der Usability her gesehen eine Katastrophe gewesen, ein historisch gewachsenes Chaos, das innerhalb von fast 9 Jahren entstand und immer mehr und mehr üppig wucherte. Er hatte dabei einige wirklich gute Ideen gehabt, wenn man sie entsprechend zu nutzen weiß, wie das Tortenmenü. Jaja, ich weiß manche können das nicht leiden, aber es ist auch nicht totzukriegen. Während sie im offiziellen Lindenviewer verschwanden gibt es Spekulationen darüber, ob in MS Office 15 nicht diese eingeführt werden, um die Nutzung auf Touchscreens zu erleichtern.

Aber wie auch immer: der 1er-Viewer war von der Usability her gesehen die reinste Katastrophe, der Punkt dabei ist allerdings der: wir kannten und hatten nichts besseres zur Hand gehabt. Jeder, der früh genug mit Second Life anfing, musste sich erst einmal mühsam durch diesen Viewer quälen und sich mit ihm anfreunden – oder er hörte irgendwann in dieser Arbeit einfach auf. Die Lernkurve zur Beherrschung dieses Viewers war extrem steil gewesen und für viele frustrierend hoch, zu hoch. Es gab zwar Projekte wie Imprudence, die sich auf die Fahnen schrieben, alles besser machen zu wollen und es in Details auch taten, aber niemals den Drive und die Masse entwickelten, in Second Life wirklich relevant zu werden.

Wer noch heute davon schwadroniert, wie leicht und einfach die 1er-Viewer zu bedienen seien, der lügt sich selbst in die Tasche. Es fällt einem nur deswegen leicht, weil man es eben so gewohnt ist und sich da inzwischen mit schlafwandlerischer Sicherheit bewegen kann, aber bis man diese Sattelfestigkeit erreicht hatte, das dauerte mitunter Wochen! Ein wirklich einfach und intuitiv zu bedienendes Programm sieht anders aus, mir fallen da beispielsweise von früher Kais Power Tools unter Windows ein.

Das ist auch der Grund, weswegen Linden Lab irgendwann einmal damit anfing, seinen Viewerdschungel 1 genauer zu analysieren und – ich finde zu Recht – einen der Hauptgründe, warum viele Benutzer nur einmal einloggten und danach nie wiederkamen in der absolut unterirdischen Usability dieses Viewers ausmachte. Im Klartext: das Programm hat einfach die Mehrheit der potentiellen Benutzer so dermaßen überfordert gehabt, dass sie genau einmal einloggten und dann nie wiederkamen, weil sie sich einfach diesen Mist nicht geben wollten.

Die richtige Entscheidung von diesem Desaster ist gewesen, dass man den Viewer grundauf von der Benutzeroberfläche her renovieren wollte – und das auch tat. Damit wollte man die Zahl der Benutzeranmeldungen steigern und dafür sorgen, dass man sich sofort einfacher zurecht findet in Second Life. Das ist im Prinzip eine Entscheidung gewesen, die nach wie vor richtig ist, nur die Umsetzung an sich ist das absolute Debakel gewesen.

Es ist nunmal so, und da kann man sich auf den Kopf stellen und mit den Beinen wackeln wie man will, das ändert nichts daran: der Mensch ist ein Gewohnheitstier. Hat er sich erst einmal an eine Plattform gewöhnt, dann will er diese auch in der Art und Weise damit arbeiten können, wie er es gelernt hat und sich nicht auf einmal durch eine neue Version der Software wieder vorkommen wie ein kleiner Pennäler in der Schule. Er erwartet einfach, dass die Menüs genauso weiterhin aufgebaut sind, wie er es gewohnt ist, die Buttons da sind, wie er es gewohnt ist und genauso aussehen, und und und…

Mehr erfahren

Firestorm 4

Bartholomew Gallacher 20. März 2012 0 Kommentare

Heute ist der neue Firestorm in der Version 4 erschienen (wer den Phoenixviewer nutzt, der sollte sich ebenfalls das heute erschienene Update für den holen, damit das Inventar weiter richtig funktionier).

Dieses Release ist als Wartungsrelease zu betrachten; es gibt nicht wirklich neue und nennenswerte Features, statt dessen hat man die Performance hoch geschraubt, Fehler bereinigt und allgemein dafür gesorgt, dass der Firestorm einen flotteren und runderen Eindruck hinterlässt.

Das ist auch wirklich diesmal gelungen; als ich ihn unter Windows startete, war das auf derselben Maschine ein gefühlter Unterschied wie Tag und Nacht. Es ist die erste Version vom Firefox die locker fluffig genug läuft, dass ich mir vorstellen kann, sie zu meinem neuen Hauptviewer zu machen.

Lange genug haben die Macher vom Firestorm daran auch gearbeitet, dies ist das Ergebnis von über 15 Monaten Arbeit und noch mehr, und diese Arbeit trägt nun endlich Früchte.

Mit diesem Release vom Firestorm gibt es nun so langsam wirklich keinen Grund mehr, sich in Second LIfe noch einen 1er-Viewer anzutun, vor allem da gewisse Sachen wie Multiple Tattoolayers bei Mesh geradezu Pflicht sind.

Blinder Aktionismus und Kony

Bartholomew Gallacher 18. März 2012 2 Kommentare

All diejenigen, die gerade bei der von Internetaktionisten losgetretenen Kampagne „Kony 2012“ mitmachen, sollten mal fünf Minuten ihrer Zeit opfern und sich diesen Artikel in der Telepolis genau durchlesen, der die Hintergründe und vor allem die Macher dieser Kampagne genauer beleuchtet.

Und dann solltet ihr mal genauer überlegen, vor wessen Karren ihr euch da alle bereitwilligst habt spannen lassen. Die Absichten der Organisation „Invisible Children“ und anderer Leute sind nämlich alles andere als nur redlich noch offensichtlich, die haben alle eine geheime Agenda.

Dann schaut euch noch an, was für Bodenschätze in Uganda liegen (die weltgrößte Kobaltmine, Erdöl u.a.), und denkt mal in Ruhe darüber nach: es geht dabei gar nicht um Kony, es geht dabei nur um die Rohstoffe und dass die USA einen Fuß nach Uganda rein kriegen und nicht, wie sonst meistens in Afrika, die Chinesen. Mal wieder.