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.

Tastenkombination, um mit Firestorm den Beacons-Dialog zu sehen

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!

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.