Die Woche: Virtualisierung, SCO, offene Standards

Inhaltsverzeichnis

Es gibt Wochen, da fällt es schwer, überhaupt ein Thema für diese Kolumne zu finden – es passieren nun mal nicht jede Woche sensationelle Dinge in der Welt. Und es gibt Wochen wie diese, da kann man sich kaum entscheiden, worüber man schreiben möchte. Daher jetzt einfach ein paar Worte zu verschiedenen Themen.

Virtualisierung

Nachdem Red Hat bereits im letzten Jahr mit der Einführung seiner neuen Virtualisierungsprodukte und folgerichtig dann auch mit Red Hat Enterprise Linux 5.4 den Umstieg von Xen zu KVM eingeleitet hat, zieht Novell jetzt nach: Ab dem Service Pack 1 für Suse Linux Enterprise 11 unterstützt der Linux-Anbieter ebenfalls KVM als Alternative zu Xen. Natürlich garantieren beide Distributoren ihren Kunden weiterhin Support für ihre Xen-Installationen, aber der allgemeine Trend – weg von Xen, hin zu KVM – ist deutlich. Auch Ubuntu beispielsweise liefert KVM als Kernbestandteil der Distribution mit, während Xen als nicht offiziell unterstützte Community-Software im Universe-Repository steckt.

Dass KVM in der Linux-Welt das Rennen macht, hat einen einfachen Grund: KVM ist ein Bestandteil des Linux-Kernels; genauer gesagt: KVM macht den Linux-Kernel zum Hypervisor. Der Xen-Hypervisor hingegen wird außerhalb des Kernels gepflegt, lediglich die Gasterweiterungen, die Linux für den Betrieb unter Xen optimieren, gehören zum Kernel.

Der KVM-Ansatz hat zwei Vorteile. Der erste ist technischer Art: Während für den Xen-Hypervisor eine Menge Code zum Ansteuern von CPU und Chipsatz neu geschrieben werden muss, kann KVM einfach die Infrastruktur des Kernels nutzen. Dinge wie Powermanagement oder Treiber für neue Chipsätze fallen KVM damit gewissermaßen in den Schoß, während die Xen-Entwickler sie eigens implementieren müssen.

Der zweite Vorteil ist organisatorischer Art: Da KVM von den Kernel-Entwicklern gepflegt wird, ist es selbstverständlich in jeder Kernel-Version enthalten. Der Xen-Hypervisor hingegen arbeitet nur mit ausgewählten Kerneln zusammen; will ein Distributor eine andere Kernel-Version verwenden, muss er sich selbst um die Anpassung des Codes kümmern.

Angesichts dieser beiden Vorteile spielt es (zumindest aus Sicht der Linux-Distributoren) kaum eine Rolle, dass KVM als die jüngere Technologie nicht so ausgereift ist wie Xen und bei den Features noch nicht mithalten kann. Den Rückstand, so die Überlegung, wird KVM schnell aufholen – und bis dahin bietet man Kunden, die mit KVM nicht glücklich werden, eben noch Xen an.

Damit ist aber auch klar: Red Hat und Novell werden Xen noch auf Jahre unterstützen – trotz des Schwenks auf KVM.

SCO und kein Ende

Das Urteil ist gesprochen: Ein Geschworenengericht hat entschieden, dass Novell das Copyright an Unix hält, nicht die SCO Group. Damit, so sollte man meinen, ist den diversen Klagen von SCO ebenso die Grundlage entzogen wie dem ulkigen Geschäftsmodell, Lizenzgebühren für Software anderer Hersteller zu fordern (die sogenannten Antidot-Lizenzen für Linux, die in Art eines Schutzgeldes vor einem Überfall, pardon, einer Klage schützen sollen). SCO ist ja schon lange bankrott, die jüngste Niederlage vor Gericht sollte damit eigentlich nur noch den endgültigen Schlusspunkt der unendlichen Geschichte markieren. Oder?

Weit gefehlt. Denn SCO will weitermachen. Wie die Prozessbeobachter von Groklaw berichten, hat Konkursverwalter Edward Cahn, ein ehemaliger Richter, bereits neue Ideen. Den Prozess gegen IBM will man mit nur leicht geänderter Argumentation fortführen: Dass IBM Unix-Code in den Linux-Kernel habe einfließen lassen, soll jetzt nicht mehr SCOs Urheberrechte am Code verletzt haben (diese Rechte hat SCO nach dem jüngsten Urteil ja nicht); stattdessen habe IBM damit SCOs Geschäfte geschädigt, wofür Big Blue jetzt Schadenersatz leisten soll.

Und auch SCO-Anwalt Stuart H. Singer hat eine neue Idee ausgebrütet: Wenn die Verträge von anno dazumal das Unix-Copright nicht an SCO übertragen haben, wie es die Geschworenen entschieden haben, soll der Richter eben jetzt SCO das Unix-Copyright einfach zusprechen. Quasi nach dem Motto: Damals haben wir nicht aufgepasst, aber moralisch sind wir trotzdem im Recht.

Wir können also mit einer weiteren Staffel "SCO vs. Linux" rechnen.

Offene Standards

Während es mir zugegebenermaßen schwer fällt, angesichts der Verrenkungen von SCO nicht ins Spotten zu verfallen, sind offene Standards ein ernstes Thema. Am vergangenen Mittwoch war Document Freedom Day, eine weltweite Veranstaltung, die auf die Wichtigkeit von offenen Standards vor allem (aber nicht nur) bei den Dateiformaten hinweisen möchte. Wie nötig das ist, zeigt die Diskussion um die gerade entstehende Version 2 des European Interoperatibility Framework (EIF), die in Sachen offenen Standards weit hinter der aktuellen Version zurückbleibt – dank der Lobby-Arbeit einiger Software-Hersteller.

Bei offenen Standards geht es um viel mehr als um die Frage "Linux vs. Windows" oder "Open Source vs. proprietäre Software" (auch wenn die Diskussionen um offene Standards häufig in diesem Kontext geführt werden). Offene Standards bedeuten vor allem Wahlfreiheit für Anwender: Wenn zwei Programme den gleichen Standard unterstützen, sind sie gegeneinander austauschbar; und wenn es sich um einen offenen Standard handelt, kann jeder ein solches Programm schreiben. Proprietäre Dateiformate und Kommunikationsprotokolle, die nur von einem Hersteller implementiert werden können, machen den Anwender von diesem Hersteller abhängig, sobald wichtige Daten oder Prozesse dieses Format oder Protokoll verwenden.

Nicht oder nicht vollständig offen gelegte Formate und Protokolle sowie proprietäre Erweiterungen von Standards sind daher ein probates Mittel von Software-Herstellern, um Anwender an die eigenen Produkte zu binden. Beispiele dafür gibt es zuhauf, und Microsoft ist keineswegs das einzige Unternehmen, das so arbeitet. Das Beharren auf offenen Standards ist daher keineswegs eine praxisferne, womöglich rein ideologische Diskussion, sondern ganz entscheidend, ob Anwender flexibel über ihre Software-Infrastruktur verfügen können – oder in "Sachzwängen" stecken, aus denen sie sich nur mit hohem Aufwand befreien können.

So gesehen, können offene Standards eine Menge Geld sparen. (odi) (odi)