Tag Archives: tpv

Creeping featurism

Bei Linden Research ist die Featuritis ausgebrochen: momentan gibt es so viele unterschiedliche Projektviewer wie schon seit Ewigkeiten nicht mehr.

Einerseits ist das natürlich eine gute Sache, so zeigt es doch, dass man zu technischen Verbesserungen und Innovationen bereit ist und diese auch voran treiben will.

Andererseits aber ist es wiederum schlecht, wenn man zu viele Baustellen gleichzeitig hat und sich so verzettelt. Momentan scheint das bei Second Life der Fall zu sein. Und was noch schlimmer ist, es macht gerade die Arbeit von Entwicklern der alternativen Viewer nicht gerade unbedingt einfacher. Einerseits sollen sie die "shared experience" garantieren, aber wie sollen sie andererseits mit diesem Featuredschungel da noch gerade teilweise mithalten können?

So schön neue Features wie CHUI, SSA, das Materialsystem und weitere (wie der parametrische Meshdeformer) sein mögen, momentan scheint es doch ein wenig zu viel des Guten zu sein. Und so treten sich teilweise gerade alle Arbeiter gegenseitig auf den Füßen herum.

NiranVs Viewer wird eingestellt - oder auch nicht

Das mit den Gemütslagen mancher Opensourcentwickler ist ja so eine Sache. Das Leben ist natürlich nicht einfach, meistens ist es sogar recht undankbar, längst nicht alles, was man programmiert, wird auch von Projektleitern dann übernommen. Das empfinden viele als einen Schlag ins Gesicht, kommt aber täglich vor und damit muss man eben einfach leben, fertig. Nicht umsonst hieß das Essay von Eric S. Raymond damals "Die Kathedrale und der Basar."

NiranV Dean hat nun bei Linden Lab einen Bugreport eingereicht, dass die Attachments im Viewer nicht genau symmetrisch dargestellt werden und, wie es sich gehört, das alles schön fein säuberlich dokumentiert plus eine mögliche Problemlösung gleich mitgeliefert. Das klingt im Prinzip erstmal nach einer runden Sache, das Ticket nennt sich Open-162. Da gibt es auch einige Bilder dazu, inwieweit nun sich der bisherige Fehler genau auswirkt. Eigentlich ist es mehr eine Kleinigkeit kosmetischer Natur.

Nun hat Linden Lab aber den Bugfix nicht angenommen und das Ticket geschlossen. Warum? Ganz einfach, weil dieser Bugfix Unmengen an bereits existierendem Content kaputt machen würde, und die Besitzer per Hand nachbessern müssten. Die meisten Designer haben nämlich drum herum gebaut und fertig, also es ist kein wirklich weltbewegender Fehler, sondern mehr so eine Sache mit der man leben gelernt hat und an die man sich gewöhnt hat. Second Life ist voll davon, und würde man nun hergehen und das korrigieren, dann wäre der Schaden eindeutig größer als der Nutzen. Also ist es besser, man lässt es so bleiben wie es ist und fertig.

NiranV Dean weiß zwar darum, aber er ist folgender Meinung:

better break all available content that has been attached to those bones instead of creating even more broken stuff in the future making it unnecessarly harder for avatar and clothing creators to align their stuff symetrically correct. If this issue would have never happened , i wouldnt have lost so many hours on finetuning my legs and other attachments because they are simply not symetric to each other.
And instead of saying "it breaks content" we actually DO it and prevent more broken stuff to be created which makes this shitstorm just bigger.

Und mit der Meinung eben flog er auf die Schnauze, fertig. Das kommt vor, und es ist einmal wirklich einer der Fälle, wo ich die Meinung von Linden Lab absolut unterstütze, die da lautet:

Real bodies are not perfectly symmetric, and neither is our avatar model; changing this now would be more disruptive than symmetry justifies.

Also Linden Lab erspart seinen Zigtausend Benutzern hunderte von Stunden unnötiger Arbeit. Schön. Die Reaktion von Niran darauf ist trotzig, er hat nun angekündigt, deswegen mit der Entwicklung seines Viewers aufhören zu wollen.

Er selber schrieb dazu das noch: 

for my users , i will do one last release sometime soon (not sure yet) and i guess thats it then , i will just return to what i´ve done prior to creating a Viewer that doesnt try holding the users hand and wants to improve Second Life instead of keeping its broken state

Da sage mal noch einer, dass Programmierer keine Diven sein können.

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.

Linden Lab unterbindet die Nutzung ihrer eigenen Viewer mit Opensim

Linden Lab hat letzte Woche in ihren eigenen Beta- und Entwicklungsviewern den Kommandozeilenparameter "-loginURI" ersatzlos gestrichen, mit dem es bisher möglich gewesen ist mit Linden Labs eigenen Viewern per Hand andere Grids anzusteuern.

Dazu gibt es folgenden Chatlog mit Oz Linden, in dem er es Nebadon Izumi erklärt:

[10:07] <nebadon> OzLinden : ping
[10:09] <OzLinden> pong
[10:10] <nebadon> are you guys really removing -loginURI support from the viewer?
[10:10] <nebadon> or is that just a mistake?
[10:10] <nebadon> cause latest Dev and Beta viewers get an error if you try to use it
[10:11] <OzLinden> that was deliberate, but there is a related bug that I'm working on now
[10:12] <nebadon> ok so it will eventually be back?
[10:12] <OzLinden> no, I don't believe so
[10:12] <nebadon> why is it being removed?
[10:13] <OzLinden> part of cleaning up grid handling - it really doesn't serve much useful purpose
[10:13] <nebadon> sure it does
[10:13] <nebadon> it lets us connect to opensim
[10:14] <nebadon> this essentially kills all support for OpenSim
[10:14] <OzLinden> which our Havok license does not allow

Kurz und gut: der Parameter wurde aufgrund von internen Bereinigungen am Gridhandling entfernt, da er zudem nicht wirklichen Sinn gemacht hätte. Nebadon warf ein, der Parameter hätte sehr wohl Sinn gemacht, da man so mit Linden Labs Viewern zu Opensim hätte verbinden können, worauf Oz Linden einwarf, dass die Havok Lizenz, welche Linden Lab erworben hat, genau das verbietet. Zur Erinnerung: wegen der Einführung des Pathfindings hat Linden Lab dem Viewer selber Teile von Havok beilegen müssen.

Was bedeutet das nun für die Zukunft? Die Mehrheit der Opensimbewohner hat ohnehin nicht Linden Labs eigenem Viewer benutzt, man bevorzugt Hippo, Imprudence und Singularity, sie wird es wohl kaum vermissen.

Für Viewerentwickler wiederum wird es nur dann interessant, wenn auch sie Pathfinding aktiv haben wollen, denn dann darf auch deren Viewer nur zu Second Life verbinden können. Firestorm hat das Problem so gelöst, indem es nun einen Firestorm für SL gibt und einen eigenen für Opensim geben soll.

Dass so etwas kommen wird, war klar. Die Auswirkungen sind aber wesentlich weniger drastisch, als mancher meinen könnte. Bei Hypergrid Business jedenfalls haben sie ein Fass aufgemacht und dabei alles zu Wort kommen lassen, was im Bereich Opensim Rang und Namen hat. Natürlich steht es jedem Entwickler von alternativen Viewern nach wie vor frei, diese Funktionalität wie auch immer geartet im eigenen Produkt zu bieten, sei es als Kommandozeilenparameter oder Gridmanager. Linden Lab jedenfalls wird das nicht mehr tun.

Exodus-Viewer und seine Kollegen

Zasta hat ja heute bei sich mal den Exodus-Viewer getestet und fast als gut für seine fortgeschrittenen Bedürfnisse befunden. Die Grafikeinstellungen seien eindeutig am Mächtigsten und man könne am meisten grafisch aus der Kiste rausholen, wenn ja wenn nicht da der Viewer überall in die Bilder irgendwelche, störende Linien einbauen würde. Schade.

Eigentlich ist es ja so, dass geile Grafik für den Exodus-Viewer nur Nebensache ist, denn sein Hauptaugenmerk - und dafür ist er gedacht und dafür wurde er optimiert - liegt auf Kampf. Schock! So oder so, seit knapp 60 Tagen hat sich im offiziellen Sourcecode-Repository des Viewers absolut nichts, aber auch rein gar nichts mehr getan. Schade!

Also habe ich mich mal ein wenig auf Spurensuche begeben, um zu schauen, ob es denn irgendwelche Lebenszeichen der Entwickler nach dem Anfang Februar gegeben hat. Die webbasierten SL-Profile? Fehlanzeige, einige der Entwickler sind noch vor 14 Tagen aktiv gewesen, das war es dann aber auch gewesen. Twitter? Der letzte offizielle Tweet ist auch 60 Tage her.

Dann gibt es da noch die offiziellen Supportforen, welche bei Google Groups gehostet werden, und das war dann endlich mal ein Treffer. Am 2. April fragte nämlich jemand dort offen, ob das Projekt denn bereits als tot anzusehen sei, und Ash Qin antwortete darauf genau am 3. April dann das:

I can't speak for the other developers. But I can speak for myself - I don't believe the project is dead at all.
I haven't contributed much to Exodus in the past month while trying to get employed at a company in real life. I'm certain once I've dealt with this real life hurdle, I'll be contributing frequently again. Funny how unemployment can consume more time!
I can tell you that there has been work going on in the development repositories still.

 

Nach Ash also, der nur für sich selber spricht, ist das Projekt nach wie vor lebendig und er hat deswegen nicht viel zum Viewer beitragen können, weil er momentan damit beschäftigt ist, eine Arbeit zu finden. Er werde weiterhin regelmäßig zum Viewer beisteuern und merkt noch an, dass es auch weiterhin Commits in den Entwicklungs-Repositories gegeben habe.

Mag sein, dass es die gab, nur im offiziellen selber sind die dann noch nicht gelandet. Nun ist aber auch diese Antwort bereits wieder bald einen Monat alt, getan hat sich seitdem nicht viel, so dass zumindest nach außen hin der Eindruck gerechtfertigt ist, dass das Projekt Exodus-Viewer momentan zum Stillstand gekommen ist. Von den Entwicklern hört und sieht man nichts mehr, es ist so als seien sie vom Erdboden verschluckt worden und das ist nun einmal Fakt. Da ist also irgendwie die Luft raus.

Wer übrigens schon immer mal wissen wollte, was es so alles für Viewer gibt, der wird hier fündig: Viewer Round-up page. Die Seite ist zwar auf Englisch, aber als reine Linksammlung sollte sie wirklich für jeden gut ihren Dienst tun.

Update: nach Aussage des Exodus-Chefentwicklers ist ein Update in Planung, die Entwicklung sei nur langsamer als früher.

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:

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.

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!

Emerald sucks again

Well... there's again some hiccups and discussion about an action of Modular Systems around their Second Life Viewer Emerald. One of the developers changed the login page in a kind of manner to generate quite much unnecessary traffic to a blog of a person which wrote something against Emerald some while ago. There have reportedly been many Iframes in the page to generate literally tons of traffic.

Well, the victim of that action had around 16.5 million hits so far. Otherwise there seems to be no harm done, but it is the intention that counts in my opinion.

Personally I am getting more and more fed up with the attitude of Modular Systems at all. Again there's an excuse for that behaviour, they didn't deny that it happened, but otherwise there are no more consequences or so it seems to me. If this would have been the first incident, well, we could count it as lessons in better behaviour. But now? I am sure that this is not going to be the last startling revelation about Emerald - and it sucks, because the viewer really was once upon the competition for quite some time, but now keeps loosing ground more and more against the other third party viewers.

Personally I've switched long ago already to Imprudence because of that and my distrust into Modular Systems at all.

But what's getting more and more annoying is in discussions the attitude of many Emerald fanboys. As always they keep saying and saying "Nothing bad at all has ever happened!", and I bet they would even say that to a mobster who just smashed his fist into their face. Even if there is hard evidence, as it is now, they just keep saying that like a badly broken record.

But of course all what the other side doing is bad, even if it has not happened yet but only could happen, and oh my they think this is still an everlasting campaign against Modular Systems. Truth to be told: partly of course it is. But: no campaign would last so long if there's not a continuing fueling for those campaigns done by Modular Systems. In other words: unlikely that Modular Systems will ever learn, instead they are going to keep their kind of whatever attitude, I doubt that any serious change is ever going to happen and surely are going to produce more incidents like that in the future.

Why, for example, has the webmaster or developer that played that kind of "prank", not been removed from the project? This is something I am never going to understand, sorry.