Der Weg der Software oder: auf den Schultern von Riesen stehen

Die moderne Entwicklung von Software hat es so an sich, dass die Programmierer oft das Rad nicht mehr neu erfinden müssen, sondern sich bereits existierender Programmbibliotheken für alle möglichen Bereiche, wie beispielsweise Verschlüsselung, dem Abspielen von MP3s, Videos u.v.m. bedienen können. Der Entwickler nutzt die Schnittstellen der entsprechenden Bibliothek und baut sie in sein Produkt ein, fertig. Natürlich muss er damit auch ab und an sein Projekt der Bibliothek anpassen, wenn sich diese ändern sollte.

konqueror-web-browser

Das hier, werte Leser, ist Konqueror. Der Mehrzahl von euch wird Konqueror nichts sagen, es handelt sich dabei um den alten Dateimanager des Desktop Environments KDE unter *nix. Konqueror war schon immer fähig, als Webbrowser zu fungieren und hatte dazu eine eigene, kleine Websiterenderingengine namens KHTML eingebaut plus eine Javascriptengine namens KJS. KHTML war recht flott, leichtgewichtig und einfach in eigene Programme einzubauen.

KHTML kennt heute kaum noch einer, es wird auch nicht mehr weiter entwickelt. Als Apple im Jahre 2003 seinen eigenen Webbrowser namens Safari vorstellte, ging ein Raunen durch die Webszene. Denn in dieser Email meldete sich ein gewisser Don Melton bei den KDE-Entwicklern und verkündete der erstaunten Welt in der Mailingliste, dass Apples neuer Webbrowser auf einem Fork von KHTML mit KJS basieren würde. Dieser Fork, also eine auf Grundlage von KHTML unabhängige Weiterentwicklung trug damals den Namen WebCore, das Gesamtprojekt hörte auf den Namen Webkit.

Die KDE-Leute waren verzückt und gleichzeitig die Macher bei Mozilla verärgert, dass Apple nicht deren ebenfalls quelloffene Engine Gecko benutzt hatte. Gecko war den Entwicklern bei Apple zu groß, zu schwer einzubauen und zu langsam, aber KHTML genau richtig. Dafür konnte Gecko aber auch deutlich mehr Webseiten korrekt anzeigen, als dies bei KHTML der Fall war.

Webkit wuchs und gedieh und findet sich heute auf jedem Smartphone und Rechner als Engine, es ist die Basis für Safari und war die Basis für Google Chrome. An der Entwicklung von Webkit sind unter der Federführung Apples viele, bekannte Firmen beteiligt. Google verabschiedete sich allerdings 2013 von Webkit und gründete seinen eigenen Fork namens Blink. Der Grund dürfte einfach sein, dass man sich so aus der technischen Abhängigkeit von Apple befreien wollte. Ebenso verwendet bis heute der Second Life Viewer Webkit als Viewerkomponente.

Mozilla arbeitet übrigens selber schon seit längerem an einer vollkommen neuen Renderingengine namens Servo, die in einer dafür eigens geschaffenen Programmiersprache namens Rust implementiert wird. Man darf gespannt sein, was dabei am Ende herauskommen wird.

HTTP/2.0 in den Startlöchern

Das moderne World Wide Web hat ein Problem, nämlich sein Übertragungsprotokoll namens Hypertext Transfer Protokoll. Dieses ist recht einfach und designmäßig in die Jahre gekommen, das merkt man eben.

Es gibt bisher zwei Versionen davon, nämlich HTTP/1.0 aus dem Jahre 1996. Bei HTTP/1.0 wird für jede übertragene Datei oder Bild eine neue Netzwerkverbindung aufgebaut, die Daten übertragen und danach die Verbindung wieder geschlossen. Wenn man nur wenig überträgt, dann ist das kein großes Ding, aber eine moderne Webseite besteht heute locker aus über 80 verschiedenen Dateien oder mehr. Jede Verbindung, die per TCP/IP aufgebaut werden muss, benötigt einen gewissen Vorlauf im Betriebssystem als auch im Netzwerk und danach wird sie wieder geschlossen. Das ist so sinnvoll, als würde man für drei Kästen Bier im Supermarkt jeden Kasten Bier einzeln holen.

1999 kam dann eine Verbesserung namens HTTP/1.1 heraus, die bis heute der aktuell gültige Standard ist. Bei HTTP/1.1 kann man eine bereits bestehende Verbindung offen halten und darüber mehrere Dateien anfordern. Man spricht von persistenten Verbindungen und Pipelining, d.h. der Übertragung mehrerer Dateien über die offene Verbindung hintereinander. Das Problem daran ist nur, dass korrektes Pipelining extrem schwer zu implementieren ist und daher nutzt es kaum jemand wirklich. In Google Chrome beispielsweise ist Pipelining implementiert, aber standardmäßig abgeschaltet. Zudem gab es Benchmarks mit mehreren Webbrowsern und dabei keine wirklich meßbaren Unterschiede zwischen an- und abgeschaltetem Pipelining.

Ob nun HTTP/1.0 oder HTTP/1.1, beide Protokolle sind recht einfach gestrickt, sie genügen nicht mehr den heutigen Anforderungen im Webserverbereich wirklich und ein Flaschenhals. Die Übertragung von Webseiten könnte deutlich schneller sein, was aber wegen des zugrundeliegenden Übertragungsprotokolls bisher nicht möglich ist. Es ist ein Hemmschuh.

Google hat das Problem vor knapp zwei Jahren mit der Entwicklung des hauseigenen SPDY-Protokolls angegangen; dieses bildet nun die Grundlage für die aktuelle Entwicklung von HTTP/2.0, dessen Einführung in nächster Zeit absehbar sein wird.

Bei HTTP/2.0 wird zu jedem Webserver grundsätzlich nur noch eine TCP/IP-Verbindung aufgebaut und diese wird on the fly komprimiert. Die Übertragung findet binär statt und der Webserver beherrscht dabei das Multiplexing von verschiedenen Dateien gleichzeitig; auch erkennt er, welche Dateien der Webbrowser als nächstes höchstwahrscheinlich für den Seitenaufbau benötigt und schickt diese dem Browser von sich aus direkt zu.

HTTP/2.0 dürfte dem Web einen dringend benötigten, ordentlichen Geschwindigkeitsschub bringen, der die Breitbandleitungen deutlich besser als bisher auslasten wird.

CDN und was es bedeutet

Second Life bekommt aktuell Unterstützung für CDNs, also Content Delivery Networks, eingebaut. Aktuell gibt es einen Projektviewer dazu und rund 28 Regionen auf dem Mainland, die das unterstützen.

Das Problem daran ist nur: viele können sich unter einem CDN absolut nichts vorstellen, aber sie benutzen es täglich. Was also ist ein CDN und warum ist es gut?

Ein CDN ist, wie der Name schon sagt, ein Netzwerk, das Inhalte verteilt. Nehmen wir mal an, ín meiner Gegend gibt es zwei ALDI-Filialen, die eine ist drei Kilometer von mir entfernt und die andere zehn. Nehmen wir weiter an, ich als ökonomisch handelnder Mensch kaufe immer dasselbe Toilettenpapier bei ALDI, das es in jeder Filiale als Eigenmarke vorrätig gibt. Wohin werde ich natürlich fahren? Richtig: zu der Filiale, die näher an meinem Wohnort ist, denn das Angebot in dem Fall ist ja in allen ALDI-Filialen gleich und es gibt für mich absolut keinen vernünftigen Grund, in die weiter entfernte Filiale zu fahren.

Und genau das ist das Prinzip eines CDNs, nämlich die Inhalte eines Diensteanbieters geographisch (!) gesehen wirklich so nahe als möglich an den Abrufer zu bringen. Das geschieht dabei völlig automatisch, transparent und der Benutzer kriegt davon nichts mit. Der CDN-Anbieter muss dafür eine globale Infrastruktur betreiben.

Wie funktioniert das? Nun, in Second Life wird es für Meshes und Texturen freigeschaltet werden. Bekannte Anbieter von CDNs sind beispielsweise Akamai oder Amazon. Wenn ich also in Zukunft als Deutscher eine Textur runter laden will, dann geht diese Anfrage auf CDN-aktiven Regionen nicht mehr direkt an die Rechenzentren von Linden Lab in den USA, sondern an einen Server des CDN-Anbieters, der irgendwo in Europa steht. Der prüft dann zunächst, ob diese Textur schon lokal vorhanden ist, und wenn ja, dann schickt er mir diese direkt, was in einer deutlich besseren Ladezeit resultiert (das ist einfacher Physik und der Übertragungsgeschwindigkeit geschuldet, sprich man hat eine bessere Pingzeit). Wenn die Textur bisher nicht vorhanden ist, dann fordert er diese beim Stammserver an und hält sie danach für weitere Deutsche für eine gewisse Zeit vor.

Das ist alles. Dadurch haben wir dann in Zukunft eine Entkoppelung des Ladens von Texturen und Meshes von der Infrastruktur Linden Labs in den USA, weil das hauptsächlich über das CDN passieren wird. Als Ergebnis wird man eine spürbare Beschleunigung der Ladezeit von oft bzw. oft wiederholt besuchten Sims feststellen können. Wie hoch, das wird sich zeigen .

Zu beachten dabei ist allerdings, dass nach wie vor die Regionserver in den USA stehen und damit die Avatarpositionsberechnung, Physik usw. ausschließlich über dort geschehen wird.

High Fidelity, SL TNG und Opensimulator

Philip Rosedale arbeitet unter Hochdruck mit seinen motivierten und fähigen Mitarbeitern an der nächsten Inkarnation einer virtuellen Welt, High Fidelity. Linden Lab überraschenderweise auch schon seit längerem, auch wenn das Kind noch keinen offiziellen Namen hat - manche nennen es einfach Second Life The Next Generation (SL-TNG) - so soll doch bereits 2015 eine Beta verfügbar sein.

Beiden ist gemeinsam, dass sie ordentlich Manpower und ordentlich Geld zur Verfügung haben, um ihre Pläne Wirklichkeit werden zu lassen, dazu kommt noch sehr viel praktische Erfahrung mit dem Betrieb von virtuellen Welten. Während High Fidelity Opensource ist mit einigen, zentralen Diensten, wird SL TNG erst einmal Closed Source sein.

Aber denken wir mal ein wenig weiter und tun so, als ob zumindest einer dieser neuen Dienste verfügbar wäre: neue Möglichkeiten, zeitgemäßere Architektur, bessere Leistung und Geschwindigkeit.

Was wird dann aus Opensimulator? Bis auf einige Hartgesottene bin ich mir sicher, dass es vor allem wegen High Fidelity dann sehr rasch und stark an Bedeutung verlieren wird und irgendwann wohl sanft sterben wird, denn mit dem Erscheinen eines dieser Produkte wird es ziemlich sicher seine besten Zeiten schlagartig hinter sich haben.

The new kid on the block

Es gibt mal wieder einen neuen Second Life Viewer, mit dem keiner rechnete, namens Replex. Dahinter steckt Latif Khalifa, seinerseits absolut kein Unbekannter, sondern der Autor vom Radegast-Client und einigen anderen Sachen.

Replex kommt einem dabei von Anhieb seltsam bekannt vor, und das ist kein Wunder, handelt es sich doch schließlich bei diesem 1er-Viewer um einen Fork vom Singularity Viewer. Replex basiert dabei auf dem letzten Alphacode von Singularity, enthält aber einen Haufen an Verbesserungen im Vergleich zu Singularity 1.8.5. Allerdings stammt die Mehrheit davon vom Singularity-Team selber, der bisherige Beitrag von Latif Khalifa liest sich dann doch recht bescheiden:

  • Added Replex skin (Latif)
  • Bundle Replex, Gemini and Silver skins (Latif)
  • Windows 64 viewer now supports parcel media (QuickTime) (Latif)
  • gtp chatbar command now allows omitting height. (Latif)

Im Grunde ist also Replex eine leicht veränderte Version des aktuellen Singularity-Alpha-Codes plus einigen, wenigen Änderungen von Latif Khalifa.

Da stellt sich dann die Frage: warum hat der Kerle das gemacht? Einer der Singularity-Entwickler beschreibt das so:

Replex is by no means the successor, it's just something done because someone has no confidence that we can get our alpha build system up.

Also in seinen Augen ist der Grund, dass Latif einfach kein Vertrauen darin habe, dass das Singularity-Team seine neue Build-Infrastruktur zum Laufen bekommen würde und daher selber was gebaut und nichts anderes.

Latif Khalifa selber schreibt zu seiner Motivation auf seiner Seite nichts dazu. Es bleibt also abzuwarten, ob er wirklich die Energie hat, Replex weiter zu entwickeln oder Replex bald wieder, wie viele andere Viewer vorher auch schon, von der Bildfläche verschwinden wird.

Linden Lab arbeitet an einer neuen, virtuellen Welt

Da ich das bisher komischerweise noch nicht in der deutschen Blogosphäre gelesen habe, eben nun hier: Linden Lab arbeitet nach eigenen Aussagen an einer neuen, virtuellen Welt (oder nennen wir es Plattform).

Diese soll closed source sein, und viele der Fehler von Second Life beheben. Das bedeutet nicht das Ende von Second Life, sondern beide Plattformen werden lange Zeit parallel existieren. Ein Import der Daten von Second Life in diese neue Welt ist nicht vorgesehen und mit einer Beta irgendwann im Jahr 2015 zu rechnen. Die Mehrheit der Programmierer Linden Labs würde inzwischen an dieser neuen Welt arbeiten, außerdem stellen sie gerade zusätzliche Programmierer ein.

In Sluniverse gibt es dazu einen inzwischen sehr langen Thread, in dem sich auch Ebbe Altberg bereits mehrfach dazu geäußert hat, auch hat er diese Meldung offiziell bestätigt. Ein Ziel der neuen Plattform wird definitv auch die Möglichkeit sein, sie mit mobilen Geräten benutzen zu können.

Ist TrueCrypt unsicher?

Momentan hat die freie Softwareszene ein gewaltiges Beben erschüttert, und keiner weiß so recht, woran man wirklich ist. Einige kennen vielleicht das freie Verschlüsselungsprogramm TrueCrypt: man kann damit Dateien oder komplette Festplatten verschlüsseln, es läuft unter Windows, Mac OS X und Linux gleichermaßen gut und vor allem auch so, dass man es portabel installieren kann sowie es einfachst zu bedienen ist. Viele Menschen benutzen es weltweit, um sensible Daten zu schützen, wie zum Beispiel der Sicherheitsexperte Bruce Schneier (genauer: er nutzte es) oder Edward Snowden.

TrueCrypt wurde dabei von einem Team an Entwicklern verfasst, deren Identität weitgehend unbekannt ist und sich nur selten in der Öffentlichkeit oder per Email zu irgendetwas äußern. Es ist seit über 10 Jahren bereits verfügbar und sein Quellcode offen verfügbar. TrueCrypt stand bisher im Ruf, weitgehend vertrauenswürdig und sicher zu sein, auch ist gerade momentan eine kommerzielle Sicherheitsprüfung des Quellcodes auf Schwachstellen und mögliche Hintertüren im vollen Gange, die bisher nichts schlimmes zu Tage förderte.

Also ist alles gut im TrueCrypt-Land, so sollte man meinen, aber weit gefehlt: seit ca. zwei Tagen hat sich die Webseite von TrueCrypt dramatisch verändert. Dort, wo bisher eine recht gut gemachte Webpräsenz unter www.truecrypt.org erreichbar war, findet sich nur noch eine im Vergleich dazu recht lieblos und schludrig dahingestellte Warnung, man solle die Software nicht mehr benutzen, da sie nicht mehr sicher sei. Warum TrueCrypt auf einmal unsicher geworden sei, darüber schweigt sich die neue Seite einfach aus.

Als Grund für die Einstellung der Software wird dabei das offizielle Supportende von Windows XP angegeben. Auch die Empfehlungen, welche Software man anstelle von TrueCrypt benutzen sollten, wirken komisch, denn unter Windows wird BitLocker empfohlen, das vermutlich eine serienmäßige Hintertür für die NSA eingebaut haben dürfte, für Mac OS X FileVault und unter Linux solle man einfach installieren, was man installieren wolle. A-ha. Und es gibt eine neue Version der Software zum Download namens 7.2, die aber nur noch das Entschlüsseln ermöglicht und nicht mehr verschlüsselt.

Alles in allem wirkt es auf den ersten Blick sehr sonderbar und so, als wäre da ein Hacker unterwegs gewesen. Der Fakt allerdings, dass die neuen Downloadpakete mit dem digitalen Schlüssel des Entwicklerteams signiert worden sind, machen das dann doch recht unwahrscheinlich. Solch ein Hacker hätte nämlich erst die Identität der Entwickler herausfinden müssen, sich dann noch den Schlüssel besorgen müssen plus das Passwort, mit dem man diesen benutzen kann. Es ist zwar möglich, aber extrem unwahrscheinlich.

Also ist es wahrscheinlicher, dass die Seite selber nicht gehackt ist, sondern echt vom Entwicklerteam so verändert wurde und sie nun keine Lust mehr haben, TrueCrypt weiter zu entwickeln. Die Frage, die man sich dabei stellen muss, ist aber: warum auf einmal das und warum auf einmal so, dass sie alles daran setzen, das bisherige Vertrauen in ihr Produkt nachhaltig zu zerstören?

Auch da gibt es wieder mindestens vier Möglichkeiten, nämlich:

  1. es gab einen Streit im Entwicklerteam und einer der Entwickler, der den Schlüssel hat, wählte diesen Weg als Rache, während der Rest weiter machen will,
  2. die Entwickler sahen sich möglicher, staatlicher Repression ausgesetzt und wurden gezwungen, die Entwicklung einzustellen, dürfen aber darüber nichts sagen (die National Security Letters in den USA kommen da einem in den Sinn und wie mit der Fa. Lavabit verfahren wurde),
  3. oder aber die Entwickler hatten wirklich einfach nur keine Lust mehr und fertig,
  4. TrueCrypt war in Wirklichkeit das Projekt irgendeines Geheimdienstes, niemals sicher und so zogen sie nun den Stecker.

Gegen 4 spricht, dass der Quellcode offen verfügbar ist und bisher im Audit nichts wesentliches gefunden wurde, was aber nicht heißt, dass man noch nichts finden wird. Auch untersucht das Audit ja den Quellcode, aber nicht die Downloadpakete, in denen könnte man ja noch Backdoors eingearbeitet haben. Außerdem würde gerade ein Geheimdienst ja wollen, dass man sein Produkt einsetzt und ein solch weit benutzes Ding wie TrueCrypt wohl kaum mit solch einer Aktion es beenden, denn das wäre ja gegen seine Interessen. Allerdings gelang es neulich jemandem, aus dem Quellcode dasselbe Paket zu bauen wie es zum Download in der Version 7.1a unter Windows zur Verfügung stand, also ist auch das eher unwahrscheinlich.

Gegen 3 sprechen die komischen Empfehlungen, die die Entwickler geben. Wenn jemandem wirklich Sicherheit so wichtig ist, dann wird der nicht auf einmal BitLocker oder FileVault einsetzen noch es empfehlen.

Also bleibt 1 oder 2. Beides ist möglich, und wenn es 2 sein sollte, dann werden wir es so schnell wohl nicht erfahren. Dazu kommt ja, dass keiner weiß, aus welchem Land die Entwickler eigentlich stammen und welchen Gefahren sie sich da möglicherweise ausgesetzt sähen.

Persönlich halte ich Möglichkeit 2 für wahrscheinlicher, denn wenn es 1 wäre, also der interne Streit, dann hätte sich nach über drei Tagen inzwischen sicher mindestens ein weiterer Entwickler vom Team dazu irgendwie geäußert oder gar die alte Seite wieder hergestellt. Was es letzten Endes aber wirklich ist, das muss die Zeit erst noch zeigen, es weiß eben keiner. Übrigens hat sich bei Twitter auch was getan, nämlich bei Steven Barnhart hat sich per Email ein Entwickler des Teams namens "David" gemeldet, der die Einstellung des Produktes einfach damit begründe, dass man keine Lust mehr habe und nein, es stünde keine staatliche Repression dahinter. Ob man dem nun trauen schenken kann oder nicht, auch das ist wieder ungewiß.

Überhaupt zeigt all diese Heimlichtuerei um die Entwickler ein großes Grundproblem von TrueCrypt: warum bitte haben wir die ganze Zeit lang einem Team von Entwicklern in dieser sensiblen Angelegenheit vertraut, das keiner kennt und die ihre Identität systematisch verheimlichen?

Bruce Schneier jedenfalls ist erst einmal wieder auf PGP Disk umgestiegen, wie es scheint. Die Version 7.2 der Software sollte man besser mit Vorsicht beäugen, d.h. gar nicht benutzen, solange keiner das Programmpaket auf mögliche Hintertüren durchsucht hat. Es gibt bereits Bestrebungen, wie beispielsweise unter www.truecrypt.ch, die Software als Fork weiter zu entwickeln. Eines steht dabei schon fest: TrueCrypt wird sie dann nicht mehr heißen können, weil das ein eingetragenes Warenzeichen ist.

So oder so, es ist alles nur sehr merkwürdig, viel im Dunkeln und was das alles genau soll, kann bis auf die Entwickler vielleicht keiner so recht sagen. Es bleibt also viel Raum für Spekulationen aller Art übrig.

Als Lehre aus dem Desaster sollte man, so finde ich, bei einem so wichtigen Stück Software einem anonymen Entwicklerteam, das keiner wirklich kennt, nicht mehr vertrauen. Gerade bei solchen Programmen ist es wichtig, dass man auch weiß, wer dahinter steht (und Satoshi Nakamoto von Bitcoin kennt bisher auch keiner).

Slinfo.de in treue Hände abzugeben

Ui, das ist mal eine Bombe: in diesem Beitrag hier schreibt Swapps Swenson, dass Slinfo.de gehackt worden sei und die ersten Spuren Ende April 2014 zu finden seien. Zwei Benutzer haben sich als Administrator anmelden können und diverse Änderungen an Templates und Plugins vorgenommen, obwohl das Forum immer sicherheitstechnisch auf dem neuesten Stand gewesen sei. Mag sein.

Da er keine Zeit zur vollständigen Fehlersuche habe, möchte er daher das Forum kostenlos inkl. Domäne und Software in vertrauensvolle Hände abgeben, genauer an nur ihm bereits bekannte Personen, oder es alternativ komplett schließen.

Uiuiui.

Wenn ich das lese, dann dreht sich mir gehörig der Magen um: ein Fehler kann ja mal passieren, PHP ist sicherheitstechnisch ein Krampf und das wird man leider niemals dicht bekommen können. Wenn also so was passiert, dann sollte man sich die Zeit nehmen, um sicher zu stellen, dass der normale Betrieb wieder gewährleistet ist und solange man das nicht kann, gehört der Dienst einfach abgeschaltet.

Hier aber wurde mehr oder minder kurz drüber geschaut und die Installation läuft einfach weiter. Go figure, ich halte das für ausgesprochen schlecht, weil so ein sicherer und vertrauenswürdiger Betrieb aktuell nicht möglich ist.

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.