Tag Archives: phoenix

Es ist für Phoenix-Benutzer mal langsam an der Zeit über einen neuen Viewer nachzudenken

Wir erinnern uns: Phoenix ist seit Anfang des Jahres tot wie ein Dodo. Da kann und wird keinerlei Weiterentwicklung stattfinden, da Firestorm nun das einzige Projekt der Macher ist. Ich kann sie gut verstehen, dass sie ihren Zombie endlich beerdigt haben und froh darum sind.

Nun macht Linden Lab mit seinen Änderungen im Simulatorbereich langsam, aber sicher ernst, und erste neue Features wie die neuere HTTP-Bibliothek sind bereits auf gewissen Servern live. Da wird es auch nicht mehr lange dauern, bis das Serverside Baking (SSB) kommt und damit dann veraltete Viewer wie Phoenix die Avatare nur noch in schickem Grau sehen werden.

Also ist es langsam aber sicher für die Phoenix-Benutzer an der Zeit, ihren Phoenix in den wohlverdienten Ruhestand zu schicken und über einen geeigneten Ersatz nachzudenken. Wer sich mit Firestorm und dem Interface nicht anfreunden kann (obwohl es ein Phoenix-Skin hat!), der sollte sich mal den Cool Viewer von Henri Beauchamp oder Singularity Viewer 1.8.0 anschauen. Beide sind auf diese kommenden Änderungen nämlich vorbereitet und werden ihre Benutzer da nicht im Stich lassen.

Was bedeutet die Reform des JIRA-Trackers genauer?

Ich habe mir zu der Änderung im Umgang mit dem JIRA-Tracker noch so einige, weitere Gedanken gemacht.

Die einen sehen darin einen notwendigen Schnitt und Schritt in die Normalität. Ein Bugtracker ist schließlich zum Melden von Fehlern gedacht und nicht als Abstimmungssystem über Features, die viele nun sehr gerne hätten oder um in den Kommentaren Druck auf die Entwickler auszuüben. Aber gerade das war sehr häufig im Laufe der Zeit im JIRA geschehen, wer kennt es nicht, dass irgendjemand ein Ticket zu irgendwas eröffnete, dann den Link weiter reichte und darum bat, man möge bitte dafür abstimmen, damit Linden Lab mal den Arsch hochkriegt und das behebt? Eben!

Dafür war das System nie gedacht gewesen, andererseits ist es aber auch so, wenn man es wirklich systematisch ausgewertet hat, konnte man daraus eine Menge über die Wünsche seiner Kunden erfahren.

Also ist das aus Sicht Linden Labs ein Schritt in die richtige Richtung, diese Unkultur im Bugtracker zu unterbinden, für die er niemals gedacht gewesen ist.

Aber das greift dann eben doch ein wenig zu kurz. Man hätte nämlich es so machen können, dass Bugs sehr wohl noch für jeden öffentlich sichtbar sind, aber nicht mehr jeder kommentieren/abstimmen kann. Die meisten erfolgreichen Opensource-Projekte fahren generell mit offenen Bugtrackern, weil eben diese durch die Offenheit leben. Beispiele dafür sind die Bugtracker von Firefox, Linux, Video Land Client, Chromium (die Basis von Google Chrome) und viele weitere. Offen einsehbare Bugs gehören zu einer guten Opensource-Entwicklung einfach dazu, denn sie bringen eine Menge an Vorteilen. So etwas ist also Standard.

Was nun Linden Lab getan hat, ist die Abstimmungskultur im JIRA schlagartig zu beenden. Gut, das ist deren Sache. Aber sie taten eben noch mehr, indem sie dafür sorgten, dass Bugs grundsätzlich nicht mehr öffenlich sind, auch die Bugs, die die Viewerentwicklung betreffen.

Und damit zeigen sie den externen Viewerentwicklern eindeutig den Stinkefinger, etwas anderes ist das nämlich nicht. Sie berauben diese Entwickler nämlich einer immens wichtigen Informationsquelle.

Wer das nicht glaubt, der sollte sich mal damit auseinandersetzen, was gerade in einem ähnlichen Fall passiert. Die Datenbank MySQL gehört schon seit längerem zu Oracle. Oracle selber entwickelt diese als Opensource auch weiter, aber es gibt mindestens zwei kommerzielle Konkurrenten zu MySQL, einmal Percona und dann MariaDB.

Was tut also Oracle, um seine eigene Datenbank zu pushen und die Entwicklung der Konkurrenz zu erschweren? Sie sorgen dafür, dass gewisse Bugs nicht mehr öffentlich sind und stellen zu gewissen Features im öffentlich zugänglichen Quellcode nicht mehr die Testfälle zur Verfügung.

Die externen Entwickler sehen dann in Release-Notes meinetwegen nur noch, Bug 123 und 456 wurde behoben - was aber der Bug gewesen ist, das wissen sie nicht mehr. Das erschwert ihnen also die Entwicklung und das Gleichziehen mit dem Mutterprodukt MySQL gehörig.

Ebenso wird es ihnen erschwert, die Kompatibilität ihrer eigenen Forks noch zu gewährleisten, wenn Oracle nicht mehr die dazu notwendigen Testfälle bereitstellt.

Aus Sicht von Oracle ist das ein logischer Schritt: man behindert die unleidliche Konkurrenz, hofft darauf, dass die Benutzer auch weiterhin den Arsch nicht hoch kriegen sondern bei MySQL bleiben und man so verstärkt Supportverträge verkaufen kann. Diesen Effekt, die unliebsame Konkurrenz so trotz Opensource abhängen zu wollen verstärkt Oracle noch dadurch, dass sie MySQL mit einer brachialen Geschwindigkeit weiter entwickeln.

Also alles in allem eine Sache, die in der MySQL-Nutzerschaft sehr skeptisch aufgenommen wird und kritisch beäugt, wie man beispielsweise bei Kris Köhntopp nachlesen kann.

So, und nun zurück zu Second Life und der JIRA-Reform: die Parallelen sind mehr als offensichtlich. Linden Lab lässt die Entwickler von alternativen Viewern am langen Arm verhungern, indem sie alle Bugreports nun als privat markieren, dazu kommt auch die sehr schnelle Weiterentwicklung der eigenen Viewerlinie.

Damit macht Linden Lab nichts anderes als Oracle mit seinen Konkurrenten: man zeigt ihnen den Stinkefinger und trocknet deren Tümpel aus. Gerade dieser Schritt von Seiten Linden Labs ist nun wirklich mal brachialer und auch folgenreicher als die damals stark kritisierte Havok-Unterlizenz, die ja nur optional ist.

Mit dieser Maßnahme schadet Linden Lab den Entwicklern von Firestorm&Co. nämlich wirklich massiv, und viele bemerken das nicht einmal.

Phoenix Viewer, Attachment Points und der Rest

Es ist soweit: keiner der ehemaligen Emerald-Fanboys scheint ihm noch groß nachzuweinen. Knapp zwei Monate, nachdem Linden Lab für den Emerald-Viewer endgültig den Stecker zog kann sich der Phoenix Viewer mit Fug und Recht als der legitime Nachfolger Emeralds bezeichnen was die Beliebtheit und Verbreitung angeht. Bisher sind auch aus dem Maschinenraum der Phoenix-Entwickler keine schlimmen Geschichten bekannt, hoffen wir mal, dass es dabei bleibt.

Eine Sache hat Phoenix von Emerald mit übernommen: die doppelten Attachmentpunkte. In der Zwischenzeit brachte Linden Lab seine eigene Implementierung dieses Features heraus, die natürlich zu Emerald inkompatibel ist, nur um sie stillschweigend im Viewer 2.3 wieder auszubauen. Bummer.

Also greifen nach wie vor alle möglichen Fashionistas und Rollenspieler, denen es am Avatar zu wenig Attachmentpunkte gibt, nur zu gerne zu Phoenix. Nur: was im Phoenixviewer korrekt aussieht, sieht für den Rest der Welt einfach nur komisch aus, die Objekte stehen einfach irgendwie in der Luft und sehen seltsam aus. Das ist eine Sache, die man daher in Rollenspielgebieten tunlichst vermeiden sollte, wenn man nicht schief angesehen werden will, schließlich kann man es nicht verlangen, dass der Gegenüber irgendwelche seltsamen Handgriffe an seinem Viewer vornimmt, nur damit er den eigenen Avatar endlich richtig sieht oder gar Phoenix installieren muss. Nene, das kann es nicht sein.

Wer zu seinen Mitspielern nett ist, der verzichtet freiwillig auf den Schnickschnack und gut ist es.

Phoenix&Co., Kakadu, Linden Lab und der Rest...

Linden Lab ist mal wieder auf Kriegspfad, so sehen es jedenfalls viele Verschwörungstheoretiker. Deren Meinung ist ganz einfach diese: Linden Lab verfolge eine Strategie, alle wichtigen alternativen Viewer uninteressant zu machen, so dass man geradezu gezwungen ist, den unglücklichen Viewer 2.x von Linden Lab zu benutzen. Diese Theorie ist weit verbreitet und macht immer wieder die Runde, was die Vertreter dabei allerdings  übersehen ist der einfache Fakt, dass das Linden Lab herzlich egal ist, mit welchem Viewer man auf das Grid zugreift, Hauptsache man greift darauf zu und lässt sein Geld dort. Das Geschäftsmodell von Linden Lab basiert nämlich nach wie vor Großteils auf der Landvermietung und nichts anderem, der Viewer der Wahl ist dabei wirklich herzlich egal.

Nun ist es so, dass alle Texturen in Second Life auf dem Bildformat JPEG2000 basieren (nähere Erklärung in diesem Blogpost von mir). JPEG2000 ist eine sehr stark verlustbehaftete Bildkomprimierung und benötigt sehr viel Rechenzeit.

Der Viewer von Linden Lab benutzt dafür eine kommerziell vertriebene Programmbibliothek aus dem Hause Kakadu Software, während die meisten alternativen Viewer dafür das deutlich langsamer arbeitende OpenJPEG benutzen, welches Opensource ist (wen es interessiert, hier gibt es dazu viele Benchmarks, Kakadu gewinnt dabei immer). Nun war es bisher aber möglich, und der Code dafür stammt von den Lindens selbst, dass man einem alternativen Viewer wie meinetwegen Phoenix dazu überreden kann, die Bibliothek aus dem Hause Kakadu zu benutzen. Man musste dafür nur die Programmbibliothek llkdu.dll aus dem Verzeichnis eines offiziellen Second Life Viewers in das Verzeichnis des alternativen Viewers kopieren, neu starten - fertig. Das ist eine Sache, die auch viele gemacht haben, der alte Emerald kam am Ende sogar mit einer eigenen Version dieser Bibliothek namens emkdu.dll daher. Dies war für viele ein schöne, gern gesehene Sache, da doch so der alternative Viewer vor allem auch auf älteren Prozessoren spürbar flotter arbeitete.

Die Technik, die dabei eingesetzt wird, nennt sich DSO - dies steht für "Dynamic Shared Object" und ist nichts anderes als eine zur Laufzeit geladene Programmbibliothek. Im Falle der Second Life Viewer wird diese Bibliothek direkt aus dem Programm heraus geladen, die dafür notwendigen Routinen befinden sich im Quellcode in der Datei llimage/llimagej2c.cpp. Das Vorhandensein der KDU-Bibliothek ist dabei für keinen der Viewer ein Muss, weil er nicht gegen diese Bibliothek gelinkt worden ist. Ist diese nicht vorhanden, läuft er dennoch und benutzt statt dessen als Fallback OpenJPEG. Ist allerdings auch OpenJPEG nicht vorhanden, dann startet er erst gar nicht richtig und quittiert das mit einer Fehlermeldung.

So. Die Codebasis, auf der alle bisherigen alternativen Viewer basieren, steht unter der GPLv2 inkl. einiger Ausnahmen, einer sog. FLOSS, damit man gegen Bibliotheken linken darf, die nicht mit der GPL kompatibel sind, die der Viewer aber zum Laufen benötigt (Snowstorm steht unter der LGPL, aber auf dessen Basis gibt es bisher keinen alternativen Viewer).

Was aber ist die GPL? Die GPL (Wikipediartikel dazu und Post von Kris Köhntopp) ist die Softwarelizenz, unter der dieser Code vertrieben wird und die genau festlegt, was man damit machen darf und was nicht. Das zentrale Wesen der GPLv2 ist dabei, dass sie virulent ist. Code, der einmal unter der GPL publiziert worden ist, bleibt das auf alle Zeit und alle daraus abgeleiteten Programme müssen ebenfalls unter dieser Lizenz zur Verfügung gestellt werden. Wichtig dabei ist, dass die GPL sagt: du musst mit mir kompatibel sein! Wenn man ein Projekt leitet und Code damit baut, der zum Teil auf Produkte mit anderen, inkompatiblen Lizenzen basiert, dann verstösst man damit gegen die GPL. Will man gegen lizenzmässig inkompatible Bibliotheken linken, dann braucht es eine FLOSS, so wie Linden Lab das getan hat.

Nun wird die KDU-Bibliothek als "Black Box" benutzt. Das bedeutet, der Viewer checkt, ist sie da und lädt sie dann zur Laufzeit, ansonsten funktioniert das Programm auch ohne. Das Vorhandensein von KDU ist keine Voraussetzung für das Funktionieren des Viewers an sich. Damit bewegt man sich lizenzmässig gleich auf einem Drahtseilakt, aber möglich ist dieses durchaus. Letztendlich wäre es ein Fall für die Juristen, das abzuklären.

Jedenfalls sagt jetzt Linden Lab nun dies: "Wer alternative Viewer baut, die auf das Grid zugreifen wollen, der darf die KDU egal welcher Form nicht mehr nutzen können." und daran scheiden sich jetzt die Geister. Es bedeutet für die Benutzer von alternativen Viewern eine gehörige Verschlechterung der Ladezeiten und der Aufruhr ist dementsprechend groß. Es hat zudem Auswirkungen auf die in world Wirtschaft, da OpenJPEG mit einigen Texturen einfach nicht klar kommt und diese bestenfalls falsch darstellt, wenn überhaupt. Sollten dies natürlich Height Maps für Sculpties sein, dann guckt man schön in die Röhre. Entsprechend sauer sind viele auf Linden Lab und meinen sarkastisch, LL wolle die letzten verbliebenen Avatare nun auch noch endgültig aus Second Life vertreiben.

Nun ist die Begründung von Seiten Linden Labs, mit der sie das durchsetzen wollen, auch reichlich dünn: sie begründen das mit einem Verstoß gegen die GPL. Die meisten Entwickler alternativer Viewer sehen das naturgemäß anders, aber kommen in der Mehrheit Linden Labs Wünschen dennoch nach.

Warum? Weil Linden Lab eine ganz einfache Stellstchraube hat, mit denen sie die Entwickler dazu bewegen können: sie müssen keinen alternativen Viewer aufs Grid lassen, der ihnen nicht gefällt. Das ist der Knüppel im Sack, mit dem Linden Lab zur Not arbeiten kann, Emerald hat das bereits ja zu spüren bekommen.

Über den Grund, warum Linden Lab auf einmal diesen Schritt vollzieht, gibt es auch so einige Spekulationen. Am wahrscheinlichsten ist dieser, dass Kakadu Software Linden Lab mit der juristischen Keule in Form massiver Schadensersatzzahlungen wegen möglicher Lizenzverletzungen gedroht hat. Denn was Linden Lab mit der llkdu.dll geschaffen hat ist nichts anderes als eine beliebig kopierbare Variante dieser proprietären Bibliothek, die von jedem beliebigen Programm unter Windows, Linux und Mac OX S aufgeruft werden kann, um JPEG2000 zu handhaben. Die dafür notwendigen Schnittstellen sind ja offen im Quellcode von Linden Lab dokumentiert und so ist das ein leichtes. Es ist durchaus möglich, dass dies auch bereits geschehen ist, jedenfalls ist das so oder so eine Sache, die man natürlich im Hause Kakadu Software nicht gerne sehen dürfte.

Wenn dem aber so ist, dann sollte Linden Lab wenigstens auch so ehrlich sein und das offen zugeben. So aber kommen die meisten Entwickler mit der geballten Faust in der Tasche den Forderungen Linden Labs nach, aber bezeichnen die Begründung bestenfalls als unehrlich, meist eher noch als verlogen. Den Schaden tragen jedenfalls alle Benutzer, die lieber mit einem alternativen Viewer unterwegs sind in Form deutlich langsamerer Texturaufbauzeiten davon. Bis OpenJPEG die Qualität und Geschwindigkeit von Kakadu erreicht, dürfte noch einiges an Zeit vergehen, Bildkomprimierung ist ein ungeheuer theoretisches und ekliges Feld der Programmierung.

Phoenix Viewer Changeset 3de7c9b5acf3: OpenJPEG statisch unter Windows

Die Macher vom Phoenix-Viewer haben im Changeset 3de7c9b5acf3 eine wichtige Änderung eingebaut: fortan wird OpenJPEG als statische Bibliothek direkt ins Programm gelinkt und nicht mehr erst zur Laufzeit als DLL geladen.

Wer sich mit einem Texteditor auskennt, für den ist es natürlich ein Leichtes, diese Änderung zu revidieren, dann muss er aber noch immer ein komplettes Buildsystem haben und Phoenix selber bauen können. Der tiefere Sinn dieser Änderung erschließt sich mir jedenfalls nicht wirklich.

Emerald ist endgültig tot

Ab Mittwoch den 8. September 2010, 19:00 Uhr unserer Zeit, wird Linden Lab den Zugriff aller Emerald-Viewer auf das Second Life Grid sperren. Dies war bereits seit einiger Zeit absehbar und ist kein Beinbruch, da für alle Emerald-Liebhaber mit dem Phoenix Viewer ein würdiger Nachfolger bereit steht, der sogar im TPVD gelistet ist.

Linden Lab ließ es sich nicht nehmen, jeden Benutzer davon sogar per Email in Kenntnis zu setzen. Naja, es ist das Ende eines  Projekts, das durchaus seine Spuren hinterlassen hat, aber von Leuten betrieben wurde, die ihrer Verantwortung teilweise nur bedingt dauerhaft gerecht wurden.

Rezzen im Phoenix Viewer beschleunigen

Der Phoenix-Viewer nutzt wegen der Auflagen von Linden Lab keine Emkdu.DLL mehr und kommt mit OpenJPEG 1.3.0 als dafür zuständige Bibliothek daher. Das macht sich im Vergleich zum alten Emerald in einem langsameren Rezzen der Texturen bemerkbar.

Nun ist Phoenix dergestalt umgebaut worden, dass er das Rezzen nur noch mittels OpenJPEG vornimmt, auch wenn LLkdu vorliegen sollte, und sonst gar nicht. Das war eine der alten Forderungen von Seiten Linden Labs an die Emerald Entwickler, ich habe es mit allen möglichen LLkdus probiert, es funktioniert nicht.

Nun kann man mit einem kleinen Trick Phoenix dennoch zu schnelleren Rezzingzeiten überreden. Die Version 1.3.0 von OpenJPEG nämlich ist nicht mehr aktuell und Imprudence kommt mit der deutlich schneller arbeitenden Version 1.4.0.565 daher.

Also lädt man unter Windows sich einfach zuerst Imprudence herunter (z.B. die 1.3.0 RC2) und installiert diesen. Aus dem Programmverzeichnis von Imprudence kopiert man dann die Datei OPENJPEG.DLL in das Programmverzeichnis vom Phoenix-Viewer und startet diesen danach.

Wenn alles geklappt hat, dann sieht man im Menü "Hilfe" unter "Über Phoenix Viewer" folgendes, wichtig ist dabei der farbig eingekastete Bereich:

In dem muss als Runtime "1.4.0.565" stehen, damit nutzt nun Phoenix Viewer die neuere Bibliothek und sollte schneller arbeiten.

Und wie der Phönix aus der Asche…

Emerald ist tot, es lebe der Phoenix-Viewer! Das abgespaltene Emerald-Team um Jessica Lyon hat einen eigenen Fork vom alten Emerald unter dem Namen Phoenix Viewer gestartet.

Das Hauptziel des Emerald-Viewers ist die Weiterentwicklung der bereits vorhandenen Codebasis vom alten Emerald unter Einhaltung von hundertprozentiger Transparenz. Jeder Arbeitsschritt soll von außen kontrollierbar sein, es gibt bereits jetzt einen IRC-Channel der Entwickler, ein öffenliches Quellcoderepository, und und und... Zudem hat man bereits die Aufnahme im Third Party Viewer Directory beantragt und rechnet damit, dass dies eine rein Formsache sei, da keine historisch belasteten Entwickler mehr mit an Bord seien.

Unter den Entwicklern ist der bekannte LordGregGreg Back zurück und Kitty Barnett, von der die RLV(a)-Implementierung stammt. Auch ansonsten ist man personell sehr gut bestückt, man darf gespannt sein, welches Leben diesem Projekt in der Zukunft beschert sein wird, es liest sich wie all die guten Sachen von Emerald minus dem unnötigen Drama.

Hoffentlich haben die Entwickler dabei ihre Lektionen gelernt!