Linden Lab verwirft mal wieder Jabber/XMPP

Tateru Nino zufolge hat Linden Lab – mal wieder – alle Bestrebungen aufgegeben, das bisherige gewohnt miserabel funktionierende Chatsystem durch Jabber/XMPP zu ersetzen.

Oskar Linden wird mit den folgenden Worten zitiert:

Our work on an XMPP solution for group chat was an investigation. We wanted to determine whether or not we could make something scalable and reliable that would replace our current chat architecture. XMPP didn’t do that for us.

Kurz und gut: die Arbeit an einer XMPP-Lösung diente der Erforschung der Möglichkeiten. Sie wollten herausfinden, ob sie damit etwas skalierbares und verlässliches schaffen können, dass die bisherige Chatarchitektur ersetzen kann. XMPP hat das für Linden Lab nicht geleistet.

Das letzte Mal, als man XMPP getestet habe, kam dabei heraus dass es Gruppen mit vielen Tausend Zuhörern nur schlecht bedienen konnte. Über die Gründe, wieso man XMPP erneut testete, kann nur spekuliert werden, entweder gab es einen neuen Ansatz oder man hat einfach nur die Resultate des letzten Tests nicht gelesen. Wie auch immer.

Die Frage ist nun, was Linden Lab anstelle dessen vorhat, um das seit Jahren bestehenden Ärgernis des oft schlecht funktionierenden Gruppenchats endlich mal aus der Welt zu schaffen und wann sie damit anfangen. Second Life ist nun einmal ein in erster Linie ein 3D-Chat, dessen wichtigste Grundlage – der Chat an sich – nicht immer zuverlässig funktioniert.

Verbindungsaufbau unter Firefox 4 beschleunigen

Eines der „Probleme“ bei der Einführung von Firefox 4 ist, dass die Verbindung im Vergleich zu Firefox 3 zuerst einmal langsamer geworden zu sein scheint.

Der Grund dafür ist einfach: es gibt inzwischen zwei Netzwerkprotokolle, IPv6 und das ältere IPv4. Firefox probiert zuerst einmal eine Abfrage bei IPv6, und wenn es dann keine Antwort gibt oder er eine Verbindung zu dem Rechner nicht aufbauen kann, schaltet er um auf IPv4. IPv6 ist in allen aktuellen Betriebssystemen mit dabei, werkelt unter OS X und Win 7 im Autopilotmodus vor sich hin, aber da das bisher kaum ein Provider wirklich nutzt noch weitestgehend nutzlos für uns. Im Fachbegriff nennt man das übrigens Dual-Stack-Betrieb.

Also ist es naheliegend, den Mechanismus einfach abzuschalten und so den Timeout zu umgehen. Das geht so: zuerst tippe man in der Adreßleiste „about:config“ ein und gelangt so ans Eingemachte. Dann suche man nach „network.dns.disableIPv6“, und wenn es den Eintrag nicht gibt, lege man ihn an. Der Typ muss dabei BOOLEAN sein, und schließlich setze man es auf TRUE – fertig. Das war’s dann schon gewesen.

OS 0.7.1 RC kommt wohl bald…

Justin Clark-Casey schreibt in seinem Blog aktuell dies:

I restarted work on reimplementing parcel prim counts, which had been disabled for performance reasons.  More to come next week.  This is the probably the last major item of work before OpenSim begins its release candidate process for 0.7.1.

Er arbeitet also aktuell gerade daran, den Prim Zähler (bei Landdialogen u.a.) in Opensimulator neu zu schreiben, der einige Zeit lang wegen Leistungsproblemen abgeschaltet gewesen ist. Mehr dazu nächste Woche, dies ist wahrscheinlich der letzte größere wichtige Punkt, bevor der Release Candidate Prozess für Version 0.7.1 beginnt.

Endlich! Das lässt darauf hoffen, dass bald die längst überfällige Version 0.7.1 von Opensimulator veröffentlicht werden wird.

Wenn weniger nicht mehr sondern zu wenig ist

Heute mal ein kleiner Post zum Thema Webbrowser: ich persönlich nutze nach wie vor Firefox, nun in der Version 4.0, am meisten. Das kommt daher, weil ich vor allem doch so einige Add-Ons im Browser nutze, Internet Explorer unter Linux nunmal nicht läuft, mir aber auch sonst nicht wirklich gefällt und Chrome von Google zwar inzwischen auch einen Haufen Erweiterungen hat, diese aber vom Reifegrad her dem Firefox noch stark hinterherhinken.

Mit dem Sprung von Version 3.6.x auf 4.0 wurde beim Firefox – manche sagen dazu leider – das Benutzerinterface ordentlich entrümpelt. Man hat vor allem zwei Sachen ausgebaut, auf die viele nicht verzichten wollen, als da wären:

Das Hypergrid-Desaster

Eines der schönsten Features am Opensimulator ist die Technik namens Hypergrid. Diese ermöglicht dezentrale Assetstores, man kann überall sein Inventar hin mitnehmen wo Hypergrid ist und es ist eines der Killerfeatures, die viele an Opensimulator schätzen gelernt haben. Man bewegt sich nahtlos von Grid A nach C über B und hat überall sein liebgewonnenes Inventar mit dabei. Eine schöne, feine Sache im Prinzip.

Nun ist es so, dass die erste Implementierung, auch gerne Hypergrid Version 1.0 genannt, mehr ein „Proof of Concept“ gewesen ist als schon wirklich für den Produktiveinsatz gedacht. Das macht im Prinzip erst einmal nichts, Opensimulator ist ja offiziell immer noch vom Status her als Alpha eingestuft und damit ist dort sehr vieles im Fluss. Oft schneller, als manchem lieb sein kann. Hypergrid v. 1.0 hatte vor allem eine Schwäche: ein externer Server konnte dem lokalen Server mal eben einfach so sagen „Lösche dies und jenes“ und er hat es getan, oder aber – weil er das gesamte Inventar sah – alles zu sich kopieren. Es soll auch Fälle geben, wo dies geschah – entweder aus Böswilligkeit oder aber einfach aus Programmierfehlern.

Jedenfalls ist das eine Sache, die in Hypergrid v. 1.5 behoben wurde. Auf dem externen Grid sieht man fortan nur noch einen Ordner „My Suitcase“, und in dem landen erst einmal alle Objekte, umgekehrt sieht das externe Grid auch nur diesen Ordner. Es ist also ein erster Ansatz an Sicherheit für das eigene Inventar, der bei Version 2.0 noch stärker ausgebaut werden soll. Das Hypergrid ist eigentlich für Content Creators, die das bisherige Geschäftsmodell von Linden Lab gewohnt sind, sowieso der absolute Albtraum.

Nun ist es aber leider so, das Hypergrid 1.5 mit dem letzten, offiziellen Release von Opensimulator v. 0.7.0 eingeführt wurde, aktuell ist 0.7.0.2, herausgekommen vor knapp sechs Monaten im letzten September. Seitdem aber drehte sich die Welt weiter und es gab im Hypergrid v. 1.5 noch diverse Fehler, die dazu führten, dass man das Protokoll modifizierte und anpassen musste. Die notwendigen Änderungen aber wurden nicht – wie man es normal erwarten würde – in eine Version 0.7.0.3 von Opensimulator eingepflegt, sondern sind nur im Bleeding Edge verfügbar.

Das führte dazu, dass sich Hypergrid 1.5 fragmentierte. Die einen Grids lassen nun Hypergrid v. 1.5i6 laufen, die anderen 1.5i7 – und da alle diese Versionen untereinander inkompatibel sind, heißt es für den Simbetreiber nun entweder oder.

Die Inkompatibilität ist wohl notwendig, da der Fehler selber zum Teil sich im Protokoll wiederfand. Schlecht ist es aber, das es bisher keinen Backport der aktuellen Hypergrid-Version auf das letzte, aktuelle Release gegeben hat. Andere Projekte handhaben so etwas normal besser, andererseits ist es hier eine Alpha-Software mit sehr wenig wirklichen Entwicklern bei der Arbeit, so dass sie vermutlich einfach die Zeit dafür nicht haben.

Dennoch: es ist und bleibt unschön, und ausbaden darf diese unnötige Fragmentierung letzten Endes der Benutzer der Software.

Singularity Viewer nun im TPV Directory

Es gibt ja Leute, die früher gerne den Ascent-Viewer nutzten, weil Phoenix entweder bei ihnen nur am spinnen war oder aus anderen Gründen. Nun geht die Entwicklung von Ascent momentan nicht mehr wirklich spürbar voran, was aber nichts macht, da ein Resident namens Siana Gearz Ascent geforkt hat und es nun unter dem Namen Singularity Viewer in Eigenregie weiter entwickelt.

Der Singularity Viewer will dabei, so lange als möglich, auf der Codebasis von Snowglobe 1.5.x bleiben und bringt natürlich alle Features mit, die Ascent auch schon hatte. Neu hinzugekommen sind aber u.a. die Unterstützung für Displaynamen, Multiattachments nach Linden-Art, Bugfixes für Opensim und einiges mehr. Vor kurzem wurde zudem Singularity auch ins offizielle Third Party Viewer Verzeichnis der Lindens aufgenommen.

Wenn also jemand mit Phoenix nur Probleme hat und sich mit Viewer 2.x partout nicht anfreunden will, für den könnte es sich lohnen, mal einen Blick auf diesen Viewer zu werfen. Es lebe die Vielfalt!

Second Life steigt bald auf Jabber um

Wir alle kennen das: Second Life wird in erster Linie ja als 3D-Chat angesehen, aber als Chat funktioniert es mitunter lausig. Schon der offene Chat laggt oft wie bescheuert, Gruppenkanäle sind häufig mehr unzuverlässig als sonst was und IMs kommen auch nicht immer unbedingt zuverlässig an. Kurz und gut: wer wirklich Wert auf Chat als solchen legt, der fühlt sich mitunter bei der Unzuverlässigkeit der Dienste in Second Life gehörig verarscht.

Die Lindens selber haben das auch – nach den bei ihnen üblichen Jahren – eingesehen und werden die im Hintergrund werkelnden Engine austauschen, die für den Chat zuständig ist. Zumindest die Gruppenkanäle wird das betreffen und als Basis wird dafür XMPP genommen, vielen auch besser bekannt als Jabber. Jabber ist ein offener, zuverlässiger und herstellerunabhängiger Standard für Chat, es gibt inzwischen sehr viele Clients dafür, wie z.B. Pidgin u.v.m., auch Google Talk basiert letzten Endes auf diesem Standard.

In einer Email vom 1. Februar schreibt dazu Gez Linden auf eine Frage von Latif Khalifa nähere Einzelheiten, als da wären:

  • der Umstieg wird bald erfolgen, allerdings wird kein näheres Zeitfenster genannt.
  • die Jabber-ID wird die Form von slid@chat.$gridname.lindenlab.com haben, wobei $gridname als Variable für das jeweilige Grid entsprechend zu setzen ist. Man soll SSL/TLS als Verschlüsselung einsetzen, da das Passwort im Klartext übertragen wird (was einen Man-in-the-middle-Attack ermöglicht),
  • die neue Implementierung wird zuerst auf dem Grid Aditi, also dem üblichen Betagrid getestet werden,
  • die Implementierung der Gruppenkanäle wird auf dem Standard Multiuserchat nach XP-0045 basieren, und auch nicht uninteressant
  • als Nebeneffekt der Implementierung, das ist keines der vorrangigen Ziele, werden reine Jabber-Clients wie Pidgin am Gruppenchat teilhaben können. Sie seien aber noch am Überlegen, wie Chat in Zukunft genau aussehen soll, von daher sollte man dies als experimentell und „subject to change“ ansehen.
  • Ebenso wird es ein Übergangssystem zwischen dem alten und neuen System geben, wobei dies noch nicht genauer erläutert wird, wie dies funktionieren solle.

Alles in allem: YEAH! Endlich hat man ein Einsehen und bringt das Chatsystem auf den aktuellen, zuverlässigen Stand der Technik und sollte Linden Lab nicht das Rad gänzlich neu erfinden, sondern stabil laufende Server wie z.B. ejabberd dafür einsetzen, die schon auf einen normalen Rechner in der Lage sind, tausende Benutzer zuverlässig zu bedienen und Cluster zu bauen, dann wird das mal zur Abwechslung eine richtig gute Sache. Ich bin jedenfalls gespannt.

Idee: Despammer für Phoenix Firestorm

Wir alle kennen das doch: wer viel einkauft oder unterwegs ist, wird nach dem Betreten von Shops, meistens schon Sims mit diversem Gruscht regelrecht zugemüllt. Seien es Landmarken, Notecards, Gruppeneinladungen, man bekommt alles mögliche, immer und immer wieder und es nervt einfach nur. Lesen tue ich diese Sachen sowieso nicht mehr, sondern klicke es einfach nur noch weg.

Wieso sollte man diese Arbeit nicht den Viewer direkt für einen erledigen lassen können? Das sollte doch recht einfach machbar sein und wäre eine große Erleichterung für uns alle, so meine Idee, fast schon ein Killerfeature in meinen Augen, das das In World Erlebnis für viele stark aufwerten würde.

Also habe ich mich hingesetzt und im JIRA von Phoenix das als neue Feature-Idee für Firestorm unter dem Key #FIRE-527 eingereicht. Mal schauen, was daraus werden wird, ich bin ja gespannt…

Previewversion von Firestorm veröffentlicht

Die Macher vom Phoenix Viewer haben eine Previewversion ihres Next Generation Viewers Firestorm veröffentlicht. Die notwendigen Infos dazu sind hier:

Release notes are here.. please read them! http://wiki.phoenixviewer.com/doku.php?id=firestorm_preview_1_release_notes

Windows: http://downloads.phoenixviewer.com/windows/Phoenix_Firestorm-preview_2-4-1-14579_Setup.exe
Mac: http://downloads.phoenixviewer.com/Mac/Phoenix_Firestorm-preview_2_4_1_14577.dmg
Linux: http://downloads.phoenixviewer.com/Linux/Phoenix_Firestorm-preview_i686_2.4.1.14577.tar.bz2

Wichtig dabei: das sind offizielle Builds vom Phoenix Team. Diese Previewversion hat noch nicht mal den Status eines Alpha-Release. Das heißt, neben bekannten Fehlern kann sie auch einen Haufen unbekannter Fehler enthalten sowie viele Funktionen sind bisher nicht verfügbar. Allerdings reicht es mehr als aus sich mal ein Bild darüber zu machen, wie diese Version im Vergleich zum normalen Viewer 2.x bisher aussieht.

Anleitung: wir basteln uns einen Phoenix Viewer unter Windows

Intention

Dieser etwas länglichere Artikel handelt darüber, wie man auf einem unter Microsoft Windows laufenden Rechner (ab Windows XP bis Windows 7) sich selbst einen 32 bit Second Life Viewer aus dem öffentlich zugänglichen Sourcen kompilieren kann, hier in dem Fall Phoenix. Da es so etwas bisher auf Deutsch nicht zu geben scheint, kann es mal nicht schaden, das hier skizzenhaft zu dokumentieren.

Die dazu nötigen Programme samt dem Compiler von Microsoft sind dabei allesamt kostenlos erhältlich, so dass man außer etwas Zeit und Geduld nichts weiter investieren muss.

Einige Worte in eigener Sache vorweg und was man an Wissen braucht

Das Kompilieren eines Viewers ist nichts alltägliches und da Windows ohne einen Compiler daherkommt, muss man erst einmal die Buildumgebung einmalig installieren. Das braucht einiges an Zeit, Zeit um die Programme herunterzuladen und auch noch zu installieren.

Diese Anleitung setzt dabei gute Kenntnisse von Microsoft Windows inklusive des Dateisystems und dessen Kommandozeile voraus, auch sollte man grob wissen was ein Compiler ist und dieser so tut! Wem es zu mühsam ist, teilweise unter Windows  auf der Kommandozeile zu arbeiten sowie erst einmal einen Haufen Programme installieren zu müssen und auch sonst schon wenn der Drucker mal wieder streikt, den Sohnemann/Nachbarn rufen muss, weil er das nicht selber schafft und für wen Anleitungen im WWW immer nur böhmische Dörfer sind, für den ist diese Anleitung definitiv nicht gemacht!

Mit Hilfe dieser Anleitung wird der sog. „Bleeding Edge“-Code aus dem Quellcode-Repository von Phoenix kompiliert. Bleeding Edge bedeutet, dass dieser Code fehlerhaft sein kann und das oft auch ist, möglicherweise nicht einmal bis zum fertigen Programm kompiliert und auch ansonsten schlimme Sachen passieren könnten. Wenn also Aliens kommen sollten um deine Festplatte aufzufressen, dann wasche ich meine Hände in Unschuld!

Daher: Benutzung und Durchführung ausschließlich auf eigene Gefahr! Wer Angst um seinen Computer oder seine Daten hat, der möge vorher ein Backup anfertigen (auch wenn normal nichts dergleichen passiert, ist ein Backup zu haben immer eine gute Idee!) Wer Angst um seinen Avatar hat, weil er mit einem eigens gebauten Viewer nach Second Life Verbindung aufbaut, der soll es einfach gleich sein lassen oder nur zu Opensim konnektieren.

Übrigens: ich bin für Kommentare und Verbesserungsvorschläge immer dankbar, aber nicht Willens noch in der Lage in dieser Angelegenheit Support in irgendwelcher Art zu leisten. Ich habe schlicht und einfach nicht die Zeit dafür euch beim Einrichten einer solchen Umgebung zu helfen noch sonst wo nachzuschauen, wenn es bei euch mal klemmt, werde den Artikel aber längere Zeit pflegen.

So, wenn ihr nach dem ganzen Sermon noch immer mit dabei seid und euch das nicht abschreckt, dann legen wir mal los, ihr furchtlosen Recken! Mehr erfahren