Schlagwort: Programming

War es ein Fehler von Linden Lab, die Entwicklung von Opensimulator zu dulden?

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.

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

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.