Auf eigene Gefahr?

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.

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.

Installationsmanager

Neben diesen Anfängen des dateizentrischen Ansatzes steht bei allen Distributionen der unter Linux gängige, programmzentrische Weg zur Auswahl: Dieser führt vom Aufruf des Installations- oder Softwaremanagers über die Wahl des gewünschten Programms zur Installation. Fedora und Xandros sehen ihn als den einzigen "normalen" Weg an, bei Suse/YaST bietet er zahlreiche Einstellungs- und Kontrollmöglichkeiten, bei Mandrake fällt er sehr eingeschränkt aus.

So implementiert Suse die Software-Verwaltung als einen Teil von YaST. Leider bietet das unter SoftwareSoftware installieren oder löschen zu findende Installationsmodul keine Möglichkeit, eine auf der lokalen Festplatte liegende RPM-Datei auszuwählen. Zwar gibt es den Menüpunkt DateiImportieren..., doch verlangt dieser nach Paketlisten im (nicht näher beschriebenen) *.sel-Format.

Die kaum intuitiv zu nennende Lösung besteht darin, unter SoftwareInstallationsquelle wechseln über HinzufügenLokales Verzeichnis... eine neue Installationsquelle einzurichten. Damit YaST deren Inhalt findet, muss man das Installationsmodul anschließend erneut aufrufen. Dessen Handhabung gestaltet sich sehr umständlich und alles andere als intuitiv. So sieht man z. B. verschiedene Versionen eines Programms nicht auf Anhieb, und Software-Updates gelingen nur durch Ausprobieren.

Mandrake trennt ebenfalls zwischen der Installation über eine Datei (RPM) und einen Software-Installer. Letzterer bietet gegenüber YaST weniger Informations- und Kontrollmöglichkeiten. Verlief die Suche nach einem Programm ergebnislos, steht der Benutzer vor dem Rätsel: "Gab es kein Ergebnis oder habe ich einfach nur vergessen, die Suche zu starten?" Weiterhin konfrontiert Mandrake ihn mit unverständlichen technischen Gerätebezeichnungen (Abbildung 2).

Abbildung 2: Welches Laufwerk ist gemeint, wenn man auf einem Mandrake-System zwei CD-ROMs hat?

Die Installer von Fedora und Xandros bieten eine Liste aller verfügbaren Programme an. Deren Auswahl fällt bei beiden leicht, jedoch fehlt die Angabe, um welche Version der Software es sich handelt (Abbildung 3). Eine Möglichkeit, ein lokales Verzeichnis als Paketquelle anzugeben, existiert bei beiden nicht.

Abbildung 3: Handelt es sich um Gimp 1.2 oder Gimp 2? Versionsangaben fehlen bei Fedoras Installer.

Konfliktfälle

Bedingt durch die Paketabhängigkeiten (siehe Kasten 1) treten unter Linux Schwierigkeiten auf, die Windows-Nutzer so nicht kennen. Dann kommt es darauf an, wie die Software Konflikte kommuniziert und löst, und welche Hilfestellungen der Nutzer erhält.

Was zum Beispiel passiert im häufig auftretenden Fall, dass Bibliotheken auf der Festplatte fehlen und aus dem Internet oder von CD/DVD nachinstalliert werden müssen? Wie reagiert der Installer, wenn benötigte Bibliotheken mit bereits installierten, eventuell notwendigen Paketen in Konflikt stehen?

Suses YaST installiert fehlende Bibliotheken (teilweise auf Nachfrage) nach, zunächst jedoch nur von der CD/DVD. Will man auch aus dem Internet Pakete nachladen, muss man passende Installationsquellen einrichten. Auch wer die Systeminstallation per DVD durchführt und für die Nachinstallation eine CD einlegt, muss Suse dies manuell beibringen.

Mit einem ausführlichen "Konfliktdialog", der dem Nutzer verschiedene Optionen anbietet, reagiert YaST auf den zweiten Problemfall. Allerdings macht das Programm weder klar, worin die Schwierigkeit besteht, noch wodurch sie zustande kommt (Abbildung 4). Nicht immer muss es sich dabei tatsächlich um einen Konflikt handeln. Manchmal findet YaST lediglich Pakete nicht, suggeriert aber ein Szenario, das zur Systeminkonsistenz führen kann.

Eine positive automatische Lösung – etwa das Herunterladen und die Nachinstallation aller notwendigen Pakete aus geeigneten Quellen – bietet YaST nicht an. An dieser Stelle bleibt "normalen" Nutzern nur die Möglichkeit abzubrechen, denn Hilfe oder zusätzliche Informationen finden sie nicht.

Abbildung 4: Der Konfliktdialog von YaST verwirrt durch ein schwaches Design und missverständliche Texte.

Mandrakes RPMDrake liefert im Konfliktfall generell wenig verständliche Anhaltspunkte, installiert Pakete nicht nach und lässt den Nutzer weitestgehend alleine (Abbildung 5).

Abbildung 5: Ungelöste Paketkonflikte bei Mandrake bleiben ungelöst.

Fedora umgeht diese Probleme, indem es über den Installationsmanager nur jene Software anbietet, die mitgeliefert wurde oder per Online-Update bereitsteht und damit konfliktfrei sein sollte. Für den Nutzer geht alles einfach und glatt, allerdings zum Preis eines geschlossenen und eingeschränkten Systems.

Xandros kennt ebenfalls keine Konflikte, solange man sich auf das Angebot des Xandros Network beschränkt. Dennoch gibt es auch hier zuweilen unverständliche Warnhinweise (Abbildung 6). Spielt man dagegen ein RPM (in unserem Beispiel KDevelop von der lokalen Festplatte) ein, so kann es passieren, dass die Installation "erfolgreich" verläuft. Tatsächlich lässt sich das Programm aber nicht starten, weil die benötigten Bibliotheken nicht mitinstalliert wurden.

Fairerweise sei angemerkt, dass Xandros nativ auf das Debian-Paketformat setzt und daher mit dem Debian-Tool apt-get einen smarten Installationsmechanismus nutzt. Anders als für die anderen Distributionen gibt es keine für Xandros gebauten RPM-Pakete. Stattdessen greift der Distributor auf den Konverter alien zurück. Stimmen die im RPM-Paket vermerkten Abhängigkeiten nicht mit den Namen der entsprechenden Debian- bzw. Xandros-Pakete überein, hat dieser keine Möglichkeit, sie herauszufinden.

Abbildung 6: Auch bei Xandros kann es zu Problemen kommen. Leider ist deren Beschreibung nicht sehr aufschlussreich.

Desktop-Integration

Aus Usability-Sicht inakzeptabel ist es, wenn der Nutzer nach der Installation nicht weiß, wo das Programm steckt und wie er es aufrufen kann. Wünschenswert wäre es daher, dass sich das neue Programm an sinnvoller Stelle im Menü einordnet und der Anwender nach der Installation einen Hinweis darauf erhält, wo das genau ist. In keinem Fall sollte der Nutzer erst auf die Kommandozeile zurückgreifen müssen, um das Programm von dort aus zu starten.

Suse fügte das testweise installierte KDevelop zwar im Menü unter dem Punkt Entwicklung an plausibler Stelle ein, doch die muss der Anwender selbst finden: Das Installationsprogramm beendet sich ohne entsprechenden Hinweis – ob die Installation überhaupt erfolgreich war, bleibt vollkommen unklar. Viel besser schlagen sich aber auch die übrigen Distributionen nicht: Keine gibt einen Hinweis, in welches Menü das Programm eingeordnet wird, obwohl sowohl Mandrake, Fedora als auch Xandros passende Menüpunkte erzeugen. Mandrake zeigt zudem eine Erfolgsmeldung nach der Installation an.

Paradigmen-Vielfalt

Dass nachträgliche Software-Installationen einfach sein kann, beweisen die Distributionen immer dann, wenn sich der Anwender auf mitgelieferte Software beschränkt. Sobald er ein neueres oder nicht (per Update) unterstütztes Programm einspielen will (wie in unserem Szenario angenommen), bleibt er jedoch häufig auf sich alleine gestellt, sofern er überhaupt zum Erfolg kommt. Das schränkt "normale" Nutzer in ihrer Freiheit und den Möglichkeiten, die Linux an sich bietet, deutlich ein. Zwar bieten die verschiedenen Distributionen zunehmend Update-Möglichkeiten an, doch ob dies ausreicht, um zum dauerhaften Wechsel zu Linux zu überzeugen, ist fraglich.

Bei der Installation selbst bietet Suse dem Nutzer möglichst viele, jedoch uneinheitliche Wege an. Als "Schweizer Universalwerkzeug" bevormundet YaST nicht, kann aber die Komplexität der Materie kaum reduzieren. Erfahrene Administratoren werden dies zu schätzen wissen, "normale" Nutzer dürften damit aber selten glücklich werden.

Auch Mandrake folgt stark dem Installer-Paradigma, den für Windows- oder Mac-Nutzer gewohnten Datei-zentrischen Weg unterstützt die Distribution nur eingeschränkt.

Sowohl Fedora als auch Xandros bieten dem Anwender ein Set an Programmen an, das über eine Software-Verwaltungszentrale zugänglich ist. Ein manueller Installationsmanager fehlt bei Fedora im Menü, und auch die GCC-Compilersuite wird standardmäßig nicht aufgespielt. Die Hürden für die manuelle Installation setzt Fedora so hoch an, dass man die Kommandozeile beherrschen muss, um hier Erfolg zu haben. Bei Xandros kann man immerhin eigene RPMs einspielen, doch ob diese laufen, lässt sich kaum steuern: Entweder es funktioniert oder eben nicht.

Beide Distributionen zielen offenbar darauf ab, dem Nutzer ein stabiles Linux-System anzubieten, das nicht viel mehr braucht, als schon mitgeliefert wird. Das schützt unerfahrene Anwender vor "Dummheiten". Für fortgeschrittene Nutzer sieht das zwar nach Bevormundung aus, doch diesen bleiben oft weitgehende Erweiterungsmöglichkeiten wie das Anzapfen des gesamten Debian-Programmfundus bei Xandros, soweit sie wissen, was sie tun müssen. Eine befriedigende Lösung für alle, die sich mit Linux-Interna wenig auseinandersetzen und Software Dritter nutzen wollen, gibt es derzeit nicht.