 "Aufmacher Artikel")
Usability im LinuxUser
Am Thema "Usability", also: Benutzungsfreundlichkeit, dürfte sich das Schicksal von Linux auf dem Desktop auf lange Sicht entscheiden. Grund genug, ihm eine monatliche Kolumne zu widmen, in der wir Open-Source-Projekte mit Blick auf ihre Benutzbarkeit diskutieren.
Es ist gar nicht schwierig, selbst eingefleischte Windows-Nutzer für Linux zu begeistern. Doch wenn die Frage nach der nachträglichen Installation von Programmen kommt, gerät man schnell in die Defensive. Dabei geht es gar nicht so sehr um die Verfügbarkeit von Software, sondern vor allem um die Einfachheit der Installation. An dieser Stelle fällt es schwer, ruhigen Gewissens zu sagen, Linux sei inzwischen so benutzungsfreundlich, dass auch "normale" Nutzer nicht ständig den Guru von Nebenan holen müssen, um z. B. die neueste Version eines Instant Messengers zu installieren.
Linux wird sich auf dem Desktop aber nur dann durchsetzen, wenn Installation und die anschließende Nutzung beliebiger Programme einfach und intuitiv funktionieren. Ein guter Grund, sich die möglichen Installationswege aus dem Blickwinkel der Benutzungsfreundlichkeit näher anzusehen.
Das Leid mit den Abhängigkeiten
Der Maßstab, an dem sich die Installationsroutinen messen müssen, ist für die meisten Nutzer ein Klick (auf die Setup-Datei unter Windows) oder Drag&Drop (in den Programmordner unter MacOS X). Die wenigsten Anwender möchten wissen, was das System im Hintergrund tut. Stattdessen soll das Programm einfach "laufen". Nicht die Installation ist das Ziel, sondern die Software-Nutzung.
Kasten 1: Abhängigkeitsprobleme und ihre Ursachen
Open-Source-Software wird laufend aktualisiert. Nicht das Release steht dabei im Vordergrund, sondern die ständige Entwicklung. Dabei verzichten Entwickler oft auf Abwärtskompatibilität z. B. zugunsten eines besseren inneren Aufbaus ihrer Software: Eine neuere Version einer Bibliothek oder eines Programms bringt dann zwar interne (und auch äußerliche) Verbesserungen mit, bricht aber die Kompatibilität zur Vorgängerversion und macht im schlimmsten Fall ein Upgrade aller auf dem System installierten Pakete, die diese Bibliothek verwenden, notwendig.
Ein weiteres, gängiges Problem besteht darin, dass Paketersteller die Paketverwaltung des Systems aus rein praktischen Erwägungen heraus "missbrauchen", um Pakete miteinander zu verbinden, die nicht unbedingt zusammengehören. Solche künstlichen Abhängigkeiten, "synthetic dependencies", führen z. B. dazu, dass Bibliotheken gesucht, heruntergeladen und installiert werden müssen, die man gar nicht unbedingt benötigt.
Zum Beispiel verknüpfen die Live-Distributionen Morphix und Knoppix ihre GTK+2-Pakete so mit KDE, dass das Entfernen von GTK die Deinstallation von KDE zur Folge hat. Dabei basieren KDE-Programme gar nicht auf GTK, sondern auf dem Qt-Toolkit. Die Verknüpfung zwischen den beiden Bibliotheken haben die Paketersteller künstlich erzeugt. Über die Gründe könnte man spekulieren, letztendlich bleibt jedoch die Tatsache, dass diese Abhängigkeit unnötig ist und dass das Paketmanagement hier nicht bestimmungsgemäß arbeitet.
Unter Linux kann der Weg dahin mitunter sehr schwierig sein. Dies liegt vor allem an der Art und Weise, wie Distributoren mit Programmen und Bibliotheken umgehen, die bei einer Software-Installation benötigt werden (siehe Kasten 1). Fehlen diese Pakete, müssen sie "irgendwie" nachinstalliert werden. Stehen sie mit bereits installierten in Konflikt (z. B. weil eine neuere Version verlangt wird), bleibt für die meisten Nutzer nur der Abbruch oder das erzwungene "Drüberinstallieren", das zu einem inkonsistenten System führen kann.
Wir untersuchten daher vier aktuelle Distributionen daraufhin, wie leicht sie es dem Nutzer machen, Programme nachzuinstallieren, und welchen Weg sie gehen, um besagte Schwierigkeiten zu umschiffen. Das Kandidatenfeld umfasste Fedora Core 2 (mit Gnome 2.6, deutsch), Suse 9.1 und Mandrake 10.0 (beide mit KDE 3.2, deutsch) sowie Xandros Desktop 2.0 (Free Circulation Version, englisch). Beim Test kamen Standard-Pakete, die für den Desktop-Einsatz angeboten werden, zum Einsatz.
Ausgehend von RPM
Unter Windows und MacOS X orientieren sich die Installationsmechanismen überwiegend an Dateien: Der Installationsprozess startet durch das Ausführen einer Datei. Analog überprüften wir zunächst, wie die verschiedenen Distributionen mit einem lokal verfügbaren RPM-File umgehen. Dieses enthält die Binärdateien sowie im Idealfall alle Informationen, um das Programm zu installieren.
Liegt die RPM-Datei bei Suse durch ein Icon repräsentiert auf dem KDE-Desktop, so öffnet ein Doppelklick einen Dialog, aus dem der Nutzer auswählen soll, mit welchem Programm er die Datei öffnen will. Hier muss er wissen, dass der passende Eintrag SystemYaST heißt. Besser sieht die Sache bei einem Rechtsklick auf das Desktop-Icon der RPM-Datei aus: Dann bietet das Kontextmenü den Punkt AktionenMit YaST installieren an.
Doppelklickt man hingegen im Konqueror auf eine RPM-Datei, so wird sie in KRPMView angezeigt. Hier findet man an prominenter Stelle einen Button mit der Aufschrift Mit YaST installieren bzw. Install package with YaST. Wie sich das RPM grafisch installieren lässt, hängt also vom Kontext ab und verlangt drei verschiedene Verhaltensweisen. Intuitiv ist so etwas sicher nicht.
Unter Xandros, das sich einfacher Benutzbarkeit rühmt, ruft ein Doppelklick auf ein RPM-Icon auf dem Desktop direkt das Xandros Network auf, die Software-Verwaltung der Distribution. Dagegen führt ein Klick im Dateimanager (dem Xandros File Manager, hinter dem sich im Grunde KDEs Konqueror verbirgt) zu einem Dialog, der die Optionen Inhalt anzeigen und Xandros Network anbietet. Ähnlich wie bei Suse und YaST muss der Nutzer wissen, dass damit die Software-Verwaltung bzw. der Installer gemeint ist.
Mandrake startet nach einem Klick auf das RPM-Icon sowohl auf dem Desktop, als auch im Konqueror sofort RPMDrake und verlangt das Administrator-Passwort. Wofür, bleibt an dieser Stelle unklar und wird nicht kommuniziert. Das Kontextmenü bietet den Punkt RPMDrake an. Auch hier muss man wissen, dass damit das Installationsprogramm gemeint ist.
Fedora verknüpft mit RPMs standardmäßig keine Anwendung. (Dabei handelt es sich um einen Fehler der Gnome-Version [1].) So erwartet den Nutzer nach Doppelklick oder im Kontextmenü ein Verzeichnisdialog, in dem er den Eindruck bekommt, das entsprechende Programm selbst suchen zu müssen (Abbildung 1). Erst nach einem weiteren Klick bekommt er die passenden Werkzeuge angezeigt. Von Benutzerführung kann hier definitiv nicht gesprochen werden.
Abbildung 1: Fedora zeigt standardmäßig kein passendes Programm im Kontextmenü an.
Einem Freund empfehlen
