Die Probleme mit der Wifi-Karte auf meinem Thinkpad habe ich erfolgreich gelöst. Seit der Umstellung auf iwd gab es keine Kernelpanics mehr. Also konnte ich mir in Ruhe anschauen, wie Tumbleweed sich über vier Wochen allgemein verhält. Kurz gesagt: Es gab keine Probleme.

Updates

Tumbleweed ist ein Rolling-Release-System. Updates für die Pakete werden zeitnah bereitgestellt. Im Gegensatz zu Arch gibt es in Tumbleweed immer Snapshots, die veröffentlicht werden. In diesen Snapshots sind die Updates gebündelt. Dank der automatisierten Tests bei openSUSE ist sichergestellt, dass das System in seiner Gesamtheit auch nach dem Update funktioniert. Das bedeutet aber nicht, dass keine Bugs in den neuen Versionen der Pakete enthalten sein können. Soweit ich es verstehe, geht es bei den automatisierten Test eher darum, dass das Gesamtsystem weiterhin funktioniert (Bootet es? Kann eine grafische Oberfläche gestartet werden? Funktionieren die wichtigsten Programme? …). Während des Aprils gab es kein Update, welches bei mir ein Problem verursacht hat.

Allerdings haben die Updates teilweise einen enormen Umfang gehabt. Es ist nicht ungewöhnlich gewesen, dass ich an zwei oder drei Tagen in einer Woche jeweils über ein Gigabyte an aktualisierten Paketen installieren durfte. Insbesondere das Update von LaTeX ist in diesen Zeitraum gefallen. Das ist nicht nur von der Größe her ein echter Brocken, auch die Anzahl der Pakete ist enorm. Und LaTeX wurde, wenn ich mich richtig erinnere, dreimal aktualisiert. Man muss sich also darauf einstellen, dass es oft große Updatepakete geben kann.

Was aber sehr gut funktioniert, ist das Aussetzen eines oder mehrerer Updates. Ich habe auch einmal den Computer eine Woche nicht aktualisiert. Und ich habe noch ein älteres Thinkpad, das vier Wochen im Schrank lag und nicht benutzt wurde. Das war für Tumbleweed kein Problem. Ein sudo zypper dup hat auf beiden Geräten sehr gut funktioniert.

Wenn man sich vorab über den Inhalt eines Updatepakets informieren möchte, dann kann ich folgende Seite empfehlen: Tumbleweed snapshots. Ich habe die Seite in meinem RSS-Aggregator abonniert. So kann ich mir vorab anschauen, was im Update enthalten ist.

Sehr zu empfehlen ist in dem Hinblick auch der Blog von Dominique a.k.a. DimStar (Dim\*) – A passionate openSUSE user. Hier gibt es jede Woche ein Review mit den Highlights und eine Vorausschau auf die nächste Woche.

Snapshots

Bei jedem Update legt openSUSE einen Snapshot an. Sollte ein Update also doch Probleme verursachen, kann ich beim Neustart des Rechners eine ältere Version starten. Der ältere Snapshot kann dann als aktuelles, produktives System wieder aktiviert werden. Wenn der Bug kritisch ist und viele Personen betreffen sollte, sind die Chancen gut, dass es schnell einen Fix gibt. So oder so… sollte ein Update einmal schiefgehen, ein Reboot und ich habe wieder ein funktionierendes System. Und das alles kommt out of the box.

Softwareverfügbarkeit

Im Repository ist sehr viel enthalten. Es gab einige Programme, die ich nicht gefunden habe und dann als Flatpak installiert habe. Bei mir sind das unter anderem Programme wie Discord, Element, Proton Mail Bridge oder Signal. Ich wollte da auch nicht mit RPM-Paketen arbeiten, die ich selber herunterladen und dann installieren muss. Entweder es ist im Repository von openSUSE, dann freue ich mich. Ansonsten wird es über Flatpak installiert. Ich habe damit kein Problem.

Codecverfügbarkeit

Über Codecs hatte ich bereits Ende März ebenfalls geschrieben. Ich bleibe bei meiner Entscheidung Firefox und VLC als Flatpak zu nutzen. Dadurch spare ich mir die evtl. auftretenden Probleme mit dem Packman-Repository.

Community

Ich lese viel im Subreddit r/openSUSE. Man merkt, dass die Community nicht besonders groß ist. Die Anzahl der Beiträge ist überschaubar und es werden sehr wenig Screenshots des Desktops gepostet. Die meisten Beiträge sind konkrete Probleme. Und es wird auch geholfen. Ich wünsche mir, jede Community wäre so unaufgeregt wie die openSUSE-Community. Ich bin auch in ein oder zwei Matrix-Kanälen von openSUSE stiller Leser. Und auch hier ist die Kommunikation angenehm, unaufgeregt und hilfsbereit. Wenn ich mir andere Foren, Discord-Kanäle oder Subreddits anschaue, dann bin ich froh openSUSE, aktuell zu nutzen. Übrigens, es gibt ein Grafana-Dashboard von openSUSE. Es werden die Zugriffe auf den Hauptmirror registriert. Daraus kann man grob ableiten, wie viele Benutzer es mindestens gibt. Für Tumbleweed pendelt es zwischen 240000 und 250000 Benutzern. Slowroll könnte vielleicht dieses Jahr die 6000 Benutzer knacken. Das sind aber nur die Installationen, die den Hauptmirror verwenden. Da es weitere Mirrorserver gibt, liegt die Anzahl der Benutzer mit Sicherheit höher.

Der Wechsel zu Slowroll

Jetzt habe ich einige Male Slowroll erwähnt. Der Unterschied zu Tumbleweed liegt in der Anzahl der Updates. In Slowroll gibt es etwa alle vier Wochen (ich meine, dass es immer um den 9. eines Monats geschieht) ein großes Update. Darin sind dann die aktualisierten Pakete enthalten, die aus Tumbleweed gesammelt wurden. Während des Monats gibt es kleinere Updates, die primär Sicherheitslücken oder kritische Fehler beheben. Ich habe vor einer Woche meine Computer auf Slowroll umgestellt. Da mir die Updates von Tumbleweed dann doch etwas zu groß und zu viel waren, glaube ich für mich hier den richtigen Kompromiss gefunden zu haben. Slowroll ist sehr aktuell, aber eben nicht ganz so aktuell wie Arch oder Tumbleweed. Ich nenne Slowroll „entschleunigtes Rolling-Release“. Slowroll ist aktuell noch in der Beta-Phase. Ich merke davon aber nichts ☺️

Gaming

Aktuell spiele ich ab und zu Diablo 4 über Steam. Das Spiel funktioniert sehr gut unter openSUSE. Übrigens: X-Plane 12 funktioniert auch. Ich habe es aber nur kurz getestet. Andere Spiele habe ich in der Zeit nicht gespielt. Daher kann ich wenig zu Gaming allgemein sagen. Aber da Kernel, Mesa-Treiber und KDE Plasma immer sehr aktuell sind, steht aus meiner Sicht Gaming hier nichts im Wege.

Mein Fazit

Ich finde openSUSE Tumbleweed bzw. Slowroll sehr gut. Das Konzept aus Rolling-Release zusammen mit den automatisierten Tests sowie den Snapshots gibt mir genug Sicherheit, dass ich diese Distribution nutze. Ist openSUSE für jeden etwas? Ich bin da zwiegespalten. Ein Anfänger könnte doch schnell überfordert sein. Man sollte schon ein wenig über Linux wissen und auch keine Scheu vor der Kommandozeile haben. Denn Systemupdates sollten zwingend über zypper eingespielt werden.

Auf jeden Fall ist openSUSE Tumbleweed aber für jeden etwas, der ein Rolling-Release-System haben möchte aber vor Arch zurückschreckt. Bei openSUSE Tumbleweed bekommt man ein fertig eingerichtetes System. Man muss dann aber auch mit den Entscheidungen leben, die openSUSE für einen getroffen hat. Möchte man sein eigenes System aufbauen und selber die Entscheidungen treffen, dann ist Arch klar besser. Tumbleweed oder auch Slowroll müssen sich aber nicht verstecken. Und ich hoffe, dass diese Distribution bzw. das gesamte openSUSE-Projekt ein wenig mehr Aufmerksamkeit bekommt. Denn zur Zeit führt diese Distribution eher ein Schattendasein, welches nicht verdient ist.

Codecs in openSUSE Tumbleweed

openSUSE ist sehr strikt, wenn es um die Bereitstellung von Codecs geht. Das liegt, soweit ich es verstehe, an den Lizenzen. Fedora z. B. liefert ebenfalls keine unfreien Codecs aus. In beiden Distributionen gibt es jeweils ein separates Repository, welches unfreie Codecs bereitstellt. Bei openSUSE ist dies Packman (nicht mit pacman dem Arch-Paketmanager verwechseln). Es gibt das Tool opi, welches mittels zypper in opi installiert werden kann. Wenn man nun opi codecs aufruft, werden die Codecs aus dem Packman-Repository installiert. Dies führt zu einem Anbieterwechsel der entsprechenden Pakete.

Was sind die Probleme mit Packman?

Packman hat zwei Probleme.

1. Es ist kein offizielles Repository. Das Repository wird unabhängig vom openSUSE-Projekt verwaltet. Wie oben geschrieben… Lizenzprobleme. Das bedeutet, dass man sich ein Dritt-Repository in sein System einbindet. Die Pakete liegen außerhalb von openSUSE und können theoretisch kompromittiert sein. Jetzt muss man für sich selber entscheiden, wie weit man diesem Repository vertraut.
2. Sync-Probleme Das war mein Problem. Es gab in Tumbleweed Updates für Pakete, die auch innerhalb von Packman liegen und durch die Codecs installiert waren (ich glaube ffmpeg war es). Das Packman-Repository benötigt etwas Zeit, um diese Änderungen bei sich bereitzustellen. Wenn man dann ein Update durchführt, möchte zypper die Pakete von openSUSE installieren (vendorchange). In meinem Fall waren es mehrere Tage, sofern ich es auf Reddit verfolgen konnte. Zu dem Zeitpunkt hatte ich Arch installiert.

Wieder auf Tumbleweed

Ich habe mich trotz der Probleme dazu entschieden, doch wieder Tumbleweed zu installieren. Und auch das Problem mit Packman für mich zu lösen. Warum ich wieder bei Tumbleweed bin? Zum einen ist die Integration der automatischen Snapshots mittels Snapper perfekt gelöst. Zum anderen… die Community ist sehr unaufgeregt. Egal ob ich in das subreddit r/openSUSE oder in das Forum oder auf Matrix reinschaue, Diskussionen sind ruhig und sachlich. Ich habe den Eindruck, dass es einen recht festen und treuen Kern an openSUSE-Benutzern und Experten gibt. Außerdem werden geplante Änderungen ruhig besprochen und nicht übereilt durchgeführt. Und ich habe das Codec-Problem für mich vorerst gelöst. Ich verwende das Packman-Repository einfach nicht. Für Programme, die Codecs benötigen, bin ich auf die Flatpak-Variante umgestiegen. Das betrifft bei mir aktuell Firefox und VLC. Über Flatpak bringen beide Codecs mit. Und die Codecs bieten auch Hardwarebeschleunigung. Das löst dann das Auftreten von Sync-Problemen mit Packman und auch die Vertrauensfrage ist gelöst.

Wichtige Anmerkung hier: Wenn man dann Firefox und VLC mittels zypper deinstalliert, sollte man die Pakete danach in zypper “locken”. Sonst könnten sie bei einem Update wieder installiert werden. Der Befehl dazu lautet zypper al firefox bzw. zypper al vlc. Mit zypper locks kann man sich alle gelockten Pakete ausgeben lassen.

Jetzt nutze ich also openSUSE Tumbleweed. Und ich will das als Challenge angehen. Bis Ende April muss ich mindestens bei Tumbleweed bleiben. Also gut einen Monat. Ich bin gespannt, wie es läuft.

Natürlich möchte ich aber dennoch gerne irgendwann WIFI 7 nutzen können. Meine Hoffnung lag bisher auf dem Kernel 7.0. Durch einen glücklichen Zufall bin ich aber im Arch-Forum auf diesen Thread gestoßen: https://bbs.archlinux.org/viewtopic.php?id=312624 Der Benutzer dort beschreibt exakt mein Problem. Die Analyse des Arch-Mitglieds Seth ist interessant. Er kann die Logs korrekt interpretieren und führt die Probleme auf wpa_supplicant zurück. Das ist der Dienst, der mit dem WIFI-Router die Verbindung aushandelt (soweit ich es verstehe). Und wpa_supplicant kann bisher nur sehr rudimentär WIFI 7. Diese Tatsache und der Umstand, dass am ath12k-Modul sehr aktiv gearbeitet wurde und wird, scheinen dann zu der Kernelpanic zu führen. Ich habe also den Lösungsvorschlag von Seth bei mir umgesetzt.

Lösung

Es hilft, wenn man wpa_supplicant durch iwd ersetzt. Das funktioniert unter Arch sehr einfach. Im Wiki wird das hier beschrieben: https://wiki.archlinux.org/title/NetworkManager#Using_iwd_as_the_Wi-Fi_backend

1. iwd mittels pacman -S iwd installieren
2. Dem Networkmanager mitteilen, dass iwd als Backend verwendet werden soll. Dazu wird die Datei /etc/NetworkManager/conf.d/wifi_backend.conf mit folgendem Inhalt angelegt:

   [device]
   wifi.backend=iwd
   

3. wpa_supplicant am besten dann mit sudo systemctl mask wpa_supplicant maskieren. Das verhindert, dass irgendwie doch noch wpa_supplicant genutzt werden kann.
4. Den Rechner einmal neustarten
5. Die alte WIFI-Verbindung einmal löschen und neu verbinden.

Seit ich diese Änderung auf meinem Thinkpad durchgeführt habe, läuft die WLAN-Verbindung stabil. Es gibt in KDE Plasma einen kleinen kosmetischen Bug. Beim Klicken auf das WLAN-Symbol wird in dem Widget nicht direkt der Status der WLAN-Verbindung angezeigt. In den Systemeinstellungen kann man aber die Verbindungsgeschwindigkeit sowie weitere Informationen einsehen. Im KDE-Forum habe ich bereits eine Diskussion mit diesem Problem gefunden. Für mich ist das nicht wichtig. Das Symbol selber signalisiert korrekt, ob ich mit dem WLAN verbunden bin. Das reicht für mich aus. Ich habe dafür aber auch Vorteile bemerkt. iwd baut die WIFI-Verbindung viel schneller auf. Insbesondere beim Aufwachen aus dem Standby muss ich nicht mehr lange warten. Für mich ist iwd eine Verbesserung und nicht nur, weil die Kernelpanics nicht mehr auftreten.

Ja… manchmal muss man in Linux vielleicht auch bei einem Bug um die Ecke denken. Es gibt oft nicht nur ein Tool, welches Funktionen bereitstellt. Sondern zwei oder drei oder viele. Und manchmal hilft es dann einfach, das Tool zu wechseln. Ich bin aber zuversichtlich, dass auch wpa_supplicant irgendwann mit WIFI 7 umgehen kann.

Also habe ich gestern und heute sowohl mein Notebook Jupiter als auch meinen PC Mars auf Arch umgestellt. Und ja… Vanilla Arch. Kein EndeavourOS, kein CachyOS. Ich habe es auf beiden Systemen mittels archinstall und dem Wiki es sogar geschafft, dass ich automatische Snapshots während eines Updates habe. Es ist also wie openSUSE. Wenn ein Update schwere Fehler mitbringen sollte, kann ich auf einen älteren Snapshot wechseln und hoffentlich das Problem aussitzen.

Mir gefällt Arch. Man merkt irgendwie, dass es eine reine Community-Distribution ist. Die Struktur ist klar, alles ist recht logisch aufgebaut. Und das Arch-Wiki ist wohl die beste Linux-Dokumentation, die man finden kann. Da können sich viele andere Distributionen eine große Scheibe von abschneiden. Ich weiß, so etwas ist nur durch viel Einsatzbereitschaft der Maintainer und Entwickler möglich. Und dafür möchte ich hier einfach Danke sagen.

Ich bin gespannt, wie sich jetzt Arch die nächste Zeit schlägt. Auf meinem PC Mars hatte ich wirklich lange EndeavourOS im Einsatz. Meine Phase des extremen Distrohoppings fing eigentlich erst mit dem Thinkpad an, da ich hier auf die WLAN- und Stabilitätsprobleme gestoßen bin. Bisher… mit abgeschaltetem Wifi-7 läuft die Kiste aber richtig gut. Von daher hoffe ich, dass es jetzt so bleibt. Und dass ich mich auf eine ruhige Zeit mit Arch freuen kann.

Welcome Back openSUSE Tumbleweed.

Kurzer Blick zurück

Ich habe ein Thinkpad Gen 5 AMD. Darin ist eine Wifi-7-Karte verbaut (Qualcomm WCN785x). Ich habe ebenfalls eine Fritzbox, die bereits Wifi-7-fähig ist. Seit dem Kernel 6.18 wird beim Aufwachen aus dem Standby reproduzierbar eine Kernel Panic ausgelöst. Seit dem Kernel 6.19 läuft auch die WLAN-Verbindung selber hakelig. Das Gerät verbindet sich immer wieder neu, wechselt zwischen 2,4 GHz und 5 GHz hin und her. Oder baut gar keine Verbindung auf. Ich kann das Verhalten mit diversen Distributionen nachstellen. Das Problem entsteht irgendwo im ath12k-Modul.

Das war auch der Grund, warum ich jetzt erstmal Ubuntu LTS genutzt habe. Das war die einzige Distribution mit einem stabilen Kernel und Wifi.

Der heutige Durchbruch

Heute habe ich mir gedacht… egal… ich kann auf das Thinkpad auch ein wenig verzichten. Ich teste eine Distribution mit aktuellem Kernel und versuche dann, dort im Forum eine entsprechende Meldung zu posten. Vielleicht gibt es dort dann Entwickler, die darauf aufmerksam werden. Denn ich denke, ich bin nicht alleine mit dem Problem.

Ich habe daher CachyOS (Arch-basiert) installiert. Das war für mich hier das Einfachste. Und ich weiß, dass die Entwickler von CachyOS auch durchaus Richtung Upstream mit Kernelentwicklern kommunizieren.

Nach der Installation hatte ich, wie erwartet, den Kernelcrash beim Aufwecken aus dem Standby. Ich habe das Gerät erst einmal weiter eingerichtet, aber es lief auch nicht richtig rund. Wifi hing, was sogar zu kurzen Freezes in Gnome geführt hat. Wie sage ich dann immer: “Das Gerät lief wie ein Sack Flöhe”. In den Logs fand ich dann u. a. diesen Fehler:

• ath12k_pci 0000:02:00.0: ML peer 0 exists already, unable to add new entry for [MAC]
• wlan0: failed to insert STA entry for the AP (error -17)
• WARNING: drivers/net/wireless/ath/ath12k/mac.c:11932 at ath12k_mac_op_unassign_vif_chanctx

Das sind wohl Fehler, die beim Versuch, das MLO mit dem Router auszuhandeln, entstehen (zumindest nach meiner Recherche… ich habe da aber wirklich wenig Ahnung). Das ist wohl ein Feature von Wifi 7. Also… was verliere ich, wenn ich den Router auf Wifi 6 umstelle? Eigentlich nicht viel, da mein Thinkpad eh das einzige Wifi-7-fähige Gerät ist.

Gesagt, getan… ich habe die Fritzbox umgestellt. Und eine KI empfahl mir, noch folgende Einstellung im Thinkpad vorzunehmen:

Mittels sudo nano /etc/modprobe.d/ath12k.conf eine Konfiguration für das ath12k-Modul anlegen und folgenden Inhalt einpflegen:

options ath12k mlo_capable=0

Ob der Parameter wirklich funktioniert, habe ich nicht weiter getestet. Denn… nachdem ich in der Fritzbox die Änderung durchgeführt und meinen Laptop neu gestartet habe, lief das Gerät perfekt. Ich habe keine Kernel Panic mehr beim Resume. Die Verbindung zu meinem WLAN wird quasi sofort aufgebaut. Es läuft auch alles stabil. Keine kurzen Freezes oder langsamen Übertragungen mehr.

Ich werde das Problem weiter beobachten. Vielleicht bringt der Kernel 7.0 dann die Verbesserungen und Fixes. Ich werde das Problem auf jeden Fall in den nächsten Tagen im CachyOS-Forum posten. Vielleicht hilft jemandem diese Erkenntnis oder jemand kann bei weiteren Analysen unterstützen.

Update

Ich habe den Bug mal im openSUSE-Projekt gemeldet: https://bugzilla.opensuse.org/show_bug.cgi?id=1259775

Update 2

Es gibt eine Lösung, um WIFI 7 nutzen zu können. Ich beschreibe das hier: Thinkpad läuft jetzt stabil

Für meine Rollenspielrunden habe ich lange Zeit Discord verwendet. Ich habe dort einen eigenen “Server” aufgesetzt, einige Chat- wie auch Videoräume eingerichtet und es dann einfach für meine Runden genutzt. Discord ist einfach zu benutzen, ich muss mir keine Gedanken über das Hosting machen und es funktioniert auch meistens stabil.

In den letzten Monaten aber wurde immer mehr Werbung in Discord eingeführt. Und Discord hat angekündigt, dass ein System für die Verifikation des Alters kommen wird. Ob das nun bedeutet, dass man seinen Ausweis hochlädt, das Bild gescannt wird oder die Chats per KI durchsucht und bewertet werden, weiß ich nicht. So oder so habe ich aber ein immer schlechteres Gefühl, wenn ich Discord benutze. Also habe ich mich ein wenig nach Alternativen umgeschaut.

Meine Anforderungen

Ich benötige folgende Funktionen in einem Chatclient, damit ich meine Rollenspielrunden leiten kann:

• Es muss Chaträume für den allgemeinen Austausch geben.
• Dateien müssen einfach für die Spieler zur Verfügung gestellt werden können.
• Videochat mit mehreren Personen muss stabil und in guter Qualität funktionieren.
• Der Dienst soll möglichst bei einem Dienstleister in Europa gehostet oder selber auf einem Server bereitgestellt werden

Die Suche

Zuerst habe ich an Teamspeak gedacht. Vor Jahren hatte ich einen kleinen, gemieteten Server. Und ich erinnerte mich, dass es für Sprache genial war. Teamspeak gibt es immer noch. Leider ohne Videochat. So wie ich es sehe, wird diese Funktion auch nicht entwickelt. Also war Teamspeak sofort raus. Ich bin dann auf Matrix gestoßen. Matrix kannte ich schon länger. Im Linux-Umfeld hat Matrix die alten IRC-Chats nahezu vollständig abgelöst. Man kann entweder auf einigen größeren Servern sich eigene Instanzen anlegen (ähnlich wie bei Discord) oder selber einen Matrix-Server aufsetzen und betreiben. Da Matrix mit zum föderierten Netz gehört, können eigene Server durchaus sich mit anderen austauschen. Es muss also nicht jeder zwingend auf dem eigenen Server einen Account haben. Und ich kann mich mit einem Account auf meinem Server auch auf andere Matrix-Server verbinden. Aber auf meinem Server bin ich der Hausherr. Das klingt doch gut. Matrix sollte es also werden.

Die Einrichtung

Hui… Matrix… wo fängt man da an. Es gibt gar nicht den einen Matrix-Server. Es gibt diverse. Begriffe wie Synapse, Livekit, Coturn begegnete ich sofort. Und Element, Fluffychat, Nheko, … Und dann habe ich es zumindest im Ansatz verstanden (glaube ich).

Matrix

Matrix selbst ist das Protokoll. Es umfasst alle Spezifikationen, wie ein Matrix-Server in etwa aufgebaut sein muss, damit er auch mit anderen Matrix-Servern funktioniert. Dazu gibt es dann noch diverse Clients. Die verbinden sich dann mit dem Matrix-Server. Clients haben auch nicht alle denselben Funktionsumfang. Einige können zum Beispiel eigene Emojis anzeigen, andere dafür Videocalls starten… Es ist kompliziert. Ich habe mich dann aber für das Ökosystem von Element (ESS) entschieden. Element ist ein Client. Dazu gehört dann der Server Synapse. Soweit ich es beurteilen kann, ist es der am meisten eingesetzte Server in der Matrixwelt.

Die Einrichtung ist aber doch nicht so einfach wie gedacht. Du siehst meine Anforderungen oben? Videochats bzw. Videocalls… das wird mich fast zur Verzweiflung bringen.

Ich habe mir erstmal einen neuen virtuellen Server besorgt und die ersten DNS-Einträge konfiguriert, die notwendig sind. Dank KI-Unterstützung und einiger Recherche in kagi konnte ich schnell mittels Docker auf dem Server den Communityserver von Element einrichten. Ich konnte mich selber registrieren und die ersten Chaträume anlegen. Das war der einfache Teil. Und hat vielleicht eine Stunde gedauert.

Dann kamen Videocalls…

Uff… ja… Videocalls. Das hätte einfach sein können. Wenn ich nur eine vernünftige Anleitung gefunden hätte, die einfach erklärt, was alles benötigt wird. Aber einfache Anleitungen für Matrix scheint es nicht zu geben. Verstehe mich nicht falsch. Element hat wirklich viele und umfangreiche Dokumentationen. Die sind auch bestimmt super. Aber eine Art Best-Practise-Installation auf einem Debian-System mit Docker habe ich nicht gefunden. Auch keine wirkliche Erklärung, was alles benötigt wird.

Ich habe Stunden benötigt. Habe Yaml-Dateien bearbeitet, getestet, Neustarts durchgeführt und irgendwie hat es nie geklappt. Der Fehler MISSING_MATRIX_RTC_FOCUS hat mich immer wieder beim Start eines Videocalls begrüßt. KI konnte hier auch nur bedingt helfen, denn scheinbar ist diese Funktion noch recht neu. Nach vielen Stunden habe ich dann wohl das Problem gelöst. Es fehlte ein Dienst, der Tokens für die Videocalls ausstellt. Und im Reverseproxy mussten noch einige Konfigurationen geändert werden.

Auf einmal konnte ich in dem Raum für Videocalls einen echten Anruf starten und sah mich selber. Auch die Verbindung über ein zweites Gerät hat geklappt.

Ich dachte, ich wäre fertig.

Matrix ist nicht Matrix… wenn du glaubst, du hast es gelöst…

Ich war auch fertig… mit den Nerven… ich war müde und unkonzentriert. Aber ein letzter Test sollte noch gemacht werden. Ich habe einen zweiten Raum für Videocalls erstellt. Der müsste ja auch funktionieren. Ja… ne… hat es nicht. Das war wirklich spannend. Ich konnte in dem neuen Raum einen Call starten. Aber ich habe nie den Ton oder das Bild des anderen Client gesehen. Habe ich den ersten Raum genommen und dort einen Call gestartet… na… klar… es funktioniert. Ich habe noch einmal meine Firewall geprüft. Ob die Ports korrekt freigegeben sind. Logs geprüft… usw… und es wollte nicht. Bis (und hier muss ich KI mal loben) die KI mir einen guten Tipp gegeben hat. Der Element Client cached scheinbar gerne und viel. Das ist auch grundsätzlich in Ordnung. Aber manchmal cached er auch kaputte Informationen. Der neue Raum muss irgendeine falsche Information im Element Client gehabt haben, sodass die Übertragung des Videosignals nicht funktioniert hat. Als ich im Client den Cache gelöscht habe, klappte der Call sofort. Und auch mit einem dritten und vierten Testraum…

Und jetzt habe ich meinen eigenen Server

Jetzt bin ich also stolzer Besitzer eines eigenen Matrix-Servers. Irgendwie fühlt es sich schon cool an, das überhaupt geschafft zu haben. Heute morgen habe ich mit einem PC, zwei Laptops, Handy und Tablet einen Testcall mit Video gemacht. Der Server hat quasi Däumchen gedreht. Die Qualität der Videos sah sehr gut aus. Zum Audio kann ich nicht viel sagen (fünf Geräte im selben Raum… da sind lieber alle Mikrofone abgeschaltet). Einige Freunde sind auch auf dem Server und testen ein wenig. Jetzt geht es daran, sich über die Konzepte von Spaces, Chats, Gruppen, etc. Gedanken zu machen und für die Rollenspielrunden eine vernünftige Struktur zu erstellen.

Und vielleicht kann ich dann demnächst Discord den Rücken kehren und in der Matrix leben.

• Wir haben diese Pixelgrafik und wollen diese auf dem Plotter mit einem Stift zeichnen lassen. Der Plotter benötigt unbedingt ein SVG, welches möglichst einfach ist.
• Die Brother-Software kann grundsätzlich aus einer Pixelgrafik eine Vektorgrafik erzeugen. Das Ergebnis ist ok. Bei der obigen Grafik waren wir aber mit dem Ergebnis nicht zufrieden. Daher habe ich mich damit beschäftigt, wie man in Inkscape eine Pixelgrafik vektorisieren kann.

Bild in Inkscape einfügen

• Inkscape öffnen
• Bild entweder per Drag and Drop oder über “Datei öffnen” in Inkscape öffnen

SVG erzeugen

• Das geöffnete Bild in Inkscape einmal anklicken, damit es selektiert ist
• Im Menü “Pfad” den Punkt “Bitmap nachzeichnen” aufrufen
• Im rechten Bereich öffnet sich jetzt der Dialog. Die Vorschau sollte bereits das SVG anzeigen. Wenn die Vorschau leer ist, dann noch einmal das Bild anklicken.

Parameter

• Strichzeichnung vektorisieren Diese Option erzeugt aus der Pixelgrafik eine echte Strichzeichnung. Jede erkannte Linie wird unabhängig von ihrer Dicke zu einer dünnen Vektorlinie umgewandelt. Es gibt keine ausgemalten Flächen. Für den Plotter ist das wichtig, da sonst das Plotten Stunden dauern kann oder gar nicht funktioniert. Eine Erklärung der anderen Parameter findet man auf der Inkscape-Seite: https://inkscape.org/de/doc/tutorials/tracing/tutorial-tracing.html
• Ich erhöhe immer “Ecken glätten” und “Optimieren” ein wenig. Ich habe den Eindruck, dass dadurch die Linien besser und etwas runder werden.
• Wenn das Ergebnis in der Vorschau ok ist, wenden wir alles auf das Bild an.

Vektorbild

• Das Vektorbild ist jetzt in unserem Arbeitsbereich über dem Pixelbild. Im rechten Bereich “Ebenen und Objekte” können wir sowohl den Pfad (die Vektorgrafik) wie auch das image (unser Pixelbild) auswählen. Ich verschiebe gerne erst einmal den Pfad im Arbeitsbereich nach rechts und vergleiche das Ergebnis.

Pixelbild löschen

• Sind wir mit dem Ergebnis zufrieden, können wir das Pixelbild löschen. Dazu in “Ebenen und Objekte” das image auswählen und anschließend löschen.
• Es bleibt unsere Vektorgrafik im Arbeitsbereich zurück

SVG in Größe anpassen

• Evtl. stimmt unser Arbeitsbereich nicht mit der Größe der Grafik überein. Damit es passt, wählen wir die Vektorgrafik aus. Anschließend wählen wir im Menü “Bearbeiten” “Seitengröße auf Auswahlgröße”
  • Jetzt sollte die weiße Seite exakt mit der Größe unserer Grafik übereinstimmen

SVG vereinfachen

• Wenn wir unsere Grafik auswählen und links auf das Knotenwerkzeug wechseln, sehen wir alle Knoten der Grafik. Das können ggf. noch sehr viele sein.
• Wir können im Menü “Pfad” “Vereinfachen” wählen und dann das Ergebnis prüfen
• Wenn die Grafik jetzt “kaputt” aussieht, stellen wir über “Bearbeiten” “Rückgängig” den vorherigen Zustand her

SVG korrekt exportieren

• Wir wählen unter “Datei” “Exportieren” aus
• Es ist wichtig, dass wir als Dateiformat “Plan SVG” wählen.
• Ggf. noch den Dateipfad auswählen und dann Exportieren.

Ergebnis

• Wir erhalten jetzt eine einfache SVG-Datei mit der Strichzeichnung als Ergebnis. Die Datei kann ohne Probleme über die Software von Brother verarbeitet und an den Plotter gesendet werden. Einen Transfer per USB haben wir nicht versucht.
• Der Brother-Plotter sollte diese Datei jetzt innerhalb weniger Minuten plotten können
• Wir lernen: mit Inkscape kann man sehr einfach und schnell aus einer Pixelgrafik ein SVG erzeugen. Es funktioniert natürlich an sich nur gut, wenn die Ausgangsgrafik bereits eine Zeichnung abbildet.

Aber spulen wir ca. zwei Wochen zurück. Ich hatte Debian installiert. Von den Problemen mit der Kernelpanik hatte ich geschrieben. Über die Live-Umgebung war aber die Installation erfolgreich. Das Gerät lief auch soweit stabil. Aber ich hatte einige Tage später herausgefunden, dass die Wifi-Karte sich per Wifi 7 nur mit 80 MHz mit meiner Fritzbox verbindet. Das bedeutet dann “nur” ca. 800-900 MBit. Jetzt könnte man denken, das ist nicht so schlimm. Aber ich transferiere durchaus ab und zu größere Datenmengen zur und von der NAS. Da wären die vollen knapp 2000 MBit schon nett. Unter Arch hatte ich diese Bandbreite.

Was ist eigentlich in meinem Thinkpad verbaut? Das Gerät selber ist das T14 Gen 5 mit AMD-CPU. Es ist also nicht die aktuelle Generation sondern Anfang 2024 von Lenovo auf den Markt gebracht worden. Die Wifi-Karte ist eine Qualcomm Wifi 7-Karte (lspci spuckt folgendes aus: WCN785x Wi-Fi 7(802.11be) 320MHz 2x2 [FastConnect 7800] (rev 01)). Bei der Bestellung hatte ich die Wahl zwischen dieser oder einer Wifi 6e-Karte. Da meine Fritzbox bereits Wifi 7 unterstützt, wollte ich natürlich im Thinkpad dann auch in den Genuss der neuesten Technik kommen.

Laut meinen Recherchen sollte die Karte auch eigentlich bereits mit dem LTS-Kernel 6.12 unter Debian gut funktionieren. Und in den Backports ist bereits der 6.16.3 enthalten. Noch besser… denn es gab zwischen den Versionen einige Verbesserungen für diese Karte. Aber irgendetwas war wohl noch nicht ganz optimal und daher hatte ich nur 80 MHz (Die Karte kann übrigens sogar 320 MHz, wenn ich es richtig verstanden habe).

Mich hat das ein wenig geärgert und überlegte, was ich machen könnte. Eigenen Kernel kompilieren? Uff! Die Sache aussitzen und warten, bis ein neuerer Kernel in den Backports enthalten ist? Ich bin ungeduldig.

Also habe ich mir Xubuntu heruntergeladen. Ja… quasi Ubuntu… aber ich wollte erstmal nur die Liveumgebung starten und prüfen, wie schnell dort die Wifi-Verbindung ist. Gedacht, getan und siehe da: ich hatte wie unter Arch knapp 2000 MBit. Ok… ich kann mit Ubuntu auch gut leben. Es ist die 25.10… also die Interimversion. Aber bis zum nächsten LTS-Release im April ist es auch nicht so lange hin. Ich fand die Idee gut und installierte also Xubuntu. Fun Fact: Warum Xubuntu bei einer Installation mit aktiver Internetverbindung nicht gleich die aktuellen Pakete installiert, weiß wohl niemand. Denn nach dem Reboot begrüßte mich erstmal der Hinweis, dass 300 Pakete aktualisiert werden können. Unter anderem der Kernel. Also wurden die Updates installiert, der nächste Reboot und ich fing an Programme zu installieren. Und da fing ich schnell an mich zu wundern. Es fing mit sehr langsamen Downloads von Flatpaks aus dem Flathub an. Ja… manchmal sind die Downloads am Abend nicht so schnell. Aber das war schon sehr träge. Und Pakete aus dem Ubuntu-Repository zu installieren war ebenfalls sehr langsam. Irgendetwas stimmte nicht. Ich prüfte meine Wifi-Verbindung….. und ich war nur noch mit dem 2,4 GHz-Netz des Routers verbunden. Mit knapp 250 MBit… Und das in einer Nachbarschaft, in der ca. 20-30 andere Router rumfunken. Da bleibt dann wirklich nichts mehr übrig.

Ich verstand die Welt nicht mehr. Live-Umgebung war super. Aber die installierte Version war richtig kaputt. Ich fing an zu recherchieren und fand sehr schnell eine Bug-Meldung im Canonical-Bugtracker. Da ging es um Wifi-Verbindungen in Aserbaidschan, aber für mich klang es durchaus nach meinem Problem. Und einer der Entwickler hatte ein neues linux-firmware-Paket bereitgestellt. Ich habe also bei mir das genannte Paket eingespielt, Neustart und zack… volle Leistung auf der Wifi-Karte. Wie in Arch… ich war glücklich. Oder auch nicht… denn in dem Ticket war bereits ein commit, der die Änderung in dem Paket rückgängig gemacht hat.

Am nächsten Tag hatte mein Laptop dann auch ein Update für das linux-firmware-Paket gemeldet und nach der Installation war mein Wifi wieder kaputt.

Als durchaus technisch versierter Mensch dachte ich mir: ok… du installierst dir wieder das etwas ältere Paket. Und du bist ja nett und meldest in dem Ticket per Kommentar deine Beobachtung. Das hilft den Entwicklern bestimmt. Das erste war einfach. Nachdem ich die ältere Version des Pakets installiert und in APT festgepinnt habe (das verhindert, dass Updates für das Paket eingespielt werden), lief meine Wifi-Karte wieder super.

Dann habe ich in dem Ticket meine Beobachtung gemeldet. Das war wohl ein Fehler. Ich wurde am nächsten Tag sehr direkt (ich würde fast schon sagen: unfreundlich) darauf hingewiesen, dass es hier um Wifi-Verbindungen in Aserbaidschan geht. Ich kann einen neuen Bug-Report erstellen, wenn ich meine, dass es notwendig wäre. Boaa… ja… neee…. ich habe dann in dem Bugtracker nach weiteren Meldungen gesucht und einen zweiten Eintrag gefunden. Quasi dasselbe Problem wie ich oder der Reporter in Aserbaidschan. Wir hatten alle drei mit dieser Wifi-Karte Probleme eine Wifi6/7-Verbindung zu unseren Routern aufzubauen.

Ich habe keinen Bug in Launchpad erstellt. Die Erfahrung hat mir gereicht. In Arch muss ich mich vielleicht über ein kaputtes Update ärgern. Aber das ist dann ein Bug, der auch direkt von Upstream (also der Quelle) kommt. Keiner der Arch-Paketmaintainer fummelt da an den Paketen rum, es wird nicht irgendeine alte Version ausgeliefert, die kaputt gebastelt ist. Es läuft einfach stabiler. Und dann noch etwas anders. Liebe Entwickler. Ihr beklagt euch alle, dass ihr soooo ausgebrannt seid und niemand euch helfen will. Wenn dann schon jemand sich so die Mühe macht, eine Regression feststellt und darauf hinweist, reagiert vielleicht freundlicher. Ich wollte hier wirklich helfen und ich hätte gerne mit euch weiter getestet und den Fehler behoben. Und ich glaube, ihr hättet damit mindestens zwei Tickets auf einmal erledigen können. Ich mache diesen Job beruflich. Aber ihr wolltet nicht, dann helfe ich auch nicht. Heult dann aber auch nicht rum, wenn niemand Bugs meldet oder sich beteiligen will.

Ich habe jetzt wieder Arch installiert. Es ist leider die stabilste Distribution, die ich bisher verwendet habe. Debian kommt da nicht ran, Ubuntu nicht, Fedora auch nicht. Vielleicht ist Upstream einfach am besten?

Diese Probleme treten seit dem Sommer immer wieder verstärkt auf. Soweit das Arch-Projekt es mitgeteilt hat, werden DOS-Attacken auf das Projekt durchgeführt. Meistens trifft es dann insbesondere das AUR. Irgendwann funktioniert es dann wieder und alles ist in Ordnung.

Aber… es nervt… und das in mehrfacher Hinsicht.

Zum einen ist es für mich unverständlich, wer daran Spaß hat, Arch zu attackieren. Oder welche Vorteile jemand dadurch haben sollte. Arch ist ein Communityprojekt. Wer hat da Interesse daran, Arch zu schaden?

Was aber auch nervt… das Projekt ist sehr intransparent. Es gibt auf der Startseite nur einen Beitrag, der über die Ausfälle informiert. Und es wird informiert, wie man dennoch über einen alternativen Weg Pakete aus dem AUR installieren kann. Welche Maßnahmen durchgeführt werden, um diese Attacken abzuwehren, wird nicht bekannt gegeben. Oder ob überhaupt noch an dem Problem gearbeitet wird. Ich kann verstehen, wenn keine technischen Details herausgegeben werden. Man möchte einem Angreifer nicht verraten, was man weiß. Aber Statusupdates, ob und wie noch an dem Problem gearbeitet wird, wären schon nett.

Ich muss leider sagen, dass ich immer mehr das Vertrauen in das Arch-Projekt verliere. Und das ist wirklich schade, denn es ist eine so gute Distribution. Aber dann sehe ich jetzt das Thinkpad mit Debian. Durch die Backports habe ich einen recht aktuellen Kernel und zur Zeit sogar den aktuellsten Mesa-Treiber. Gleichzeitig habe ich kaum Wartungsarbeiten durch das System. Also… ist es Zeit Arch den Rücken zu kehren und zurück zu Debian auf dem PC zu gehen?

Mein Plan ist jetzt abgeschlossen. Mein Thinkpad läuft mit einem stabilen, wartungsarmen Debian. Auf meinem PC ist Arch installiert. So kann ich in beiden, sehr gegenteiligen Welten, der Linuxdistributionen arbeiten und meine Erfahrungen machen.

Übrigens: Mit Debian habe ich vor über 25 Jahren meine ersten Gehversuche in der Linuxwelt gemacht. Damals noch mit Windowmaker. Wer erinnert sich daran?

Grafische Oberflächen

Die meisten kennen Windows oder MacOS. Beide Betriebssysteme haben eine grafische Benutzeroberfläche. Und in beiden ist die Oberfläche so wie sie vom jeweiligen Hersteller vorgesehen ist. In Windows haben wir die Taskleiste mit dem Startmenü unten. In MacOS gibt es z. B. das ikonische Dock und die Titelleiste. Was bei beiden Systemen identisch ist: wir als Anwender können die Oberfläche nicht austauschen. Wir können einige Einstellungen verändern, ein wenig die Optik an unsere Vorlieben anpassen, ein Hintergrundbild setzen und dann ist im Wesentlichen Schluss.

Möchten wir aber z. B. in Windows ein Dock haben. Oder in MacOS ein Startmenü, dann wird es schwierig. Vielleicht gibt es einige Drittanbieterlösungen, die so tiefgreifende Änderungen durchführen können, aber eigentlich sind beide Betriebssysteme so wie sie sind.

In Linux ist bekanntlich alles anders. Und so ist es mit den grafischen Benutzeroberflächen. Wer denkt, da gibt es nur eine… tja… nein. Ich kann wahrscheinlich zehn verschiedene Desktopumgebungen aufzählen. Und dann gibt es noch reine Fenstermanager. Den Unterschied erkläre ich hier nicht. Nur so viel… wir haben sehr viel Auswahl. Die bekanntesten und auch am verbreitetsten sind mit Sicherheit Gnome und KDE Plasma. Beides sind mächtige und sehr moderne Benutzeroberflächen. Beide werden ständig weiterentwickelt und verfolgen aktuell auch ganz stark den Kurs voll auf Wayland zu setzen (ich erkläre nicht weiter, was Wayland ist. Das sprengt den Rahmen). Daneben gibt es dann noch weniger verbreitete. Z. B. Cinnamon, der Desktop, den das Linux Mint-Team entwickelt. Und ich… ja ich benutze XFCE.

Was ist XFCE?

XFCE ist eine sehr alte Desktopumgebung. Gnome und KDE Plasma sind ungefähr gleich alt. XFCE ist mittlerweile 28 Jahre alt. Also zum einen in der Softwarewelt ist das uralt, aber XFCE wird immer noch betreut und auch weiterentwickelt. XFCE hat sich schon immer dadurch hervorgehoben, dass es sehr simpel aufgebaut ist. Der Fokus liegt auf Geschwindigkeit und gut durchdachte und sinnvolle Funktionen. Es gibt keinen grafischen Schnickschnack, nur sehr wenig Effekte und wenig mitgelieferte Tools. Für mich ideal: die grafische Benutzeroberfläche nervt mich nicht mit ständiger Ablenkung und sie verbraucht auch keine unnötige Ressourcen für Funktionen, die ich eh nicht nutze.

Und sie funktioniert stabil. Ich habe absolut keine Probleme bisher mit XFCE gehabt. Während KDE Plasma doch den ein oder anderen Bug hat und manchmal einfach abstürzt oder Gnome nach einem Update wieder mit neuen weggelassenen Funktionen oder seltsamen Entscheidungen überrascht (wo ist eigentlich das Systray?), bleibt XFCE sich sehr treu. Die grundsätzlichen Bedienkonzepte, UI-Elemente und Tools haben sich kaum im Laufe der Zeit geändert. Die technische Basis wurde beständig erneuert und ganz langsam geht die Entwicklung jetzt auch für XFCE wohl in Richtung Wayland. Es gibt ca. alle zwei Jahre ein Major-Release.

Mit anderen Worten: XFCE bringt für mich Stabilität, Verlässlichkeit und Kontinuität. Gerade in Verbindung mit Arch ist das angenehm. Ich könnte mehrmals am Tag nach Updates suchen und es wird immer irgendein Paket im System aktualisiert. Die grafische Benutzeroberfläche aber ist hier sehr selten vertreten. So habe ich eine recht hohe Sicherheit, dass nach den Updates XFCE weiter so funktioniert, wie ich es möchte.

Was ich noch sehr an XFCE schätze: es ist sehr gut anpassbar. Es ist kein KDE Plasma. Aber ich finde, es ist gar nicht so weit weg. Die Funktionen, die XFCE hat, können auch oft angepasst werden. Ich habe mir z. B. Rofi als Launcher und Fensterlisten-Menü eingerichtet. Ich benutze gar nicht das Startmenü und könnte es quasi weglassen. Ich habe nur am oberen Bildschirmrand eine Leiste mit den Fenstern, dem Systemtray und der Uhr. Ja… ich habe ein graues Theme eingerichtet. Die modernen, weißen oder gar dunklen Themes vertragen meine Augen überhaupt nicht. Also sieht mein Dateimanager Thunar ein wenig wie Windows 95 aus… grau. Und ganz ehrlich: perfekt für mich.

X11 vs Wayland

XFCE nutzt auch immer noch X11. Alle meine bisherigen Ausflüge in die Wayland-Welt, sei es unter Gnome oder KDE Plasma, hatten ihre kleineren oder größeren Probleme. Mein Emacs z. B. hat eine geringe Latenz beim Tippen. Mein Slicer für den 3D-Drucker macht mit Wayland ab und zu Probleme. Drag und Drop über verschiedene Applikationen hinweg funktioniert nicht immer. Manchmal verschwinden Inhalte aus der Zwischenablage. Für mich sind das alles einzeln betrachtet keine schlimmen Probleme. In Summe nervt es aber.

Unter XFCE mit X11 habe ich all diese Probleme nicht. Vielleicht sind diese Kinderkrankheiten von Wayland dann behoben, wenn XFCE auch Wayland kann.

Vielleicht doch mal etwas anderes probieren?

Aktuell sehe ich keinen Grund, einen anderen Desktop zu installieren. XFCE ist einfach rock solid und für mich der stabile Fels in der hektischen Arch-Welt. Ich warte auf ein neues Thinkpad. Und ich bin ernsthaft am überlegen, ob ich nicht vielleicht Debian darauf installiere. Dann hätte ich wohl die langweiligste Linux-Distribution mit dem langweiligsten Desktop auf dem langweiligsten Notebook. Interessante Idee.

Was hat mich gestört?

Ubuntu verändert die Gnome-Oberfläche. Ich glaube, dass die Änderungen auch grundsätzlich für Gnome gut sind. Es gibt ein Tray und ein Dock. Damit sind wohl die beiden größten Kritikpunkte an Gnome in Ubuntu behoben. Aber ist euch schon einmal folgendes aufgefallen? Wenn das Dock am linken Bildschirmrand platziert ist (so wird es auch als Standardeinstellung installiert), dann ist die Uhr im oberen Panel nicht zentriert. Sie ist ein Stück nach rechts verrutscht. Und dann noch etwas… Wenn der Bildschirm entsperrt wird und eine Anwendung ist maximiert, muss das Fenster sich kurz “zurechtruckeln”. Ich glaube, dass der Windowmanager in Gnome zuerst die Fenster ohne Dock positionieren will. Dann wird das Dock wieder aktiviert und die Fenster müssen einmal neu in der Größe und Position angepasst werden. Mich hat das massiv gestört, dass die Fenster immer kurz sich bewegt haben. Eine weitere Sache, die ich nicht besonders mag (und hier geht es um persönlichen Geschmack) ist das Yaru-Theme. Gerade die helle Variante ist mir viel zu weiß. Und die Schrift ist viel zu dünn. Ich habe Probleme, die Schrift nach einiger Zeit gut zu lesen. Und dann gab es noch eine Sache, einen Bug. Aktuell können in der Version 25.10 keine Flatpaks aktualisiert oder installiert werden. Ich weiß, Canonical möchte gerne ihr eigenes Snap-Format forcieren. Dafür habe ich auch Verständnis. Aber Flatpak ist nun einmal in der Linuxwelt etabliert und sehr, sehr weit verbreitet. Viele Anwendungen gibt es als Flatpak und es ist einfach bequem. Soweit ich den Bug verstanden habe, liegt es an der Sicherheitseinrichtung AppAmor. Der Bug wurde sogar in der Beta-Phase gemeldet, aber nicht rechtzeitig zum Release behoben. Ich frage mich da schon, wo die Qualitätskontrolle ist und ob nicht gerade solch ein Bug noch hätte behoben werden müssen. Was mich noch gestört hat… die Snap-Version von Firefox. Auf meinem PC funktioniert die Hardwarebeschleunigung in Firefox nicht auf Anhieb. Ich habe in dem Computer eine recht neue AMD 9070XT Grafikkarte. Und ich vermute, dass die im Snap gebündelte Mesa-Version nicht mit dieser Grafikkarte funktioniert. Es gibt Tricks, wie man das lösen kann. Aber ist das nicht eigentlich der Sinn eines Snaps oder Flatpaks? Das benötigte Bibliotheken dann auch in einer entsprechend aktuellen Version enthalten sind? Ich hatte auch noch andere interessante Probleme mit dem Snap-Paket. Ab und zu hat mein Firefox scheinbar das Profil vergessen. Und ich durfte dann mich auf Webseiten neu anmelden. Und die letzte Sache, die mich gestört hat: Die Snap-Version hat keinen Zugriff auf das tmp-Verzeichnis. Das benötige ich ab und zu, da ich aus Emacs heraus die ein oder andere HTML-Seite exportieren und diese dann in tmp liegt. Die Probleme mit Firefox könnte ich lösen, wenn ich das Paket von Mozilla direkt installiere. Aber ich hatte auch einmal das Problem, dass trotz apt-pinning plötzlich wieder die Snap-Version installiert war. Also… ein System, welches meine Wünsche nicht beachtet, möchte ich nicht.

Es ist wieder Arch

Also habe ich am Samstag dann kurz entschlossen mir das ISO der Archinstallation auf einen USB-Stick geladen und dann Arch installiert. Ich habe nicht die komplette Hardcore-Installation durchgeführt und jeden Schritt einzeln mit Hilfe des Wiki abgearbeitet. Archinstall war mir schon eine große Hilfe, um zügig ein Basissystem auf dem Laptop zu haben. Das war nämlich der erste Computer, den ich umgestellt habe. Zuerst mit KDE. Aber ich habe mich dann doch für XFCE entschieden. Ich will erst einmal Wayland ein wenig fernbleiben und beobachte aus der Ferne, wie die Entwicklung da weiter geht (Fun Fact: KDE ist mir auf beiden Rechnern mehrmals beim Login eingefroren….).

XFCE… Retro oder was?

Für diejenigen, die nicht wissen, was XFCE ist… es ist eine sehr “alte” Desktopumgebung. Mit alt meine ich, sie sieht sehr klassisch aus und verhält sich auch sehr klassisch. Die Entwicklung findet nur sehr langsam statt, größere Versionen gibt es ca. alle zwei Jahre. Ich habe also eine sehr stabile, sich kaum verändernde grafische Benutzeroberfläche und als Unterbau ein Rolling Release-System. Das ist auch eine schräge Kombination. Aber mir gefällt XFCE… ich habe jetzt wieder Rofi als Launcher, virtuelle Desktops, kann die Dinge, die mir wichtig sind, einstellen. Und die Optik… ist mir egal.

Du wechselst doch eh bald wieder…

Ja… mag sein. Aber eigentlich frage ich mich… wohin??? Arch bietet eigentlich alles, was ich haben möchte. Es ist eine Community-geführte Distribution. Das gefällt mir schon einmal. Sie ist grundsätzlich sehr simpel aufgebaut. Das Wiki ist eine exzellente Quelle für die Konfiguration. Man muss nur wissen, was man haben möchte und wo man es im Wiki findet. Und dann läuft es. Ja… das System benötigt ein wenig Pflege. Man sollte schon regelmäßig Updates installieren, alte Pakete löschen und ab und zu die News auf der Arch-Homepage lesen. Aber ehrlich… das ist gar nicht so schlimm. Ich mag es so. Ein wenig muss ich vielleicht basteln. Aber es läuft schnell und ich verstehe, was ich hier mache. Und wenn etwas schief geht… auf beiden Systemen habe ich Snapshots eingerichtet. Ich kann also durchaus nach einem fehlerhaften Update einen älteren Stand booten und dann auf Fehlersuche gehen.

I use Arch, btw

Mir ist aufgefallen, dass ich in der Ubuntu 25.04 und 25.10 keine Hardwarevideobeschleunigung in Firefox aktivieren konnte. Ich habe in zwei Systemen eine AMD GPU. Scheinbar wird ein Paket des Mesa-Treiber nicht installiert.

Um das zu beheben im Terminal das fehlende Paket installieren:

sudo apt install mesa-va-drivers

Ich habe hier einfach mal Kagi (meine Suchmaschine der Wahl) nach einer Definition gefragt.

Distrohopping bezeichnet das Ausprobieren und Wechseln zwischen verschiedenen Linux-Distributionen (kurz: Distros) oder anderen Betriebssystemen.

Es ist ein Hobby für viele Nutzer, die sich für freie Software interessieren und die Vielfalt und Flexibilität von Betriebssystemen erkunden möchten.

Diese Beschreibung trifft es sehr gut. Im Endeffekt installiert jemand, der zwischen den Distros hin- und herwechselt immer wieder sein System neu. Das kann zum Teil sehr oft geschehen.

Warum mache ich es?

Es gibt verschiedene Gründe für das Distrohopping. Bevor ich verrate, warum ich es mache, zähle ich vier mögliche Gründe auf:

1. Erkundung und Lernen Der Nutzer möchte einfach möglichst viele verschiedene Distributionen kennenlernen.
2. Suche nach perfekter Passform Irgendetwas an der aktuellen Distribution stört den Nutzer. Er sucht das perfekte System und wechselt daher auf eine andere Distro.
3. Zeitvertreib Es kann einfach Spaß machen, sich etwas neues anzuschauen
4. Ungelöste Fehler Das ist die schlimmere Variante von 2. Der Nutzer hat in einer Distribution einen Bug, den er nicht beheben kann.

Nun zu mir…. Ich distrohoppe wirklich viel. Meine Partnerin lacht immer schon, wenn ich ihr den aktuellen Namen der Distribution sage und um einen neuen Sticker bitte (Sie hat einen Plotter und kann fantastische Sticker damit herstellen). Bei mir ist es eine Art Drang zu wechseln. Ich nutze eine Distribution für einen gewissen Zeitraum und verspüre dann irgendwann Langeweile. Das kann manchmal schon nach einem Tag eintreten. Oder zwei Wochen oder einem Monat.

Ein anderer Grund, der mich auch gerne erwischt: Featuritis. Insbesondere Rolling-Release-Distributionen sind hier für mich gefährlich. Die neueste Version von Gnome? Oh… neuer Mesa-Treiber? Die neueste Emacs-Version? Ich will das haben. Aber so eine Distribution dann pflegen? Regelmäßig Updates installieren? Evtl. neue Bugs fixen oder abwarten bis sie gelöst sind? Das möchte ich eigentlich auch nicht. Aber manchmal irgendwie auch.

Linux ist für mich wohl einfach zu langweilig geworden. Selbst Distributionen wie Arch oder openSUSE Tumbleweed funktionieren gut bis sehr gut. Und dann schaue ich zu Ubuntu oder Fedora und denke: hey, die sehen auch spannend aus. Die haben doch gerade auch eine neue Version veröffentlicht. Wie ist die denn so?

Es ist vielleicht nicht für jeden nachvollziehbar. Ehrlich gesagt, verstehe ich es manchmal selbst nicht. Aber eigentlich ist es nicht schlimm. Denn mir macht es Spaß und ich freue mich immer ein wenig über den Tellerrand zu schauen.

Wie kann ich davon wegkommen?

Nun habe ich gerade geschrieben, dass mir Distrohopping Spaß macht. Und es nicht schlimm ist. Warum möchte ich dann eigentlich davon wegkommen? Ich bin recht gut darin, das System neu aufzusetzen. Meine Daten liegen alle auf einer NAS. Aber dennoch habe ich dann jedes Mal den zeitlichen Aufwand das System einzurichten. Programme installieren, Konfigurationen wiederherstellen, Spiele herunterladen, … Ich sollte meine beiden Computer vielleicht einfach mal nutzen, oder?

Ich habe aktuell sowohl auf meinem Laptop Ubuntu installiert. Auf dem PC die aktuell 25.04 (Plucky Puffin) und auf dem Laptop die Beta von 25.10 (Questing Quokka). Und ich setze mir jetzt selbst eine Challenge. Ich werde bis Ende Oktober diese Distribution nicht verlassen. Mal schauen, wie es läuft und wie stark ich dem Drang neu zu installieren widerstehen kann.