‘Was Anwender tun, ist niemals falsch’

1991 hatte Torvalds aus seiner Unzufriedenheit mit den damals existierenden PC-Betriebssystemen begonnen, ein eigenes, Unix-ähnliches Betriebssystem zu programmieren. Ursprünglich war Linux nur für den Rechner des damals 21-Jährigen gedacht; aber nach Veröffentlichung der Version 0.01 im Internet gewann Linux sehr schnell Anhänger und eine ständig wachsende Schar von Entwicklern. Mittlerweile läuft das Open-Source-System auf allen gängigen Hardware-Architekturen und hat sich vor allem bei den Internet-Servern einen festen Platz erobert.

c't: Linux hat das, was du ursprünglich wolltest, doch schon vor einigen Jahren erreicht. Warum hast du an diesem Punkt weitergemacht?

Torvalds: Die Ziele haben sich verändert. Am Anfang ging es mir vor allem darum, etwas Interessantes zu machen und dabei Spaß zu haben. Ich ging davon aus, dass ich der einzige Anwender sein würde, und machte auch keine konkreten Pläne hinsichtlich der Features. Ich wusste, was ich von einem Unix erwartete; aber ich war beispielsweise nicht an Grafik interessiert, weil ich lediglich Quellcode editieren und kompilieren wollte.

Linus Torvalds (links) im Gespräch mit c't-Redakteur Oliver Diedrich.

Nachdem ich Linux im Internet veröffentlicht hatte, fragten jedoch andere Anwender nach Features, an die ich nie gedacht hatte, und es kamen immer mehr neue Ideen auf. Statt eines Unix für meinen eigenen Desktop sollte Linux nun das beste Betriebssystem überhaupt werden. Durch die Wünsche anderer Leute und später dann ihre Patches und Hilfe wurde es viel interessanter. Inzwischen wird ja die meiste Arbeit von Anderen gemacht.

Mittlerweile geht es mir um ein gutes Betriebssystem-Design, das auch für andere Leute nützlich ist. Meine Tätigkeit hat sich gar nicht so sehr geändert: Ich programmiere und lese eine Menge E-Mails. In Hinblick auf meine ursprünglichen Pläne ist Linux längst fertig; aber die vielen neuen Einsatzbereiche für Linux motivieren mich, weiterzumachen. Wenn ich Linux nicht ins Internet gestellt hätte und diese anderen Anwender nicht wären, hätte ich die Arbeit an Linux wahrscheinlich schon 1992 beendet.

c't: Wie lange willst du mit Linux weitermachen? Siehst du irgendwann in der Zukunft einen Punkt, an dem du sagen wirst: ‘Jetzt habe ich genug davon?’

Torvalds: Ich glaube nicht, dass es da einen speziellen Punkt gibt. Ich habe immer mit einzelnen Dingen aufgehört, und das fing schon sehr früh an. Ganz am Anfang beispielsweise habe ich selbst für alle Anwendungen gesorgt: Ich musste - zusätzlich zur Arbeit am Kernel - die Shell portieren, den Compiler und die Bibliotheken. Darum haben sich dann aber sehr früh andere Leute gekümmert, und ich konnte mich auf den Kernel konzentrieren. Heutzutage arbeite ich immer noch am Kernel, aber ich beschränke mich jetzt weitgehend auf zentrale Funktionen wie Speicher- und Prozessverwaltung und das grundlegende Design.

Ebenso habe ich weitgehend aufgehört, auf Veranstaltungen wie dieser LinuxWorld zu sprechen. Ich habe hier an der Panel-Diskussion teilgenommen, aber keine Keynote gehalten, weil mich solche Dinge fürchterlich stressen. Ich gehe davon aus, dass ich mich auf immer speziellere Gebiete konzentrieren werde; aber ich glaube nicht, dass ich völlig mit Linux aufhören werde - bis vielleicht irgendwann jemand kommt, der besser ist als ich, sodass ich mich zurückziehe.

c't: Wenn du irgendwann keine Lust mehr auf Linux hast - wie könnte sich dann die Organisation der Linux-Entwickler gestalten?

Torvalds: Ich sehe nicht, dass das in absehbarer Zeit passiert; aber es gibt eine Menge Leute, die meine Arbeit tun könnten. Mittlerweile programmiere ich kaum noch selbst, sondern ich zeige ‘guten Geschmack’ - ich treffe Entscheidungen hinsichtlich der Architektur. Aber es gibt andere Leute, die ebenfalls ‘guten Geschmack’ haben. Ich bin eine Art zentrale Anlaufstelle, bearbeite E-Mails, lese sie, schicke sie zu den richtigen Leuten.

Veranstaltungen sind offensichtlich PR-Arbeit, und es gibt genug Leute, die das genauso gut könnten. Zurzeit ist es am wichtigsten, eine Art Identifikationsfigur für Linux zu sein, rein aus psychologischen Gründen. Mittlerweile kennt man Linux von Firmen wie SuSE, IBM oder Red Hat; aber lange Zeit war Linux diese radikale, von Linus Torvalds angeführte Bewegung.

Wenn jetzt das Flugzeug von Frankfurt nach San Francisco abstürzen würde, könnte jeder - nun gut, vielleicht nicht jeder, aber eine Menge Leute könnten meinen Job übernehmen. Es wäre sicherlich nicht eine einzige Person. Dass es im Moment eine Person ist, hat historische Gründe. In Wirklichkeit ist Linux ja nicht eine einzige Person: Ich tue, was ich tue, und [der XFree86-Entwickler] Dirk Hohndel macht seinen Job. Meine technische Arbeit am Kernel zum Beispiel könnten mehrere Leute erledigen.

Wenn man sich ansieht, wie Linux tatsächlich entwickelt wird: Ich rühre beispielsweise den Kernel 2.2 gar nicht an, das macht alles [der Kernel-Hacker] Alan Cox. Jetzt haben wir bald den Anwenderkernel 2.4 fertig, und dann wird sich Ted Ts’o [Entwickler des ext2-Dateisystems] um den Kernel 2.4 kümmern. Ich kann mich dann auf die Entwicklerkernel konzentrieren, weil mich das am meisten interessiert und weil die Entwickler damit zufrieden sind, wie ich das tue. Aber es ist nicht so, dass das niemand anderer tun könnte. Es würde sicherlich eine Menge Aufregung in den Medien geben, wenn ich über dem Ozean abstürze, aber für die Linux-Entwicklung bin ich nicht mehr so wichtig.

c't: Kannst du uns ein bisschen mehr darüber erzählen, wie die Entwicklung von Linux organisiert ist?

Torvalds: Nehmen wir ein einfaches Beispiel. Da hat jemand eine Idee. Zunächst wird er das mit Bekannten und auf der Kernel-Mailingliste diskutieren: Ich brauche dieses Feature aus jenen Gründen, arbeitet da jemand dran? Wenn sich niemand meldet, wird er es programmieren. Dann benutzt er das neue Feature erst einmal selbst, spricht mit Leuten in seiner Umgebung drüber und postet es auf der Kernel-Mailingliste, wenn er möchte, dass sein Code in den Standardkernel eingeht. Er weiß, wie es läuft, und schickt nicht gleich eine Mail an mich.

Wenn es perfekter Code ist, heißt es in der Mailingliste vielleicht gleich: ‘Ja, das wollen wir haben.’ Doch das passiert in der Praxis nicht. Die Reaktion sieht eher so aus: ‘Wir verstehen, was du willst, aber so ist das ziemlicher Mist. Ich möchte etwas Ähnliches machen, aber das geht nicht zusammen mit deinem Code.’ Und dann ändert man die Schnittstellen, sodass beides gleichzeitig geht, und es kommt zu Modifikationen, an denen andere Leute interessiert sind.

Das kann sehr lange dauern. Vor allem große Änderungen können sogar mehrere Jahre als Patches in der Kernelliste kursieren, während darüber diskutiert wird und sogar schon eine Menge Leute den neuen Code einsetzen. Ich bekomme solche Patches und Diskussionen auf der Liste mit; und irgendwann entscheide ich dann, dass der Code so nützlich ist, dass er Teil des Standardkernels werden soll. Vor allem bei wichtigen Fragen diskutiere ich mit und sage vielleicht: ‘Ich sehe, worum es dir geht; aber aus Sicht der Kernelarchitektur ist das der falsche Weg’. Irgendwann fließt der Code dann in meinen Standardkernel ein, oder er bleibt ein externer Patch für spezielle Zwecke.

c't: Wie stehst du zu der Möglichkeit eines Code-Forking im Kernel? Der Linux-Chef bei IBM etwa hat vor kurzem gesagt, dass ein Kernel nicht alle Anforderungen vom Embedded Device bis zum unternehmenskritischen Server abdecken kann.

Torvalds: Forking kommt ständig vor. Nur weil mein Kernel als der offizielle gilt, heißt das nicht, dass es nicht eine Menge ‘inoffizielle’ Kernel gibt. Beispielsweise haben die meisten Distributoren eigene Kernelversionen mit speziellen Features. SuSE etwa legt viel Wert auf ISDN, weil das in Deutschland wichtig ist; für den Rest der Welt ist ISDN jedoch kein Thema. Verschiedene Distributionen richten sich an unterschiedliche Klassen von Anwendern; SGI zum Beispiel interessiert sich vor allem für den SGI-Markt mit Rechnern mit Hunderten von CPUs. Der SGI-Kernel wird daher Features für den Einsatz auf großen Maschinen enthalten.

Ich versuche, einen gemeinsamen Standardkernel zu pflegen; aber das ist kein Kernel für jedermann. Natürlich stellen Supercomputer und Embedded Devices ganz unterschiedliche Anforderungen, und der Kernel wird nie derselbe sein. Ich versuche, die Unterschiede so klein wie möglich zu halten, und neue Dinge so einzubauen, dass sie die extremen Anwendungen nicht behindern.

c't: Während der Arbeit am Entwicklerkernel 2.3 gab es eine Menge Diskussionen um die Speicherverwaltung ...

Torvalds: ... die gibt es immer noch.

c't: Wenn man in Servern große Mengen an Hauptspeicher adressieren will, benötigt man eine Speicherverwaltung, die bei Systemen mit wenig RAM nicht so effizient ist.

Torvalds: Das ist ein klassisches Beispiel. Eine Menge Dinge scheinen unvereinbar miteinander zu sein. Da brauche ich auf der einen Seite Unterstützung für kleine Geräte, und auf der anderen Seite stehen große Maschinen mit 16 Knoten, jeder mit seinem eigenen Speicher und insgesamt Hunderte GByte an RAM. Die Lösungen dafür müssen natürlich ganz unterschiedlich aussehen. Die erste Antwort besteht meist aus zwei verschiedenen Code-Strängen, einfach weil es am wenigsten Arbeit macht - der Code muss nicht so viele Möglichkeiten berücksichtigen. Aber die Pflege des Codes wird schwieriger, weil man Schnittstellen zu beiden Codesträngen haben muss.

Doch dann kommt es zu einer Virtualisierung der Speicherverwaltung. Das war eines der Dinge, an denen wir während der 2.3-Entwicklung gearbeitet haben: den Begriff eines ‘Speicherknotens’ zu virtualisieren. Ein kleines Gerät ist dann dasselbe wie eine große Maschine, mit dem einzigen Unterschied, dass es lediglich einen Speicherknoten hat, während der große Rechner mehrere dieser Knoten hat. Das kleine Gerät wird so zu einem einfachen Fall der großen Maschine.

Aus demselben Code entstehen dann über eine entsprechende Konfigurationsoption unterschiedliche Kernel. Im Quellcode gibt es eine Schleife über die Knoten; aber bei einem Knoten läuft die Schleife von Null bis Null, wird beim Kompilieren wegoptimiert und ist im Binary nicht mehr vorhanden. Das macht die Pflege der Quelltexte viel einfacher, und mit solchen Designfragen befasse ich mich.

Natürlich geht das nicht immer so. Manchmal hat man einfach unterschiedliche Geräte, die verschiedene Treiber benötigen. Man muss beim Design die Entscheidung treffe, welcher Code allgemein ist, und wann man unterschiedlichen Code für die verschiedenen Fälle schreibt. Darum geht es letztlich in der Computer Science.

c't: Die Kernelquellen sind mittlerweile sehr umfangreich ...

Torvalds: ... um die 55 MByte Quelltexte; ich habe die genaue Zahl nicht parat, aber es sind etwa drei Millionen Zeilen Code. Der Kernel ist riesig, und niemand könnte ihn pflegen, wenn nicht das allermeiste davon völlig unabhängige Treiber wären. Aber auch Treiberentwicklung ist nicht einfach, weil man all die Schwächen der Hardware ausbügeln muss.

c't: Programmierer kennen ja das Problem, dass sie an einer Stelle im Code etwas ändern und das Programm dann an einer anderen Stelle abstürzt.

Torvalds: So etwas passiert mit dem Kernel auch.

c't: Wie kriegt ihr solche Schwierigkeiten in den Griff?

Torvalds: Es gibt nur eine Lösung: saubere Schnittstellen. Idealerweise sollte es niemals überraschende Bugs geben oder Interaktionen, an die man nie gedacht hat. Die Schnittstellen müssen so klar sein, dass man bei einer Änderung des Codes an einer Stelle weiß, an welchen Stellen man sonst noch ändern muss. Ich behaupte nicht, dass die Schnittstellen in Linux immer so sauber sind, aber wir arbeiten darauf hin. Viele der Änderungen im Kernel 2.4 zielen in diese Richtung. In den meisten Fällen ging es mehr darum, saubere Schnittstellen zu entwerfen, als tatsächlich neuen Code zu schreiben. Häufig passt der Programmcode jedoch nicht zu dem, was man sich überlegt hat; das macht das Ändern der Schnittstellen so mühsam. Aber es ist enorm wichtig, auch wenn der Anwender erst einmal gar keinen Vorteil darin erkennen kann - bis er auf eine neue Maschine stößt, wo die geänderte Schnittstelle nötig ist.

c't: Ich will gar nicht erst fragen, wann der Kernel 2.4 erscheinen wird ...

Torvalds: ... ich hoffe, noch dieses Jahr ...

c't:... aber mich würde interessieren, wo die Probleme mit dem neuen Kernel liegen.

Torvalds: Eine grundlegende Schwierigkeit ist gar nicht technischer Art, sondern liegt darin, dass die meisten Leute überhaupt nicht auf einen neuen Kernel upgraden wollen. Sie sind mit dem Kernel 2.2 zufrieden, haben keine größeren Probleme damit - warum sollten sie einen Entwicklerkernel ausprobieren? Es ist eine bestimmte Gruppe von Anwendern, die neue Kernels testen; und vor der Veröffentlichung eines neuen Anwenderkernels muss zumindest ein Teil dieser User den neuen Kernel getestet haben. Die Entwickler haben ihren eigenen Blick auf neue Versionen, wir brauchen externe Anwender zum Testen. Das ist nicht nur bei Linux ein Problem; manche Softwarehersteller bezahlen ja sogar Leute für das Ausprobieren neuer Betaversionen.

Aber es gibt auch noch ein paar technische Schwierigkeiten. Wir wissen von einigen echten Bugs, für die teilweise sogar schon Lösungen existieren; allerdings sind nicht alle Entwickler überzeugt, dass diese Lösungen auch wirklich gut sind. In dieser Hinsicht gibt es noch einige offene Fragen: Häufig wollen die Entwickler bessere Lösungen, die garantieren, dass ein bestimmtes Problem in Zukunft nicht mehr auftritt.

Darüber hinaus gibt es auch Probleme in der Kommunikation. Die Leute, die Bugs finden, sind ja meist nicht die Entwickler selbst und beschreiben die Probleme ganz anders, als das ein Entwickler tun würde. Das kostet einfach viel Zeit.

c't: Vorhin hast du schon von den Kernelerweiterungen der Linux-Distributoren gesprochen. SuSE beispielsweise liefert die Anwenderkernels 2.2 mit dem Logical Volume Manager und dem Journaling Filesystem ReiserFS aus. Gerade über ReiserFS haben die Kernelentwickler intensiv diskutiert - mit der Entscheidung, es noch nicht in den ‘offiziellen’ Kernel aufzunehmen. Was hältst du von derartigen ‘Eigenmächtigkeiten’? Ihr hattet doch sicher eure Gründe für die Entscheidung gegen ReiserFS.

Torvalds: Vor allem im letzten Jahr sind neue Gruppen von Anwendern hinzugekommen, und gerade SuSE - ohne jetzt für SuSE sprechen zu wollen - hat viel mit großen Kunden zusammengearbeitet, die an LVM interessiert sind. Zur Verwaltung von mehreren hundert Platten braucht man solche Tools. Und auch, wenn das System nicht abstürzt, sondern nur gelegentlich neu gebootet wird, sind e2fsck-Läufe von mehreren Stunden nicht akzeptabel, sodass man lieber ReiserFS nehmen wird. Derartige Anwendungen sind erst in der letzten Zeit aufgekommen, und es braucht einfach seine Zeit, so etwas zu integrieren. LVM ist seit einem halben Jahr im Entwicklerkernel 2.3, aber noch letzte Woche haben wir daran gearbeitet. ReiserFS wollte ich auf keinen Fall vor dem Kernel 2.4 aufnehmen, weil ich immer dachte, kurz vor dem Code Freeze zu stehen und keine völlig neuen Fragen mehr in die Diskussion bringen wollte. SuSE und andere haben ReiserFS in der Zwischenzeit getestet, daher werden wir es wahrscheinlich in die Version 2.4.1 aufnehmen.

Was Anwender tun, ist niemals falsch. Ich kann den Linux-Usern doch nicht vorschreiben, was sie zu tun haben. Meine Ansicht war immer: Was immer die Leute tun wollen, es ist in Ordnung. Ich kann nur Entscheidungen treffen, wie die Architektur aussehen soll, die das ermöglicht, oder Hinweise geben, wie man dasselbe Ergebnis mit einem anderen Ansatz erzielen kann. ReiserFS wird kommen, und ich kann nicht einfach ‘nein’ dazu sagen. Für mich geht es nur um das Timing und vielleicht einige Änderungen, um ReiserFS besser in den Kernel zu integrieren.

[SGIs Journaling Filesystem] XFS ist eine andere Sache. Es ist noch nicht so weit wie ReiserFS, und ich kann nicht sagen, ob es in einem Jahr Teil des Standardkernels sein wird. [Der Nachfolger des Linux-Standard-Dateisystems ext2] ext3fs ist wieder eine andere Angelegenheit. Der Code ist schon da, und es gibt Anwender, die es bereits benutzen. ext3fs könnte durchaus in die Kernelserie 2.4 integriert werden oder zu einem frühen Zeitpunkt im Kernel 2.5. Mir geht es um Flexibilität. Open Source bedeutet, dass man mit dem Code alles Mögliche machen kann.

Das heißt nicht, dass ich ReiserFS oder ext3fs selbst benutze. Was mich daran interessiert, ist etwas anderes. ReiserFS, XFS und ext3fs werden offensichtlich eine Menge gemeinsam haben. Was bedeutet das für das Virtual File System [die Kernelstruktur, die die Schnittstelle zu den Dateisystemen bildet]? Vielleicht nehmen wir Teile des Codes, den mehrere der Dateisysteme enthalten - auch wenn sie unterschiedliche Dinge tun, geht es ja letztlich um dasselbe -, und versuchen, dafür eine gemeinsame Schnittstelle zu schaffen. So etwas macht wirklich Arbeit. Bis das VFS selbst mit Journaling umgehen kann, werden wohl noch zwei oder drei Jahre vergehen; aber dann haben die Dateisysteme nicht mehr so viel Arbeit damit. Das ist die Art von Fragen, mit denen ich mich befasse.

c't: Was sind zurzeit die interessantesten technischen Entwicklungen bei Linux?

Torvalds: Bei den meisten Dingen geht es überhaupt nicht um den Kernel. Natürlich gibt es da spannende Entwicklungen, beispielsweise die Skalierbarkeit - das war technisch extrem interessant. Aber die wirklich faszinierenden Dinge machen andere Leute. Die ganze Aufregung um DVD war sehr interessant, wenn auch vielleicht etwas entmutigend. Und dann natürlich der Desktop und Dinge, die für Unix eigentlich ganz ungewöhnlich sind. Wenn ich beispielsweise Fernsehen gucke, tue ich das mit einem Linux-Rechner, dessen Festplatte als Videorecorder dient. Wenn man so ein Gerät mal benutzt hat, will man nie wieder einen klassischen Videorecorder anfassen. Ich benutze solche Geräte nur noch für Filme, die es nicht auf DVD gibt.

c't: Und allgemein in der IT-Welt? Schließlich arbeitest du ja in einer Hightech-Firma.

Torvalds: Diese ganzen drahtlosen Geschichten. Ich habe beispielsweise ein großartiges Handy, einen Laptop und einen Palm. Wenn ich unterwegs bin, benutze ich meinen Laptop, um E-Mail zu lesen; und dann will ich das Handy als Modem einsetzen. Aber das geht nicht; diese Art Kommunikation funktioniert einfach noch nicht. Ich denke, in fünf Jahren werden alle diese Geräte miteinander kommunizieren können. Interessant ist dabei weniger die Technik, sondern die Umsetzung in Anwendungen.

c't: Wenn du auf die lange Entwicklungsgeschichte von Linux zurückschaust: Gab es da Dinge, die dich überrascht haben?

Torvalds: Sehr wenig. Natürlich wäre ich am Anfang sehr überrascht gewesen, wenn ich gewusst hätte, wo sich Linux hinentwickeln würde. Aber als das alles passierte, hat mich nichts davon wirklich überrascht. Als ich die Version 0.01 ins Internet stellte, rechnete ich mit Kommentaren. Vielleicht kamen damals etwas mehr Reaktionen, als ich erwartet hatte; aber ich glaube, nicht mal das war wirklich so. Nach einigen Monaten waren es 50 statt der erwarteten fünf Leute, dann einige hundert; und das hat mich schon etwas überrascht. Aber gleichzeitig erlebte ich die Entwicklung von fünf über zehn und zwanzig zu fünfzig Usern, daher gab es keinen Punkt, an dem ich mir sagte: ‘Mein Gott, was passiert da?’ Dann das kommerzielle Interesse, das zunehmende Medienecho - die meisten Leute denken, das sei alles in den letzten zwei Jahren geschehen, aber tatsächlich entwickelte es sich langsam über die letzten neun Jahre. Firmen begannen, Linux zu unterstützen - manchmal war es überraschend zu sehen, in welchem Ausmaß, etwa bei IBM. Niemand rechnete damit, dass IBM so weit gehen würde. Aber auch da gab es nicht diesen einen Punkt, an dem ich wirklich überrascht gewesen wäre.

c't: Gibt es etwas, was dich geärgert hat?

Torvalds: Nicht viel. Die unangenehmste Überraschung war wohl diese Mindcraft-Studie [eine von Microsoft finanzierte Studie, in der im April 1999 Linux gegenüber Windows NT sehr schlecht abgeschnitten hatte]. Ich erinnere mich noch, wie sauer ich damals war. Mittlerweile ärgert es mich nicht mehr, da es am Ende gut ausgegangen ist. Am überraschendsten sind vielleicht die durchgängig positiven Reaktionen gegenüber Linux. Die Entwicklergemeinde war von Anfang an sehr freundlich, trotz all dieser Diskussionen um den Linux-Kernel, die zuweilen sehr heftig wirken können.

c't: Da gibt es eine Menge hässlicher Diskussionen ...

Torvalds: Ja, bei Diskussionen um ihre technischen Ideen werden die Leute sehr hitzig und unangenehm.

c't: Ist das typisch für die Open-Source-Gemeinde? Beispielsweise diese starke Antipathie gegenüber Microsoft ...

Torvalds: Nein, nicht nur. Mac-User sind da sehr ähnlich. Das Internet macht es leicht, einfach drauflos zu reden, und dann kommt es schnell zu Flame Wars. Man kennt die Leute nicht, mit denen man streitet, und dann übertreibt man es leicht. Das ist definitiv nicht nur bei Linux so - wenn man sich all die ‘Advocacy Groups’ da draußen ansieht ... es ist amüsant. Die Auseinandersetzungen zwischen Linux- und FreeBSD-Fans zum Beispiel sind noch viel heftiger, weil sich diese Gruppen gut kennen und wissen, wo es wehtut. Die Leute streiten sich einfach gerne. Es ist ein sozialer Wettbewerb, man zeigt so seine Überlegenheit anderen gegenüber. Viele dieser grundlegenden Debatten sind inzwischen völlig vorbei, etwa die Auseinandersetzung um vi versus Emacs. (odi) (odi)