Der traurige Zustand von OpenGL

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.

Er ist unter anderem der Meinung, dass OpenGL den Mist von über 20 Jahren mit sich herum schleppe und einfach radikal von Grund auf neu geschrieben gehört. Wenn dies nicht bald geschehe, dann würden AMDs neues API Mantle als auch Direct X12 OpenGL performancetechnisch ungespitzt mal wieder in den Boden rammen. (Wobei da sicher diese Entwicklung, wie OpenGL bis zu 15x schneller laufen könnte, wohl nicht berücksichtigt ist).

Jedenfalls ist es ein interessanter Artikel aus der Siche eines Programmierers, der sich wirklich mit OpenGL auskennt.

Auch interessant ist noch sein Artikel „Die Wahrheit über die Qualität von OpenGL-Treibern“, in dem er sich massiv über die unterschiedlichen Treiberqualitäten von Hersteller A, B und C auslässt. Unschwer zu erkennen handelt es sich dabei bei A um Nvidia, B um AMD und C um Intel.

Auch das liest sich interessant. Nvidia kommt relativ gut weg, der Treiber sei aktuell leistungstechnisch der Standard. Der Hersteller lege mehr Wert auf ein Funktionieren des Treibers als nun alle möglichen GL-Erweiterungen zu unterstützen. Aber auch der Treiber hatte so seine grundlegenden Fehler, die einfach nicht hätten passieren können und vor allem sei der Treiber so programmiert, dass er intern ganze Shader für Schlüsseltitel/spiele durch eigene ersetzen würde, nur damit die Leistung stimme. Der Hersteller mache da vor nichts halt. Allerdings habe eben Nvidia auch die beste, interne Qualitätskontrolle und das würde man deutlich spüren.

AMD dagegen kommt deutlich schlechter als ein Kuddelmuddel weg, sehr fehlerreich, inkonsistente Qualitätstests und das Treiberthreading sei komplett außerhalb der Kontrolle der offiziellen Entwickler. Leider könne man diesen Hersteller aber nicht ignorieren, da seine GPUs hardwaretechnisch sehr leistungsfähig und verbreitet seien, obwohl sie als Hersteller softwaretechnisch gesehen Idioten seien.

Die Treiber von AMD würden sich strikter an die Standards halten, aber da die meisten Leute nur mit Nvidia entwickeln würden und dann wenn es mit AMD nicht funktionieren würde, würden sie AMD die Schuld geben und nicht dem Status Quo von OpenGL an sich selbst.

AMDs Schlüsselerweiterungen funktionieren nicht, und er schaffe es einfach nach wie vor nicht, gewisse grundlegende Dinge zuverlässig zum Laufen zu bringen.

Außerdem habe AMD es bisher nicht geschafft, mal ein Treiberupdate rauszubringen, das nicht irgendetwas gleichzeitig kaputt machen würde, ein Fehler würde behoben und zwei neue eingeführt. Außerdem seien viele Entwickler von AMD zu Nvidia gegangen, und wenn man sich anschauen würde, was der Treiber intern so treibe, dann gäbe es da Zillionen an Fehlerworkarounds von diesen Leuten, die heute bei AMD keiner mehr verstehen würde.

Interessanterweise aber habe AMD ein fähiges Entwicklerteam für Debuggingtools, die sogar meist funktionieren, solange man mit AMD entwickeln würde.

Die langfristige Entwicklung des Treibers sei aber so, dass die Zuverlässigkeit ziemlich wahrscheinlich noch abnehmen würde.

Auf der Sonnenseite sei es aber so, dass sie die OpenGL-Spezifikationen auswendig kennen würden. Wenn man von ihnen Hilfestellungen bekommen würden, dann sei diese (ohne Erweiterungen) meist sehr vernünftig.

Intel wiederum sei eine Firma, die eigentlich nicht wirklich Grafik produzieren wollen, aber da der aktuelle Trend dazu gingen, Chipsatzgrafik auf dem Prozessor zu integrieren, es eben müssen. Es sei daher schwer, sauer auf sie zu sein, weil es eben nicht ihr Kerngeschäft sei.

Sie seien der Marktführer in Sachen Opensourcegrafiktreiber und haben so viel Geld, dass sie sogar zwei komplette Entwicklerteams für Treiber im Haus haben, für jedes Betriebssystem ein komplett eigenes. Außerdem seien die Hardwarespezifikationen komplett öffentlich.

Das Entwicklerteam sei schlau und sie würden direkt Open Source Wiz Kids anheuern, um den Treiber am Laufen zu halten. Der Treiber sei im Vergleich zu AMD und Nvidia am wenigsten fortgeschritten, aber er funktioniere, solange man nicht begreife oder darauf Wert legt, wofür „FPS“ stünde. Wenn man gut darin sei, Fehler in dem Treiber zu beheben und Patches zu liefern, dann kriegt man sogar vielleicht einen Job bei Intel.

Geldreich schließt mit dem Fazit, dass, wenn man für OpenGL richtig entwickeln wolle, man sein Programm auf jeder Hardwareplattform erneut testen müsse, andernfalls habe man keine Garantie, dass es eben gescheit laufe. Und wenn man Fehler entdecken möge, dann müsse man auf die Hilfe der OpenGL-Gurus hoffen, ansonsten sei es mitunter sehr schwierig.

Oder anders gesagt: die OpenGL-Treiber aller drei Firmen saugen, aber sie seien eben das Beste, was wir momentan leider haben. Und nach Gelbreichs Meinung ist eben Nvidia momentan in Sachen OpenGL nach wie vor der beste Hersteller, den wir haben.

Btrfs sucks

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.

High Fidelity und Opensimulator

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

hifi-system-architecture1

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.

Als Basis für die virtuelle Welt dient eine Voxel-Engine, eigentlich ein uralter Hut, der aber in der breiten Masse bisher kaum Fuß fassen konnte, weil Voxel so ihre eigenen, systembedingen Probleme mit sich bringen, wie beispielsweise im Vergleich zu Polygonen deutlich höherer Speicherverbrauch. Man darf gespannt sein, wie sie diese Probleme lösen werden.

Alles in allem aber sieht das jetzt bereits auf dem Papier sehr interessant aus und wenn HiFi es schaffen sollte, das auch so zu bringen, dann wird es mit einem Schlag dem 3D-Web deutlichen Vorschub bringen und nebenbei, davon bin ich überzeugt, Opensim sehr alt aussehen lassen.

SSDs und der Viewercache

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.

Nun hält sich noch immer hartnäckig das Gerücht, dass SSDs ach so empfindlich seien und dann kam auch sofort wieder der Mist auf, wenn man das täte, wäre die SSD nach 1-2 Jahren kaputt. Nein, wäre sie nicht.

Zuerst einmal ist es so, dass auch mechanische Festplatten mit der Zeit kaputt gehen können und im Schnitt eine Lebensdauer von fünf Jahren haben. Bei SSDs ist es so, dass diese mit jedem Schreibzugriff bauartbedingt ein wenig altert.

Bei Tech Report wollte man es mal genau wissen und beschreibt verschiedene, aktuelle SSDs seit Monaten im Dauereinsatz. Das Ergebnis ist, kurz gesagt, dass eine SSD robuster ist, als viele denken und diese Datenmengen, welche da geschrieben worden sind, ein typischer Durchschnittsbenutzer wohl in 30-35 Jahren erreicht. Wenn man nur den Second Life Viewer Cache auf eine SSD packt, dann dauert das gar noch viel länger.

Von dem Argument mit der viel zu kurzen Lebensdauer einer SSD in einem solchen Fall ist daher absolut nichts mehr zu halten, es zeigt nur, dass derjenige, der es vorbringt, einfach keine Ahnung von modernen SSDs hat.

Leap Motion in Aktion

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:

Ich kann mir vorstellen, dies ist für Leute, die hauptsächlich gerne per Voice unterwegs sind, sehr praktisch.

Man kann den Controller auch einzeln kaufen, er wird dann per USB an den Rechner gesteckt und ist in etwa so groß wie ein Feuerzeug. Windows steuern kann man damit übrigens auch:

Bullshit made in Germany: SSL/TLS-Umstellung bei T-Online, GMX und Web.de

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.

Was eigentlich geschieht denn nun genau?

Die Provider führen verpflichtend eine Verschlüsselung des Transportweges ein, d.h. vom Endbenutzer zum Emaildienstleister wie GMX hin. Verschlüsselung bedeutet dabei, dass die komplette Kommunikation eben verschlüsselt wird und es so potentiellen Angreifern massiv erschwert werden soll, die Kommunikation zwischen beiden Geräten, also Rechner zuhause und Rechner beim Dienstleister, abzuhören.

Das klingt zunächst einmal an und für sich nach einer guten Sache und das ist es im Grunde auch. Warum ist es eine gute Sache? Nun, beispielsweise wenn man irgendwo an einem öffentlichen WLAN-Hotspot sitzt und da seine Emails unverschlüsselt abruft, da kann jeder weitere Rechner im selben Netz dies Passwort mit praktisch kaum Aufwand aufzeichnen und speichern. Damit kann dann ein böswilliger Angreifer das Emailkonto für seine Zwecke mißbrauchen, beispielsweise zum Spamversand.

Mit Hilfe der Transportverschlüsselung ist dieses Szenario praktisch nicht mehr existent. Klingt gut, ist in dem Fall auch gut.

Was ist daran ärgerlich?

Transportverschlüsselung ist eigentlich ein alter Hut! Den ersten Standard, SSL, gibt es bereits seit 1994 (!), und den Nachfolgestandard TLS seit 1999 (!). Warum, bitte, machen die Diensteanbieter diese Standards erst nach über 15 Jahren ihrer Festschreibung verpflichtend?

Dazu kommt, dass damit zwar die Übertragung an sich sicher wird, aber nicht die Speicherung auf den Rechnern entlang des Transportweges.

Genauer gesagt, und das ist der Knackpunkt: eine Email nimmt auf dem Weg vom Absender zum Empfänger meistens einen nicht immer genau vorhersehbaren Weg; die Rechner auf diesem Weg kommunizieren nun verschlüsselt, sofern es sich um die vier Provider oben handelt. Aber die Speicherung der Email auf den Rechner innerhalb dieses Wegs erfolgt nach wie vor im Klartext! 

Das bedeutet nichts anderes, das zwar die Kommunikation mit Hilfe dieser Initiative nur zwischen diesen vier Anbietern garantiert nun verschlüsselt wird, während die Emails aber auf dem jeweiligen Rechner im Klartext vorliegt. Wenn also jemand Emails abgreifen will, dann kann er dies nach wie vor ohne großen Aufwand tun.

Die Hochglanzwebbroschüre aber erweckt beim Laien den falschen Eindruck, als seien die Emails da nun auf einmal so bombensicher, und das ist einfach schlichtweg falsch. Das sind sie eben nicht.

Was bleibt zu tun, wenn man wirklich sichere Emails nutzen will?

Die Initiative sorgt also nur für sichere Transportwege, aber nicht für eine sichere Ende-zu-Ende-Kommunikation! Es gibt nach wie vor genug Einfallslöcher, dass Böswillige die Emails einfach auf dem Weg von A nach B abgreifen und auswerten.

Wenn man wirklichen Wert darauf legen sollte, dass seine Emails höchstwahrscheinlich nicht von unbefugten Dritten gelesen werden können, dann bleibt einem nichts anderes übrig, als dies selbst in die Hand zu nehmen.

Es gibt dabei zwei verschiedene, seit langem etablierte Ansätze, nämlich:

  • den Klassiker Pretty Good Privacy (PGP) von Phil Zimmerman, dessen erste Version bereits 1991 (!) erschien. Es basiert auf einer dezentralen Schlüsselerzeugung, in der man sich gegenseitig das Vertrauen ausspricht, sog. Key Signing Parties waren früher gang und gäbe.  Edward Snowden sah PGP bei korrekter Anwendung als sicher an, also können wir das auch.
  • S/MIME, ein seit 1995 festgeschriebener Standard, den die meisten Mailprogramme wie Outlook direkt unterstützen. S/MIME basiert auf einer zentralen Zertifikatvergabe, es gibt einige Anbieter, die kostenlose persönliche Zertifikate zur Verfügung stellen, und ist in Sachen Sicherheit mit PGP durchaus vergleichbar. 

Dennoch sollte man besser, wenn möglich, PGP benutzen, denn die zentralen Zertifikatvergabestellen bei S/MIME haben in den letzten Jahren mehrfach grandios versagt.

Whatsapp vs. Threema

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:

  1. der Quellcode von Threema ist nicht öffentlich einsehbar, und daher kann keiner sagen, ob es nicht Fehler im Kryptographiecode oder eingebaute Hintertüren gibt,
  2. die Server sind ebenfalls eine Black Box und auch daher gilt bei denen, keiner kann bis auf den Hersteller sagen, was sich auf den Servern genau abspielt und
  3. die Nutzerzahl ist viel zu gering sowie
  4. wer weiß schon, was sich auf dem eigenen Smartphone abspielt, das kann sowieso geknackt sein.

Also alles in allem eine nett gemeinte Idee, die man aber nicht ernst nehmen kann, solange das Programm nicht öffentlich seinen Code publiziert und jeder damit seine eigene Infrastruktur bauen kann, ist es wertlos. Und dann kann man bei der geringen Nutzerzahl gleich bei Whatsapp bleiben.

Was die Softwareentwickler wohl rauchen…

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.

Dazu kam, dass mit Cinnamon und Mate zwei Forks entstanden, die auf unterschiedlicher Grundlage die althergebrachte Desktopmetapher weiter sponnen. Diese erhielten massiv Zulauf und GNOME selber hat Schadensbegrenzung betrieben, aber ist inzwischen in einem Zustand, dass es nur noch wenige benutzen dürften. Das Internet ist jedenfalls voll mit Postings Marke „GNOME 3 sucks“, und das zu Recht. Canonical hat mit Unity daher inzwischen auch seinen eigenen Desktop im Bau.

Microsoft wiederholte haargenau denselben Fehler mit Windows 8: man stülpte dem Desktop eine Tabletoberfläche über und entsorgte den Desktop. Nur machte das bei Microsoft noch Sinn, weil eben die auch wirklich Windows-Tablets herstellen. Dennoch ist auch hier Microsoft seit dem Erscheinen nur noch am Zurückrudern, den Startknopf gibt es inzwischen wieder, in Bälde soll man auch die Kacheloptik ganz auf dem PC abschalten können. Warum wohl trotz inzwischen 200 Millionen verkaufter Lizenzen? Ganz einfach weil kaum eine Firma Windows 8 bei sich einsetzen will, daher.

PS: wer meint, Apple sei da wirklich besser, der solle sich nur einfach einmal in Ruhe anschauen, was denn Apple in Mac OS X 10.7 mit dem Rollbalken verzapft hat. Mit 10.8 haben sie dann nachgebessert.

Die Beschleunigung des Viewer-Caches

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.

Was aber passiert, wenn wir den Rechner gerade erst gestartet haben, dabei noch nicht in Second Life waren und einen recht gut gefüllten Viewercache haben? Dann bleibt dem System nichts anderes übrig, als alle diese Texturen nacheinander von der Festplatte zu lesen. Und da dies schon auf einer normalen Sim, auf der man sich bewegt und ein normales Blickfeld hat, durchaus mehrere Hundert Stück sein können, dauert das dann eine Weile.

Wieso kommt dies so? Ganz einfach daher, weil hier nun die mechanischen Beschränkungen einer Festplatte greifen. Die Leistungsfähigkeit einer modernen Festplatte wird an zwei Kennziffern gemessen, nämlich der maximale Schreib-/Lesedurchsatz sowie die Zugriffszeit. Die Zugriffszeit ist dabei der Zeitraum, den die Festplatte im Schnitt benötigt, um den Schreib-Lese-Kopf auf den Anfang der gewünschten Datei zu positionieren. Diesen Vorgang nennt man übrigens auch Seek. Typischerweise wird diese Zeit in Millisekunden gemessen, und eine moderne Festplatte hat eine Zugriffszeit im Bereich von irgendwo 5-10 ms. Dabei gilt natürlich die Devise: je niedriger die Zugriffszeit, desto besser. Eine gewisse Zugriffszeit aber wird man mit Festplatten niemals unterschreiten können.

So. Was bedeutet das? Wenn wir neu einloggen auf irgendeine Sim, dann will der Viewer aus einem gut gefüllten Cache einen Haufen an Texturen von der Festplatte lesen. Das bedeutet, dass es innerhalb kurzer Zeit zu einem Haufen an Seeks kommt, die die Festplatte abarbeiten muss.

Und hier nun eine einfache Rechnung: wieviel Seeks pro Sekunde schafft eine Festplatte maximal? 1 Sekunde sind 1000 Millisekunden, also meinetwegen 1000 ms / 8 ms = 125 Seeks/Sekunde. A-ha, damit kommen wir der Sache dann nämlich schon näher. Und sollte die Festplatte meinetwegen 6 ms Zugriffszeit haben, dann kommen wir da auf 1000 ms / 6 ms = 167 Seeks/Sekunde, was auch nicht wirklich besser ist.

Wenn wir uns dann noch klar machen, dass die Festplatte meist nicht nur von Second Life alleine benutzt wird, sondern zeitgleich auch andere Programme sie benutzen, dann wird einem klar, dass der Viewer längst nicht immer die theoretisch maximal mögliche Anzahl an Seeks pro Sekunde für sich alleine zur Verfügung haben wird.

Mit anderen Worten: die Festplatte ist in der Regel für den Anwendungsfall gut gefüllter Cache, neu gestartetes System und man loggt mit dem Viewer gerade ein, das Nadelöhr. Der Prozessor könnte mehr leisten, aber er kann es eben nicht, weil er auf die Festplatte warten muss und das ist schlecht.

Wenn man den Viewer-Cache für den obigen Fallo also beschleunigen will, dann muss man dafür sorgen, dass die Anzahl an Seeks pro Sekunde erhöht wird. Klingt einfach und ist es auch eigentlich, denn man könnte ja anstelle einer Festplatte eine billige Solid State Disk (SSD) im Rechner einbauen und den Viewercache darauf speichern. SSDs sind für solche Anwendungsfälle, also Ordnerstrukturen mit tausenden, kleinen Dateien, gerade zu ideal. Eine SSD hat keinerlei bewegliche Teile und ihre Zugriffszeit ist in der Regel um den Faktor 100 besser als einer Festplatte.

Die Zugriffszeit einer SSD beim Lesen liegt so im Bereich von 0,05 bis 0,08 Millisekunden. Einfache Rechnung also: 1000 ms / 0,07 ms = 14285 Seeks/Sekunden. Und selbst günstige SSDs sind nur unwesentlich langsamer. Das bedeutet klar, dass eine SSD ganz einfach das Speichermedium der Wahl für solche Anwendungsfälle ist.

Wenn man aber keine SSD hat oder erwerben will, dann kann man dennoch seinen Rechner beschleunigen. Voraussetzung dafür ist, dass man mindestens zwei Festplatten im Rechner installiert hat. Moderne Betriebssyssteme haben die Möglichkeit, zwei Festplatten oder zwei gleich große Partitionen auf zwei verschiedenen Festplatten zu einem sog. Stripe-Set  zusammenzufassen. Die Anwendung sieht nur ein Laufwerk in der Größe der beiden Partitionen zusammengerechnet, in Wirklichkeit aber handelt es sich dabei um diese beiden Festplatten, die das Betriebssystem als eine ansteuert.

Dabei verteilt das Betriebssystem nun Schreib-/Lesezugriffe möglichst gleich zwischen beiden Festplatten, ebenso die Dateien. Dies hat den Vorteil, dass ein Stripeset umso schneller wird, auf je mehr Festplatten es angelegt ist, denn die Zahl der Seeks pro Festplatte addiert sich (d.h. ein Set auf zwei Platten erreicht theoretisch bei 8 ms Zugriffszeit je Platte eben maximal 125 * 2 = 250 Seeks/s, bei 3 Platten 125 * 3 = 375 Seeks/s usw.), allerdings bietet es absolut keine Sicherheit für die darauf befindlichen Dateien. Geht eine Platte kaputt, dann ist das komplette Set unbrauchbar.

Das aber macht im Falle des Viewercaches absolut nichts aus, da dies ohnehin nur ein temporärer Zwischenspeicher ist, der jederzeit erneuert werden kann. Sollte man also beispielsweise unter Windows mehr als eine Festplatte im Rechner verbaut haben, dann kann sich der Aufbau eines Stripesets für den Viewercache durchaus lohnen, denn es bringt einem ohne Mehrkosten einen spürbaren Leistungsgewinn.

Eine Anleitung, wie man unter Windows 7 solch eine Konfiguration aufbaut, findet sich hier. Dabei ist wie immer zu beachten, dass man besser weiß, was man tut, denn man arbeitet an der Festplattenpartitionierung und ein falscher Handgriff kann da schlimmstenfalls Datenverlust nach sich ziehen. Also Vorsicht.

Bitcoin – blablabla

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.

Und überhaupt Geld: eine Währung lebt davon, dass ihr Wert recht stabil ist, fluktuiert und ausgegeben wird. Der Wert von Bitcoins bemisst sich einzig und alleine darüber in Wirklichkeit, wieviel echte Dollars und anderes man bereit ist zu bezahlen. Für den eigentlichen, angeblichen Nutzungszweck – als Währung – werden Bitcoins kaum genutzt. Bitcoins sind vielmehr ein astreines Spekulationsobjekt geworden und wenn man sich mal den Werteverlauf der Bitcoins anschaut, dann wird einem auch klar, dass dem so ist und mit so etwas kaum ein vernünftiger Mensch Sachen bezahlen würde noch Zahlungen annehmen würde.

Und ein Spekulationsobjekt, bei dem die Early Adopters recht einfach eine nette Menge anhäufen konnten, die sie nun teuer verkloppen könnten, ja das sind sie durchaus. Alles, was nun Bitcoins mined, wird es immer schwerer haben, noch einen einzigen Coin zu minen als früher. Und bei knapp 22 Millionen, also irgendwann um 2020 rum, wird damit Schluss sein. Es ist eine gigantische Umweltverschmutzung und Energieverschwendung für nichts und aber auch wieder nichts.

Und Bitcoins können unwiederbringlich verloren gehen – dazu reicht es schon aus, wenn die Festplatte mit der Wallet abraucht und man kein Backup hat. Diese Coins sieht man nie wieder und stehen auch dem Rest nie mehr zur Verfügung.

Kurz und gut es ist ein interessantes Experiment, eine Spekulationsblase allererster Güte ohne wirklich praktischen Nutzen, aber auch ein Anfang. Hoffentlich lernen spätere Ansätze dieser Art aus den Fehlern bei Bitcoin und machen es besser. Denn gut ist Bitcoin nun wirklich nicht, bestenfalls gut gemeint, das ist aber auch alles.