Eigentlich wollte ich ja keine der drei großen Distributionen testen, da es für diese schon genügend gute und tiefgründige Reviews gibt. Aber der KDE4-Remix von Kubuntu 8.04 “Hardy Heron” reizte mich dann doch zu sehr. Schließlich hat KDE4 seit Januar auch wieder erhebliche Fortschritte gemacht und dies wäre die erste große Distribution, welche (wenn auch nur als Remix) ein pfannenfertiges KDE4 mitliefert.
Der Review wird sich daher eher auf KDE4 und dessen Status resp. Integration in Kubuntu als auf die Distribution selbst fokussieren, da es bereits genügend andere Reviews gibt und geben wird, welche die Distribution tiefgründiger und professioneller betrachten.
Herkunft / Ursprung
Ubuntu und dessen Geschwister Kubuntu, Xubuntu, Edubuntu haben ein Debian 4 als Basis und werden von der Firma Canonical und einer großen Community weiterentwickelt. Canonical wurde vom Milliardär Mark Shuttleworth gegründet bietet einen kommerziellen Support für Desktop- und Serverversionen an, mit dem irgendwann auch mal Gewinn gemacht werden soll.
Package-Management: Apt-get mit Debian Paketen (dpkg)
Release-Zyklus: halbjährlich
Standarddesktop: Je nach Geschmacksrichtung (Gnome, KDE, XFCE), kann aber später auch jederzeit gewechselt werden
3D-Desktop / Desktopeffekte: Teilweise integriert in KDE4-Windowmanager (kwin) mit Compositing oder Compiz-Fusion basierend auf AIGLX oder XGL
Kosten für Updates und Support: Keine (Wiki, Foren)
Lizenz: Größtenteils GPL V.2, proprietäre Software und binäre Treiber sind in der Grundinstallation vorhanden
Besonderheiten dieser Version
Die Einbindung von KDE4 ist natürlich die wichtigste Besonderheit dieser Version mit Betonung der Distributionshersteller, dass es sich um eine Remix-Version mit Beta-Status handelt.
Erster Eindruck vom Desktop
Der Standarddesktop hat sich seit dem Frühjahr nicht groß geändert. Leider wurde auch dasselbe Hintergrundbild verwendet. Ich schaue neidisch auf den Ubuntu-Desktop und wünsche mir, dass ein ähnliche künstlerisches Hintergrundbild bald den Weg in die KDE-Versionen findet.
Hat man einmal die zusätzlichen Plasmoiden installiert, machen diese wider erwarten sogar Spass (solange sie nicht auf allen virtuellen Desktops rumhängen), vor allem die täglichen Userfriendly Comis sind praktisch. Auch die von Vista bekannte Diaschau ist dabei und vieles mehr:
Als nächsten Schritt in der vollständigen Migration aller Services auf virtuelle Server mit Xen wollte ich wegkommen von den unhandlichen Image-Dateien, welche niemals konsistent gesichert werden können und auch keine schnellen Zugriffszeiten bieten. Nach kurzem Überlegen und bestätigt durch Erfahrungen anderer Admins gab es einen einfachen Weg: LVM der Logical Volume Manager von Linux eignet sich dafür bestens. Der Hauptgrund war erst, dass man sogenannte “Snapshots” von einem aktiven logischen Volume machen kann. Dieser Snapshot ist quasi statisch und repräsentiert somit einen konsistenten und permanenten Zustand der Daten zum Zeitpunkt der Erstellung dieses Snapshots. Dadurch wird das Erstellen von konsistenten Backups sehr erleichtert. Wie sich zeigte, löste der Umstieg auf LVM aber auch noch ein anderes altbekanntes Problemchen…
Das I/O-Wait Problem wird entschärft
In all den Jahren meines beruflichen und privaten Umgangs mit Computersystemen war es immer wieder dieser Flaschenhals, der die größten Performanceprobleme machte: I/O Wait: Der Prozessor wartet auf den Festplattencontroller, bis dieser seine Lese- oder Schreiboperation vollständig abgeschlossen hat.
Auch für meinen Backupserver (Backups via NFS und rsync) hiess das immer wieder Warten mit bis zu 90% I/O Wait, was den Server praktisch unbrauchbar macht für weitere Tätigkeiten. Mit den VM’s auf LVM fiel mir nun auf, dass die DomU’s zwar auch bis zu 100% I/O Wait haben, dass aber das Wirtssystem indessen keinen bis ganz wenig I/O Wait aufweist. Vermutlich liegt dies daran, dass die DomU gar nicht direkt auf die Hardware zugreift (obwohl im Endeffekt dieselben Backups auf dieselbe externe USB-Disk geschrieben wird bei mir). Auch die Geschwindigkeit, in der diese bis 20GB grossen Backups geschrieben sind, scheint mir subjektiv nicht viel kleiner zu sein als zuvor.
Ich bin kein Kernelspezialist und kann daher nur vermuten, dass die I/O-Wait-Last deswegen geringer ist, weil der Dual-Core in diesem Setup besser zur Geltung kommt, da die VM gezwungenermassen nur auf einem Kern läuft (je nach Konfiguration natürlich) und das Wirts-Betriebssystem nach wie vor 1-2 Kerne zur Verfügung hat (je nach Last). Man möge mich bitte aufklären, falls es andere Gründe sind, die zum besseren I/O-Wait-Verhalten führen.
Mir scheint fast, als sei Virtualisierung so etwas wie der Stein der Weisen, wenn es um die Gleichzeitigkeit von lese- und schreibintensiven Operation und anderen Services auf einer einzigen Maschine geht.
Auf dem Bild ist zu sehen, dass der Xen-Wirt (oberer Teil) nur sehr wenig I/O-Wait aufweist, während die VM (unterer Teil) praktisch nur noch I/O-Wait hat:
Im Rahmen meiner RHCE-Ausbildung hatte ich das erste Mal die Gelegenheit, Xen-Installationen für den “professionellen” Einsatz einzurichten. Die überraschend gute Performance auch bei mehreren Instanzen auf einem einzelnen Rechner hat mich sehr beeindruckt. Diese Performance erreicht man indes nur, wenn die virtuellen Maschinen “paravirtualisiert” sind, also dann wenn nicht nur das Wirts- sondern auch das Gastsystem einen Xen-angepassten Kernel verwendet, der gegenseitig kompatibel ist.
Mein Spieltrieb für zu Hause war geweckt. Nach und nach migrierte ich also alle Services themenorientiert auf vier verschiedene sog. DomU’s (unprivilegierte Domains = virtuelle Maschine = Gastsystem, alles austauschbare Begriffe) unter einem CentOS 5.1 Wirts-Server. Dazu benötigt man unter den Redhat Derivaten folgende Komponenten: Xen-Kernel, libvirtd und xend. Dank yum reicht eigentlich ein “yum install kernel-xen” und man hat im Handumdrehen alle notwendigen Werkzeuge für die Virtualisierung zur Hand.
Nach anfänglichen Abhängigkeitsproblemen zwischen den VM’s (oder besser Anfängerfehler, denn das der DNS-Server als erster gestartet werden sollte, müßte mir klar gewesen sein…) kann ich bestätigen, dass die Virtualisierung auch für den kleinen Server im Keller zu Hause durchaus Sinn machen kann. Ich kann nichts über komplexere Applikationen wie Oracle u.ä. sagen aber die Antwortzeiten von LDAP, DHCP, DNS, FTP etc. sind praktisch identisch zu ihren Pendants direkt auf physischen Servern. Auch netzwerktechnisch gesehen ist die Antwortzeit (Ping-Messung) identisch zu einem klassischen Server.
Den Overhead durch die Verwaltung von 4 gleichzeitig laufenden virtuellen Maschinen kann ich indes nur schätzen resp. beobachten. Im Leerlauf sind es zur Zeit nicht mehr als 5-15% des Wirtsystems, die verbraucht werden. Durch die Erweiterung von 2 auf 4 oder gar 6 GB Arbeitsspeicher erhoffe ich mir einen weiteren Leistungsgewinn, da die Resourcen im Moment doch etwas knapp zu sein scheinen, vor allem der Wirt selber hätte etwas mehr Arbeitsspeicher verdient. Die durch den Einsatz des Xen-Kernels fehlende CPU-Geschwindigkeitsregelung (das cpu-ondemand Kernelmodul gibt’s noch nicht für den Xen-Kernel) wird mehr als aufgehoben durch die Tatsache, dass bei mir der 2. Server nicht mehr ständig laufen muss (naja, zumindest sobald ich mir für das Backup resp. NFS/SMB auch eine Lösung geschnitzt habe).
Eine Live-Migration der Server bei einem Ausfall habe ich noch nicht getestet, sobald beide Server RAM-technisch aufgerüstet sind, werde ich dies aber vermutlich in Angriff nehmen. Eine gewisse Flexibilität ist sowieso gegeben, wenn man z.B. wöchentlich die virtuellen Disk-Imagedateien sichert und diese auf einen zweiten Server transferiert. Dann muss im Falle eines Ausfalls des ersten Servers dort nur noch die virtuelle Maschine gestartet werden und schon ist der Service (z.B. FTP) wieder einsatzbereit, ganz ohne weitere Eingriffe in DNS oder DHCP. Dies alleine bedeutet schon einen enormen Fortschritt an Unabhängigkeit im Vergleich zu Server-gebundenen Diensten oder klassischen Failover-Lösungen, da der Server an sich nur noch aus einer Disk-Imagedatei und der Xen-Konfigurationsdatei besteht.
Fazit
Abgsehen vom Aufwand, die VM’s einzurichten, empfinde ich den Serverbetrieb nun als ziemlich aufgeräumt und elegant. Habe ich irgendwo ein Problem, kann ich es auf die betreffende VM eingrenzen. Und auch der Aufwand für die Einrichtung der VM’s lässt sich in engen Grenzen halten, wenn man die Installation mit Kickstart-Konfigurationen, DHCP-vergebenen Adressen sowie mit Netzwerk-Images weitgehend automatisiert.
Hier noch ein Beispiel des virt-install Aufrufes für eine solche automatische Installation. Wenn man das grafische Werkzeug virt-manager zur Einrichtung einer DomU nimmt, geschieht im Hintergrund so ziemlich dasselbe wie hier von Hand:
Bei Distrowatch habe ich heute eine lustige Distribution “Famelix” aus Brasilien gefunden (die Webseite ist leider nur auf Portugiesisch und Spanisch). Das besondere an dieser Distribution ist, dass sie das Hauptaugenmerk auf das exakt gleiche Aussehen wie die entsprechenden Windows-Versionen legt.
Die Version 1.3 “Professional” sieht aus wie XP und die Version 2.0 “Hast la Vista” wie der Name schon sagt wie Vista. Die Screenshots beweisen, dass dies zum größten Teil gelungen ist.
Nur: Wollen wir das überhaupt? Muss Linux wirklich wie die “Konkurrenz” aussehen, um Desktopbenutzer zu gewinnen? Ist es der Sinn der Sache, den Windows-Umsteigern mit einem Klon den Umstieg leichtzumachen? Vielleicht, aber es birgt meines Erachtens einige Tücken:
Die Benutzer werden teilweise der Meinung sein, es handle sich um Windows, mit welchem sie arbeiten. Es gäbe also kaum ein Bewusstsein für das benutzte Betriebssystem
Sie würden erwarten, dass alles gleich aussieht und funktioniert für die nächsten 7 Jahre (was bei Windows ja bei jeder Version der Fall ist). In der Linux-Welt ist nach 7 Jahren aber kein einziges Programm mehr wirklich dasselbe.
Benutzer könnten in Versuchung kommen, irgendwelche Windows-Software zu installieren (das mag ja sogar bei 30% mit wine funktionieren)
Ich persönlich würde sowas nie einsetzen, weshalb ich auch auf einen Test verzichte. Wenn ich eine Firma auf Linux-Desktops umrüsten müßte, so würde ich den Fokus eher auf die Applikationen richten und nicht auf das Aussehen der Betriebssystemoberfläche und des Fensterdekorateurs. Dennoch ist die Arbeit der Entwickler sehr beeindruckend, mit KDE4 konnten sogar die Desktop-Applets umgesetzt werden, auch Aero wurde offenbar perfekt geklont, wenn ich den Screenshots im oberen Teil der Webseite glauben darf (ich nehme mal an mittels Compiz-Fusion).
Chris on 
Hans Harald on 
Janu on