Kommentar: Der ewige K(r)ampf - Grafische Verwaltungsprogramme unter Linux

Die Diskussion um das Verhältnis der grafischen Oberfläche (GUI) zur Kommandozeile flackert in vielen Diskussionforen regelmäßig auf. Meist auf die Spitze getrieben von Puristen, die in grafischen Benutzerschnittstellen nur Ballast sehen und auf die Effizienz und Fehlerfreiheit der Kommandozeile schwören.

Grundsätzlich ist dies nicht einmal eine reine Linux-Diskussion. Auch andere Betriebssysteme wie macOS oder sogar Windows lassen umfangreiche Interaktionen im Terminal oder der PowerShell zu.

Während bei diesen beiden Betriebssysteme beide Schnittstellen als Ergänzung funktionieren beharren im Linux-Umfeld manche darauf, dass die grafische Benutzeroberfläche im Bereich der Systemverwaltung letztlich ein Risiko darstelle, da sie zu Fehlern führe, die sich dann nur auf der Kommandozeile beheben lassen.

Der Befund ist dabei noch nicht einmal grundsätzlich falsch. Tatsächlich gibt es in Foren zahllose Beispiele in denen - insbesondere bei systemnahen Operationen - die grafische Oberfläche versagte und schließlich zur Kommandozeile gegriffen werden muss. Paketverwaltung und Partitionierung sind hier regelrechte Klassiker.

Das liegt jedoch weniger an grundsätzlichen Mängeln grafischer Oberflächen, sondern vielmehr an strukturellen Mängeln grafischer Oberflächen unter Linux.

Wieder einmal muss man hier macOS als funktionierendes Gegenbeispiel heranziehen. Die grafische Programmverwaltung mittels App Store funktioniert sowohl zur Aktualisierung des Betriebssystem, sowie der Installation und Deinstallation der Apps vollkommen problemlos. Parallel dazu gibt es ein Kommandozeilenwerkzeug (softwareupdate), das sich beispielsweise für Automatisierungen eignet. Das gleiche gilt für systemnahe Werkzeuge wie das Festplattendienstprogramm, das sich auch mittels diskutil im Terminal nutzen lässt.

Ursächlich hierfür ist, dass Apple zielgruppenorientiert entwickelt und die normalen Benutzer nicht vernachlässigt. Nur ein kleiner Teil der Anwender zieht es vor ständig auf der Kommandozeile zu arbeiten. Grafisches Programm und Kommandozeile sind hier unterschiedliche Wege zum gleichen Ziel - keine wird offensichtlich bevorzugt oder vernachlässigt.

In dieser Hinsicht waren vor allem die frühen Jahre von Ubuntu sehr förderlich für Linux auf dem Desktop. Endlich nahm sich ein Distributor des Problems an und versuchte hier die Lücken zu schließen. Rund um den GNOME Desktop entstand ein Set an Werkzeugen zur Verwaltung des Systems. Mit dem weitgehenden Rückzug von Canonical bricht diese Lücke wieder auf. Unzureichende Werkzeuge wie der halbfertige GNOME App Store sprechen da Bände.

Oftmals fehlt hier vor allem Kontinuität. Grafische Systemverwaltungsprogramme werden so schnell aus dem Boden gestampft, wie sie wieder beerdigt werden. Alle großen Distributionen haben in den letzten Jahren ein gutes halbes Dutzend an Paketverwaltungsprogrammen eingeführt und dann wieder ersetzt. Mit Flatpak und Snaps stehen hier sicherlich auch im grafischen Bereich schon wieder Umbrüche bevor. Insbesondere in einem so sensiblen Bereich muss der Anwender sich permanent auf etwas neues einstellen.

Unter vielen Linux-Entwicklern und -Distributoren scheint zudem die Idee vorherrschend zu sein, dass grafische Software nicht den gleichen Funktionsumfang haben kann, wie das Kommmandozeilen-Äquivalent. Anders kann man sich den funktionalen Reduktionsimus der App Stores kaum erklären. Ausnahmen wie das bewährte Synaptic für die Debian-Paketverwaltung werden kaum beachtet. respektive gepflegt. Selbst diese Basisfunktionen sind jedoch oft nicht hinreichend getestet. Schlicht weil die meisten Entwickler kaum selbst mit grafischen Schnittstellen arbeiten. So sind beispielsweise vor einiger Zeit zentrale Fehler in der grafischen Paketverwaltung Muon vor einem Release nicht aufgefallen, weil kein Kubuntu-Entwickler das Werkzeug nutzte.

Linux lässt sich deshalb bis heute nicht annähernd vollständig ohne die Kommandozeile bedienen. Entgegen der Behauptung, dass dies an ihrer allgemeinen Überlegenheit liege, ist hierfür vor allem die begrenzte Aufmerksamkeit für grafische Werkzeuge verantwortlich - sowohl durch Upstream-Entwickler, als auch Distributoren. Ob dies ein Problem darstellt, hängt von der Zielgruppe der jeweiligen Linux-Distribution ab.

Kurzum: Grafische Programme verleiten nicht zu Fehlern, sondern schlechte grafische Programme verursachen Fehler. Anstatt aber jeden auf die Kommandozeile zu verweisen, sollten gute grafische Alternativen empfohlen werden. Gibt es keine, sollte man zu einem/r anderen System/Distribution greifen.

Man sollte sich nämlich keinen Illusionen hingeben. Den meisten Anwendern jagt die Kommandozeile erst einmal Angst ein. Die weit verbreitete Annahme, dies ließe sich mal eben schnell aneignen, geht hier fehl. Die Lernkurve beim Linux-Umstieg ist so schon steil genug, mit einer Verpflichtung zum Einsatz der Befehlszeile steigt sie unnötig an.

Thomas
Als ewiger Debian-Jünger bin ich durch meinen Arbeitgeber auf Suse gedrängt worden. Und ich muss sagen, hier funktionieren die grafischen Systemtools sehr gut. Gerade die Partitionierung von Raids klappt wunderbar. Von Yast sollten sich andere Distributionen mal eine Scheibe abschneiden. Leider macht zumindest openSuse nicht immer die beste Figur in Sachen Stabilität. Naja, da vergleiche ich auch Äpfel mit Birnen. Also Fazit: Yast ist ein schönes Gegenbeispiel zu deinem Artikel.
Cruiz
Tatsächlich hat mich openSUSE zu diesem Artikel inspiriert. Leider hat YaST die Usability der 90er. Da hat man nie wirklich dran geschraubt, wodurch es insbesondere für Neulinge schwer zu durchschauen ist.
Prokov94
nachvollziehen kann ich das, aber bei Linux ist das Grafische mit den Programmen sowieso am Ende, ich sehe es eher so, das Frameworks wie Electron es ermöglichen optische Oberflächen auf allen Plattformen einzusetzen.

Cruiz
Mit dem Nachteil, dass sich diese Oberflächen kaum in das jeweilige System einfügen. Siehe die diversen Messenger auf Electron-Basis.
Prokov94
Wenn sich Gnome/KDE mal zusammenreißen würden, eine richtige Dokumentation als Styleguide anzufertigen, dann denke ich wäre es garnicht unmöglich für Webentwickler entsprechend diese als Unterbau in Electron einzusetzen, somit schlägt man 2 Fliegen mit einer Klappe, es würde mehr grafisch ansprechende Programme unter Linux geben und mehr davon hätten ein selbes design.
Aber ob das bei den Grafikumgebungs Entwicklern mal ankommt, bezweifle ich.
Bin selbst Webentwickler und habe mit Electron einfache Sachen realisiert. Wenn ich Zeit hätte, würde ich gern mal so ein Gnome oder KDE Layout in Electron entwickeln wollen. Aber Zeit ist leider wenig da...

abbc
Oben wurde ja schon Yast in OpenSuse erwähnt. Beim Punkt, wieso gibt es so wenige grafische Konfigurationsm öglichkeite n unter Linux, denke ich das der größte Teil der OpenSource Entwickler meist Windows oder MacOS verwenden. Darüber glaube ich auch mal etwas gelesen zu haben. Nebenher wird OpenSource dann für Linux lediglich kompiliert, aber nicht ausgiebig getestet. Auch ist die Großschar der OpenSource-Anwendungen und Windows zu finden und nicht auf Linux. Also gibt es nicht genug Nutzer(somit Tester) unter Linux die auf Probleme hinweisen. Als Softwareentwick ler (überwiegend Web), habe ich auch keinen Linux Clientel. Also muss man oft Windows-Software weiterentwickel n oder für Windows programmieren. Ist halt so...
ati
Volle Zustimmung zum Kommentar. Ich lebte viele Jahre von DOS/Windows-Service (auch Novell Netware, falls das jemand noch kennt), aber mein Herz schlug für Apple. Irgendwann entdeckte ich Linux und war begeistert, habe diverse Distributionen und Desktops getestet, eines Tages Windows zu Grabe getragen. Nach jeder neuen Version war ich der Meinung, Linux bräuchte nur noch zwei Jahre, um auch eine ernsthafte Desktop-Alternative zu werden. Das ist nun viele Jahre her und meine Visionen musste ich ebenfalls begraben. Natürlich habe ich Linux weiterhin im Einsatz, aber meine diversen Desktops ziert jew. ein Apfel. Ich bin Web-Entwickler (programmiere seit 1984) und kann mit der Kommandozeile umgehen. Nur, ich mag nicht. Ein Vergleich: Klar, am Wochenende kurvt man zum Spass gerne mal mit einem puristischen Gefährt kurz herum, im Alltag will man aber den Komfort, den viele kleine Helferlein bieten (Servolenkung, Bremskraftverst ärker, Fensterheber, etc.), nicht missen.
Peter
muss man halt keine grafischen tools nutzen, wenn die sich eh ständig ändern. die CLI tools sind da stabiler
Thomas_Do
Ich persönlich bin kein Purist und benutze gern auch grafische Werkzeuge. Allerdings ist die Fehlersuche und die Möglichkeit des Supports über Foren bei CLI-Programmen und textbasierten Konfigurationsd atein erheblich einfacher.

Ein Aspekt wurde noch nicht genannt, die Programmierung und Testung guter und durchdachter grafischer Oberflächen ist sehr aufwendig. Gerade private Entwickler stecken ihre Zeit lieber in das eigentliche Projekt als in das GUI. Das sieht bei kommerziellen Entwicklern anders aus, wenn sie für zahlende Kundschaft arbeiten.

1000 Buchstaben übrig


Über

[Mer]Curius bietet Informationen zur technischen Dimension des Datenschutz im digitalen Bereich. Neben permanent aktualisierten Artikeln zu Betriebssystemen, Verschlüsselung und Kommunikationsabsicherung werden im Blog aktuelle Trends präsentiert und kommentiert.

Top