Schlagwort: viewer

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.

Die rabiate Phoenix-Fanbase und noch ein paar Statements von Henri Beauchamp zum Thema Serverside Baking

Am 17. Dezember 2012 verkündete das Phoenix-Team das Ende der Entwicklung des beliebten Phoenix-Viewers. Die Gründe dafür sind unter anderem, dass man nicht mehr weiterhin zwei unterschiedliche Codebasen pflegen will und 2013 neue Features wie Serverside Baking erscheinen werden, die ohnehin die Kompatibilität mit der 1er-Viewercodebasis brechen werden.

Festzuhalten dabei ist: man kann seinen Phoenix noch weiterhin benutzen, die Entwicklung aber wurde Ende 2012 eingestellt. Eine lange überfällige Ankündigung, bei der man förmlich die Freude des Teams, endlich diesen Zombie losgeworden zu sein, spüren könnte. Die Reaktionen auf den Post sind zweigeteilt: die einen haben absolut kein Problem damit, und sich beim Phoenix-Team für all die Arbeit bedankt, sie nutzen in Zukunft nun entweder eben Firestorm, Singularity oder den Cool Viewer. Andere aber tun so, als sei dies der Untergang des Abendlandes und überziehen das Team mit überbordender Häme und Flames.

Diese Flamer haben dabei offensichtlich nicht verstanden, was Opensource ausmacht. Opensource heißt, du kannst den Code nehmen und damit im Rahmen der Lizenz machen, was du willst. Es heißt aber nicht, dass nun die Entwickler eines Projekts unentgeltlich nach der Pfeife ihrer Benutzer tanzen müssen und machen müssen, was die wollen. Wenn die Entwickler keine Lust mehr haben, etwas weiter zu entwickeln, dann ist das eben so und fertig. Dann kann man entweder selber die Initiative ergreifen und da weitermachen, oder lebt damit und lässt es eben sein. Punkt, aus, fertig!

Alles in allem sind aber die anhaltenden Flames der Phoenixfanbase mit bisher 178 Kommentare im Blogpost oben dermaßen überzogen, dass sich die Entwicklerin Tonya Souther zu dem Kommentar „Go ahead, fork Phoenix!“ hinreißen ließ. Souther beschreibt die Codebasis des Phoenix-Viewers als hoffnungslos veraltet, dass es schon massiver Arbeit bedürfe, alleine das Meshrendering auf den Level von 3.4 zu bringen – es basiere noch auf Viewer 2.8.

I’m not kidding when I say it’s an unmaintainable tissue of hacks held together by spit, chewing gum, duct tape, and baling wire.

Ich übertreibe nicht, wenn ich sage, dass es [Phoenix] eine unwartbare Masse an Hacks ist, die von Spucke, Kaugummi, Tesafilm und losen Drähten zusammengehalten wird.

Das Zitat lässt dann schon tief blicken, und weil die Fanbase so rabiat weiterhin auf Phoenix pocht, soll sie doch den Mist einfach übernehmen, warten und fertig. Der Rest könne ja mit Singularity oder dem Cool Viewer glücklich werden.

Kurz: Undank ist wohl der Welten Lohn und manche Hohlpfosten fordern da von Freiwilligen eine Arbeitsleistung ein, auf die sie kein Recht haben das einzufordern. Klar, dass da einem schon mal die Galle überlaufen kann.

Übrigens schwebt über all diesen Probleme Henri Beauchamp, denn der bastelt ja nach wie vor an seinem eigenen Viewer, dem Cool Viewer, alleine. Diesen entwickelt er vor allem für sich selbst und wenn jemand Gefallen daran hat, bitte, kann er ihn gerne nutzen. Beauchamp gibt an, über 35 Jahre Programmiererfahrung zu verfügen und dementsprechend kein unbeschriebenes Blatt zu sein.

Gut, Beauchamp hatte mal wieder Langeweile, und daher kann die aktuellste Version vom Cool Viewer bereits Server Side Baking. Ein Feature, das der Phoenix-Viewer nie mehr bekommen wird, es sei denn jemand macht einen Fork und nennt den dann anders. Der Cool Viewer ist damit der erste TPV, der dieses Feature offiziell unterstützt.

Übrigens gibt’s zu dem Thema auch noch eine launige Mail von Beauchamp in der Entwicklerliste an Oz Linden, die es in sich hat. Beauchamp wirft Linden Lab in Sachen Opensource schlichtweg Vollversagen vor, anders kann man es nicht nennen. So schreibt er dies:

I’d rather not judge „Oz, the man“ because it is hard to tell whether his actions are the only result of his own decisions and doings, or are the materialization of LL’s policy towards OpenSource and, if we can judge from the resulting actions their policy would clearly be: „take benefit of all the advantages OpenSource can bring to us (i.e. free coding and debugging horsepower provided by volunteering developers), and dismiss all the duties OpenSource cooperation involves in return (such as providing clean diffs for changed we made behind closed doors(*) before releasing them, but also providing an *open* list of known bugs to developers)“.

Kurz und gut: Linden Lab würde gerne die Vorteile der Community wie kostenlosen Code und Debugging abgreifen, dafür im Gegenzug aber nicht mal die grundlegendsten Selbstverständlichkeiten an die Community, wie eine offene Liste der bekannten Bugs, zurückliefern. Eine Klage, die nun überhaupt nicht neu ist, sondern genau so schon Nicholaz Beresford vor fast fünf Jahren formulierte. Linden Lab bleibt also sich und seiner Linie treu. Das Hauptproblem von Linden Lab sei, dass sie hinter verschlossenen Türen monatelang neues Zeug entwickeln würden und dann – BUMM! – ist es auf einmal eben da. Das sei nicht die Art und Weise, wie Opensource funktioniere, und vor allem käme da Linden Lab seinen Pflichten nicht wirklich nach…

Daran angehängt ist eine Email von Beauchamp an Oz Linden vom Juli 2012, in dem sich Henri lange und breit darüber auslässt, wieso er die Art der Implementierung – basierend auf dem „Current Outfit Folder“ für eine denkbar schlechte Idee hält.

Und jetzt, wo die ersten Testimplementierungen da sind und das Feature offenkundig so bockt wie Beauchamp voraussagte, zeigt Beauchamp denen mit Freuden den Stinkefinger und sagt dazu: „Ich habe es euch doch gleich gesagt!“ – Tja, und er hat damit sogar noch Recht, aber Linden Lab wollte ja nicht hören…

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!

Da liegt sie nun, die Hoffnung der Meshfreunde und ist doch noch nicht das, was man sich erhofft hat…

Dieser obige Gedanke kam mir, als ich bei Maddys Wochenumschau die Neuigkeiten von Nalates Urriah in Bezug auf den Mesh Deformer gelesen habe.

Nun, was ist geschehen?
Zunächst einmal die gute Nachricht: es wird nach wie vor am Mesh Deformer mit Hochdruck gearbeitet und die Entwicklung geht offenkundig weiter, auch wenn man davon in der Öffentlichkeit momentan weniger mitbekommt, so stehen die Räder da dennoch nicht still. Das ist schon mal eine gute Sache, vor allem wenn man auch bedenkt, wie lange dieses Feature nun bereits in der von SL-Bewohnern finanzierten Entwicklung steckt! Wer zahlt, der will schließlich auch irgendwann etwas dafür sehen, und man sieht es auch!

Wo liegt das Problem?
Das Problem liegt nach Nalates Urriah darin, dass der sagenhafte Mesh-Deformer momentan vor allem auf älteren Rechnern das Tempo einer Weinbergschnecke vorlegt im Bereich seiner Berechnungen.

Die Avatare werden nacheinander, also seriell, abgearbeitet und die Kalkulationen sind sehr umfangreich. Die Zeit, die sich dann ein älterer Rechner gönnen soll bis er mit Deformieren fertig ist, soll im Bereich von mehreren Minuten liegen und das ist einfach für ein fluffiges SL-Erlebnis viel zu lange.

Wer neuere Rechner hat, der soll das Problem nicht haben. Nun wird darüber spekuliert, dass das Problem auch daher rühren könnte, dass der Deformier-Thread im Viewer eine recht niedrige Priorität habe und ein Anheben diese das Problem beseitigen könne. Ich bin mir sicher, das wird ein TPV-Entwickler sehr flott ausprobiert haben.

Der andere Vorschlag, der gefallen ist, ist dass das Deformieren auf SL-Servern stattfinden solle wie in Zukunft auch das Texture Baking für die Avatare, so dass die Clients damit nichts mehr zu tun haben. Die Wahrscheinlichkeit aber, dass dies realisiert werden wird, ist dann doch recht gering.

Was bleibt?
Es klingt alles schlimmer, als es in Wirklichkeit ist. Ich bin mir sicher, der Deformierer wird nun erst einmal getuned werden und man wird schon versuchen Mittel und Wege dafür zu finden, seine Arbeitsweise zu beschleunigen. All das wird noch ein wenig Zeit und Arbeit erfordern, aber findet sicher schon statt und dann irgendwann wird er vielleicht doch einmal Ready for Prime Time werden. Im Moment ist er es offenkundig als Baustelle jedenfalls noch nicht.

Und wer dann eben einen älteren Rechner haben sollte, der wird dann unter Umständen eben Pech haben. Das mag zwar hart klingen, aber so ist das Leben.

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.