»Microsoft ist nicht der böse Feind«
Interview mit Chefarchitekt Kurt Garloff von Novell
Garloff: Ganz im Gegenteil! Seit der Übernahme durch Novell sind einige Dinge geschehen, die sehr positiv für dieses Produkt sind. Zum einen, dass YaST endlich unter der GPL veröffentlicht wurde, was ja lange gefordert, auch bei vielen intern bei Suse schon lange gewünscht war und dann endlich umgesetzt wurde. Das OpenSuse-Projekt selbst ist ja auch, seit Suse Teil von Novell ist, zu einem Commmunity-Projekt gemacht und aus meiner Sicht auch sehr, sehr gut angenommen worden. Dort finden jetzt auch weitere innovative Dinge statt: Der Build-Service, der es Benutzern ermöglicht, sehr leicht ihre Software auch in binärer Form für verschiedene Distributionen gebaut - und nicht nur Suse Linux, es sind auch Fedora und Ubuntu möglich - bereitzustellen. Das sind Dinge, für die ich ein gutes Feedback kriege.
Ich habe jetzt keine Zahlen. Ich kann nicht nachzählen, wieviele Leute es vorher waren, und wieviele es anschließend sind. Es ist sicherlich so, dass diese Box, die man im Laden kaufen kann, uninteressanter wird für die Leute. Es gibt einfach viele, die eine entsprechend gute Internet-Verbindung haben, die Produkte lieber herunterladen, die sich auch mit Linux gut genug auskennen, so dass sie auch die Dokumentation nicht unbedingt als sehr wertvoll ansehen. Es gibt also sicherlich weniger Menschen, die dieses Boxprodukt kaufen. Aber es werden dadurch trotzdem mehr Benutzer.
Pro-Linux: Ich würde noch gerne das Thema GPL-Treiber ansprechen. Ihr Unternehmen hat angekündigt, nur noch GPL-Treiber auszuliefern. Hat man sich aber OpenSuse oder gerade auch die Enterprise-Produkte angeguckt, so waren da teils Closed-Source-Treiber dabei, zum Beispiel ATI oder nVidia, andere Treiber sind wiederum herausgeflogen. Wieso diese Diskrepanz?
Garloff: Prinzipiell ist es so, dass wir als Open-Source-Distributor diese nicht-GPL-Kernelmodule niemals mochten. Wir haben immer versucht, die irgendwie zurückzudrängen, weil man im Kernel, der der zentrale Teil eines Betriebssystems ist, keinen Code haben möchte, den man nicht kennt, den man nicht ändern kann, und der relativ viel Schaden anrichten kann. Sicherheitlücken in dem Code kann man nicht fixen, und er kann auch den Kernel sehr leicht zum Absturz bringen.
Wir sind Anfang diesen Jahres in dieser Beziehung auch etwas konsequenter geworden. In der Vergangenheit sind wir häufig Kompromisse eingegangen. Nun sagen wir: Nein, wir können diese Treiber nicht ausliefern, und das ist mit Suse Linux Enterprise 10 und Suse Linux 10.1 auch nicht passiert. Die Treiber von nVidia und ATI, die Sie als Beispiel genannt haben, werden nicht von uns ausgeliefert, sondern von ATI und nVidia auf deren Webservern zur Verfügung gestellt.
Pro-Linux: Wie wollen Sie das dann mit Xgl machen? Ohne nVidia oder ATI funktioniert Xgl gar nicht. Wie soll das dann funktionieren, wenn Sie keine Closed-Source-Treiber ausliefern und trotz allem Linux im Desktop durch solche Gimmicks wie Xgl voranbringen wollen?
Garloff: Ich möchte jetzt mal sehr lobend Intel erwähnen. Intel hat eine Chipsatz-Grafik, die für die 3D-Effekte, die man auf dem Desktop hat, durchaus ausreicht, und Intel hat es geschafft, für diese Chipsatz-Grafik auch Treiber bereitzustellen, bei denen man kein Closed Source für den Kernel braucht. Die funktionieren wunderbar mit dem, was wir ausliefern. Für mich auch ein Kauftipp für jeden, der sich ein Laptop- oder Desktop-System kaufen möchte. Das ist auch, was viele bei uns benutzen.
Für die Kunden, die tatsächlich ATI- und nVidia-Karten haben, ist es so, dass ATI und nVidia gesagt haben: Ja, wir stellen diese Treiber bereit, wir nehmen diese Arbeit auf uns. Ich kann für die Kunden hoffen, dass ATI und nVidia das weiterhin tun, aber wir können das nicht sicherstellen, weil wir diese Treiber nicht ausliefern können.
Pro-Linux: Soll das bedeuten, dass sie auch in Zukunft Closed-Source-Treiber aus Ihrer Distribution heraushalten werden? Im Umkehrschluss würde das bedeuten, dass alle Nutzer, die ATI oder nVidia haben, irgendwann keine 3D-Funktionalität mehr nutzen können. Oder wird das doch möglich sein, einfach die proprietären Treiber herunterzuladen?
Garloff: Zwei Antworten dazu. Ja, wir werden auch in der Zukunft keine nicht-GPL-Kernelmodule ausliefern. Ich gehe davon aus, dass, wenn genug Benutzer das möchten und mit nVidia und ATI reden, diese auch weiterhin ihre Module zur Verfügung stellen werden. Unser Wunsch ist natürlich - und daran arbeiten wir auch mit ATI und nVidia und drängeln da auch -, dass sie es schaffen, einen Treiber zu bauen, der zumindest im Kernel-Bereich keinen Closed-Source-Code braucht. Da gibt es ein paar Ideen, wie man das machen kann. Man kann einen größeren Teil des Treibers im Userspace machen, um dieses Problem zu umgehen, und darüber reden wir und suchen nach technischen Möglichkeiten.
Da würde ich hoffen, dass der größere Druck der Kunden und auch der Druck von uns sie dazu bringt, dass wir das Problem irgendwann nicht mehr haben werden.
Pro-Linux: Einer ihrer Entwickler, Herr Hartman, hat ja eine stabile API für den Kernel vorgeschlagen, gerade für proprietäre Treiber. Wie weit ist diese API eigentlich fortgeschritten?
Garloff: Für Kernelmodule selbst gibt es insofern keine stabile API, als Kernel-Module eben als Teil des Kernels auf alles, was sich im Kernel befindet, zugreifen können, und man kann nicht den ganzen Kernel stabil halten und gleichzeitig nichts ändern. In der Form wird das also nicht passieren. Die Ideen, die es gibt, gingen in zwei Richtungen: Die eine ist, wenn man als Distributor einen Kernel ausliefert und liefert Updates aus, dass diese Updates an diesen Datenstrukturen, die die Module benutzen, nichts verändern, so dass man, wenn man ein Security Update einspielt, nicht die ganzen Treiber neu compilieren muss. Das ist etwas, was wir bereits tun.
Aber im Wesentlichen ist das auch nicht für Module von dritter Seite gedacht, sondern es geht wirklich auch um die Module, die wir selbst ausliefern, die wir auch nicht immer alle neu compilieren wollen. Einfach, damit der Kunde nicht soviel herunterladen und nicht so viel neu testen muss.
Die zweite Sache, die man jetzt tun könnte - aus meiner Sicht sind das aber Ideen in einem frühen Stadium - ist, vielleicht einen kleinen Teil der API stabil zu halten. Das wäre die API speziell für ein Modul, z.B. SCSI, und das kann man dann vielleicht besser stabil halten als alles. Da ist, denke ich, noch mehr Diskussion zu leisten, bevor das dann dahin kommt. Aber wenn man von einer Kernelversion ein paar Versionen weitergeht, wird es sicherlich immer Änderungen geben.
Pro-Linux: Herr Garloff, wir bedanken uns für das Gespräch und wünschen noch viel Erfolg während der Messe.
