Vom Update-Wahn zur Gelassenheit

Neue Versionen üben einen eigentümlichen Reiz aus. Sie versprechen neue Funktionen, geschlossene Sicherheitslücken und technische Verbesserungen. Über die Jahre ist daraus aber eine andere Erkenntnis entstanden: Ein gutes System muss nicht möglichst aktuell sein. Es muss zuverlässig funktionieren.

Als ein Windows-Update den Rechner lahmlegte

2015 endete ein Windows-Update auf dem Desktoprechner eines Mitarbeiters mit einem Bluescreen. Der Rechner war anschließend praktisch unbrauchbar. Eine Wiederherstellung war nicht sinnvoll möglich; für eine saubere Neuinstallation wäre zugleich der Wechsel auf eine neue Windows-Lizenzversion erforderlich gewesen.

Linux war zu diesem Zeitpunkt längst kein völlig unbekanntes Terrain mehr. Kurz zuvor hatte ein externer Dienstleister die damals eingesetzte SugarCRM-Installation von einem Windows-Server auf Ubuntu 12.04 migriert. Der Linux-Server verrichtete seine Arbeit unauffällig und zuverlässig.

Warum also nicht auch Linux auf dem Desktop?

Der Rat des Dienstleisters war naturgemäß nicht völlig objektiv. Er betreute bereits die CRM-Installation und stand Linux deutlich näher als Windows. Sein wesentliches Argument war die zunehmend restriktive Lizenzpolitik von Microsoft. Dagegen stand eine wesentlich wichtigere Frage: Würde ein Wechsel des Betriebssystems die Akzeptanz und Produktivität der Mitarbeiter beeinträchtigen?

Die Lösung war überraschend unspektakulär.

Ubuntu, GNOME – und möglichst nichts verändern

Auf den Arbeitsplatzrechnern wurde Ubuntu LTS mit GNOME installiert. Und zwar als einheitlicher Standard, ohne individuelle Anpassungen und ohne Experimente.

Das funktionierte hervorragend.

Der Grund dafür lag wahrscheinlich weniger in einer grundsätzlichen Überlegenheit von Linux als in der Art der Nutzung. Die Rechner waren Arbeitsgeräte. Browser, E-Mail, Office-Anwendungen und die benötigten betrieblichen Programme mussten funktionieren. Welches Betriebssystem darunter lief, spielte im Alltag erstaunlich schnell keine große Rolle.

Diese Erfahrung prägt den Umgang mit fremd genutzten Rechnern bis heute: Ubuntu LTS, GNOME, Standardinstallation. Möglichst wenig verändern.

Beim eigenen Rechner entwickelte sich die Sache allerdings anders.

Wenn aus Anpassung Bastelei wird

Linux bietet eine Freiheit, die ausgesprochen verführerisch sein kann. Was nicht gefällt, lässt sich häufig ändern. Und was sich ändern lässt, wird irgendwann auch geändert.

Der eigene Desktop wurde deshalb über die Jahre immer stärker an die persönlichen Arbeitsabläufe angepasst. Mit Canonicals zunehmender Ausrichtung auf Snap kam ein weiterer Antrieb hinzu. Snap sollte möglichst vollständig vermieden werden.

Anfangs waren dafür nur kleinere Eingriffe notwendig. Mit der Zeit wurden die Anpassungen tiefer. Pakete wurden ersetzt, Installationswege verändert und Ubuntu immer weiter von dem Zustand entfernt, für den die Distribution eigentlich entwickelt und getestet worden war.

Bis irgendwann der Punkt erreicht war, den Linux Jahre zuvor eigentlich überwinden sollte: der eigene „Bluescreen“ – nicht unbedingt als blauer Bildschirm, aber im übertragenen Sinn.

Das System war durch die eigenen Eingriffe unnötig kompliziert geworden.

Die Konsequenz war nicht die Rückkehr zu Windows, sondern ein Wechsel zu Debian 12. Die selbst genutzten Rechner wechselten auf Debian, die von anderen genutzten Arbeitsplätze blieben bei Ubuntu LTS mit GNOME.

Damit war eine wichtige Lektion gelernt: Die Möglichkeit, ein System zu verändern, ist noch kein Grund, es zu verändern.

Dann kam KDE Plasma

Eigentlich hätte die Geschichte damit enden können.

Tat sie aber nicht.

Ein Artikel über Manjaro weckte das Interesse an KDE Plasma. Zunächst stand deshalb sogar ein Wechsel der Distribution im Raum. Manjaro versprach einen sehr aktuellen Desktop und durch das Rolling-Release-Modell ständig neue Softwareversionen.

Damit begann die nächste Abwägung: Wie viel Aktualität ist tatsächlich sinnvoll? Welche Vorteile bringt ein Rolling Release – und welche Risiken erkauft man sich damit?

Am Ende führte die Beschäftigung mit Manjaro zu einer ganz anderen Entscheidung. Nicht die Distribution wurde gewechselt, sondern der Desktop.

Debian blieb. GNOME ging. KDE Plasma kam.

Das erwies sich als die eigentlich interessante Kombination: die konservative Basis von Debian Stable mit einem Desktop, der erheblich mehr Möglichkeiten zur individuellen Gestaltung bietet.

Und damit tauchte das alte Problem in neuer Form wieder auf.

Ein Rechner ist ein Werkzeug – darf aber trotzdem Spaß machen

„Der Rechner ist nur ein Werkzeug“ klingt vernünftig. Ganz stimmt es trotzdem nicht.

Ein guter Akkuschrauber darf schließlich ebenfalls angenehm in der Hand liegen.

Neue Desktopfunktionen können Arbeitsabläufe verbessern. Eine gut durchdachte Oberfläche spart Zeit. KDE Plasma bietet zahlreiche Möglichkeiten, den Desktop an die tatsächliche Nutzung anzupassen. Und manches Neue ist schlicht interessant und macht Freude.

Software ausschließlich nach ihrer unmittelbaren Notwendigkeit zu beurteilen, wäre deshalb ebenso dogmatisch wie der Drang, immer die neueste Version installieren zu müssen.

Genau hier liegt die Versuchung von Debian Testing.

Nach dem Wechsel zu Plasma kam schnell der Blick auf Forky, die derzeitige Testing-Version und Basis des kommenden Debian 14. Neuere Plasma-Versionen, aktuellere Anwendungen und die Aussicht, Entwicklungen früher nutzen zu können, haben ihren Reiz.

Technisch wäre der Wechsel machbar.

Trotzdem bleibt Debian Stable vorerst auf den Rechnern.

Warum Stable inzwischen gewinnt

Das wäre vor einigen Jahren möglicherweise anders entschieden worden.

Über die Jahre hat sich der Umgang mit Softwareupdates deutlich verändert. Früher war eine neue Version ein Grund, möglichst schnell zu aktualisieren. Heute spricht einiges dafür, genau das nicht zu tun.

Bei größeren Versionssprüngen darf inzwischen gern erst das erste Point Release erscheinen. Kinderkrankheiten können andere finden. Bei produktiv eingesetzter Software haben stabile Versionsstände grundsätzlich Vorrang vor maximaler Aktualität.

Das bedeutet nicht, Sicherheitsupdates aufzuschieben. Sicherheitsaktualisierungen, Fehlerkorrekturen und Versionssprünge sind unterschiedliche Dinge und sollten auch so behandelt werden.

Entscheidend ist vielmehr die Frage:

Welches konkrete Problem löst die neue Version?

Gibt es darauf eine gute Antwort, kann ein frühes Update sinnvoll sein. Lautet die Antwort lediglich „Dann ist die Versionsnummer höher“, darf die Aktualisierung warten.

Gerade bei einem Betriebssystem sprechen Stabilität und eine verlässliche Versorgung mit Sicherheitsupdates für eine konservative Strategie. Der Rechner soll morgens eingeschaltet werden und funktionieren. Die Pflege des Betriebssystems darf nicht selbst zu einer regelmäßigen Beschäftigung werden.

Aktualität ist kein Selbstzweck

Ausgerechnet Linux verleitet technisch interessierte Nutzer dazu, diese Grenze gelegentlich zu vergessen. Es gibt ständig etwas Neues: Kernel, Desktopumgebungen, Anwendungen, Paketformate und ganze Distributionen.

Das auszuprobieren gehört zum Reiz eines offenen Systems.

Problematisch wird es erst, wenn aus Interesse ein permanenter Aktualisierungszwang entsteht. Wer ein funktionierendes System ständig umbaut, nur um auf dem neuesten Stand zu bleiben, macht irgendwann das Werkzeug selbst zum Projekt.

Die Erfahrungen seit 2015 haben deshalb zu einer deutlich konservativeren Haltung geführt: stabile Distributionen, Sicherheitsupdates zeitnah, größere Versionswechsel mit etwas Abstand und Anpassungen dort, wo sie einen tatsächlichen Nutzen bringen.

Ganz konsequent ist diese Haltung allerdings nicht.

Debian Testing und Forky bleiben interessant. Ein aktuelleres KDE Plasma ebenfalls. Vielleicht kommt irgendwann doch der Zeitpunkt für einen früheren Wechsel.

Bis dahin darf das Liebäugeln mit Testing als charmante Schwäche durchgehen.

Denn ein Rechner bleibt ein Werkzeug.

Aber ein Werkzeug darf auch Spaß machen.