Wo Licht ist, ist auch Schatten: Linux hat - wie jedes technische Produkt - ebenfalls Schwächen.

1. Links zum Thema

• Unter http://www.unix-ag.uni-kl.de/~linux/linuxtag99/konzeptionelle_maengel_von_unix.html findet sich beispielsweise ein Dokument des Linuxtages 1999, welches versucht, einige Mängel aufzuzeigen. Manche der seinerzeit angesprochenen Punkte sind immer noch aktuell

2. PaketManager

• Der Paketmanager bemerkt nicht, wenn Dateien, die zu einem Paket gehören, vom Datenträger verschwinden (beispielsweise durch eine Unvorsichtigkeit gelöscht oder durch ein make install überschrieben wurden). Somit sind Inkonsistenzen möglich, wenn der PaketManager nach wie vor der Ansicht ist, die Datei sei noch da. Zwar kann man beispielsweise bei Verwendung von apt/RPM mit rpm -Va und apt-get install --reinstall wieder einiges reparieren, aber das System wacht nicht selbst über die Konsistenz, und der normale Anwender ist mit solchen Aufrufen sicher auch überfordert ;-).

  • Ein "normaler" Anwender wird aber als root keinen Dateimanager etc starten und beliebig Dateien löschen. (Zumindest sollte das so sein.)

• Der Paketmanager bemerkt nicht, wenn Dateien manuell in das System kopiert wurden, beispielsweise, weil man von einem Programm kein Paket erhalten hat, sondern Sourcecode. Zwar kann man sich mit dem Programm Checkinstall behelfen, welches zum Installationszeitpunkt ein (sauber deinstallierbares) Paket erstellt, CheckInstall überwacht dabei jedoch nicht, ob dabei evtl. lebenswichtige Dateien durch andere Versionen überschrieben werden. CheckInstall kuriert auch nur an den Symptomen, anstatt einen ganzheitlichen Ansatz zu bieten. Es sei angefügt, dass CheckInstall ein durchaus nützliches Programm ist, welches der Autor sehr gerne benutzt .

• So viele technische Vorteile shared Libraries auch haben (Plattenplatzersparnis, RAM-Ersparnis, erleichterte Systemwartbarkeit bei Sicherheitsupdates), so lästig sind PaketAbhängigkeiten für den Benutzer, der Software A installieren möchte, diese aber erst noch einige andere Pakete benötigt. Im heftigsten Falle muss der Anwender sich die benötigten Pakete selbst besorgen und dann in der richtigen Reihenfolge installieren.

  • Die Probleme mit den Shared-Libraries sind unter http://www.autopackage.org/faq.html sehr gut erklärt, man darf hoffen, dass sich da in Zukunft etwas bessern wird.

• Der Paketmanager lässt es meist nicht zu, dass man mehrere Versionen ein und desselben Programmes auf dem System hat. Bei manchen Anwendungsprogrammen möchte man jedoch gerne die alte Version 'zur Sicherheit' noch ein wenig installiert lassen, während man sich in die neue Applikation einarbeitet. Bei AppDir ist so etwas problemlos möglich. Es sei aber angemerkt, dass dies nicht direkt ein Problem des Paketmanagers, sondern des zu installierenden Paketes ist

• Ein Paketmanager ohne Abhängigkeitsverwaltung funktioniert nur mit Paketen die alle Abhängigkeiten mitbringen, ansonsten ist es ein Glücksspiel, ob sich ein Programm starten lässt oder nicht. Eine der Stärken eines PaketManagers ist es, dass dieser Paketabhängigkeiten verwalten kann. Dies ist notwendig, da Linux wesentlich stärker von Konzept der Shared-Libraries Gebrauch macht. Letztendlich soll auch vermieden werden, hunderttausende Kopien von Bibliotheken etc. zu vermeiden. Allerdings prüft der Paketmanager Abhängigkeiten nicht nach dem tatsächlichen Vorhandensein einer Datei auf dem Datenträger, sondern beispielsweise nach dem Paketnamen oder den Provides-Feldern des Paketes. Das führt dann dazu, dass sich Programm B nicht installieren lässt, auch wenn alle benötigten Dateien vorhanden sind, weil im Paket des Programmes A die Provides-Felder etwas anders lauten oder das Paket anders heißt als erwartet.

  • Bei RPM werden Library- und File-Provides/Requires automatisch erzeugt und sind so auch portabel.

• Die Distributoren verteilen die Softwarepakete gern auf mehrere verschiedene Einzelpakete. Dies alles führt dazu, dass man auf der Distribution W.X.y meist nur Pakete installieren kann, die auch für genau diese Version erstellt wurden. Ob man nun ein Paket eines neuen Programmes installieren kann, hängt somit ausschließlich davon ab, ob jemand sich die Zeit genommen hat, das Paket für die gewünschte Plattform zu erstellen. Zudem bedarf es großer zentraler Repositories; eine dezentrale Haltung der Paketdateien ist fast nicht realisierbar. Sehr viel schöner wäre es, ein distributions- und plattformunabhängiges Paketverwaltungssystem zu haben, welches idealerweise PaketAbhängigkeiten zum Installationszeitpunkt vollautomatisch auflöst. Im Idealfalle wäre das System so gut, dass es direkt die Quellen eines Programmpaketes verwenden kann, die direkt der Programmautor zur Verfügung stellt.

3. Konfigurationsdateien

• Wenn man sich von jeglichen Ideologien freimacht, dann muss man sagen, dass die Sache einer zentralen Konfigurationsdatenbank nicht so schlecht ist wie ihr Ruf. Wenn man es richtig machte, wäre es eine enorme Erleichterung. In einem Standard-Linux sind zwar sehr viele Konfigurationsdateien unter /etc/ untergebracht, aber eben nicht alle. Rennomierte Ausnahmen machen beispielsweise Datenbanken, KDE usw.. Leider bekommt man nur sehr schwierig heraus, welches Programm welche Konfigurationsdatei verwendet. Mir ist ein netter Fall bekannt, in dem jemand lange verzweifelt die Datei /etc/XF86Config bearbeitet hat, die Datei, die er aber hätte bearbeiten sollen, unter /etc/X11/XF86Config zu finden war. Ein Problem bei Verwendung einer Datenbank stellt evtl. die Versionierung dar, wenn man denn nicht eine "richtige" Datenbank verwenden will.

• Eine Lösung, die eine Zentrale und vereinheitlichte Schnittstelle bereitstellt und dabei alle Vorteile einfacher Konfigurations-Textdateien beibehält ist Config4Gnu. Dies behebt jedoch nicht den Schönheitsfehler, dass die Konfigurationsdateien in sehr vielen unterschiedlichen Formaten and verschiedenen Stellen im Dateisystem liegen. Zur Behebung der aktuellen Misere ist es jedoch ein sehr guter Ansatz.

4. Distributionsaufbau

• Die Distrubutionen unterscheiden sich in technischen Details erheblich. Wer soeben gelernt hat, ein SuSE-System (ohne YaST) zu handhaben, wird sich bereits am nächsten Tag auf einem RedHat oder Debian schwer tun, einen Dienst zu stoppen oder eine Internet-Verbindung aufzubauen. Das ist auch der Grund, warum man Distributonsspezifische Werkzeuge, die keine freie Software sind, argwöhnisch betrachten kann: YaST gibt es nur auf SuSE und auf keiner anderen Distribution. Wenn Sie nicht SuSE, sondern Linux lernen möchten, dann versuchen Sie ohne YaST zum Ziel zu kommen. Was zugegebenermaßen ungleich viel aufwendiger ist.

• Die Distributionsvielfalt führt auch zu der Schwierigkeit, dass die Erstellung einer umfassenden, allgemeingültigen Dokumentation sehr schwierig ist.

5. Komplexität

• Wer zum ersten Mal mit einem Linux in Berührung kommt, wird mit einer unüberschaubaren Anzahl von Programmen, Diensten und Fremdwörtern konfrontiert. Oft ziehen Einstellungen, die unter anderen Betriebssystemen mit wenigen Mausklicks erledigt sind, unter Linux mehrere Stunden Lesen von Dokumentation nach sich.
• Das Lösen (angenommenermaßen) selbst einfacher Aufgaben kann unter Linux dann doch wieder Problem für Problem nach sich ziehen, und die ganze Sache zieht sich viel mehr in die Länge als ursprünglich eingeplant.

6. Dokumentation

• Die Dokumentation liegt in vielen verschiedenen Formaten an unterschiedlichen Stellen nicht intuitiv abrufbar vor. Spezielle Probleme können ohne Internetanbindung zur Abfrage von Google, News- und Mailgroups überhaupt nicht erst gelöst werden. Zusätzlich stellt hier die Fragmentierung in viele unterschiedliche Distributionen eine zusätzliche Hürde dar. Eine im Web beschriebene Problemlösung, die auf einem Debian-System funktioniert, muss noch lange nicht auf einem SuSE-System funktionieren.
• Zur Benutzung von Linux ist das Abonnieren einschlägiger Newsgroups und Mailinglisten schon fast Pflicht. Um dort jedoch mitreden und Fragen stellen zu können, muss der Anwender erst einmal lernen, was Newsgroups und Mailinglisten überhaupt sind und sich mit den dortigen Gepflogenheiten beschäftigen. Eine aufwendige und langwierige Sache.

  • Zur Benutzung nicht, aber zur Problemlösung schon, ich wüßte allerdings auch keine Alternative. -- RonnyBuchmann 2003-10-06 16:55:38

7. Zwischenablage

Obwohl der Informationsaustausch zwischen Applikationen unter Un*x bereits eine lange Tradition hat, die sich bis in die moderne InterprozessKommunikation der ein oder anderen DesktopUmgebung fortsetzt, fristet interessanterweise die Zwischenablage ein Nischendasein. Besieht man ein anderes BetriebsSystem (Windows, Mac OS) ist die ZwischenAblage _das_ Mittel der Wahl, um Daten zwischen Applikationen auszutauschen. So lassen sich beispielsweise in einem CAD Vektorgraphiken in die Zwischenablage schreiben, die dann in einer Bildbearbeitung eines komplett anderen Herstellers als Pixelgraphiken eingefügt werden können.

Arbeitet man jedoch unter Linux beispielsweise unter X, so gibt es hier ein anderes ZwischenAblagenkonzept, was gelegentlich zur Verwirrung des Anwenders führen kann, weil nicht alle Programme das Konzept sauber umsetzen.

Dem Zwischenablage Problem nahm man sich auf http://freedesktop.org an.

8. Quellcodedistribution

Möchte der ambitionierte Einsteiger neue Programme ausprobieren, darf er sich - sofern von dem zur Verfügung gestellten Programm keine Binärpakete zur Verfügung stehen - das Programm aus den Quellen selbst kompilieren. Dies ist jedoch nicht immer ganz einfach, denn es gilt evtl., zuerst benötigte Devel-Pakete einzuspielen, Systemvariablen zu setzen und dann gegebenenfalls dem ConfigureScript die passenden Optionen mit auf den Weg zu geben. In den seltensten Fällen genügt der Spruch «Mit einem einfachen Dreisatz wird das Programm übersetzt und (als Root) installiert»