Firestorm

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.

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.

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.

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.

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.

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:

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.

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.

Auch in Firestorm gibt es den praktischen Dialog, mit dem man sich Beacons aller Art anzeigen lassen kann, zum Beispiel wenn man herausfinden will, wer denn nun gerade da mit Sounds um sich wirft. Die dazugehörende Tastenkombination ist Strg+Alt+Umschalt+N. Sehr praktisch!

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!