Erfahrungsbericht Fedora 34 mit GNOME 40

Hinweis: das ist ein Meinungsartikel.

Seit vielen Jahren bin ich auf meinen Produktivrechnern mit Ubuntu (meist LTS) unterwegs. Da mich seit den letzten Installationen das Paket-Chaos bei der Canonical-Distro nervt (Snap, Apt, Flatpak, AppImage), habe ich in den letzten Monaten Manjaro ausprobiert, bin aber aufgrund drohender Stabilitätsprobleme und einer ungenügenden Umsetzung von Wayland, wieder davon abgekommen. Nun ist Fedora 34 mit dem brandneuen GNOME 40 Desktop an der Reihe.

Damit mich niemand falsch versteht, Fedora 34 ist eine sehr gute Distribution, die sowohl von Anfängerinnen als auch von Profis verwendet werden kann. Der neue GNOME 40 Desktop ist sehr stylisch und benutzerfreundlich. Die Installation und die grundsätzliche Bedienung funktionierten bei meinen bisherigen Tests unspektakulär und problemlos, bis auf ein paar Fehlermeldungen des Systems, die meinen Arbeitsfluss nicht behinderten. Ich führe diese auf die grossen Änderungen in Fedora 34 und auf die Aktualität des Systems zurück.

Für meine Tests habe ich die Distribution zuerst in einer virtuellen Maschine (GNOME Boxes) und dann auf Alteisen (einem 10 Jahre alten Tuxedo i3 Notebook) installiert. Alle Erfahrungen beziehen sich auf die letztgenannte Installation. Ausserdem habe ich mich bei diesem Erfahrungsbericht nur auf bekannte Problemfälle konzentriert, die mir bei anderen Distros (insbesondere Ubuntu und Manjaro) auch aufgefallen sind. Die vielen positiven Erfahrungen mit Fedora 34 erwähne ich hier nicht.

Meine Problemfälle haben Namen: Desktop, Flameshot, Gimp, Nextcloud, Paketverwaltung.

Der Desktop

Ohne Extensions ist der GNOME 40 Desktop (aber auch die vorherige 3er-Version) nicht effizient nutzbar. Die grundsätzliche Bedienung der GNOME-Shell ist zwar durchdacht und fördert einen bestimmten Arbeitsfluss, lässt aber wesentliche Elemente vermissen. Ein einfaches Umstellen zwischen Farb-Themen gibt es in der Version 40 immer noch nicht. Zwar lässt sich (nach der Installation des Tweak-Tools) zwischen dem standardmässigen hellen Thema und einem dunklen umschalten, das Dunkle hat jedoch so wenig Kontrast, dass man oft an die falsche Stelle klickt, weil man ein Fenster nicht von einem anderen unterscheiden kann. Obwohl viele Anwender ein dunkles Thema bevorzugen, ist das Kontrastproblem bisher in keiner (mir bekannten) Desktop-Umgebung befriedigend gelöst worden. Beim hellen Thema funktioniert das tadellos; dafür sieht es ziemlich langweilig aus.

Beim Vanilla-GNOME-Desktop gibt es zwar ein Dock, dieses ist jedoch nicht permanent sichtbar, sondern erst nach dem Drücken der SUPER-Taste bzw. dem Bewegen der Maus in die Hot-Corner (links oben) sichtbar. Meiner Meinung nach ist die Sichtbarkeit der favorisierten und laufenden Anwendung essenziell für eine gute Übersicht und Bedienbarkeit eines Desktops; ansonsten macht man ständig einen unnötigen Bedienschritt zu viel. Sobald die Extensions 'Dash-to-Dock' und 'Dash-to-Panel' für GNOME 40 verfügbar sein werden, hat sich die Sache erledigt.

In den Standardeinstellungen ist eine Grössenänderung von Fenstern nicht vorgesehen. Entweder gibt man sich mit der Default-Grösse eines Anwendungsfensters zufrieden oder man verwendet Hot-Keys (SUPER+Cursortasten) zur Positionierung eines Fensters. Wer dennoch die Fenstergrösse anpassen möchte, ist auf die Anfasser am Fensterrand angewiesen. Diese sind in der Regel 10 Pixel breit, damit man sie ohne Lupe mit der Maus treffen kann. Das ist bei Fedora 34 auch der Fall, jedoch nicht bei allen Fenstern. So beträgt die Breite beim beliebten Passwortmanager KeePassXC genau 1 Pixel. Da muss man lange üben, bis man den Anfasser trifft. Dieselbe Anwendung unter Ubuntu 20.04/10 hat die übliche 10 Pixel-Breite.

Flameshot

Weiter geht es mit den subjektiven und selektiven Erfahrungen eines Endanwenders. Das Standard-Screenshot-Werkzeug bei GNOME ist gnome-screenshot, welches völlig unzureichend für ein ernsthaftes Arbeiten ist. Der beste Screenshotter ist wahrscheinlich Flameshot. Das Werkzeug ist in allen Repos enthalten und lässt sich mit drei Klicks installieren. Dummerweise fehlt in Fedora 34 ein System Tray, was dazu führt, dass Flameshot nicht mit einem Klick aufgerufen werden kann. Abhilfe schafft die Installation der Extension track-icons in der reloaded Version. Danach erscheint das Flammen-Icon im Tray und die Bildschirmaufnahme lässt sich bequem von dort starten. In meiner Alteisen-Installation funktioniert das nur erratisch; das Fadenkreuz zur Markierung des Aufnahmebereichs erscheint nur mit erheblicher Verzögerung, falls überhaupt, während das in der virtuellen Maschine problemlos geht.

Gimp

Die Installation der 'besten Bildbearbeitung' läuft selbstverständlich ohne jegliche Probleme aus dem GNOME Software Store. Jede, die mit Gimp ernsthaft arbeiten möchte, braucht ein paar Plugins, wie zum Beispiel die 'Heal Selection' (aka Resynthesizer). Dieses magische Werkzeug ersetzt eine Bildauswahl durch den Hintergrund (wer das noch nicht kennt; unbedingt ausprobieren). Unverständlicherweise gehört diese Funktion nicht zur Standardausstattung von Gimp. Also muss man sehen, woher man das Plugin bekommt. Jetzt glaubt bloss nicht, dass ihr das im Software-Store findet. Aber es gibt ja DNF:

[ralf@fedora ~]$ dnf search gimp-resynthesizer
============================= Name exakte Treffer: gimp-resynthesizer ==============================
gimp-resynthesizer.x86_64 : Gimp plug-in for texture synthesis

Die Freude ist gross und das Plugin wird sofort mit 'sudo dnf install gimp-resynthesizer.x86_64' installiert. Ab jetzt müsst ihr als Leser sehr tapfer sein. Noch einmal von vorne: ich habe Gimp aus GNOME-Software installiert; alles gut, es läuft. Dann habe ich per 'dnf' das Resynthesizer-Plugin für Gimp installiert - alles paletti. Und dann kommt der grosse Moment, wenn man die SUPER-Taste und 'Gimp' eintippt. Tätä, es erscheinen zwei Gimps im Dashboard:

Was geschah? Nun, die erste Gimp-Installation aus dem Software-Store hat ein Flatpak installiert. Die Installation des Plugins mittels 'dnf' hat alle Abhängigkeiten nachgezogen, namentlich Gimp selbst und diverse andere Pakete, wie zum Beispiel 'Python 2', und zwar als native Fedora rpm-Pakete. Da verschiedene Paketformate, bzw. Paketmanager, nicht miteinander reden, bewahrt einen die Distribution nicht vor solchem Unsinn. Schlimmer noch: ich habe eine Weile gebraucht, bis ich wusste, was hinter den beiden Gimp-Installationen steckt. Man kann auf die beiden App-Starter klicken und sich die Installationsdetails anzeigen lassen. Beide Gimps nennen: 'Quelle: registry.fedoraproject.org' mit identischer Dateigrösse und Versionsnummer. Ich komme später noch auf diese Paket-Hölle zu sprechen.

Nextcloud

Nextcloud ist unser aller Liebling und sollte in keiner GNU/Linux-Konfiguration fehlen. Hier muss man zwischen der Einbindung eines Nextcloud-Kontos und des Nextcloud-Desktop-Clients für die Synchronisation von Verzeichnissen und Dateien unterscheiden. Hier geht es um den Nextcloud-Desktop-Client. Es beginnt damit, dass eben dieser in GNOME-Software nicht existiert (obwohl ich alle denkbaren Repos für Fedora eingebunden habe). Diese Situation kenne ich von Ubuntu; das Software-Ding kennt kaum etwas, apt oder pacman oder dnf kennen alles. 'sudo dnf install nextcloud-client' erledigt den Job. Seit ca. einem Jahr ist der Nextcloud-Client nach meiner Meinung völlig kaputt. Die Anwendung erscheint als eine Chimäre mit 'qt' und 'gtk' Genen.

Startet man diesen Janus, erscheint zuerst ein Prozessfenster (qt), in dem der Synchronisationsverlauf angezeigt wird. Aus diesem heraus kann eine Einstellungsanwendung im GTK-Style gestartet werden. Darin kann man einstellen, dass der Client im System Tray als Icon angezeigt wird; Pustekuchen, geht nicht. Bei Ubuntu habe ich es mit einem Eintrag bei den Startprogrammen geschafft, dass sich der Nextcloud-Client bequemt, (manchmal) im Tray zu erscheinen. Unter Fedora 34 ist mir das noch nicht gelungen. Das kann man nicht Fedora anlasten, sondern liegt am über entwickelten Nextcloud-Client (übrigens, das funktionierte alles einmal perfekt).

Paketverwaltung

Beim Gimp- und Nextcloud-Absatz scheinen die Probleme mit der Paketverwaltung schon ein wenig durch. Eine unserer Redakteurinnen schrieb heute den Satz "Snap is Crap". Dieser Ausruf beleuchtet nur die kleinen Schmerzen, dem sich das GNU/Linux-Ökosystem in den nächsten Jahren wird stellen müssen. Wenn ich als Anwender nicht mehr (bzw. nur mit Fachwissen) nachvollziehen kann, woher ein Software-Paket kommt und wie es mit anderen zusammenspielt (siehe das Gimp-Beispiel), verspielt GNU/Linux den Heimvorteil der homogenen Paketverwaltung und lässt sich (in diesem Alleinstellungsmerkmal) rechts und links von Microsoft, Apple und Google überholen. Über dieses Grundsatzthema werde ich einen eigenen Artikel schreiben.

Fazit

An Fedora 34 habe ich nichts auszusetzen, bis auf ein paar Instabilitäten, die ich auf die junge Version zurückführe. Die Installation ist kinderleicht, das System läuft sogar auf uralter Hardware und trotz des ressourcenintensivem GNOME 40 Desktops erstaunlich schnell. Die Probleme liegen eher bei den Kinderkrankheiten von GNOME 40, der schlechten Integration der Anwendungen und dem grundsätzlichen Problem der zersplitterten GNU/Linux Paketverwaltung.