Programming

Khufu Greymoon (der frühere Name war falsch!) hat sich heute hingesetzt und eine Forenbaustelle auf Basis von SMF als Software erschaffen, das nach meiner Info bereits für den Publikumsverkehr offen ist, und so sieht das Ding ausKhufu

Und so sieht bisher meine eigene Baustelle auf Basis von myBB aus:

Natürlich bin ich da völlig voreingenommen und finde mein Template tausend mal augenschonender und besser lesbar, außerdem habe ich nicht vor, irgendwelche Werbebanner von Virwox, Google Ads und sonst noch zu schalten. Weiß auf Grau ist einfach nur noch retro und dazu noch rot - nein danke.

So oder so - bei beiden hapert’s beim Namen. “Second Life Forum” ist bei mir ein ganz dummer Projekttitel, weil mir bisher nichts besseres eingefallen ist und “SL-Inside” beim anderen als Name ist auch schlecht, weil Avameet vor seiner Umbenennung Slinside hieß und das einfach nach wie vor zu Verwechslungen führen könnte.

In Slinfo.de gab’s mal wirklich einen interessanten Thread zum Thema Skriptscanner und deren Unwirksamkeit.

Das Fazit in Kurzfassung ist das folgende: die Anzahl der Skripte pro Avatar sagt absolut nichts darüber aus, welchen Einfluss diese auf die gesamte Simleistung haben werden.

Und selbst wenn jemand ein Killerskript schreibt, das Rechenleistung wie Sau zieht und das zigfach kopiert - schaut euch hier mal das Beispielskript von Shirley an - dann bringt das die Sim immer noch nicht aus dem Tritt, sondern sie läuft fluffig geschmeidig weiter, weil inzwischen Linden Lab offensichtlich intern die Abarbeitung der Skripte so gut geregelt bekommen hat, dass die Sim davon gänzlich unbeeindruckt einfach stur und gut weiter läuft.

Also, liebe Simbesitzer, werft endlich eure überflüssigen Skriptscanner ein für allemal raus, denn sie bringen absolut rein gar nichts - eure zukünftigen Besucher werden es euch danken!

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.

Auf der Mailingliste “Opensim Users” ist seit gestern durch eine Ankündigung von Snowcrash Short (nachzulesen hier) eine denkbar lebhafte Diskussion entbrannt.

Worum geht es? In Kurzfassung darum: Snowcrash Short hat angekündigt ein clientseitiges Tool zur Dezentralisierung von Benutzerinventaren zu schreiben, das er in zwei Wochen als Opensource veröffentlichen will.

Die Idee dahinter ist, dass das Inventar und die dahinterliegenden Assets vom Benutzer kontrolliert werden könnten. Es sei für ihn frustrierend, in X Grids X verschiedene Inventare zu haben. Zu diesem Zweck habe er ein Tool geschrieben, das das Inventar in einen lokalen Cache kopiert und dann in ein anderes Grid kopieren kann. Dabei sei es so geschrieben, dass es die Second Life Richtlinien für den Export beachte, es gäbe auch eine uneingeschränkte Version für Opensim.

Diese simple Ankündigung reichte schon aus, dass in der ansonsten recht friedlich vor sich hin dümpelnden Liste ein gewaltiges Echo ausbrach.

Nun ist es bald schon ein Jahr her (28.10.2011), seitdem die SL-Community 5,555 US$ ausgab, um durch Karl Stiefvater eine Lösung für das Problem mit dem automatische Anpassen der Meshes an die jeweilige Avatarstruktur in Auftrag zu geben.

Das Tempo seitdem war mal schneller und mal langsamer, Drittviewer wie Nirans bauten zuerst bei sich die jeweiligen Arbeitsfassungen des Deformers ein, und manchmal schien es als sei das Projekt auch auf der Kippe, als Oz Linden um Shapes bat aber ihm das nicht schnell genug ging.

Entgegen der ursprünglichen Befürchtungen ist die Unterstützung durch die Lindens doch recht gut gewesen, und es gab sogar einen offiziellen Project Viewer mit dieser eingebauten Technologie.

In der Zwischenzeit waren andere auch fleißig und so gibt es mindestens einen alternativen Ansatz, der auch funktionieren soll aber von dem meines Wissens außer den Ankündigungen der Macher bisher nur das Prinzip bekannt ist und man sonst wenig gesehen hat.

Sooo… nachdem die Meinungen zur neuen JIRA-Politik ein wenig auseinandergehen, noch einige Fakten: hat man nun als Entwickler noch Zugriff darauf oder nicht?

Tonya Souther von Firestorm sagt, sie habe keinen Zugriff mehr darauf. Katharine Berry dagegen sagt, sie habe aktuell sehr wohl Zugriff darauf

Wie geht das zusammen? Die Antwort darauf ist einfach: Linden Lab wird noch auch ausgewählten Entwicklern Zugriff auf das JIRA geben, genauer auf die Suche, die im Vorfeld das Contribution Agreement unterzeichnet haben. Die genauen Bedingungen werden nach Oz Linden zwar noch diskutiert, aber darauf wird es ziemlich sicher hinauslaufen nach seiner Aussage.

Ist das nun gut oder schlecht, dass sich zukünftig nur noch ein handverlesener Kreis an Auserwählten sich alle Fehlerberichte ansehen kann? Eindeutig schlecht, denn es macht die Entwicklercommunity kaputt!

Warum macht es die Community kaputt? Ganz einfach weil die Mehrheit niemals die Vereinbarung mit Linden Lab unterzeichnet hat und viele, gute Programmierer wie Henri Beauchamp das auch aus sinnvollen Überlegungen niemals tun werden.

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.

Eric S. Raymond verfasste und veröffentlichte 1996 einen der grundlegenden Essays zum Thema Opensource: “Die Kathedrale und der Basar.” In diesem beleuchtet er genauer die unterschiedlichen Vorgehensweisen zwischen kommerzieller Softwareentwicklung und Opensource.

Herkömmliche Softwareentwicklung ist dabei für ihn die Kathedrale: es gibt einen Chefarchitekten, der genau bestimmt, in welche Richtung hin sich die Entwicklung bewegen wird, und dieser leitet das Projekt unangefochten.

Im Gegenzug meint er, dass Opensourcesoftware nach einem anderen Modell entwickelt wird, das er den Basar nennt: da jeder zu einem Projekt beitragen kann, gibt es wenn die Entwicklerbasis für ein Projekt groß genug ist, verschiedene alternative Ansätze zur Lösung desselben Problems, aus denen sich der Projektleiter das seiner Meinung nach am Besten geeignete rauspicken kann - oder man baut einfach beide gleichzeitig ein. Nach Raymonds Meinung ist der Basar wegen seiner Vielfalt der Kathedrale deutlich überlegen. Als erfolgreiche Bestätigung für dieses Modell sieht er den Linux-Kernel an.

Bittorrent dürfte dem einen oder anderen ein Begriff sein, zumindest ab und an gehört hat man es sicher einmal, wenn man sich mit Computern beschäftigt. Angeblich ist es ja böse, vielleicht fallen einem dann dazu noch Sachen wie “The Pirate Bay” in Schweden ein, die massiv auf Bittorrent setzen und zu den prägenden Gestalten der Szene gehören. Andere wiederum sagen, Bittorrent selber sei legal, es kommt nur darauf an, wie man damit umgeht. Was aber nun ist Bittorrent eigentlich genau?

Bittorrent selber ist zunächst einmal ein Netzwerkprotokoll, das vom Amerikaner Bram Cohen erfunden wurde. Cohen dachte sich damals, dass die zunehmende Verbreitung von Breitbandanschlüssen ans Internet doch auch dazu genutzt werden könnte, um das Downloaden von Dateien vom Server auf die einzelnen Rechner zuhause zu verlagern. Das würde Zeit und Kosten sparen, wenn jemand große Daten der Allgemeinheit zur Verfügung stellen wolle, wie Filme, Programme usw.

Ein bekannter Vertreter war früher beispielsweise S.C.U.M.M. von Lucas Arts, in dem viele von deren berühmten Adventures (wie Monkey Island, Day of the Tentacle und weitere) programmiert worden sind. Heutzutage aber ist der bekannteste Vertreter dieser Art eindeutig Lua.

Wo kommt es her? Lua ist ursprünglich eine Entwicklung einer katholischen Universität aus Rio de Janeiro in Brasilien. Die Entwickler beschreiben Lua als schnelle, leichtgewichtige, mächtige und einbettbare Skriptsprache. Es ist sehr einfach möglich, Lua in beliebige Spiele als Skriptsprache einzubetten und dann zu benutzen. Der gepackte Download hat gerade einmal 182 Kilobyte und Lua selber ist in nur 20.000 Zeilen C-Code implementiert. Damit ist die Codebasis klein und überschaubar, also auch sehr gut wartungsfähig.