Firestorm Support auf Deutsch

Wer bisher noch nicht genug an der Menschheit zweifeln sollte, der möge einfach mal der Gruppe „Firestorm Support auf Deutsch“ beitreten und sich da einige Supportanfragen im Kanal geben. Danach dürfte derjenige kuriert sein.

Die meisten Fragenden da drin haben die Aufmerksamkeitsspanne eines Goldfisches mit Hirnerschütterung, also mehr als das Lesen und Verstehen eines Halbsatzes ist nicht drin. Und selbst wenn man ihnen was sagt, dann fragen sie mindestens noch dreimal nach, bevor sie dann das Gesagte eventuell annehmen. Es kann aber auch sein, dass sie es dann trotz allem nicht tun, wo man sich dann schon mal die Frage stellen kann, wieso sie dann überhaupt in der Gruppe nachfragen.

Firestorm Viewer Private Build Nr. 4.5.2.39868 zum Download verfügbar

Mir ist gerade ein wenig langweilig und daher dachte ich mir, ich könnte ja mal der Community einen möglicherweise kleinen Dienst erweisen – und das mache ich nun.

Ohne weiteren Umschweife: ab sofort biete ich nun einen sog. aktuellen Nightly Build vom Firestorm für Windows (32 bit) zum Download an. Nun wo das raus ist, der Reihe nach.

F: Was ist ein Nightly Build?
A: Ein Nightly Build ist eine möglicherweise lauffähige Version des Firestorm Viewers, die auf dem aktuellen Sourcecoderepository des Entwicklersteams beruht.

F: Auf welchem Quellcode basiert dieser Viewer?
A: Er basiert auf dem unter http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ öffentlich verfügbaren Code. Er wurde mit Hilfe von Microsoft Visual C++ Express 2010 kompiliert und es handelt sich dabei um die 32bit-Variante des Viewers.

F: Gibt das Firestormteam nicht selber Nightly Builds heraus?
A: Nein, das haben sie noch nie.

F: Warum bietet das Firestormteam nicht selber einen Nightly Build zum Download an? Andere Viewer, wie beispielsweise Singularity, machen das doch auch!
A: Es ist keine Frage des Könnens, sondern des Wollens. Das Entwicklerteam vom Firestormteam will keine solchen Builds veröffentlichen. Wer es genau wissen will, der kann es unter http://modemworld.wordpress.com/2013/02/19/firestorm-meeting-13th-february-2013-video-and-transcript/7/ auf Englisch nachlesen. Jessica Lyon begründet es mit mangelnder Qualitätskontrolle. Nightly Builds sind das, was man auf Englisch als das Bleeding Edge bezeichnet. Es handelt sich dabei von der Qualität her nicht einmal um Alphaversionen. Ein Nightly Build kann funktionieren, muss aber nicht, und keiner wird garantieren, dass alle Funktionen richtig oder fehlerfrei funktionieren und man muss schlimmstenfalls auch mit Fehlern rechnen, die Datenverlust nach sich ziehen könnten.

Wer einen Nightly Build benutzt, der muss sich dieser Gefahr sicher sein, dass er auf eigenes Risiko handelt und keinerlei Support bekommen wird. Offensichtlich gehen die Firestormentwickler davon aus, dass die Benutzer dazu einfach in der Masse unfähig sind und daher veröffentlichen sie keine Nightly Builds.

F: Warum veröffentlichst du dann einen Nightly Build, wenn die Firestormentwickler selbst es nicht tun?
A: Weil ich es kann! Und weil das letzte Release von Firestorm von Oktober 2013 ist, und – seien wir da mal ehrlich – einfach nur schnarchlangsam rezzed. Ich persönlich benutze den Bleeding Edge selbst schon seit einiger Zeit und bin der Meinung, die bald vier Monate seit dem letzten Release machen sich durchaus bemerkbar.

Außerdem bin ich der Meinung, dass es ein Fehler des Firestormprojektes ist, bewusst keine Nightly Builds zur Verfügung zu stellen. Andere Viewer fahren sehr gut damit, und getreu dem Motto „Release early, release often“ stelle ich nun diese Kompilate zur Nutzung auf eigene Gefahr hin der Allgemeinheit zur Verfügung, weil einfach nicht jeder fähig ist, sich selbest eine Buildumgebung zu bauen und es selbst zu kompilieren. Das füllt damit eine Lücke.

F: Darfst du das denn veröffentlichen? Und was ist, wenn es den Firestormentwicklern nicht gefällt?
A: Ja, sicher darf ich das veröffentlichen. Der Viewer unterliegt einer Opensourcelizenz, der Quellcode ist ebenfalls verfügbar und wenn ich daraus kompilierte Binaries verteilen will, dann kann, darf und werde ich das tun, solange nicht proprietäre Bibliotheken wie von Kakadu mit dabei sind. Und wenn es den Firestormentwicklern mißfällt, dann können sie nicht viel mehr dagegen tun, als ihre Mißbilligung auszudrücken. Denn es ist absolut nichts illegales.

F: Ich vertraue dir nicht!
A: Schön, das musst du auch nicht. Eine gesunde Paranoia ist sogar besser. Nur wenn du mir nicht vertraust, dann benutze auch besser das Programm erst gar nicht, sondern besorge es selber aus einer anderen Quelle oder baue es einfach selber.

F: Mit welchen Einstellungen ist das Programm kompiliert?
A: Es benutzt als Grafikbibliothek OpenJPEG und ist mit Opensimulatorunterstützung kompiliert. Dies entspricht der Autobuild-Konfiguration ReleaseFS_open.

F: Kannst du nicht noch X, Y oder Z ins Programm kompilieren? Kannst du nicht noch X, Y oder Z für mich machen?
A: Nein! Kein Support, keine Unterstützung für Sonderwünsche. Entweder das Programm ist so, wie es vorliegt, für dich brauchbar, oder eben nicht. Ich habe nicht die Zeit dazu, auf solche Wünsche eingehen zu können!

F: Was kann das Ding, was fehlt?
A: Das Ding kann alle Grundfunktionen, die Firestorm eben auch kann. Fehlen tun u.a. fortgeschrittene Baufunktionen, wie beispielsweise Havok. Erwartet alles, nur keinen stabilen Betrieb oder eine vollständige Funktionalität wie im offiziellen Lindenviewer! Dieser Viewer ist eine Baustelle, und das merkt man auch mitunter!

F: Ist es gefahrlos möglich, mit dem Ding auf dem Second Life Grid zu arbeiten?
A: Im Zweifelsfalle: nein. Es handelt sich hierbei um eine Version, die offiziell mit Opensimunterstützung arbeitet und für Opensim gedacht ist. Das bedeutet, dass höchstwahrscheinlich viewerseitige Einschränkungen, die Linden Lab von Second Life Viewern fordert, in dieser Version abgeschaltet sind. Daher rate ich von einer Benutzung des Programms auf dem Second Life Grid ab.

F: Ist das hier nicht dein eigenes Viewerprojekt?
A: Nein. Es wäre mein eigenes Viewerprojekt, wenn ich Änderungen am Code vornehmen würde oder bereits vorgenommen hätte. Das aber habe ich nicht getan. Ich habe einzig und alleine den öffentlich zugänglichen Viewerquellcode unverändert genommen und kompiliert.

Rechtliche Hinweise
Ich biete keinerlei Support! Weder für den Firestormviewer an sich, noch für das kompilierte Programm oder beides. Ich stelle das Kompilat so zur Verfügung, wie es ist, nicht mehr und nicht weniger.. Weder bin ich ein Entwickler noch ein Mitarbeiter des Firestormentwicklerteams, sondern agiere von ihnen unabhängig und damit eigenständig!

Ich weise ausdrücklich darauf hin, dass es sich bei diesem Kompilat um eine Version handelt, deren Qualität noch vor Alpha ist. Das bedeutet, dass das Kompilat unvollständig sein kann, schwere Fehler enthalten kann und schlimmstenfalls Datenverlust nach sich ziehen kann. Ich gebe keinerlei Gewährleistung auf das Kompilat noch hafte ich für mögliche Schäden, die durch seine Nutzung entstehen könnten!

Ich erkläre, dass ich beim Kompilieren ausschließlich die öffentlichen Quellen unter http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ verwandt habe, und den Code in keinster Weise modifiziert habe. Ich erkläre, dass ich dem Setupprogramm weder Trojaner, Keylogger oder andere Schadprogramme beigefügt habe und es zum Zeitpunkt des Uploads vorher auf Virenbefall überprüft habe.

Weiterhin weise ich ausdrücklich darauf hin, dass es sich hierbei um eine Version handelt, die für Opensimulator gedacht ist! Die Benutzung dieser Version auf dem Second Life Grid kann schlimmstenfalls den Verlust des Zugangs nach sich ziehen!

Kurz und gut: ich übernehme keine Haftung – für gar nichts, weder für Datenverlust, möglichen Schäden an der Hardware noch den möglichen Verlust des Second Life Zugangs oder falls der Viewer deinen Kaffee verschüttet! Die Nutzung des Programms geschieht ausschließlich und ausdrücklich auf eigene Gefahr hin! Wer das Programm nutzt, der ist sich dieser Sache bewusst und erklärt sich damit einverstanden!

Nichts destotrotz freue ich mich natürlich über Kommentare. Und hier geht es zum Download: https://drive.google.com/file/d/0B_BpSLqaUY_dUlBPby0yYk5qVmM/edit?usp=sharing

Ich habe meinen Viewer fertig

Mein Firestorm ist inzwischen fertig und das Ergebnis schnurrt unter Windows so vor sich hin. Er läuft gefühlt um Längen schneller als das letzte Release, allerdings hat er ein übles Memory Leak und ist damit nach einer Weile absolut unbrauchbar, weil er sich wirklich allen Speicher krallen will.

Macht nichts – was nicht ist, das kann ja noch werden. Mal schauen, wie das normale Release mit OpenJPEG anstelle von KDU läuft, das ist als nächstes in der Pipeline.

Mein Wochenendprojekt: ich bastele mir einen Firestorm unter Windows

Da der offizielle Firestorm unter Windows momentan lahm ist wie Sau und dafür meine eigens aus dem Sourcecoderepository kompilierte unter Linux rennt wie Sau, baue ich mir heute mal unter Windows selbst eine aus dem aktuellen Code.

Das dauert ein wenig, da man erst einmal ja die gesamte Infrastruktur dafür runter laden und installieren muss (Compiler, Header, Utilities usw.), aber kostet außer Zeit ansonsten nichts, da alles ja umsonst verfügbar ist. Auf das Ergebnis bin ich jedenfalls sehr gespannt und werde dann darüber mal berichten.

Firestorm gone bad?

Fredi schreibt bei sich gerade, dass die Benutzung von Firestorm keinen Spaß mehr macht – zu langsam, zu instabil. Mir geht es momentan ähnlich, ich setze daher unter Windows lieber inzwischen den Cool Viewer ein.

Die Frage ist aber: woran liegt das? Dass die Macher von Firestorm durchaus fähig sind, einen flotten und schlanken Viewer zu bauen, sah man ja am alten Phoenix-Viewer. Friede seiner Asche.

Also ist ihnen entweder die Fähigkeit, einen gescheiten Viewer zu programmieren abhanden gekommen, was ich weniger vermute, oder es liegt an anderen Dingen. Wie beispielsweise den vielen, gleichzeitigen Baustellen, die Linden Lab momentan hat.

Diese sind teilweise voneinander abhängig und machen es den Entwicklern schwer, ihren eigenen Viewer auf den aktuellen Stand zu bringen, solange ein Projekt nicht abgeschlossen ist. Für die Lindens ist es natürlich kein Problem, da gute Viewer zu bauen, aber für Projekte mit begrenzter Manpower wird das dann schwierig. Abgesehen davon, man ist der Programmiergott Henri Beauchamp, denn der schafft das Unmögliche und Wunder ganz alleine.

Ich vermute daher, es liegt daher eher ganz einfach an der Vielzahl von Projects, die Linden Lab am Laufen hat, die es den Opensourcentwicklern schwer machen, ihre Viewer auf dem aktuellen Stand der Lindens zu halten. Einerseits schön, dass es sie gibt, andererseits rammt Linden Lab so dieses Ökosystem in den Boden. Ob mit Absicht oder nicht, darüber kann man sicher streiten.

Compiling Firestorm for dummies

Heute mal völlig unmotiviert eine kurze Anleitung, wie man Firestorm unter Linux selbst kompiliert.

Man benötigt: eine einigermaßen aktuelle Linuxdistribution wie Ubuntu, Debian, OpenSUSE, Fedora o.ä. mit funktionierendem C/C++-Compiler sowie installiertem Mercurial und Cmake, Python und Perl.

Zum Erstellen der Makefiles benutzt Linden Lab ein eigenes Tool namens autobuild. Dies installieren wir mittels

hg clone http://hg.secondlife.com/autobuild

Danach

cd autobuild; python setup.py build

Den Unterordner /bin nehmen wir dann in den Pfad auf, etwa so:

export PATH=/home/user/autobuild/bin:$PATH

Dann holen wir uns den Quellcode vom Repository mit

hg glone http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/

Wir wechseln in den Quellcodeordner von Firestorm und lassen nun Autobuild laufen mit:

autobuild configure -c ReleaseFS_open

Danach wechseln wir in den Ordner, dessen Namen mit build anfängt und beginnen mit dem Compilen. Dazu nehmen wir den Befehl

make -jX

X ist dabei ein Platzhalter für die Anzahl der Prozessorkerne +1.

Je nach Rechner dauert es dann 20 Minuten oder länger, bis er damit fertig ist.

Wenn alles geklappt hat, dann ist im Unterordner newview/packaged das lauffähige Programm. Das ist alles.

Alles so schlecht hier und überhaupt

Die Firestorm Version 4.4 stößt bei vielen gerade auf wenig Gegenliebe. Der einfache Grund: sie ist relativ fehlerhaft und macht keinen Spaß. Das kann bei einem Opensourceprojekt schon mal vorkommen, vor allem wenn die Firma Linden Research eben Druck macht und man gewisse Sachen einfach drin haben muss, wenn sie den Schalter umschalten.

Nun gibt es dazu passend auch den entsprechenden Heulthread in Slinfo. Sehr schön.

Was ich bei all diesen Sachen immer nie verstehe, ist folgendes: wenn alles so schlecht ist, und dieser Viewer so furchtbar – wieso benutzt man ihn dann noch? Es gibt genügend andere Viewer, die man genau so gut benutzen kann und wenn man mag, kann man ja auch die ältere Version benutzen. Alles kein Problem.

Und wer meint, Second Life sei voller Fehler und nur noch schlecht – was macht er dann noch hier? Warum ist er nicht schon gegangen? Es zwingt einen keiner dazu, Second Life zu benutzen, wenn man es nur noch unerträglich findet und es zwingt einen keiner dazu, einen Viewer zu benutzen, den man nicht mag.

Es ist nunmal so: die Entwickler um Firestorm arbeiten umsonst, das ist ihr Hobby und sie bekommen dafür gar nichts. Sie können tun und lassen, was sie wollen, und wenn sie keine Lust mehr haben, werden sie einfach aufhören. Fertig. Manchen Benutzern aber scheint in ihrem Anspruchsdenken das zunehmend aus dem Sinn zu entfliehen, denn sie halten sich für Kunden, die Ansprüche stellen können. Und das können sie nunmal eben nicht.

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.