Programming

OpenGL, so sollte man meinen, habe eine prachtvolle Zukunft vor sich: immerhin ist es ein offener Industriestandard, auf jeden Fall aber der Standard auf jedem Iphone/Ipad, Android-Telefon und Macintosh. Damit wird es zahlenmäßig gesehen an Microsofts DirectX (Xbox, Windows und Windows-Phones) weit vorbeiziehen. Aber weit gefehlt!

Ein Entwickler von Valve, Rich Geldreich, befasst sich aktuell in seinem Blog genauer zum Zustand von OpenGL und dessen Treibern. Das ist interessant, da Valve ja zum Bau seiner eigenen Konsole Steam Box auf Linux und damit OpenGL setzt - die haben also nichts gegen OpenGL, im Gegenteil, die finden es toll und liefern momentan ein Opensource-Produkt nach dem anderen ab, um damit besser arbeiten zu können.

In dem Artikel “Dinge, die mich bei OpenGL in den Wahnsinn treiben” schreibt denn auch Geldreich sehr plastisch, wo es denn bei OpenGL hakt. Das ist auf Englisch geschrieben, aber durchaus mal das Lesen wert.

Btrfs wird ja unter Linux als das nächste, große Standarddateisystem angesehen. Es ist so eine Art “running gag”, jedenfalls ist es noch in der Entwicklung und wird als in zwei bis drei Jahren als möglicherweise stabil genug für den Alltagseinsatz angesehen.

Btrfs ist dabei ein Copy on write-Dateisystem und die Featureliste liest sich so, als habe man da fröhlich bei ZFS von Sun abgekupfert. Btrfs wurde ursprünglich von Oracle entwickelt, dann kauften die Sun und haben seitdem auch die Rechte an ZFS, nun wird es extern entwickelt. Wie auch immer.

Btrfs liest und fühlt sich wie eine schlechte Kopie von ZFS an. Da kann man auch besser gleich zum Original greifen, das stabiler ist, mehr Features hat und für den Produktionseinsatz bereit ist.

Beispiele gefällig, wieso ZFS saugt?

• df unter Btrfs lügt und zeigt nicht den freien Plattenplatz an. Dumm aber, wenn es Skripte/Programme geben sollte, die auf die Ausgabe von df vertrauen. Der notwendige Befehl lautet “btrfs filesystem df /”. Ein Unding.
• Btrfs ist im Vergleich zu Ext4/XFS in den meisten Fällen schnarchlangsam.
• Btrfs ist für den Betrieb von Datenbanken oder virtuellen Maschinen denkbar ungeeignet. Dafür nimmt man besser Ext4 oder gleich XFS.
• Tree Balancing, also das Verteilen von Daten über mehrere Festplatten, kann durchaus einen Tag oder länger dauern.
• Es besteht noch immer die geringe Möglichkeit, dass sich wenn ein Fehler gefunden werden sollte, das On-Disk-Format geändert werden muss.

Wirklich ein dolles Ding, dieses Btrfs. Wer unter Linux solch ein Dateisystem nutzen will, der sollte besser gleich zu ZFS on Linux greifen.

Dies hier ist die aktuelle Systemarchitektur von Philip Rosedales virtueller Welt der nächsten Generation, High Fidelity:

Wie man sehen kann, ist diese extrem dezentral aufgebaut. Alles unter “Global Services” wird von High Fidelity Inc. betrieben, der Rest von jedem, der mag. Ein mögliches Geschäftsmodell wird sein, so stelle ich mir das vor, dass die Firma dann einem die virtuelle Identität “verkauft”, also genauer die Verwaltung, sofern man die Systeme über deren Server laufen lässt. Oder beispielsweise deren Marketplace nutzt.

Ich stelle mir das so vor: grundsätzlich ist alles kostenlos möglich, aber wenn man bestimmte zentrale Dienste von HiFi nutzen will, dann muss man für deren Benutzung eben bezahlen. Von irgend etwas will die Firma ja schließlich auch denn leben können.

Das muss man aber nicht unbedingt tun, denn der Sourcecode für alle wichtigen Komponenten liegt bereits unter der Apache Software License 2.0 auf Github vor und kann von jedem, der mag, genutzt werden. Also kann man auch seine eigenen Inselchen bauen und damit glücklich werden.

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:

Ab heute ist es ja soweit: die Mailproviderschwergewichte T-Online, GMX, Web.de und Freenet stellen im Bereich der Email auf die sog. Transportverschlüsselung um. Es gibt sogar im Web das Äquivalent zu einer PR-Buzzword-Hochglanzbroschüre, um den Leuten Sand in die Augen zu streuen, namens “E-Mail made in Germany.”

Email in Deutschland für Deutschland wird also nun endlich, endlich sicher. Auf dem Transportweg, die wie Provider schreiben, aber welcher Laie kann schon beurteilen, was das genau bedeutet oder eben auch nicht. Viele Emailnutzer, die ich kenne, sind in Sorge, dass sie ohne Umstellung ihre ach so wichtigen Emails nicht mehr bekommen könnten und mit der Umstellung total überfordert, sie wissen einfach nicht, wieso, weshalb, warum und was der ganze Zinnober soll.

Genau für solche Leute ist die Umstellung eigentlich gedacht, aber genau diese Leute verstehen es auch einfach nicht, was das soll und die meisten werden es auch nicht begreifen wollen. Für die ist Email einfach ein alltäglich benutztes Kommunikationsmedium, das out of the box zu laufen hat und wehe, daran könnte sich einmal etwas ändern. So und nicht anders sieht es da aus.

Facebook kauft Whatsapp für 19 Milliarden Dollar. Nun überlegen also viele angeblich, auf andere Messenger zu wechseln, weil sie die Daten bei Facebook nicht sehen wollen. Nun ja, wie es immer bei so etwas ist, wird das in den Medien hoch gepusht und in Wirklichkeit wird es 98% der Kunden nicht weiter interessieren, die werden bei Whatsapp bleiben und fertig.

Whatsapp ist wie ein Fax: es lebt von der Masse seiner Benutzer. Andere Apps mögen noch so schön sein in dem Bereich, wenn sie nicht die Masse erreichen, dann sind sie nutzlos.

Und nun wird ausgerechnet ein Produkt namens Threema aus der Schweiz gepusht mit dem Versprechen “Wir verschlüsseln alles und sind damit sicher!”, das auch Geld kostet und sich auf dem Papier erst einmal gut liest. Nur, wie kann man da sicher sein? Selbst, wenn man dem Hersteller die besten Absichten unterstellt, so läuft es in Wirklichkeit darauf hinaus:

Also manchmal verstehe ich es einfach nicht, was in den Köpfen von Softwareentwicklern vorgeht. Irgendwie dreht sich in den letzten Jahren alles um das Thema Tablet und Vereinfachung der Benutzeroberflächen. Das ist im ersten Augenblick auch in Ordnung, wenn man dem Benutzer die Möglichkeit lässt, sein Programm so einzurichten, wie er es mag. Aber genau diese Wahlmöglichkeit nehmen die Entwickler einem häufig, die Ergebnisse gleichen sich häufig erstaunlich, und von den Fehlern der Vorgänger lernen? Fehlanzeige!

In Second Life war das der unglückliche Viewer 2, sozusagen das Vista von Linden Lab. Außer Haus entwickelt, eine nette Idee, aber total katastrophal und mit vielem Zeug wie Webprofilen, die keiner wirklich braucht. Kein Wunder, dass Firestorm da wohl nach wie vor der Marktführer ist.

Oder im Bereich der freien Software muss man sich nur mal GNOME anschauen. GNOME war bis zur Version 2.X unter Linux der beliebteste Desktop, doch dann erschien im Herbst 2010 die Version 3.0. GNOME 3.0 war, kurz gesagt, ein völliger Umbau, der dem Benutzer viele Wahlmöglichkeiten nahm. Aber genau diesen Wegfall pries man dem Nutzer noch als Fortschritt an und GNOME 3.0 würde sicher gut funktionieren, wenn es denn ein GNOME-Tablet geben würde. Das gibt es aber bis heute nicht, die Hauptanzahl seiner Benutzer sind nach wie vor klassische Desktopmausschubser und für die war GNOME 3.0 ein sofortiges Hassobjekt. Davon hat sich GNOME bis heute nicht erholt, die Benutzer verließen scharenweise das sinkende Schiff und selbst Debian hat GNOME als Standarddesktop rausgeworfen.

Eines der Nadelöhre in der Architektur jedes Second Life Viewers ist sein Cache auf der Festplatte. In dem Cache legt der Viewer sowohl die dargestellten Texturen als auch der Objekte einer Sim ab. Klingt erst einmal nicht dramatisch, aber das hat seine Konsequenzen, die in der Natur der Festplatte liegen.

Nun ist es so, dass die meisten Texturen abgelegt auf der Festplatte für sich alleine nicht viel Speicherplatz benötigen. Ein typischer Cache-Ordner besteht aus 10000-30000 Dateien. Es sind eben pro Sim schon sehr viele Texturen, die ihren Weg auf die Festplatte finden, und damit greift dann letzten Endes die Festplatte als Nadelöhr.

Jedes moderne Betriebssystem ist sich der Tatsache, dass der Zugriff auf die Festplatte um Längen langsamer als auf den Hauptspeicher ist, bewusst. Deswegen nutzt jedes Betriebssystem automatisch den nicht durch Programme genutzten Teil des Hauptspeichers als Schreib-Lese-Cache. Das bedeutet, dass Schreibzugriffe auf die Festplatte zeitverzögert stattfinden und vorher noch vom System optimiert werden, sowie oft benötigte Dateien möglichst lange im Hauptspeicher gehalten werden. Fordert ein Programm eine solche Datei an, dann wird erst geschaut, ob sie im Cache vorliegt und wenn ja (das nennt man dann einen Hit), wird sie direkt aus dem Cache geliefert und nicht von der Festplatte gelesen. So weit, so gut.

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.