Programming

Ich hatte neulich in der SL-Gruppe “slinfo.de” eine Diskussion darüber, wie man Computer beschleunigen kann, die den Second Life Viewer benutzen. Neben den üblichen Verdächtigen, in Reihenfolge der Wichtigkeit: Grafikkarte, mehr Hauptspeicher, besserer Prozessor - empfahl ich den Einbau einer kleinen SSD, um darauf den Viewer-Cache zu speichern.

Der Grund liegt einfach darin, dass der Viewercache bei 1 GB typischerweise aus ca. 20.000 Dateien besteht und man bei dem Cache nach einem Neustart, wenn man in Second Life einloggt und auf eine seiner Stammsims geht, die Limitierung der Festplatte merkt.

Eine Festplatte hat nunmal typischerweise eine Zugriffszeit von 6-8 ms, eine Sekunde sind 1000 ms, das bedeutet wenn die Festplatte exklusiv nur für den Viewer arbeitet (was sie normal nicht macht), dann schafft sie es in einer Sekunde im Bestfall 1000/8 = 125 verschiedene Texturen zu laden.

Eine SSD ist mindestens um den Faktor 10 schneller und damit für solch ein Konstrukt wie lesende Zugriffe auf einen vollen Cache nunmal die erste Wahl.

Bei all dem Gerede über Oculus Rift ist mir bisher eine Technologie weniger aufgefallen, die einfacher einzusetzen ist und auch die Handhabung eines Rechners ordentlich auf den Kopf stellt, nämlich Leap Motion.

Nun, was ist das? Einige mögen vielleicht Kinect von der Xbox kennen, eine Sensorphalanx, mit der man seine Xbox einfach per Körperbewegungen steuern kann. Nun stellen wir uns mal diese Sensoren ordentlich verkleinert und in einer Computertastatur eingebaut, dann haben wir Leap Motion. Es ist im Grunde der Computersteuerung sehr ähnlich, die manche im Scifi-Film “Minority Report” sahen, nur mit dem Unterschied, dass man dazu keine Handschuhe anziehen muss und die Technik bereits heute verfügbar ist und gerade damit angefangen wird, sie in manchen Notebooks serienmäßig einzubauen.

Ein Video sagt mehr als tausend Worte, und es gibt schon seit über einem Jahr im Second Life Viewer von Linden Lab eine eingebaute Unterstützung für Leap Motion. So sieht das dann eben aus:

Bitcoin ist ja gerade ein Hype, wie er im Buche steht und das wird momentan immer schlimmer. Angeblich zittern ganze Staaten vor dieser digitalen Wunderwährung, die sie nicht kontrollieren können und was weiß ich noch alles. Alles Käse - Bitcoin ist ein interessantes Experiment ohne besonders praktischen Wert, nicht mehr, aber auch nicht weniger.

Doch was ist Bitcoin eigentlich? Zum einen eine nach oben hin künstlich gedeckelte digitale “Währung”, zum anderen ein verteiltes Finanztransaktionsprotokoll im Bereich Micropayments. Die Transaktionen sind dabei der eigentlich interessante Teil, denn für so etwas gibt es nun wirklich Bedarf und hier ist ein Weg gezeigt worden, wie das geht. Die Frage dabei ist natürlich, wie gut das für zig Millionen skalieren würde, das wäre vermutlich ein Desaster.

Die Währung dagegen ist ein astreiner Fehlschlag. Bitcoin hat eine eingebaute Deflation, weil die maximale Geldmenge künstlich gedeckelt ist. Warum heute eine Ware für 1 Bitcoin kaufen, wenn man sie in vier Wochen auch für 0,50 Bitcoins bekommen könnte? Also hocken viele lieber auf ihren Coins, anstelle sie auszugeben.

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.

F: Auf welchem Quellcode basiert dieser Viewer?
A: Er basiert auf dem unter http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/ öffentlich verfügbaren Code. Er wurde mit Hilfe von Microsoft Visual C++ Express 2010 kompiliert und es handelt sich dabei um die 32bit-Variante des Viewers.

F: Gibt das Firestormteam nicht selber Nightly Builds heraus?
A: Nein, das haben sie noch nie.

F: Warum bietet das Firestormteam nicht selber einen Nightly Build zum Download an? Andere Viewer, wie beispielsweise Singularity, machen das doch auch!
A: Es ist keine Frage des Könnens, sondern des Wollens. Das Entwicklerteam vom Firestormteam will keine solchen Builds veröffentlichen. Wer es genau wissen will, der kann es unter http://modemworld.wordpress.com/2013/02/19/firestorm-meeting-13th-february-2013-video-and-transcript/7/ auf Englisch nachlesen. Jessica Lyon begründet es mit mangelnder Qualitätskontrolle. Nightly Builds sind das, was man auf Englisch als das Bleeding Edge bezeichnet. Es handelt sich dabei von der Qualität her nicht einmal um Alphaversionen. Ein Nightly Build kann funktionieren, muss aber nicht, und keiner wird garantieren, dass alle Funktionen richtig oder fehlerfrei funktionieren und man muss schlimmstenfalls auch mit Fehlern rechnen, die Datenverlust nach sich ziehen könnten.

Ich habe heute in irgendeinem Kanal in Second Life - welcher, spielt keine Rolle - interessante Neuigkeiten über den Firestormviewer (oder war es der normale? Egal!) gehört.

Und das ging so: der Viewer käme bald in 64bit raus, und dann würden endlich die Texturen in HD rendern und viel klarer zu sehen sein als bisher. Ja holla, so viel Schwachsinn kreativer Wissensdrang auf einem Haufen war dann doch schon ein wenig zu viel, da musste ich dann einfach dagegen halten.

Zunächst mal bedeutet 64bit-Viewer nichts anderes, als dass der Viewerprozess mehr Speicher als bisher adressieren kann und es ggf. auch ein wenig flotter läuft. Aber was bedeutet es für die Grafik? Die Bilder in Second Life sind allesamt im Format JPEG2000 gespeichert. Die offiziellen Viewer benutzen dabei die Bibliothek dazu von der Firma Kakadu, manch anderer Openjpeg.

Die Bildkomprimierung in Second Life ist dabei verlustbehaftet, reversibel und vor allem qualitätstreu. Sprich, wenn man ein Bild einmal komprimiert hat und es mit derselben Routine tausend Mal dekomprimiert, dann kommt dabei immer wieder genau dasselbe Bild heraus. So und nicht anders arbeiten nun einmal Computer, sie sind berechenbar. Ob dabei die Routine in 32bit oder 64bit läuft, spielt dabei keine Rolle, die Qualität ist dabei absolut dieselbe.

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.

Habt ihr es bemerkt? Nach dem ursprünglichen Plan von Microsoft hätte Windows 7 bereits ab Ende Oktober 2013 nicht mehr verkauft werden sollen. Aber im Gegensatz zum ursprünglichen Plan kann man die Retail-Lizenzen nach wie vor verkaufen und das Ende der Lebenszeit ist “to be determined”, also sie denken nun darüber nach, wann es offiziell der Fall sein wird.

Anders gesagt: Microsoft hat damit endlich eingesehen, dass Windows 8 Schrott ist und dies keiner wirklich haben will. Da ab April 2014 der Support für Windows XP endet, stehen nun langsam viele Firmen vor dem Problem, auf welches Windows sie umsteigen sollen. Windows XP hat schließlich schlappe 13 Jahre gehalten und damit viel länger, als ursprünglich geplant und gedacht.

Alle Firmen jedenfalls, die ich persönlich kenne, wollen dabei auf Windows 7 umsteigen. Windows 8 ist ihnen zu zappelig, krank zu bedienen und fremdartig. Windows 7 hat damit beim momentanen Stand der Dinge das Zeug zum neuen Ewig-Windows und wird damit ziemlich sicher nun Windows XP ablösen. Endlich hat auch Microsoft das eingesehen, bleibt nur zu hoffen, dass Windows 9 wieder besser werden wird.

Google hat heute Chrome Version 30 veröffentlicht. Die interessanteste Neuerung daran ist, dass es ab sofort WebGL unterstützt.

Warum ist das interessant? Ganz einfach, weil Cloudparty darauf basiert. Es könnte also nun sein, dass man ab jetzt Cloudparty auf Android-Tablets laufen lassen kann. Chrome für Android ist nun offiziell jedenfalls soweit.

Einfach mal so, gerade weil mir danach ist, ein kleiner Exkurs zum Thema “Dateisysteme unter Linux.” Das sind die Arbeitspferde, die im Hintergrund eines Betriebssystems hoffentlich unbeachtet ihren Dienst tun. Sollten sie mucken, dann ist es wie Zahnschmerz: besser, man hat ihn nicht.

Zunächst einmal: was ist ein Dateisystem? Das ist eine Ablageorganisation für Dateien auf einem Datenträger (Festplatte, Bandlaufwerk, CD-Rom, Diskette…) des Computers. Es ist eine Abstraktionsschicht zwischen der Hard- und der Software: Dateien/Ordner müssen angelegt, umbenannt und gelöscht werden können. Die Dateien können dabei von sehr klein (einige wenige Bytes) bis sehr groß (mehrere Gigabyte und mehr wie bei Videos) im selben Dateisystem schwanken. Für unterschiedliche Einsatzzwecke gibt es dabei unterschiedliche Systeme.

Linux als quelloffenes Betriebssystem kommt dabei, im Unterschied zu Windows das im Grunde nur mit NTFS arbeitet, von Hause aus mit einer Myriade an unterschiedlichen Systemen daher. Hier nun in einigermaßen chronologischer, kurzer Auflistung die Wichtigsten.

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.