8

Was ist das Feature von Windows 10, an dem sich die meisten Geister derbe scheiden? Richtig: das automatische Update, welches man nur verschieben, aber nicht beliebig aufschieben kann. Irgendwann muss man einfach das Update fahren, ob es nun für einem Sinn macht oder eben nicht! Die einzige Abhilfe ist es, seinen Rechner ohne Internet zu betreiben, aber wer macht das heute noch?!?

Sicherheitsexperten fanden diese Änderung einfach toll, weil so der Benutzer endlich gezwungen wird, wichtige Sicherheitsaktualisierungen relativ zeitnah einzuspielen. In Wirklichkeit aber ist diese Funktion ein Riesendesaster und hat zu einer Menge an Unmut gegenüber Microsoft geführt, weil das Update entweder immer genau dann gefahren wird, wenn man es am wenigsten braucht oder aber möglicherweise ein größeres Update erst einmal ungefragt gewisse Treiber und Programme kaputt macht. So oder so, es entreißt dem Benutzer ein gutes Stück der Kontrolle über den eigenen Rechner und ist in der Praxis einfach nur eine richtig üble Idee.

Man könnte also aus den Fehlern von Microsoft lernen und das sein lassen. NirvanV Dean mit seinem Black Dragon Viewer aber machte genau das Gegenteil: er hat diesen um eine automatische Updatefunktion erweitert. Diese ist ab Version 2.5.6 aktiv, der Download findet im Hintergrund statt und irgendwann ploppt dann von Windows eben die Meldung auf, dass sich der Black Dragon Viewer aktualisieren will. Das kann man dann tun, man kann es auch sein lassen, nur dann funktioniert nach dem Autor eben der Login vom alten Viewer nicht mehr. Also wird hier ein Zwang auf den Benutzer ausgeübt, die Aktualisierung vorzunehmen.

Der Grund dafür ist, dass dem Autor der Supportaufwand für seine alten Viewer einfach zu groß wird. Das ist noch bis zu einem gewissen Grad verständlich; aber dann kann man genau so gut sagen, dass es eine neue Version gibt, in der der Fehler behoben ist und fertig ist die Laube.

So aber zeigt der Autor hier eine Attitüde, die einfach nur noch zum Himmel stinkt. Er meint, besser als seine Benutzer zu wissen, welche Viewerversion von seinem Produkt sie genau haben wollen - nämlich immer die aktuellste - und ihnen das diktieren zu können. Wie man schon an Microsoft gesehen hat, kann und wird genau dies nicht gut gehen und für eine riesige Menge an Ärger sorgen.

Es ist nämlich nichts anderes hier als die Bequemlichkeit des Autors, die ihn letztendlich zu diesem Schritt bewogen hat - und seine Benutzer dürfen es nun ausbaden und nicht wenige werden darunter leiden.

Dazu kommen noch seine pampigen Reaktionen darauf, wenn sich nun Benutzer darüber beschweren, wie beispielsweise hier von Penny Patton:

Vielleicht wäre NiranV Dean einfach besser damit beraten, da ihm seine Benutzer ja so auf den Keks gehen, wenn er die Entwicklung seines Viewers gleich einstellt. Dann muss er nämlich nicht mehr unter deren Wünschen und Problemchen leiden... in seinem "Monthly Writeup" vom Oktober und November wird diese Änderung jedenfalls nicht erwähnt, noch im Changelog zu 2.5.6. Gut, es gibt den Blogpost, aber das sieht für mich wenigstens aktuell so aus, als wäre das Feature zunächst stillschweigend aktiviert wurden, bis es genügend Downloads gab und erst dann wurden die Benutzer benachrichtigt.

Da kommt doch so richtig vorweihnachtliche Freude auf. Ganz im Ernst: wer bisher noch den Black Dragon Viewer benutzt, der sollte sich mal so langsam nach einer brauchbaren Alternative umsehen, denn mit der Attitüde und dem absolut unprofessionellem Gehabe von NiranV Dean werdet ihr nie mehr sicher sein können, ob der Viewer nach dem nächsten Update noch funktioniert, wie ihr es braucht und wollt, oder eben nicht.

Kloppt ihn endlich in die Tonne und erlöst ihn so von seinem Leid!

Aktuell schwappt ja durch die deutschen Qualitätsmedien eine Welle der Berichterstattung über einen ach so tollen Webbrowser auf deutschen Landen, der es Google mal so richtig zeigen soll. Wer nicht gerade blind durch's Web surft, der wird das sicherlich mitbekommen haben, es handelt sich dabei um den neuen Browser CliqZ.

Cliqz ist kostenlos verfügbar, gut. Mit dem Verkauf von Webbrowser kann man schon seit mindestens 15 Jahren kein Geschäft mehr machen, daher ist das nicht weiter verwunderlich, wer seinen Webbrowser unters Volk bringen will, der muss diesen kostenlos abgeben, sonst kann er es nämlich gleich sein lassen!

Cliqz ist dabei softwaretechnisch nichts anderes als ein Fork von Mozilla Firefox. Man hat also die Basis von Firefox genommen und entsprechend umgearbeitet, was erlaubt ist. Das Meiste an Features, was Cliqz so bietet, kann man übrigens auch problemlos bei jedem anderen, modernen Webbrowsern durch Erweiterungen problemlos nachrüsten. Die Erweiterungen von Firefox kann man jedenfalls mit Cliqz nicht nutzen, da der Entwickler das abgeschaltet hat.

Was die Medien aber stillschweigend verschweigen ist, wer hinter Cliqz steckt, denn die Firma gehört zum Medienunternehmer Hubert Burda. Burda ist einer der großen deutschen Verleger.

Und einer der Unterstützer vom Leistungsschutzrecht. Der Browser ist also eine Waffe, um die Anzeigeneinnahmen von Google zu reduzieren. Und natürlich kommt der Browser mit einer Reihe von Ausnahmen daher, die Werbung vom Verlagshaus Burda&Co. erlauben. Man will sie ja nicht ins eigene Fleisch schneiden, und ebenso wird nur "unsicheres Tracking" verhindert.

Wer also wirklich einen werbefreien Browser haben will, dem bleibt nach wie vor nichts anderes übrig, als sich das mit den zur Verfügung stehenden Mitteln selbst zu machen. Das ist ja keine große Kunst. Der Rest greift eben zu Cliqz.

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.

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.

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.

Es gibt ja manche Leute, die es als einen der Kardinalfehler in den Geschäftsentscheidungen von Linden Lab der letzten Jahre ansehen, dass sie die Entwicklung von Opensimulator geduldet und nichts dagegen getan haben.

Zunächst einmal hätten sie wohl sowieso nicht viel dagegen unternehmen können, denn wer selber seinen Viewerquellcode und damit alle Protokolle offenlegt, der muss auch damit rechnen und nimmt dies in Kauf, dass die Serverkomponente nachgebaut wird. Gut, im Falle von Opensimulator gab es schon vorher die Bibliothek für die Second Life Protokolle durch Reverse Engineering, aber die Veröffentlichung des Viewerquellcodes 2007 gab dem ganzen einen gehörigen Schub.

Und selbst wenn Linden Lab etwas dagegen hätte tun können - was hätte es gebracht?

Damit Opensimulator wirklich Linden Lab gefährlich werden könnte, müsste es massiv an der Benutzerbasis von Second Life knabbern und Landmasse abziehen, und das seit Jahren.

Hat Opensimulator das aber getan? Nein. Opensimulator ist eine Nische in der Nische, hauptsächlich ein Sammelbecken der mit Second Life Unzufriedenen, die sonst eben ganz weg wären und ist Second Life zu keinem Zeitpunkt auch nur in die Nähe einer Gefährlichkeit gekommen und wird es auch so schnell nicht werden.

Von daher kann sich Linden Lab beruhigt in seinen Sessel hocken und sich den Luxus erlauben, Opensimulator komplett zu ignorieren, denn ob es nun Opensimulator gibt oder nicht, hat für den Betrieb von Second Life keinen wirklichen spürbaren Einfluss.

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).

1

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 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.