Mit diesem Artikel möchte ich mal meine Sichtweise zum Thema Open Source / Closed Source niederlegen.

Generell gehöre ich zu der Sorte von Entwicklern, die ihre Software unter der BSD-Lizenz oder GPL veröffentlichen. Allerdings sage ich auch nicht, dass z.B. Treiber, die als Binary veröffentlicht werden, nicht in Linux integriert werden sollten.

Ich bin froh, wenn sich überhaupt Unternehmen die Mühe machen und Ressourcen binden, um die Portierung der Treiber nach Linux (BSD, MacOS, Solaris etc. – wenn ich im folgenden Text von Linux spreche, schließt dies diese Betriebssysteme einfach mal mit ein) voran zu treiben. Schließlich kann man so unter diesen Betriebssystemen neue und (oft) bessere Hardware schnell nutzen.

Die Entwicklung von Treibern nach dem altbekannten Ansatz des Reverse Engineerings, wie es z.B. bei Samba bis zur Veröffentlichung der Protokoll-Details von Microsoft der Fall war, nimmt einfach viel zu viel Zeit in Anspruch. Und Zeit ist Geld.

James Bottomley,  Vorsitzender des TAB und SCSI Maintainer, hat letztes Jahr ein Essay herausgegeben, in dem er indirekt die Bereitstellung der Treiber-Quellcodes an die Community fordert. Intel und ATI sind bereits vor einiger Zeit mit ihren Treibern auf den Zug aufgesprungen.
Die Vorteile für Intel, ATI und andere Unternehmen, die ihre Quellen und Interface-Dokumentation veröffentlichen, liegen eigentlich auf der Hand:

• Es wird eine wesentlich breitere Nutzerbasis angesprochen. Gehen wir von einer neuen 10 GBit-Netzwerkkarte, die auf den Markt geworfen wird. Folgende Szenarien sind nun möglich:
  1. Die Treiber liegen nur in binärer Form für Windows-Plattformen vor.
     Als Zielgruppe für die Nutzung dieser Karte wird man vor allem Rechenzentren oder Internet-Provider ansprechen wollen, die zum großen Teil auf Linux setzen. Es liegt ein eindeutiger #fail vor, da der Hersteller sich einen Großteil der Nutzerbasis versperrt.
  2. Der Hersteller veröffentlicht die Schnittstellenbeschreibung.
     Bleiben wir bei unserer Netzwerkkarte: Der Hersteller entschließt sich, die Treiber in binärer Form für Windows-Plattformen zu veröffentlichen. Zusätzlich legt er die Spezifikationen für die Hardware offen.
     Ambitionierte Entwickler haben nun die Möglichkeit, den Treiber für Linux nachzubauen. Wichtig ist aber, dass es beim Hersteller immer einen Ansprechpartner für die Treiber-Entwicklung gibt, da oft die Dokumentation trotz merhmaliger Reviews Fehler enthalten kann.
  3. Windows und Linux werden mit binären Treibern beliefert.
     Beide “großen” Betriebssysteme werden mit Treibern in Form von Binärpaketen ausgeliefert. An sich nicht schlecht, schließlich hat nun eine große Zielgruppe die Möglichkeit, die darunter liegende Hardware einzusetzen.
     Aber hier gibt es zwei gravierende Probleme: Auf der einen Seite werden – so habe ich zumindest das Gefühl – die Linux-Treiber als Abfallprodukt gesehen, die “mal so nebenbei” programmiert wurden. Viele Treiber-Entwickler kennen eher die Windows- als Linux-Umgebung. So kommt es, dass der Linux-Treiber Kernel-Panics auslöst oder ähnliches. Falls es mal Probleme mit dem Treiber geben sollte, wird dies (hoffentlich) zur Kenntnis genommen – aber eine baldige Lösung ist oft nicht in Sicht.
     Das zweite große Problem besteht in den Regeln bzw. Lizenzen, die der Distribution zu Grund liegt. Unter Ubuntu ist es kein Problem, binäre properitäre Treiber aus einem anderem Repository nachzuinstallieren. Das Debian-Projekt würde hingegen niemals Treiber in binärer Form einbinden.
  4. Der Treiber liegt in binärer Form und als Quellcode vor.
     Ideal ist meiner Meinung nach die folgende Form: Der Treiber liegt für Windows und auch Linux in binärer Form vor, zusätzlich gibt es den Quellcode des Treibers zum Download. Entwickler seitens des Herstellers haben sich um die Dokumentation gekümmert und stehen als Ansprechpartner zur Verfügung.
     In diesem Zuge muss ich ganz klar ATI mein Lob aussprechen, da sie den kompletten Schritt im Jahr 2008 vollzogen haben.

  Wie schon geschrieben: Ideal wäre Konzept Numero 4. Leider hat sich NVidia gegen ein solches Vorgehen ausgesprochen. Die Absage wurde mit der Begründung erteilt, dass der Treiber geistiges Eigentum enthält. Mich würde interessieren, von welchem “geistigen Eigentum” NVidia spricht. Irgendwelche genialen Treiber-Optimierungen? Ein Quake-Easteregg, dass bei einer speziellen Auflösung aktiviert wird?
  Meine Idee für eine kommende Hardware-Generation wäre die folgende: Alle Teile, die “geheim” sein sollen, werden direkt in der Hardware, z.B. mit Hilfe von FPGAs entwickelt. Die Hardware wird nun über weiter abstrahiertere Interfaces dem Kernel (Windows, Linux oder sonstwas) zur Verfügung gestellt. Bei einem Update der (Hardware-)Treiber profitieren alle Betriebssysteme.

• Der Treiber wird durch die breitere Nutzerbasis von mehr Personen überprüft und auch getestet.
• Machen wir uns nichts vor: Linux-Benutzer sind zum größten Teil Frickler – ich zähle natürlich auch dazu. Viele Frickler sind bei einem Problem bereit, Zeit in die Lösung zu investieren und wenn nötig auch dafür neue Programmiersprachen oder Techniken zu erlernen.
  Henrik Ibsen sagte mal “Weltverbesserer gibt es genug, aber einen Nagel richtig einschlagen können die wenigsten” – ich behaupte mal eher folgendes: “Frickler gibt es genug und die meisten probieren den Nagel einzuschlagen bis er wirklich sitzt.”
• Durch die große Anzahl von Entwicklern, die Zugriff auf den Quellcode haben, lassen sich Features oder Performance-Optimierungen einfacher implementieren oder sich eben eine Grundlage für eine neue Grafikkarten-Generation schaffen.

Der Grund für diesen Post lieferte mir konkret NVidia. Vor einigen Wochen bestellte ich mir ein Zotac ION-Board, dass als Grundlage für meinen neuen Server und als DVD-Player dienen sollte.
Nun ist es aber so, dass mein Fernseher in Kombination mit dem HDMI-Ausgang des Boards einen extremen Overscan produziert, dass man von der gesamten Oberfläche 3/4 auf dem Fernseher sieht.

Sucht man in den Foren von NVidia nach “Overscan”, findet man massig Einträge, die sich damit befassen. Mich stört es ganz besonders, dass der Windows-Treiber die Möglichkeit bietet, das Overscanning zu neutralisieren. Dieses Feature ist aber unter Linux – in der äußerst armseeligen – Konfigurationsoberfläche  nicht vorhande und lässt sich auch nicht per Xorg.conf vernünftig einstellen.

Ganz ehrlich: Hätte ich den Quellcode für den NVidia-Treiber, wäre ich bereit, mich des Themen “Treiber-Entwicklung unter Linux” und “Overscanning” zu stellen – so sehr stört mich dieser Bug.