Fedora KDE: Ich wollte Discover testen und landete plötzlich bei Windows 11

Ich aktualisiere Fedora normalerweise ganz klassisch über das Terminal:

sudo dnf update

Das ist vertraut, übersichtlich und zeigt mir direkt, was das System gerade vorhat. Ich sehe, welche Pakete aktualisiert werden, wie groß die ganze Angelegenheit wird und ob Fedora nebenbei beschließt, meine halbe Installation umzubauen.

Meistens tut es das nicht.

Meistens.

Vor ein paar Tagen kam ich allerdings auf die offenbar gefährliche Idee, testweise einmal Discover zu benutzen.

Nicht, weil das Terminal plötzlich aufgehört hätte zu funktionieren. Ich wollte einfach wissen, wie Fedora KDE die Aktualisierung für Menschen gelöst hat, die nicht aus reiner Gewohnheit Befehle in ein schwarzes Fenster tippen.

Also öffnete ich Discover, klickte auf „Aktualisierungen“ und ließ Fedora machen.

31 Pakete, ungefähr 1,1 Gigabyte.

Soweit alles normal.

Discover lud die Pakete herunter, bereitete sie ordentlich vor und erklärte mir anschließend freundlich, dass die Aktualisierungen beim nächsten Neustart installiert würden.

Beim Neustart.

Ich schaute noch einmal auf den Bildschirm.

Fedora KDE.

Nicht Windows 11.

Fedora KDE.

Im Abmeldemenü fand ich dann tatsächlich die Option:

Aktualisierungen installieren und neu starten

Für einen kurzen Moment erwartete ich, dass das System mich gleich noch nach meinen aktiven Nutzungszeiten fragt und mir anschließend mitteilt, dass es meinen Rechner heute Nacht um 3:17 Uhr vorsorglich selbst neu startet.

Ganz so weit ging Fedora dann glücklicherweise doch nicht.

Trotzdem war der erste Eindruck eindeutig:

Moment mal. Warum macht mein Linux plötzlich Windows-Dinge?

Discover macht nicht einfach nur DNF mit hübscheren Knöpfen

Wenn ich Fedora über das Terminal aktualisiere, werden die neuen Pakete normalerweise direkt im laufenden System installiert.

sudo dnf update

Fedora lädt die Pakete herunter, prüft die Transaktion und ersetzt anschließend die vorhandenen Dateien. Währenddessen kann ich meistens weiterarbeiten.

Discover verfolgt bei Systemaktualisierungen einen anderen Ansatz.

Die Pakete werden zunächst heruntergeladen und vorbereitet. Die eigentliche Installation erfolgt aber erst beim Neustart in einer reduzierten Aktualisierungsumgebung.

Der normale Plasma-Desktop läuft dabei nicht. Firefox ist geschlossen, laufende Programme sind beendet und die verschiedenen Hintergrunddienste versuchen nicht gleichzeitig, auf Dateien zuzugreifen, die gerade ausgetauscht werden.

Fedora räumt also erst das Zimmer leer und beginnt danach mit der Renovierung.

Beim klassischen Update wird dagegen renoviert, während man noch auf dem Sofa sitzt, Kaffee trinkt und sich gelegentlich darüber wundert, warum plötzlich die Tapete hinter einem fehlt.

Linux kann mit solchen Situationen erstaunlich gut umgehen. Trotzdem steckt hinter dem Offline-Update ein nachvollziehbarer Gedanke.

Alte Programme und neue Dateien

Während eines Updates im laufenden Betrieb können vorübergehend unterschiedliche Systemzustände nebeneinander existieren.

Auf der Festplatte liegt bereits die neue Version einer Bibliothek. Ein Programm, das vor dem Update gestartet wurde, verwendet im Arbeitsspeicher aber weiterhin die alte Version.

Ein Dienst wurde aktualisiert, läuft jedoch noch mit seinem bisherigen Code. Plasma hat vielleicht schon neue Dateien erhalten, während einzelne Teile der aktiven Sitzung weiterhin zum alten Paketstand gehören.

Das muss nicht automatisch zu Problemen führen.

In den meisten Fällen merkt man davon überhaupt nichts.

Allerdings ist „in den meisten Fällen passiert nichts“ auch ungefähr die technische Grundlage vieler meiner Linux-Experimente.

Beim Offline-Update wird dieser Mischzustand weitgehend vermieden. Die Aktualisierung läuft in einer möglichst kleinen Umgebung und danach startet das System vollständig neu.

Dadurch ist der Zustand nach dem Update ziemlich eindeutig:

Was jetzt läuft, gehört auch tatsächlich zum gerade installierten System.

Das ist nüchtern betrachtet ziemlich sauber.

Fast schon verdächtig sauber.

Das System bekommt sein eigenes Wartungsfenster

Je länger ich über den Ablauf nachdachte, desto weniger störte er mich.

Discover lädt die Aktualisierungen zunächst herunter. Währenddessen kann ich den Rechner weiterverwenden. Anschließend entscheide ich selbst, wann ich meine Programme schließe und den Neustart auslöse.

Danach bekommt Fedora ein kleines Wartungsfenster, in dem es seine Pakete ungestört austauschen kann.

Das hat etwas Kontrolliertes.

Nicht im Sinne von:

Der Computer übernimmt die Kontrolle und ich darf zusehen.

Sondern eher:

Ich entscheide jetzt bewusst, dass das System aktualisiert wird, und danach ist die Sache abgeschlossen.

Bei einem normalen Terminal-Update neige ich dazu, gleichzeitig noch fünf andere Dinge zu machen.

Firefox bleibt geöffnet. Musik läuft. Irgendwo wird eine Datei kopiert. Nebenbei starte ich noch eine virtuelle Maschine, weil der Paketmanager offenbar erst dann richtig motiviert arbeitet, wenn möglichst viele Teile des Systems gleichzeitig beschäftigt sind.

Beim Offline-Update ist die Trennung klarer:

1. Aktualisierungen herunterladen
2. Arbeit beenden
3. Neu starten
4. System aktualisieren lassen
5. Mit einem frischen Zustand weitermachen

Für Menschen, die einfach nur möchten, dass ihr Rechner ordentlich gepflegt wird, ist das kein schlechter Ablauf.

Für Linux-Einsteiger ist das ziemlich verständlich

Man muss sich einmal in jemanden hineinversetzen, der nicht freiwillig Paketmanagerausgaben liest.

Dieser Mensch möchte wahrscheinlich nicht wissen:

• welche Bibliothek von welchem Prozess noch verwendet wird,
• welcher Dienst nach einem Update neu gestartet werden sollte,
• ob ein neuer Kernel bereits aktiv ist,
• ob Plasma einmal neu angemeldet werden müsste,
• oder warum ein Programm noch die alte Version anzeigt, obwohl Discover behauptet, alles sei aktuell.

Ein normaler Nutzer möchte eher Folgendes:

Es gibt Aktualisierungen. Bitte installieren. Fertig.

Discover bietet dafür einen klaren Ablauf.

Die Updates werden vorbereitet. Der Nutzer bekommt einen eindeutigen Knopf. Das System startet neu, erledigt die Installation und kommt anschließend in einem definierten Zustand zurück.

Das erinnert an Windows, weil Windows diesen Ablauf für viele Menschen geprägt hat.

Die Grundidee wird dadurch aber nicht automatisch schlecht.

Ein Hammer wird schließlich auch nicht unbrauchbar, nur weil Microsoft irgendwann einmal einen Nagel schief eingeschlagen hat.

Gerade für Windows-Umsteiger kann dieser Ablauf sogar angenehm vertraut wirken:

• Updates wurden gefunden.
• Der Rechner möchte neu starten.
• Die Installation wird abgeschlossen.
• Danach kann weitergearbeitet werden.

Das ist weniger einschüchternd als eine Terminalausgabe mit mehreren hundert Zeilen, Transaktionsprüfungen und Paketnamen, die aussehen, als hätte jemand beim Niesen die Tastatur getroffen.

Der Rechner wird vorübergehend zum dekorativen Heizkörper

Der größte Nachteil ist allerdings ziemlich offensichtlich:

Während des Offline-Updates kann man den Rechner nicht benutzen.

Beim klassischen DNF-Update kann ich meistens weiterarbeiten. Ich kann lesen, Musik hören oder so tun, als würde ich produktiv sein, während ich in Wahrheit Paketnamen beobachte.

Beim Offline-Update bleibt nur Warten.

Bei 31 Paketen auf einer schnellen SSD ist das kein großes Drama. Bei mehreren Gigabyte, älterer Hardware oder einem größeren Systemupgrade kann die Sache aber länger dauern.

Dann sitzt man vor einem Fortschrittsbildschirm und beginnt irgendwann mit den üblichen Fragen:

• Bewegt sich der Balken noch?
• War der eben nicht schon weiter?
• Sollte der Lüfter so klingen?
• Darf ich den Rechner jetzt ausschalten?
• Warum sammle ich nicht einfach Briefmarken?

Offline-Updates sind kontrolliert, verlangen aber gleichzeitig Vertrauen.

Und wenn der Bildschirm längere Zeit scheinbar nichts tut, kann dieses Vertrauen erstaunlich schnell verschwinden.

Braucht wirklich jedes Update einen Neustart?

Linux kann viele Pakete problemlos im laufenden Betrieb aktualisieren.

Nicht jede Anwendung, nicht jede Übersetzung und nicht jede kleine Bibliothek erfordert zwingend einen vollständigen Neustart.

Discover verwendet für Systemaktualisierungen trotzdem einen einheitlichen Offline-Ablauf.

Das ist verständlich. Eine grafische Oberfläche möchte schließlich nicht bei jedem einzelnen Paket erklären:

Dieses Update kann sofort installiert werden, jenes benötigt einen Dienstneustart, das nächste einen neuen Login und Nummer vier funktioniert nur an einem Dienstag bei abnehmendem Mond.

Ein einheitlicher Prozess ist einfacher.

Für erfahrene Nutzer wirkt er allerdings manchmal etwas grob.

Wenn nur ein paar harmlose Pakete aktualisiert werden, möchte man vielleicht nicht den ganzen Rechner neu starten. Man weiß möglicherweise selbst, wann ein Neustart sinnvoll ist.

Hier treffen zwei unterschiedliche Ziele aufeinander.

Discover sagt:

Lieber einmal zu viel sauber neu starten als einmal zu wenig.

Der erfahrene Terminalnutzer sagt:

Ich verwende seit Jahren einen Paketmanager. Lass mich bitte arbeiten.

Beide Sichtweisen sind nachvollziehbar.

Weniger Informationen können angenehm sein

Discover hält die Aktualisierung vergleichsweise einfach.

Man sieht, dass Updates vorhanden sind, welche Pakete betroffen sind und wie groß die Sache ungefähr wird.

Die eigentliche Transaktion bleibt aber deutlich abstrakter als im Terminal.

Bei DNF sehe ich normalerweise sehr genau:

• welche Pakete aktualisiert werden,
• welche neu installiert werden,
• ob etwas entfernt werden soll,
• welche Abhängigkeiten hinzukommen,
• aus welchem Repository die Pakete stammen,
• und an welcher Stelle ein Problem auftaucht.

Discover erspart dem Nutzer viele dieser Details.

Für Einsteiger ist das ein Vorteil.

Niemand sollte für ein normales Systemupdate erst eine Weiterbildung zum RPM-Archäologen benötigen.

Für erfahrene Nutzer kann genau diese Vereinfachung aber unbefriedigend sein.

Ich möchte zumindest wissen, wenn das System nebenbei beschließt, zwölf Pakete zu entfernen, drei Grafikbibliotheken auszutauschen und einen mittelgroßen Hamster als neue Abhängigkeit zu installieren.

Das Terminal bietet mehr Transparenz.

Discover bietet dafür mehr Ruhe.

Die entscheidende Frage lautet also nicht nur:

Welcher Weg ist technisch besser?

Sondern auch:

Wie viel möchte der Nutzer überhaupt sehen?

Wenn das Offline-Update scheitert

Auch ein Update im laufenden System kann fehlschlagen.

Der Vorteil des Terminals ist, dass der Fehler meistens direkt sichtbar wird.

Ein Repository antwortet nicht. Ein Paket hat einen Konflikt. Eine Abhängigkeit fehlt. DNF bricht ab und zeigt im besten Fall ziemlich genau an, woran es liegt.

Beim Offline-Update passiert die eigentliche Installation außerhalb der normalen Desktop-Sitzung.

Wenn dort etwas schiefläuft, steht kein Browser bereit, um die Fehlermeldung zu suchen. Es gibt keine bequem geöffnete Konsole und auch keinen Forumsbeitrag aus dem Jahr 2019, in dem jemand exakt dasselbe Problem hatte und anschließend nie erklärte, wie er es gelöst hat.

Die Protokolle sind weiterhin vorhanden und können später untersucht werden.

Für einen Einsteiger ist die Situation trotzdem schwerer einzuschätzen.

Ein Aktualisierungsbildschirm, der scheinbar hängt, wirkt schnell dramatischer als eine rote Fehlermeldung in einem geöffneten Programm.

Das Offline-Verfahren reduziert bestimmte Risiken während der Installation.

Es macht die Fehlersuche im Ernstfall aber nicht automatisch leichter.

Offline bedeutet also nicht narrensicher.

Es verschiebt nur den Zeitpunkt, an dem geprüft wird, wie narrensicher die ganze Angelegenheit tatsächlich ist.

Fedora sperrt niemanden ins Neustartgefängnis

Der wichtigste Punkt ist: Discover ist nicht der einzige Weg.

Wer Fedora lieber klassisch aktualisiert, kann weiterhin das Terminal benutzen.

sudo dnf update

Damit werden die Pakete im laufenden System installiert.

Fedora nimmt erfahrenen Nutzern diese Möglichkeit nicht weg. Die grafische Standardmethode setzt lediglich stärker auf Einfachheit, Konsistenz und einen klaren Systemzustand.

Ich kann weiterhin entscheiden:

• Möchte ich Discover verwenden?
• Möchte ich die Aktualisierung beim Neustart durchführen?
• Möchte ich die Pakettransaktion im Terminal verfolgen?
• Möchte ich erst morgen aktualisieren?
• Möchte ich vorher genau prüfen, was geändert wird?

Diese Wahl ist entscheidend.

Und genau deshalb stört mich das Windows-artige Gefühl deutlich weniger.

Fedora sagt nicht:

So wird aktualisiert und nicht anders.

Fedora sagt eher:

Für normale Desktopnutzer empfehlen wir diesen Weg. Wer genauer hinsehen möchte, findet das Terminal weiterhin dort, wo es gestern auch schon war.

Damit kann ich leben.

Pro: Was für Offline-Updates spricht

Ein sauberer Systemzustand

Nach der Aktualisierung startet Fedora vollständig neu. Laufende Programme und Dienste gehören dadurch zum neuen Paketstand.

Weniger Konflikte mit laufender Software

Desktop, Browser und Hintergrunddienste greifen während der eigentlichen Installation nicht gleichzeitig auf Dateien zu, die gerade ersetzt werden.

Einfacher Ablauf für Einsteiger

Updates herunterladen, neu starten, warten, fertig. Kein Wissen über Dienste, Bibliotheken oder Paketmanager erforderlich.

Ein bewusst gewählter Zeitpunkt

Der Nutzer entscheidet selbst, wann die Aktualisierung stattfindet. Vorher können Programme geschlossen und Arbeiten gespeichert werden.

Sinnvoll bei großen Systemkomponenten

Bei umfangreichen Plasma-, Framework-, Grafik- oder Systemupdates ist eine komplett frische Sitzung danach durchaus vernünftig.

Kontra: Was gegen Offline-Updates spricht

Der Rechner ist währenddessen nicht nutzbar

Die Aktualisierung blockiert das gesamte System.

Ein zusätzlicher Neustart

Viele kleinere Updates würden technisch auch ohne vollständigen Neustart funktionieren.

Weniger Transparenz

Discover zeigt weniger Einzelheiten als DNF. Erfahrene Nutzer sehen dadurch weniger von der eigentlichen Pakettransaktion.

Fehler wirken schnell dramatischer

Wenn der Vorgang scheinbar hängt, fehlt die normale Desktopumgebung für eine unmittelbare Fehlersuche.

Für kleine Aktualisierungen teilweise überdimensioniert

Nicht jedes Paket braucht ein eigenes Wartungsritual mit Neustart und feierlicher Fortschrittsanzeige.

Einsteiger und erfahrene Nutzer wollen nicht dasselbe

In der Linux-Welt wird gerne behauptet, möglichst viel Kontrolle sei grundsätzlich besser.

Das klingt gut, ist aber nur die halbe Wahrheit.

Viele Menschen möchten gar nicht jeden einzelnen Schritt kontrollieren. Sie möchten, dass ihr Rechner zuverlässig funktioniert.

Ein Einsteiger braucht nicht zwingend eine vollständige Liste aller RPM-Skripte. Er braucht vor allem die Gewissheit, dass das Update abgeschlossen ist und der Rechner danach weiterhin startet.

Ein erfahrener Nutzer möchte dagegen möglicherweise genau sehen, was geändert wird. Er möchte selbst beurteilen, ob ein Neustart nötig ist, und bei Problemen unmittelbar eingreifen können.

Discover versucht vor allem, die erste Gruppe gut abzuholen.

DNF bleibt für die zweite Gruppe erhalten.

Das ist eigentlich eine vernünftige Aufteilung.

Problematisch würde es erst, wenn Fedora irgendwann das Terminal entfernt und stattdessen freundlich verkündet:

Diese Funktion wird von Ihrer Organisation verwaltet.

Dann dürften wir langsam nervös werden.

Vielleicht stört uns gar nicht der Neustart

Je länger ich mich damit beschäftigte, desto stärker hatte ich den Verdacht, dass mich gar nicht der technische Ablauf irritiert hat.

Mich störte vor allem die Erinnerung.

Ein Neustart mit Updatebildschirm fühlt sich nach Windows an.

Und Windows hat über viele Jahre geschafft, diesen Vorgang emotional ungefähr auf dieselbe Stufe zu stellen wie einen Zahnarzttermin kurz vor Feierabend.

Man verbindet damit:

• lange Wartezeiten,
• schlechte Zeitpunkte,
• unklare Fortschrittsanzeigen,
• und die leise Angst, dass danach irgendetwas anders aussieht.

Fedora verwendet einen ähnlichen Ablauf, aber unter anderen Bedingungen.

Ich starte die Aktualisierung bewusst. Die Pakete werden vorher heruntergeladen. Der Zeitpunkt bleibt kontrollierbar. Das Terminal bleibt als Alternative erhalten.

Vielleicht ist also nicht das Offline-Update das eigentliche Problem.

Vielleicht hat Microsoft einfach das Image des Neustartknopfs ruiniert.

Mein Fazit: Verdächtig vertraut, aber gar nicht so dumm

Mein erster Gedanke war eindeutig:

Fedora macht Windows-Dinge.

Nach genauerem Hinsehen würde ich das aber nicht mehr als Vorwurf formulieren.

Offline-Updates haben nachvollziehbare Vorteile. Sie vermeiden einen vorübergehenden Mischzustand aus alten laufenden und neuen installierten Komponenten. Sie geben dem System einen klaren Wartungszeitpunkt und führen anschließend zu einer vollständig frischen Sitzung.

Für Linux-Einsteiger ist dieser Weg leicht verständlich und wahrscheinlich angenehmer, als selbst beurteilen zu müssen, welche Dienste oder Programme nach einem Update neu gestartet werden sollten.

Für erfahrene Nutzer ist er weniger transparent, gelegentlich unnötig langsam und bei kleinen Aktualisierungen vielleicht etwas übertrieben.

Zum Glück bleibt DNF erhalten.

Ich persönlich bin deshalb nicht grundsätzlich dagegen.

Der Ablauf hat sogar etwas Vertrautes und Kontrolliertes. Ich kann die Aktualisierungen vorbereiten, meine Arbeit beenden und dem System anschließend bewusst Zeit geben, alles in Ruhe einzubauen.

Wahrscheinlich werde ich Fedora trotzdem weiterhin meistens im Terminal aktualisieren.

Nicht unbedingt, weil das objektiv immer besser wäre.

Sondern weil eine lange Paketliste auf schwarzem Hintergrund einfach deutlich stärker danach aussieht, als hätte ich Ahnung von dem, was ich tue.

Auch wenn ich währenddessen hauptsächlich darauf hoffe, dass am Ende wieder der Prompt erscheint. 😅