Interview: Linux auf dem Desktop ist kein Tabu mehr
Golem.de: Sie Sprachen in Ihrer Rede über die Bedeutung von Architekturen – also eine Entwicklung der IT-Landschaft in Unternehmen, die sich in kleinen Schritten von Update zu Update weiterentwickeln im Gegensatz zur Migration von einem veralteten System auf das nächste veraltete System. Betrachtet man aber die Produktstrategie von Red Hat, zwingt diese Anwendern umfassende Updates – beispielsweise von Red Hat 8 auf Red Hat 9 – auf.
Michael Tiemann: Das denke ich nicht, denn alle Applikationen, die auf Red Hat 8 laufen, werden auch unter Red Hat 9 sowie Red Hat Enterprise Linux laufen. Diese Kontinuität auf der Seite der Applikationen erlaubt es, die zu Grunde liegende Plattform auszuwechseln, ohne dabei auch die Applikationen wechseln zu müssen. Das ist keine Frage von alles oder nichts wie beispielsweise der Wechsel von Siebel auf Oracle oder Oracle auf SAP, wo sich alles im System ändern müsste. Auch wenn es gute Gründe für solch einen Wechsel geben mag, macht man den Umstieg von Oracle auf SAP nicht an einem Tag.
Wenn ich mein Betriebssystem aber auf den neuesten Stand bringe, kann ich das innerhalb von einer Stunde erledigen – und ich verliere weder meine E-Mails noch meine Web-Cookies noch andere Dinge. Es ist ein Unterschied, ob ich ein paar Software-Versionen verändere oder die ganze Welt.
Es ist weniger ein Frage, welche Versionsnummer ein Red-Hat-Produkt trägt, es geht vielmehr darum, wie einfach es ist, die einzelnen Bausteine zu verändern.
Golem.de: War also die Idee einer einheitlichen, auf Linux basierenden Plattform einer der Hauptgründe für Red Hat, um die Entwicklung von eCos einzustellen und es in die Hände der FSF zu übergeben?
Tiemann: Also die Idee einer einheitlichen Architektur begründet sich vor allem in der Tatsache, dass dieser Ansatz einen ungemeinen Vorteil bietet. Zudem muss man die Frage stellen, was für Red Hat als Unternehmen kommerziell sinnvoll ist. Aber anders als bei einer proprietären Firma, wo die Einstellung der Produktentwicklung auch das Ende des Produktes bedeutet, kann eCos weiterleben und tut dies auch.
Ich war im letzten Jahr in Südkorea und hielt dort eine Rede. Anschließend kamen viele Leute auf mich zu und jeder Zweite wollte mit mir über eCos sprechen und das, obwohl Red Hat das Projekt eingestellt hatte. In Korea und auch in Japan lebt eCos weiter, die Leute erweitern es und integrieren es in neue Produkte.
ECos passte technisch einfach nicht in Red Hats Unternehmensfokus und daher waren wir der Ansicht, es wäre besser, eCos der Community zu übergeben und dieser damit die Möglichkeit zu geben, das Beste aus eCos zu machen, als dass eCos unsere Geschäftsergebnisse belastet.
Golem.de: Sie glauben also an eine einheitliche, Linux-basierte Plattform, von Embedded-Geräten und PDAs über PCs und Notebooks bis hin zu High-End-Servern?
Tiemann: Also ich würde nicht sagen, dass es unbedingt auf Linux basieren muss, aber unser Konzept einer Open-Source-Architektur basiert heute weitgehend auf Linux. Wir setzen vor allem auf offene Standards, um mit minimalen Anforderungen die größtmögliche Vielfalt an Applikationen und Wahlmöglichkeiten zu unterstützen.
Viele CIOs stellen ihren Leuten die gleiche Frage – "Was muss gleich sein, damit alles andere unterschiedlich sein kann?" – und das beschreibt die Idee einer Open-Source-Architektur recht gut. In dem Maße, wie es uns gelingt, eine kleine Menge an Standards zu finden, die jeder in den verschiedensten Bereichen und in den verschiedensten Implementierungen nutzt, wird auch die Open-Source-Architektur ein Erfolg werden.
Wenn aber jemand sagt, sein Produkt läuft nur auf Red Hat Enterprise Linux 3, dann ist das zum einen keine Architektur und zum anderen wird das ein großes Problem, wenn der Support für Red Hat Enterprise Linux 3 in fünf Jahren eingestellt wird.
Golem.de: Red Hat hat den Verkauf von Linux-Boxen an Endkunden eingestellt und unterstützt nun das Fedora-Projekt. Könnten Sie die Beziehung zwischen Red Hat und Fedora näher erläutern?
Tiemann: Red Hat entwickelt Fedora zusammen mit der Community. Unterstützen ist nicht ganz das richtige Wort – wir entwickeln Fedora, sind davon abhängig und wir investieren. Wir versuchen, mit Fedora zurück zu den Wurzeln von Innovation durch Open Source zu kommen und so ein Produkt ohne jegliche kommerziellen Erwartungen zu haben.
Laut IDC war Red Hat Linux von 1994 bis 2003 die erfolgreichste Linux-Distribution. Wir veröffentlichten die Distribution zweimal im Jahr und jedes Mal gab es eine Phase des Bugfixing mit geschlossenen und öffentlichen Beta-Tests und einer anschließenden Veröffentlichung. Aber auf Grund der Gewohnheiten im Handel kann man die Verfügbarkeit eines Produktes nicht ankündigen, das Release taucht einfach auf und jeder kauft es. Das Problem mit diesem Modell war aber, dass rund 50 Prozent der Zeit, in der wir mit der Community zusammen an Red Hat X hätten arbeiten können, wir dies aus diversen anderen Gründen nicht tun konnten. Wir versuchten, uns als Open-Source-Unternehmen zu verhalten, aber das Fenster für die Community war immer halb geschlossen, das ist, als müsste man mit einem Arm auf dem Rücken kämpfen.
Abgesehen davon war es sehr kostspielig, Support für die vielen Versionen anzubieten, die ständig auf den Markt kamen. Dennoch war es schwierig, Support für Unternehmensapplikationen anzubieten.
Wir hatten zwar eine Version, die für Oracle zertifiziert war und auch eine Version, die für SAP zertifiziert war, aber das waren zwei unterschiedliche Versionen von Red Hat Linux. Wenn also jemand fragte: "Auf welcher Version von eurem Betriebssystem kann ich SAP mit Oracle als Datenbank betreiben?", so war die Antwort: "Keine." Es gab nicht zwei Unternehmensapplikationen, die auf der gleichen Version von Red Hat Linux liefen, und das war ein großes Problem.
Wir konnten rund 20 Prozent der Aufgaben in einem Unternehmen, wie Datei- und Druck-Dienste, zu 80 Prozent der Kosten abdecken. Nur lernt man im BWL-Studium, dass es genau anders herum sein sollte.
Das haben wir dann 2003 geändert. Denn so gut wir in Bezug auf Open Source auch waren, wir wussten, wir können es besser. So erfolgreich Red Hat Linux geschäftlich gesehen auch war, wir wussten, wir können das besser. Wir begannen also, ein auf Unternehmen zugeschnittenes Release-Modell einzuführen, was bedeutet, die Release-Zyklen auf 12 bis 18 Monate zu erhöhen. Diese langen Release-Zyklen erlauben es Oracle und SAP, Veritas und BEA sowie insgesamt rund 750 Unternehmensapplikationen, auf einer Landebahn herunterzugehen. Damit haben wir heute ein wirkliches Produkt für Unternehmen.
Um nun auf die Frage "Was ist Fedora" zurückzukommen: Fedora ist die Design-Plattform für neue Open-Source- und Linux-Technologien. Es ist auf Robustheit ausgelegt, d.h. wenn ein Final-Release erscheint, dann ist das Red-Hat-geprüfte Qualität. Wenn wir also eine schlechte Version veröffentlichen, dann tut uns das genauso weh wie den Nutzern. Damit ist das zwar ein gutes Release, es gibt aber keine langfristigen Garantien. Es kann also sein, dass wir auf Grund eines Bugs 50 oder mehr Pakete zu aktualisieren haben, wir geben also die gleichen Garantien in Hinblick auf Abwärtskompatibilität und Stabilität wie bei unseren Enterprise-Produkten. Wir nehmen uns mehr Freiheiten, was wir wann aktualisieren.
Und wie ich schon eingangs sagte: Weder verkaufen wir es noch bieten wir Support. Wir wollen die Möglichkeit, die Open-Source-Community zu 100 Prozent einzubeziehen, in keiner Weise einschränken. Wir veröffentlichen früh, wir veröffentlichen offen, schauen nach vorn, anstatt Teile auf ältere Versionen zu portieren, und haben ein von der Community getriebenes Governance-Modell. Fedora deckt dadurch den Innovationsmarkt ab, während Red Hat Enterprise Linux an den Mainstream-Markt adressiert. Auch wenn es da gewisse Überschneidungen gibt.
Golem.de: War der Wechsel hin zu Fedora nicht auch eine Reaktion auf den Erfolg von Community-Distributionen wie Debian oder Gentoo?
Tiemann: Wie ich schon sagte, wir wussten, dass wir uns verbessern können. Wir wussten, dass die Kompromisse, die wir eingehen mussten, um Red Hat Linux wirtschaftlich so erfolgreich zu machen wie es war, zugleich die Kompromisse waren, die Red Hat Linux als Open-Source-Entwicklungsplattform Schaden zufügten. Als wir also begannen, auf Fedora zu setzen, war das unsere Art zu zeigen, wie Open Source bei Red Hat aussehen kann.
Fedora wird die Basis künftiger Versionen unserer Enterprise-Produkte darstellen. Es ist aber nicht notwendig, 10.000 Pakete zu unterstützen, und wir werden wohl nur rund 1.400 kommerzialisieren. Aber wir wollen sicherstellen, dass wir eine große Entwicklungs- und Test-Community haben, die sicherstellt, dass wir absolut auf der Höhe der Zeit sind.
Golem.de: Kernel-Entwickler Ingo Molnar von Red Hat hat kürzlich einen Patch(öffnet im neuen Fenster) für Linux 2.6 veröffentlicht, mit dem Linux Unterstützung für das No-Execute-Flag von AMDs 64-Bit-Prozessoren erhält. Was erwarten Sie von dieser Funktion?
Tiemann: Es gibt theoretische Exploits gegen Linux, und das sind in erster Linie Buffer-Overflow-Angriffe. Mit der Unterstützung des No-Execute-Bit können wir nun die Gefahr, dass Cracker diese Buffer-Overflows ausnutzen können, dramatisch reduzieren. Aber Sicherheit ist ein komplexes Gebilde, es gibt also keinen einzelnen Punkt, an dem man ansetzen kann. Wenn man aber verschiedene Sicherheitsschichten einzieht, die sich überlappen, erhält man früher oder später ein System, das sehr robust gegenüber verschiedenen Arten von Exploits ist.
Golem.de: AMD vermarktet No-Execute als Virenschutz für Windows-Systeme. Würden Sie sagen, das geht zu weit?
Tiemann: Von Zeit zu Zeit muss ich mich für Red Hats Marketing entschuldigen, aber ich werde mich zu keiner Zeit für das Marketing eines anderen Unternehmens entschuldigen. (lacht)
Golem.de: Ich habe kürzlich ein Interview mit Red-Hat-CEO Suzlik gelesen, in dem er sagt, man habe Fedora in die Public Domain gegeben. Nun kann ich mir das eigentlich nicht wirklich vorstellen, denke aber, gerade er sollte den Unterschied zwischen Public Domain und GPL-Software kennen?
Tiemann: Stimmt, er sollte den Unterschied kennen. Wir haben Fedora zu 100 Prozent zu einem Open-Source-Release gemacht. Ich sage bewusst nicht Produkt und auch nicht Lösung. Es gab einige Kritik von Leuten, die sagten, Fedora sei komplizierter zu nutzen, da sie einige Teile wie den proprietären Adobe Acrobat Reader selbst herunterladen müssen. Aber es war eine ganz bewusste Entscheidung, nur Open-Source-Software in Fedora zu integrieren, denn wir wollten sehen, wie weit wir noch vom Ziel einer reinen Open-Source-Distribution entfernt sind, wie es also in einer reinen Open-Source-Umgebung aussieht. Aber ich denke nicht, es ist richtig, das als Public Domain zu bezeichnen – es ist für jeden zugänglich, es ist 100 Prozent Open Source.
Golem.de: Sie sprechen dabei von Open Source, nicht von freier Software. Hat das einen Grund?
Tiemann: Code unter der GPL ist freie Software, aber es gibt einige Teile, die unter Open-Source-Lizenzen stehen, die keine freien Software-Lizenzen sind. Als ich die Distribution vor rund einem Jahr das letzte Mal dahingehend überprüft habe, waren 74 Prozent aller Programme freie Software unter der GPL.
Golem.de: Sie verfolgen mit Fedora also einen reinen Open-Source-Ansatz, aber eine Kerntechnologie, die auch Red Hat in anderen Bereichen einsetzt, ist heute nicht Open Source: Java. Wie ist ihre Einstellung bezüglich Forderungen, Java zu Open Source zu machen?
Tiemann: Ich habe auf der Eclipse-Konferenz vor rund vier Monaten einiges darüber gesagt, warum Sun bei Java schlechte Arbeit leistet und damit die Open-Source-Community entzweit. Es gibt die eine Seite, die der Meinung ist, dass Java eine akzeptable Sprache ist, um Open-Source-Applikationen oder freie Software zu schreiben und die anderen, die der Meinung sind, Java sei eine proprietäre Plattform und mache es unmöglich, freie Software zu schreiben.
1986, als Richard Stallman begann, GNU zu schreiben, tat er dies auf Sun-Maschinen mit Sun-Compilern und das war in Ordnung, denn sein Ziel war es, einen freien Compiler und dann ein freies Betriebssystem zu schreiben. Meiner Meinung nach ist es absolut in Ordnung, proprietäre Software zu nutzen, um freie Software zu schreiben.
Würde Red Hat Java ohne Aussicht auf eine wirklich freie Java-Plattform unterstützen, dann würde ich den Kritikern Recht geben. Da wir uns aber verpflichtet haben, an einer wirklich freien Open-Source-Java-Plattform zu arbeiten, ist es in Ordnung, dass wir den Teil der Community mit einbeziehen, der freie Software in Java schreiben will.
Golem.de: Sie sagen also, Sun macht einen schlechten Job bei der Weiterentwicklung von Java, und würden eine Open-Source-Version bevorzugen?
Tiemann: Wenn man liest, was Eric Raymond geschrieben hat und was IBM geschrieben hat, dann rufen Sie Sun öffentlich dazu auf, die "Mauer einzureißen". Sun hat sich immer dagegen gewehrt dies zu tun, sich aber widersprüchlich dazu geäußert. Am besten finde ich dabei die Aussage, Red Hat habe Linux proprietär gemacht, während Sun Java als Open Source erhalten habe.
Golem.de: Was denken Sie über GCC heute, wenn man sich ansieht, dass proprietäre Compiler wie die von Intel laut Benchmarks eine deutlich höhere Leistung von teilweise 8 bis 10 Prozent versprechen?
Tiemann: Zwei Dinge: Zum Ersten hat vor kurzem Diego Novello, ein GCC-Entwickler, der bei Red Hat angestellt ist, angekündigt, dass Tree-SSA(öffnet im neuen Fenster) in den offiziellen Entwicklungsbaum von GCC 3.5 aufgenommen wurde. Dieses Projekt wurde über einige Jahre entwickelt, ungefähr seit ich aufgehört habe, Code für GCC zu schreiben. Dies ist die Schlüsseltechnologie für GCC, um in Bezug auf Vektorisierung und Software-Pipelining und andere exotische Funktionen Fortschritte zu machen, die notwendig sind, um Leistungssteigerungen auf Prozessorarchitekturen wie IA-64 zu erlangen. Damit wird ein großer Entwicklungszweig nun sichtbar. Und ich denke, dass Open-Source-Modell wird dafür sorgen, dass GCC hier in Zukunft weitere Fortschritte macht.
Zum Zweiten kenne ich auch diese Benchmarks, aber auch Kunden, die festgestellt haben, dass ihre eigenen Applikationen durch proprietäre Compiler schneller werden. Wir haben aber mit einigen Nutzern von Supercomputern und großen Clustern zu tun, und die haben mir gegenüber gesagt, dase es unmöglich ist, dauerhaft 8 bis 10 Prozent mehr Leistung mit proprietären Compilern zu erreichen.
Es bedarf einigen manuellen Tunings, um solche Zahlen zu erreichen und natürlich werden diese Compiler auch auf die Benchmarks hin optimiert.
Golem.de: Der Ansatz, den GCC dabei aber verfolgt, konzentriert sich nicht nur auf einige wenige Plattformen, oder?
Tiemann: Richtig. Jede Plattform wird davon profitieren, Software-Pipelining beschleunigt jede Plattform, die zwei oder mehr Kerne unterstützt, was praktisch alle angekündigt haben und was PowerPC schon heute tut.
Es ist wahr, dass die proprietären Compiler-Hersteller viel Geld zur Verfügung haben, um es in ihre proprietären Compiler zu investieren, aber GCC hat sich in der Vergangenheit wiederholt gegen ernst zu nehmende Wettbewerber durchgesetzt. Die Änderungen, die durch Tree-SSA jetzt Einzug in GCC halten, stellen, wenn man sich Diegos Ankündigung ansieht, fast eine komplette Neuentwicklung von GCC dar.
Golem.de: Wo liegen heute die größten Probleme für Open Source und freie Software?
Tiemann: Probleme? Es ist immer schwierig, über die Probleme zu reden, wo es doch so viele Möglichkeiten gibt!
Golem.de: Dann lassen Sie uns über die Möglichkeiten sprechen.
Tiemann: Es gibt große Möglichkeiten im Bereich der Unix-zu-Linux-Migration, denn das spart den Leuten Geld und erlaubt Leistungssteigerungen, wo sie zuvor auf einem Leistungsniveau festsaßen. Und es passiert, da sich so zwei CPUs durch eine ersetzen lassen, was wiederum Lizenzkosten spart und zu Rechenzentren führt, die sich einfacher steuern lassen.
So lange wir beobachten können, dass Milliarden US-Dollar für proprietäre Unix-Technologien ausgegeben werden, gibt es Chancen in Milliardenhöhe für Unix-zu-Linux-Migrationen.
Eine der größten Herausforderungen ist aber der Desktop. Auch wenn die Community schon lange daran arbeitet, haben wir damit gerade erst angefangen, beispielsweise mit unserer Ankündigung des Red Hat Linux Desktop. Ich denke, die Desktop-Migration wird wirklich eine Herausforderung.
Die Migration bei Desktops beginnt aus einer Vielzahl von Gründen: Einige machen es, um einen höheren Grad an Sicherheit zu bekommen, einige machen es, um die Verwaltung der Rechner zu vereinfachen, einige um mehr Flexibilität oder eine bessere Verhandlungsposition zu erreichen, einige denken an geringe Kosten. Wie auch immer die Gründe liegen, die Herausforderung liegt darin, dass seit Jahren ein Monopol existiert und je näher man sich dem Desktop nähert, desto größer wird die Macht des Monopols.
Das Open-Source-Modell hat gute Dienste geleistet, proprietäre Software im Server-Bereich zu verdrängen. Mein Notebook läuft seit Jahren unter Linux, es ist also keine Frage, ob es funktioniert. Ich glaube aber nicht, dass große Unternehmen mit Milliardenumsätzen einfach auf Linux umsteigen, nur weil es die bessere Lösung ist. Auch wenn das aus einer makroökonomischen Perspektive für jede Volkswirtschaft der Welt die beste Lösung wäre.
Golem.de: Dann muss sich aber einiges geändert haben. Noch im letzten Jahr hieß es bei Red Hat, der Desktop sei kein Thema?
Tiemann: Nun, die Dinge ändern sich. Noch im Jahr 2001 sagte ich vor Gericht, dass, wann immer ich einem Kunden, der gute Erfahrungen mit Linux im Server-Bereich gemacht hatte, auf eine Desktop-Migration ansprach, das Treffen vorbei war. Das war wie eine rote Linie, und sobald man nur in deren Richtung schaute, flog man raus.
Für mich war das kein rationales Verhalten von Geschäftsleuten, und das wurde auch im Kartellverfahren gegen Microsoft untersucht. Wenn man also zu dieser Zeit zu einem Kunden ging, um das Thema Desktop anzusprechen, flog man raus; glauben Sie, das ist ein guter Markt, in dem man sich bewegen sollte? Nicht wirklich.
Aber die Dinge haben sich geändert, unter anderem, da die Open-Source-Community fantastische Arbeit geleistet hat, die man heute nicht mehr ignorieren kann. Zudem hat sich das Marktumfeld verändert. Auch die anhaltenden Sicherheitsprobleme und andere technische Unzulänglichkeiten haben ihren Teil dazu beigetragen. Es wird also immer klarer, dass der Kaiser keine Kleider trägt.
Waren diese Fragen vor drei Jahren noch ein absolutes Tabu, rufen mich die Kunden heute zurück und fragen gezielt danach.