Linux

Mein langjähriges Projekt izulu ist ein Skript, das den Bildschirmhintergrund dem Wetter anpasst. Oder eher: Es ist es jetzt wieder. Denn izulu war kaputtgegangen und ich hatte lange keine Motivation, es zum Laufen zu bringen. In Version 2.0 (bzw 2.0.1, ein paar kleine Fixes kamen obendrauf) funktioniert es erneut, mit neuer Bilderauswahl, anderen APIs, aber auch reduziertem Funktionsumfang.

Es war überfällig, denn lange wollte ich da nicht ran. Zu ärgerlich war diese letzte API-Abschaltung, diesmal die von Dark Sky, die izulu mit in den Abgrund riss. Es ist eine lange Liste inzwischen eingestellter Dienste: Google Wetter, Yahoo Weather, Yahoos WOEID und freegeoip.net sind nur die, die mir gerade einfallen.

Nur weil ich über passende Alternativen stolperte und daraufhin eine Strategie formulieren konnte, kam jetzt die Überarbeitung:

1. Entferne alle Funktionen, die du nicht selbst dauernd nutzt.
2. Behalte den Kern, wie er ist – als recht simples Bash-Skript mit entsprechender Struktur.
3. Benutzt werden nur APIs, die keinen API-Key brauchen. Der Aufwand ist Nutzern nicht zuzumuten, auch nicht realistisch in einem Bash-Skript unterstützbar.
4. Genauso wird für das Projekt keine eigene Serverkomponente mehr betrieben, um den Aufwand dem Nutzen angemessen zu halten.

Bright Sky war Ausgangspunkt dafür. Das Projekt verpackt Daten des Deutschen Wetterdiensts in eine angenehm zu nutzende API, izulu zieht davon das aktuelle Wetter. Zweitens wird MET genutzt, das Norwegian Meteorological Institute, dessen API liefert die (optionalen) Wettervorhersageicons unten rechts. Damit izulu auch läuft, ohne dass unbedingt die genaue Position angegeben werden muss, verrät der Mozilla Location Service bei Fehlen derselben eine ungefähre Position über die IP-Adresse.

Noch etwas hat sich seit 2009 getan: Es ist inzwischen viel einfacher, an gute und frei nutzbare Bilder zu kommen. Damals war die beste mir bekannte Möglichkeit CC-lizenzierte Bilder von Flickr, wobei die damaligen CC-Lizenzen mit ihren Bedingungen nicht gut zum deutschen Rechtssystem passten, sie zudem auch im Konzept von izulu nur so halb umzusetzen waren (Herkunftsnennung in einer Dokumentationsdatei, ob das reichte?). Deswegen sind nun alle Wetterbilder mit solchen von unsplash ersetzt.

Die entfernten Funktionen (die zufällige Bilderwahl aus einem Ordner oder von Flickr, das Wetterradarbild Deutschlands oder der Schweiz) müssen nicht unbedingt dauerhaft entfernt bleiben, wenn sie wirklich gewünscht werden. Gerne würde ich zudem brightsky.dev durch eine internationalere Wetter-API ersetzen, da fand ich bisher aber keine brauchbare.

Das Skript jetzt wieder am Laufen zu haben fühlt sich toll an. Das Konzept, das ja gar nicht von mir kam, finde ich immer noch nett, der Computer fühlt sich hiermit etwas natürlicher an und die Wettereinbindung ist auch schlicht praktisch. Der über die Jahre fabrizierte Bash-Code ist abgesehen von ein paar Details angemessen simpel, vor allem da jetzt um einige Codezeilen reduziert.

Vorschläge gerade für die Wetter-API-Auswahl wären willkommen. Wer izulu mal testen will werfe einen Blick in die Readme, die Abhängigkeiten sind gering, wobei Wayland bisher nicht unterstützt wird und ich das Release nur unter IceWM getestet habe.

Vor der Bildergenerierung war die Bildhochskalierung. Die Idee ist ähnlich: Ein neuronales Netz wird auf Bilderdaten gelernt, bekommt eine Eingabe und spuckt ein Bild aus. Beim Hochskalieren ist das statt Text eben ein Bild und das Ergebnis soll möglichst nah an der Eingabe sein. Normalerweise: Größer. So wird aus einem Fitzelbild aus den 90ern ein modernes in 4K mit vollen Details, aus einem Mini-Pixelicon eine etwas größere Grafik für andere Einsatzzwecke. Aber: Geht auch einfach besser?

Denn mein Ziel ist meist nicht das Hochskalieren an sich. Fitzelbilder habe ich selten. Sondern, wenn ich ein schlechtes Bild habe, möchte ich ein gutes Bild herausbekommen. Egal was nun das Problem ist, ISO-Rauschen, ob das Bild verwackelt ist, Kompressionsartefakte hat oder was auch immer schiefgehen kann. Wenn mir Software das Bild kreativ bearbeiten könnte ist es mir egal, ob es danach die zwanzigfache Auflösung hat, wenn ich es danach wieder auf 1080p herunterskaliere und es immer noch besser aussieht als zuvor wäre ich zufrieden.

Testmotiv und Software

Ich habe das an diesem Bild getestet:

Ein perfektes Testmotiv für mein Ziel. Das ist Chichen Itza, von mir 2015 mit dem Nokia Asha 210 aufgenommen. Die Kamera des Nokia-Telefons hat etwa alle drei Fotos ein halbwegs brauchbares ausgespuckt und hier hatte ich Glück, das Bild ist hübsch. Aber man sieht trotzdem an vielen Stellen die geringe Qualität der Kamera, am Bilderrauschen in den dunklen Wolken, an den unscharfen Kanten der Pyramide, an den fehlenden Details. Trotzdem ist es 1600x1200 Pixel groß, was als Auflösung z.B. zum Zeigen hier im Blog völlig reichen würde. Es hochzuskalieren ist also für mich eher uninteressant, wenn dadurch nicht die generelle Bildqualität verbessert wird.

Genau das will ich mit Upscayl 2.5.5 testen. Die Software hat ein supersimples Interface, zeigt nach dem vierfachen Hochskalieren eine praktische Vergleichsansicht, liefert eine Auswahl verschiedener Hochskalierer mit, bietet auf Github ein praktisches AppImage an und benutzt beim Hochskalieren ohne weiteren Aufwand meine AMD-Grafikkarte für den Prozess.

Das Ergebnis

Seht selbst, klickt auf diese Fotos:

Das sind die wieder auf 1200p herunterskalierten Bilder dieser Modelle: Real-ESRGAN, Remacri, Ultramix-balanced, Ultrasharp.

Das Ergebnis variiert stark je nach genutztem Modell, und dann nochmal je nach Bildbereich. Skaliert man die Bilder wie hier wieder auf 1600x1200 herunter verlieren sich einige der Details, die hinzugedichtet wurden. So wieder verkleinert ist die Gesamtbildqualität nur beim vom Remacri-Modell produziertem Ergebnis besser – und auch dann nur minimal. Bei diesem Modell sind auch die Farben konstanter – das Bild ist nur etwas aufgehellt, bei den Schatten der Bäume und der Pyramide, während beim Ergebnis von Real-ESRGAN einige Farben verfälscht wurden, beispielsweise der Rasen sehr viel grüner ist.

Im Detail

Wegen des Effekts der Herunterskalierung zeige ich jetzt ein paar der Details des Originalbilds des gleichen Auschnitts der Hochskalierten und noch nicht wieder verkleinerten Ergebnisse von Real-ESRGAN und Remacri. So kann die Leistung der Hochskalierer besser diskutiert werden.

Reihenfolge: Real-ESRGAN, Remacri, Original.

Der Rasen stellt alle Modelle außer Remacri vor große Probleme. Schon im Original leicht unscharf, machen sie aus ihm eine grüne Masse und verlieren dabei jedwedes Detail. Zoomt man näher heran sieht man, dass auch das Remacri-Modell nicht den Rasen wiederhergestellt hat, es hat ihn nur nicht so glattgebügelt, dass er in der normalen Ansicht falsch wirkt.

Reihenfolge: Real-ESRGAN, Remacri, Original.

Die Menschengruppe auf dem Rasen wird von den Modellen seltsam hochskaliert. Die geringe Informationsdichte des Originalbilds scheint sie etwas ratlos zurückzulassen. Die vorhandenen Farben werden verstärkt, und manche Kleidungsstücke werden erstaunlich gut erträumt, aber andere Details wie die richtige Reflexionsfarbe an den Beinen gelingt gar nicht. Das Ergebnis wirkt in der Nahansicht absurd, herausgezoomt ist das Ergebnis okay, wobei die Menschen etwas mehr wie Plastikfiguren wirken als zuvor.

Wenn ich mir angucke, wie klein die Menschen im Originalbild sind, ist das Ergebnis eigentlich beeindruckend. Da werden viele Kleidungsstücke aus wenigen Pixeln erraten und dann an die Bewegungsrichtung angepasst. Es sieht nur nicht so gut aus, wie ich mir erhofft hatte, gerade durch diese grünen Lichtklekse, die ein perfektes Modell weggelassen hätte.

Reihenfolge: Real-ESRGAN, Remacri, Original.

Interessant ist, wie die Pyramide behandelt wurde: Hier sieht man, dass die Modelle auf ein solches Bauwerk geeicht wurden. Nur auf ein anderes. Zwar verwaschen insgesamt, wird beim Heranzoomen deutlich, dass hier eine Art Zeichnung auf die Mauersteine projektiert wurde. Die ist im Originalbild vielleicht zu erahnen – existiert aber in echt nicht an diesem Gebäude, es handelt sich um eine Interpretation von Bildfehlern. Man könnte sich aber gut vorstellen, dass andere Mauerwerke (aus Marmor?) solche Muster tatsächlich haben.

Reihenfolge: Real-ESRGAN, Remacri, Original.

Beim Himmel mit den aufgetürmten Regenwolken sieht das Ergebnis etwas anders aus: Den verbessern auf den ersten Blick alle Modelle. Besonders das Standardmodell für Bilder, Real-ESRGAN, lässt das Bilderrauschen verschwinden und zeichnet die Wolken trotzdem so eindrucksvoll wie zuvor. Remacri wirkt erst, als wäre es bei der Verbesserung nur etwas dezenter gewesen, überrascht allerdings, wenn man hineinzoomt: Dann sieht das Ergebnis überhaupt nicht mehr verbessert aus, sondern wurden aus dem Bilderrauschen echte Bildfehler. Und auch die Bäume wurden verstümmelt. Die wiederum sind Real-ESRGAN extrem gelungen, sie sehen einfach besser aus als im Original, schärfer und ohne Bildfehler. Allerdings sind sie auch wesentlich grüner.

Schaut man sich meinen Einsatzzweck an, ist Remacri das beste Modell und kommt dem nahe, was ich anfangs wollte: Das wieder verkleinerte Bild sieht fast identisch aus, nur Details sind verändert, der Himmel z.B. hat weniger Bilderrauschen. Wenn ich mir aber in den hochskalierten Bildern anschaue, was die Modelle gemacht haben, sind Remacris Veränderungen seltsam. Und ist die Arbeit von Real-ESRGAN viel näher an dem, was ich mir von diesen Hochskalierern erhoffen würde – Paradebeispiel sind da die auf einmal scharfen Bäume, einfach perfekt. Wenn das mit allen Details ginge! Zudem sind die Verbesserung von Remacri zu gering, als dass ich dessen Arbeit als Erfolg verbuchen wollte. Weniger Bilderrauschen bei den Wolken ist eben nicht kein Bilderrauschen, die Pyramide bleibt an den Kanten unscharft, und so geht das weiter.

Insgesamt würde ich als Fazit die Eingangsfrage verneinen, allgemein relevant und zuverlässig die Bildqualität zu verbessern scheint mit allen gesteten Modellen nicht zu gehen.

Vielleicht gibt es andere Modelle, die statt den bisher von upscayl benutzten diese Aufgabe besser erledigen würden? Das Upscale-Wiki listet einige Alternative, die von der Beschreibung her besser passen könnten. Es könnte sich lohnen, die für einen nächsten Test in upscayl zu integrieren, oder schlicht direkt eine andere Software zu benutzen. Wenn es da denn eine passende geben würde, mir ist keine bekannt.

So sieht das neue Thunderbird-Logo aus:

Es ist hübsch geworden! Und stark angelehnt ans moderne Firefox-Logo. Mit seinem flachen Design ist es wunderbar geeignet, um auf Telefonen als Startbutton für die Anwendung zu dienen, selbst wenn sie auf monochrom gestellt werden braucht es nur eine leichte Abwandlung. Genau diese Variante zeigte der Vorstellungsartikel, das war bestimmt eine der Anforderungen an das neue Design.

Doch wenn ich das Logo nur als Logo betrachte, missfallen mir im direkten Vergleich zum Vorgängerlogo ein paar Eigenheiten. Schauen wir erstmal das alte Logo an:

Dieses Logo hatte einen anderen Charakter als das neue. Da ist zum einen der Charakter des Vogels selbst. Der dünne Schnabel erinnerte mehr an eine Brieftaube, das braune Auge blickte freundlich, auf jeden Fall freundlicher als das dämonisch anmutende weiße Augenloch des neuen Logos.

Freundlicher ist generell das Stichwort. Dazu trägt auch die stärkere gezeichnete Struktur der Federn bei. Das neue Logo wirkt moderner, aber das bedeutet derzeit eben auch: abstrakter. Und flache abstrakte Strukturen wirken keinesfalls freundlich. Außerdem bin von den vielen neuartigen simplen Logos mit ihren geometrischen Formen und flachen Oberflächen gelangweilt. Da ist das neue Thunderbird-Logo keinesfalls ein sehr negatives Beispiel, das ist ja nicht einfach eine aufgemotzte Grundform wie z.B. bei den Google-Appicons, aber es ist ein Schritt in diese Richtung.

Ich würde daher das neue und das als Logo verbinden. Die neue Grundstruktur gefällt ja auch mir, die neue Rundung um den getragenen Briefumschlag mit dem Firefox-artigen Schwanz funktioniert, selbst wenn es eine Kopie ist. Auch die neuen lila Aufhellungen würde ich behalten, schon sie alleine geben dem Logo einen neuen Anstrich. Doch vom alten Logo würde ich:

1. das Auge übernehmen, genau so wie es war,
2. den hellblauen Schnabel übertragen, vermischt mit dem lila Farbverlauf, und dabei den neuen Schnabel verkleinern - meine Variante hat sogar ein kleines Atemloch,
3. die Federkleidstruktur kopieren, teilweise, sodass da wieder Fe­dern-­sym­bo­li­sie­ren­de Schritte im Körper sind und im Gesicht, um das Auge herum, die Einbuchtung wieder und die Gesichtsstruktur stärker zu sehen sind.

Das würde dann so aussehen:

Technisch ginge die Umsetzung besser, und klar, für ein monochromes Startericon ist das weniger geeignet. Durch die stärker ausgearbeitete Strukturen ist das noch weniger ein vollständig modernes Logo im Flat-Design. Aber mir gefällt diese Variante gerade deswegen. Für meine Augen bewahrt sie besser das positive des alten Logos, sie wirkt insgesamt freundlicher, macht aus einer Brieftaube weniger einen Raubvogel und ist durch die Form trotzdem im Vergleich zum alten Logo modernisiert und ans Firefox-Logo angepasst.

Durch PipeWire wird es einfach, einen systemweiten Equalizer zu setzen und damit potentiell den Ton des eigenen Ausgabegerätes anzupassen. Easy Effects ist (unter anderem) ein solcher Equalizer, ist in den Quellen von Void Linux und funktionierte bei mir auf Anhieb. Doch was genau soll man einstellen? Da kommt die Webanwendung AutoEq ins Spiel. Mit ihr kann man für viele Kopfhörer passende Voreinstellungen abrufen und in Formate für verschiedene Equalizer umwandeln, darunter auch Easy Effects. Ich habe das für meinen ATH-M50x durchgespielt und beschreibe im Folgenden mein Vorgehen.

Mit AutoEq Konfiguration herunterladen

In der Suchleiste oben auf der Webseite kann nach dem eigenen Kopfhörermodell gesucht werden.

Einmal gefunden geht die Vorschau der Einstellungen auf. Rechts kann das Zielprogramm ausgesucht werden, Easy Effects ist als EasyEffects / PulseEeffects in der Liste. Bei der nun aufgehenden Konfiguration muss der Schalter für Stereo aktiviert werden. Ob 44.1kHz, 48kHz oder gar 96kHz richtig ist sollte an der Pipewire-Konfiguration hänge, im Zweifel ist es 44.1. Unten rechts versteckt sich der Download-Button als schwer zu erkennendes Icon.

Man kann die Konfiguration hier auch ändern. Hat jemand Hinweise, was man versuchen sollte?

Mit Easy Effects Konfiguration laden

Jetzt installieren wir Easy Effects. Unter Void ging das einfach mit

sudo xbps-install easyeffects

Das Programm startet der gleichnamige Befehl easyeffects.

In Easy Effects folgen wir nun den Anweisungen der AutoEq-Webseite:

Wechsel in die Effektliste und füge das Plugin Convolver hinzu. Dort auf der rechten Seite auf den Button "Impulses" klicken. Darüber kann die eben heruntergeladene .wav-Datei importiert werden. Danach fehlt noch ein Klick auf "Load", wieder unter Impulses und neben dem eben hinzugefügten Eintrag, nun sollte der veränderte Klangeffekt direkt eintreten.

Wieviel dieser Ansatz bringt variiert natürlich extrem, je nach Kopfhörer und auch je nach Musik. Bei meinem M50x scheint mir der Effekt relativ dezent – was gut ist, sind seine Messwerte doch auch ohne jede Anpassung gut. Manche Instrumente werden leichter hörbar, auch der Sänger von Greta Van Fleet. Das war zumindest bisher nicht unangenehm, aber ich werde es mit mehr Musik testen, bevor ich entscheide ob ich dieses Profil dauerhaft aktiviere.

Aber vom M50x mal abgesehen: Generell ist es nett, die Möglichkeit zu haben den Klang zu konfigurieren. Ich frage mich, ob es neben dieser AutoEq-Anpassung an ein Zielklangprofil noch andere interessante Effekte gäbe? Dass neben der Ausgabe auch das Mikrofonsignal mit bearbeitet werden kann, inklusive Lärmfilter (wie unter Alsa, aber einfacher zu konfigurieren), kann definitiv praktisch sein. So spielt PipeWire langsam ein paar Stärken aus.

Update 05.08.2023: Ich habe Easy Effect gerade aus dem Autostart genommen. Zwei Probleme nervten mich: Gelegentlich konnte das System plötzlich keinen Ton mehr ausgeben, bis in pavucontrol zwischen dem echten und dem virtuellen Output gewechselt wurde. Und heute war auf einmal nur noch Ton auf der linken Seite des Kopfhörers, bis zum Reboot. Solche Probleme gab es vorher nicht, daher vermute ich die Schuld bei Easy Effect und verzichte zumindest eine Weile auf den Equalizer.

Überraschenderweise ist für das LG G5 eine neue Version von LineageOS veröffentlicht worden. LineageOS 19.1 basiert auf Android 12L. Das ist überraschend, weil der alte Kernel des Telefons ein Upgrade über Android 11 hinaus vorher verhinderte. Doch es wurde jetzt schlicht eine neuere Kernelversion (4.4) auf das Gerät portiert, selbst Android 13 erscheint nun möglich.

Eine gute Neuigkeit für alle, die bereits LineageOS oder ein anderes Custom-ROM auf dem Gerät am Laufen haben. Wer bis jetzt noch auf die Originalversion setzte geht dagegen leer aus – denn LG hat mit ihrer Mobilabteilung auch den Server abgeschaltet, mit dem der Bootloader des Telefons freigeschaltet werden konnte, was für ein Einspielen des Updates aber nötig ist. Sympathische Firma das.

Um von LineageOS 18.1 auf 19.1 zu aktualisieren lädt man von der Downloadseite das Lineage-Ziparchiv und die recovery.img herunter. Eine Verschlüsselung auf dem Gerät muss laut meinem Test deaktiviert werden! Bei der Updateaktion sollten dann die eigenen Daten erhalten bleiben, aber man muss definitiv ein Backup parat haben.

Danach das Telefon verbinden, den Entwicklermodus freischalten, USB-Debugging aktivieren und der Rest geht am PC:

adb reboot bootloader
sudo fastboot flash recovery Downloads/recovery.img
sudo fastboot reboot

Das Telefon startet jetzt nochmal die alte Version von Lineage, das ist kein Problem. Nach diesem Neustart schicken wir das Gerät in den frisch installierten Recovery-Modus:

sudo adb reboot recovery

Das wäre alternativ auch per Tastenkombination gegangen (und so hätte der Lineagestart verhindert werden könnten), theoretisch, in der Praxis funktionierte bei mir nur dieser Weg über adb.

Im Lineage-Recovery-Programm Apply Updates auswählen und 19.1 kann installiert werden:

adb sideload Downloads/lineage-19.1-*-nightly-h850-signed.zip

Waren vorher die Google-Apps installiert müsste man sie jetzt wieder installieren, wie in der Upgradeanleitung beschreiben.

Nach dem nächsten Neustart sollte LineageOS 19.1 auf dem G5 starten.

Skyrim funktioniert mit Steams Proton unter Linux, das Spiel läuft sogar gut. Aber beim Modden ist fast die gesamte Dokumentation auf Windows ausgerichtet. So gibt es keinen nativ unter Linuxs laufenden Modmanager – abgesehen von modsquad, dessen Dokumentation mir aber ungenügend war. Doch das tolle: Es ist alles lösbar.

0. Die Erweiterungen kaufen

Das betrifft nur jene, die wie ich auch das originale Skyrim haben und nicht die neue Special Edition kaufen wollen. Das Problem ist: Das alte Spiel (auch Oldrim oder Skyrim LE genannt) ist samt seinen Erweiterungen von Bethesda im Steam-Shop versteckt worden. Und während die SE gerade reduziert war, blieb das Originalspiel und die DLCs sicher mit voller Absicht beim vollen Preis. Aber ohne die DLCs sind viele Mods nicht installierbar.

Als Lösung kaufe man die Skyrim Legendary Edition für Steam außerhalb von Steam. Auf CDKeys.com kostete sie ~7€ (kein Affiliate-Link, auch kannte ich die Seite vorher nicht). Ich hatte zuvor nur das Grundspiel, durch den Kauf wurden die Erweiterungen dem hinzugefügt.

Die alte Version hat Nachteile zur neuen: Sie sieht wohl (ohne Mods) schlechter aus und viele neue Mods werden nur noch für die SE veröffentlicht. Vorteil der LE sei die bessere Performance, zudem ist derzeit die Modauswahl für diese Version noch größer; Außerdem ist sie beim Kauf über CDKeys günstiger.

Wer SSE schon hat oder lieber damit spielen will sollte diesem Artikel trotzdem folgen können. Am Modden ändert sich nichts grundlegendes, eigentlich ist nur die Modauswahl etwas anders.

1. SKSE ist per Steam installierbar

SKSE ist fast unabdingbar. Die Software erweitert Skyrim um Skriptmöglichkeiten, die von einigen Mods gebraucht werden. Und da sind fundamentale dabei. SKSE kann dabei für das original Skyrim einfach per Steam installiert werden, per Shopseite. Spieler der SE laden es dagegen vom Nexus.

Wer die LE hat kann hier abbrechen. Oldrim hat einen Steam-Workshop mit einer gar nicht mal so geringen Auswahl. Zusammen mit SKSE lässt sich das Spiel jetzt schon deutlich verbessern. Wer aber Mods aus dem Nexus installieren will (oder muss, weil er auf die SE gesetzt hat) sollte weitermachen.

2. Mod Organizer 2 hat einen Linuxinstaller

Die Nexusmods lassen sich auch manuell installieren – dann werden die Texturen und .esps per Hand in den Data-Ordner von Skyrim geschoben. Aber das bricht natürlich irgendwann zusammen, vor allem wenn ein inkompatibler Mod wieder entfernt werden soll. Besser ist ein Modverwalter wie Mod Organizer 2.

Und der lässt sich per diesem Repo unter Linux installieren. Die in der Readme beschriebenen Installationsschritte sind dabei nicht kompliziert:

1. Das Spiel in Steam installieren.
2. Den Installer des letzten stabilen Release herunterladen.
3. Das heruntergeladene Archiv entpacken.
4. Im Ordner ./install.sh ausführen.
5. Dem Installer folgen.
6. Wenn danach in Steam Skyrim gestart wird, startet stattdessen der Mod Organizer 2. Neben der Modverwaltung dort kann von hier aus das Spiel selbst gestartet werden.

Die Installation forderte eine bestimmte Proton-Version, die in den Steam-Einstellungen von Skyrim gesetzt werden sollte. Bei mir war das Proton-6.3 und ich habe mich dran gehalten.

3. ENBoost (Teil von ENBseries) wird irgendwann gebraucht

Jetzt läuft Skyrim mit vollem Modsupport, was ich richtig nutzen wollte. Was anfangs gut lief kippte irgendwann: Das Spiel wurde instabil. An diesem Punkt war die einzige Lösung ENB­series. Auch wenn der obere ModOrganizer-Installer auf Github dagegen empfiehlt.

Die Installation von ENB­series ist wieder leicht, es wird nur durch eine vermurkste Webseite erschwert. Das Modprojekt Step erklärt es aber eigentlich ganz gut. Man geht über die News-Sektion der Webseite auf Download, klickt dann auf den Spielnamen und landet dadurch auf der Release-Seite. Die Versionsnummern ganz unten sind entgegen ihrer Darstellung klickbar. Auf der folgenden Seite ganz unten ist der Downloadlink.

Das heruntergeladene Archiv entpacken und manuell die d3d9*.dll-Dateien, enbhost.exe und enblocal.ini in den Skyrim-Ordner schieben.

Jetzt kann man wieder der Step-Seite folgen um ENBoost zu aktivieren. Ich werde dazu allerdings noch meine eigenen Konfigurationshinweise nachliefern.

Und auch wenn Step und das Crashfixplugin davor warnten muss ich zwischendurch in der enblocal.ini ExpandSystemMemoryX64=true setzen. Danach aber entfernte ich ein paar Texturenmods und ich konnte das wieder entfernen, tatsächlich lief Skyrim mit de Einstellung nicht super stabil (aber besser als vorher), es ist besser sie nicht zu brauchen.

Ich war übrigens sicher, dass ENB­Series unter Linux nicht laufen würde, zu oft hatte ich das früher gelesen. Aber früher ist da wohl das Stichwort. Tatsächlich läuft ENBSeries gut und Skyrim damit stabiler als vorher. Sogar Grafikerweiterungen scheinen zu funktionieren, wobei ich angesichts der Performancekosten damit nur ganz kurz experimentiert habe.

4. Das High Poly Project ist ein Performancekiller

Thema Performance: Es gibt im Nexus das High Poly Project. Objekte bekommen mehr Polygone, dadurch werden Rundungen erstmals wirklich rund. Doch zumindest unter Linux, oder unter Linux mit meiner Radeon RX 570, tut der Mod der Performance gar nicht gut.

Das war nicht unbedingt absehbar, weil der Autor keine Performanceprobleme beobachtete und es auch sonst in den Kommentaren keine direkt sichtbaren Warnungen gab. Also, Finger weg, oder sorgfältig testen.

5. Schatten können gut aussehen

Das größte Problem nach der Installation waren für mich auch gar nicht die Texturen oder fehlende Rundungen der Objekte, es waren total kantige Schatten. Ich musste erst nachlesen um zu glauben, dass Skyrim schon damals da so kaputt war, ich dachte das lag an Linux (und nehm es deswegen hier auf). Um die Schatten zu reparieren muss die .ini angepasst werden. Doch Vorsicht, die im Dateisystem platzierte wird durch den Mod Organizer 2 ignoriert. Stattdessen muss man den INI-Editor der Software nutzen.

Die wichtigste Einstellung war für mich in der skyrimprefs.ini: iShadowMapResultion=8192. Später reduzierte ich das auf 4096, zugunsten der Performance. Wieder ist Step hier hilfreich.

2023 Skyrim mit seinen vielen Mods zu spielen macht mir das Spiel wesentlich sympathischer. Denn meine Erinnerungen an meinen ersten Durchlauf vor einigen Jahren sind gemischt – das Spiel hat was, aber einiges störte mich auch, ich vermisste Morrowind. Einige der Schwachstellen sind durch Mods mittlerweile verbesserbar und Modden selbst ist ja auch ein interessantes Spiel. Dadurch läuft meine Zeit mit Skyrim diesmal deutlich besser.

Ich plane zwei Folgeartikel: Einmal möchte ich näher auf die verschiedenen Konfigurationsänderungen und Mods eingehen, die das Spiel mit vielen Mods unter Linux stabiler machen. Der zweite soll alle anderen Mods vorstellen, die mir diesmal das Spiel verbessern, als Update zu meinem Modartikel von 2016.

Das A3 (SM-A310F, oder: a3xelte) bekam von Samsung nur Android 7. Mit LineageOS als Custom Rom geht mehr, es wäre schade das kleine Telefon nicht damit zu versorgen.

Wer einfach nur die Anleitung haben will sollte unter Installation weiterlesen. Ich werde nämlich jetzt erstmal erklären, was ich von dem Gerät halte und wie meine Erfahrung mit dem Flashen war. Denn es lief diesmal nicht problemlos.

Kontext und Einschätzung

Es gibt mehrere verschiedene A3. Dieses "A3 (2016)" ist tatsächlich von Ende 2015 und ist damit nicht besonders neu. Bei sustaphones ist es gelistet, weil es früher offiziell von LineageOS 17.1 unterstützt wurde. Das ist leider vorbei, keines der größeren Projekte unterstützt das Telefon noch, die von mir installierte war eine inoffizielle Version. Vielleicht spielt da eine Rolle: Das Telefon war superzickig. Lief die erste Installation der TWRP-Recovery-Software noch durch, musste ich sie wiederholen (weil ich nicht schnell genug reagierte und Samsungs Androidversion sie beim Start löscht), was dann leider nicht mehr klappte. Daraufhin startete das Telefon nicht mehr, sondern blieb immer beim ersten Schritt im Bootvorgang mit dem "Galaxy A3[6]"-Logo hängen. Da der Odin-Download-Modus noch startete war das lösbar, aber nur mit einer speziellen Kombination aus einem Heimdall-Fork und einer älteren TWRP-Version, dazu unten mehr. Zwischendurch war ich sicher, das Gerät nur noch wegwerfen zu können.

Man sollte sich also gut fragen ob der Aufwand lohnt. Ich las zwar auch Berichte von Leuten, bei denen das A3 problemlos mit einer neuen Androidversion zu flashen war. Aber Fehlerberichte gibt es ebenfalls Unmengen. Und das alles wofür? Das A3 ist zwar hübsch klein, der Bildschirm und die Kamera wirkt auf dem ersten Blick nicht schlecht, der Speicher ist sogar erweiterbar. Aber der Prozessor ist langsamer als z.B. der des LG G5 aus der gleichen Zeit, der Lautsprecher ist schrottig, vor allem aber ist der Akku nicht einfach auswechselbar. Wenn man aber schon bei Telefonen mit nicht einfach auswechselbarem Akku ist, dann gibt es Unmengen an stärkeren Alternativen mit besserer Romversorgung (z.B. das OnePlus 7 Pro).

Doch andererseits: Das alte A3 wird ja eher deswegen gewählt, weil es schon da ist und nicht im Schrank versauern soll, es wird ja wohl nicht extra gekauft. Dann lohnt es sich in jedem Fall, die folgende Anleitung nachzuvollziehen.

Installation

Die Kurzfassung: Das A3 muss erst vorbereitet werden, dann wird mit Odin (Windows) oder Heimdall (Linux) TWRP als Recovery installiert, womit dann das Rom geflasht werden kann. Ich wählte hier LineageOS 18.1, es gibt aber im xda-Forum auch eine Alpha von LineageOS 20. Lokale Daten wie installierte Apps werden dabei gelöscht!

Ich nutze Linux, also ist auch die Anleitung auf Linux ausgerichtet. Für Windows habe ich aber jeweils dazugeschrieben wie es gehen sollte – üblicherweise sind solche Anleitungen für Windows (und der Windowssoftware Odin) geschrieben, daher findet man anderswo auch alles nochmal zum nachlesen. Statt Heimdall unter Linux ebenfalls Odin (mit Wine) zu benutzen wäre eine testenswerte Alternative, vor allem wenn man sich die Kompilierung des Heimdall-Forks sparen will.

0. PC vorbereiten

Auf dem PC sollte adb installiert sein, das liegt unter Linux in den Quellen, für Windows möge man dieser Anleitung folgen. Unter Windows könnten auch Samsungs USB-Treiber gebraucht werden.

1. Telefon vorbereiten

Zuerst alle Updates durchlaufen lassen, insbesondere die für das System selbst. Da gab es 2020 das letzte, das auf meinem Gerät z.B. noch fehlte.

Sicher nun die Daten auf dem Gerät, die du behalten willst, irgendwo extern.

Dann muss der Entwicklermodus aktiviert werden. In den Einstellungen auf "About Phone" und dort siebenmal auf den Eintrag "Build Number" drücken. Eine kleine Einblendung sollte die Aktion bestätigen.

Dadurch gibt es in den Einstellungen einen neuen Eintrag mit den Entwickleroptionen. Dort müssen zwei aktiviert werden:

1. OEM Unlock
2. USB Debugging

2. Linux: Heimdall installieren & Recovery installieren

Jetzt kann das A3 in den Downloadmodus gesetzt werden, indem zum Start gleichzeitig die Knöpfe Power + Home + Lautstärke runter gedrückt und gehalten werden.

Unter Linux könnte man nun mit Heimdall die Recovery-Software aufspielen. Doch leider ist Heimdall nicht ohne weiteres mit dem A3 kompatibel, die in den Quellen verfügbare Version wird nicht funktionieren. Stattdessen kompilieren wir diese Version selbst, die einen Workaround eingebaut hat. Dafür braucht es die Pakete git, build-essential und cmake sowie ein paar weitere, die auch der Readme entnommen werden können (zlib1g-dev, qt5-default, libusb-1.0-0-dev. libgl1-mesa-glx, libgl1-mesa-dev; Paketnamen können abweichen). Dann:

git clone https://github.com/changlinli/Heimdall
cd Heimdall
mkdir build
cd build
cmake -DCMAKE_BUILD_TYPE=Release ..
make
cd bin/

Als Test ziehen wir nun die PIT-Datei, mit der das Telefon später vielleicht gerettet werden könnte falls etwas schiefginge:

sudo ./heimdall print-pit --file a310f_orig.pit

Das Telefon sollte nun neustarten, mit der Tastenkombination direkt wieder in den Downloadmodus setzen.

Kommen wir zur Recovery. TWRP kann von der TWRP-Seite heruntergeladen werden. Allerdings funktionierte die derzeit aktuelle 3.7.0 bei mir nicht. Stattdessen sollte die twrp-3.4.0-0-a3xelte.img gewählt werden, die ging.

Mit dem Telefon im Download-Modus, verbunden mit dem PC via eines USB-Kabels, kann das frisch kompilierte Heimdall nun die Recovery installieren:

sudo ./heimdall flash --RECOVERY twrp-3.4.0-0-a3xelte.img --no-reboot

oder 2. Windows: Odin installieren & Recovery installieren

Ich habe die Installation unter Linux durchgeführt. Unter Windows würde man statt Heimdall Odin benutzen. Ich verweise auf netzwelts Android: So führt ihr ein Custom Recovery auf Samsung-Smartphones durch. Auch hier würde ich von TWRP die 3.4.0 installieren.

3. LineageOS flashen

TWRP ist frisch installiert, würde aber entfernt werden, wenn das Telefon regulär neustartet. Stattdessen beenden wir den Downloadmodus mit Power + Lautstärke runter und drücken und halten direkt die Kombination für den Recovery-Modus: Power + Home + Lautstärke hoch. Es startet TWRP.

Auf dem PC laden wir LineageOS 18.1 aus dem xda-Forum herunter.

In TWRP geht es zu Wipe -> Advanced Wipe, dort Cache, Data und System auswählen und wipen.

Dann zu Advanced -> Sideload, durch swipe bestätigen. Das gerade heruntergeladene zip kann nun installiert werden:

adb sideload lineage-18.1-20230118-UNOFFICIAL-a3xelte.zip

Wer mag installiert jetzt noch genauso die Open GApps (ARM64, Android 11), ich verzichtete.

Wenn TWRP eine TWRP-App installieren will sollte das verneint werden.

Jetzt neustarten und das A3 sollte direkt LineageOS laden.

Mit LineageOS soll das A3 komplett funktionieren. Ich testete den Lautsprecher, Anrufe und die Kamera, schien zu passen, auch der Akku hielt ordentlich.

Wer keine GApps installiert hat und das nicht gewöhnt ist, dem empfehle ich direkt F-Droid herunterzuladen. Von dort bezieht man dann Firefox (Fennec) mit Ublock und alles andere was man braucht, wenn es Apps aus dem Play Store sein müssen kann Aurora die installieren (nicht alle gehen dann auch ohne GApps, aber viele). Vielleicht ist ansonsten meine eigene App-Liste eine Orientierungshilfe.

Sustaphones, meine Webseite zum Finden reparierbarer und von Android-Roms unterstützten Telefonen, hat ein paar Updates bekommen.

Diese beiden Screenshots zeigen den Unterschied (die alte Version zuerst):

Kein großer Umbau, aber praktische Änderungen sind dabei:

1. Die einzelnen Boxen haben nun oben einen Ankerlink, der die Seite an die jeweilige Stelle scrollt. Anlass dazu war dieser gnulinux.ch-Artikel zum Fairphone 2, der seine Erkenntnisse über ein spezielles Telefon nicht verlinken konnte. Jetzt ginge das.
2. Um das Design etwas symmetrischer zu machen ist der Link zur iFixit-Akku­wechsel­anleitung nach vorne in das Label gerutscht und steht nicht mehr extra hinter dem Icon. Dadurch konnten die Software- und Hardwarebereiche in der Box gleich groß werden. Das trennt gleichzeitig den unteren Bereich visuell besser vom oberen Bereich ab, bei dem Bild und Titel immer noch 33% und 66% des Platzes einnehmen.
3. MoKee gibt es nicht mehr, dementsprechend wurde es aus der Liste genommen.
4. Da LineageOS so betont hat, dass die neue Version 20 und nicht 20.0 sei, habe ich auch bei den anderen Roms die Versionsnummern angepasst (zumindest wo das jeweilige Projekt sie nicht eindeutig als X.0 benennt, wie bei DivestOS).
5. Generell lief ein Update aller Parser, insbesondere bei PixelExperience war das überfällig. Darüber wurden auch ein paar neue Telefone hinzugefügt, wie das Nothing Phone(1).

Ich möchte noch erwähnen, dass Havoc-OS auf meiner Abschussliste steht, dem Changelog zufolge ist das Projekt ziemlich inaktiv und auch bei ihrer Geräteliste hat sich nichts getan. Aber das werde ich noch etwas beobachten.

Änderungswünsche (die per Gitlab auch selbständig umgesetzt werden könnten) sind gern gesehen, ebenso Vorschläge zum Einbinden anderer Android-Projekte.

Sören kritisiert in seinem Blog LibreWolf, eine dieser alternativen Firefoxkonfigurationen. Er hat nicht völlig unrecht mit seiner Kritik, ich möchte aber zweien seiner Argumente dagegenhalten.

Das fehlende Projektimpressum

Sören schreibt:

Nun wirbt also ein Projekt um Vertrauen, welches nicht einmal ein Impressum auf der eigenen Website hat. Die Argumentation, dass im Land des Betreibers ggfs. keine gesetzliche Impressumspflicht besteht, könnte zu kurz greifen, da hier ein Produkt auch innerhalb der Europäischen Union angeboten wird. Letztlich schafft es aber auch vollkommen unabhängig von der rechtlichen Perspektive nicht unbedingt Vertrauen, wenn darauf verzichtet wird. Denn auch wenn es sich hier um ein Community-Projekt handelt, so muss es am Ende des Tages eine Person geben, welche gesamtverantwortlich für den Browser sowie Inhalte der Website ist.

Er verkennt hier in welcher Softwarewelt wir uns bewegen. Jeder von uns benutzt täglich Software, dessen Autor wir nicht kennen. Ist das tatsächlich mal anders, benutzen trotzdem die Entwickler der Software Abhängigkeiten deren Autor sie nicht kennen. Die FOSS-Welt ist auf eine andere Basis aufgestellt als die einer Internet-Impressumspflicht, einer rein deutschen Erfindung deutscher Weltregulierungsbürokraten. Schon bei Webseiten ist diese lächerlich, bei FOSS-Softwareprojekten völlig unbekannt. Klar, viele große Softwareprojekte lassen sich einzelnen Firmen oder speziell für sie gegründeten Vereinigungen zuordnen, die Regel ist das aber nicht.
Dementsprechend ist es keinesfalls so, dass für Browser oder Webseite des Projekts eine einzelne Person gesamtverantwortlich sein muss. Selbst wenn gewisse Juristen und Politiker das gerne so hätten.

Nebenbei, eine gesetzliche Impressumspflicht für solch eine private Hobbyseite besteht auch in Deutschland nicht. Edit: Diese meine Auffassung wird in den Kommentaren von fachkundiger Seite allerdings bestritten. Ich bleibe dabei, dass ein Projekt an solchen juristisch-bürokratischen Maßstäben zu messen keine gewinnende Strategie ist.

Das harmlose DRM

Sören schreibt:

Interessant ist auch die Begründung, mit der LibreWolf standardmäßig Digital Rights Management (DRM) abgeschaltet hat: Dies sei eine Limitierung der Nutzer-Freiheit. Das ist natürlich völliger Quatsch, denn im Gegenteil erlaubt DRM dem Nutzer den Konsum von Filmen, Serien und Sportveranstaltungen, sowohl kostenlos als auch kostenpflichtig, die anders überhaupt nicht angeboten werden könnten und was für den Nutzer auch überhaupt keinen Nachteil besitzt, während es das LibreWolf-Projekt ist, welches sich hier eine standardmäßige Einschränkung seiner Nutzer anmaßt – wohlgemerkt während gleichzeitig groß mit Freiheit geworben wird.

Die Aktivierung von DRM (Digital Restriction Management) in Browsern wie Firefox ist keinesfalls ohne Nachteile für die Nutzer, denn es propagiert die Nutzung dieser Technologie. Mit DRM aber kontrollieren Firmen, was die Menschen mit ihren Rechnern machen können. Dann werden Bücher aus der Ferne gelöscht, das Abspielen auf dem gewünschten Anzeigegerät verboten, das Anfertigen von Screenshots für Kritiken verhindert, das völlig legale Verleihen unterbunden; Kurz: Jedwede nicht komplett vorgesehene Nutzung der Inhalte wird verhindert. Als Firefox damals DRM aktivierte war es eine Niederlage für die Freiheitsrechte von uns allen, es in einem relevanten Browser nicht aktivieren zu können wirkte vorher gegen die weitere Verbreitung.

Natürlich kann jeder für sich abwägen, ob in einem bestimmten Kontext wie z.B. für Netflix das DRM nicht doch akzeptabel ist. Aber das sollte definitiv ein Opt-In und nicht standardmäßig an sein und ist wie ausgeführt nicht grundsätzlich eine nachteilslose Geschichte.

Das waren nur die zwei Argumente, die bei mir den größten Widerspruch provozierten. Mit den anderen Argumenten haben ich weniger Probleme, aber die Gesamtkritik findet mein Gefallen nicht.

Denn ich denke zwar insgesamt auch, dass ein Projekt wie LibreWolf natürlich Nachteile hat. Gerade Updates etwas später zu erhalten ist nicht ideal. Dazu laufen solche Projekte tatsächlich in die Gefahr, Sachen zu deaktivieren, die im Großen und Ganzen positiv sind. In diese Richtung geht der Großteil Sörens Kritik. Aber sie ist mir zu negativ, zu einseitig, das Projekt wegen seiner vermeintlichen Gefährlichkeit sogar nicht zu Verlinken empfinde ich als überzogen und wirkt auf mich kindisch. Denn erstmal ist es doch eine gute Sache, wenn alternative Konfigurationen von Firefox ausprobiert werden, wenn es ein Korrektiv für Mozillas teils eben durchaus fragwürdige Entscheidungen gibt.

Das ist immerhin die Firma, die bei der Überarbeitung der Androidversion Erweiterungen unter großem Protest deaktivierte und forkverhindernd ihre rasche Wiedereinführung versprach, was mittlerweile jahrelanges Verschleppen als Lüge entlarvt hat und nichtmal den eigenen Entwicklern erklärt wird. Besonders bei einem solchen Akteur ist Diversität eine Stärke, so ist auch LibreWolfs Existenz zu begrüßen. Ich vermute daher auch, dass die heftige Kritik weniger gegen das Projekt geht als gegen das durch das Projekt durchscheinende negative Bild von Mozilla – ob dem Autor das jetzt bewusst ist oder nicht.

Das Hacktoberfest belohnt Beiträge zu FOSS-Projekten, Ausrichter ist der US-Hoster Digitalocean. Void Linux macht dabei mit und ich empfand deren Beschreibung als sehr einladend: Die Ziele sinnvoll, klarer Einstiegspunkt und alle wichtigen Informationen wurden verlinkt. Wie war es dann, vier verwaiste Pakete für alle Void-Nutzer zu aktualisieren?

Das Prinzip

Das Hacktoberfest funktioniert so: Man meldet sich auf der Webseite an und gibt Leserechte auf den Github/Gitlab-Account. Projekte müssen über ihre Projektbeschreibung ihre Teilnahme signalisieren. Kommen dann im Projektzeitraum vier Pull-Requests an, bekommt der Teilnehmer ein T-Shirt oder es wird in seinem Namen ein Baum gepflanzt (beschränkt auf die 40.000 schnellsten erfolgreichen Teilnehmer). Der Fortschritt wird auf der Webseite in einer Übersicht angezeigt.

Void Linux hat auf seiner Webseite eine News veröffentlicht und da klar beschrieben, was sie brauchen:

1. Updates für verwaiste Pakete, und zwar lieber als Rezepte für neue Pakete
2. Upstream-Patches für Pakete, die nicht auf allen unterstützten Plattformen kompilieren
3. Fixes für ihre eigene Infrastruktur
4. Erweiterung der Dokumentation

Sie wollen also die Aktion nutzen um die anfallende Arbeit zu erleichtern, das fand ich super. Updates für verwaiste Pakete einzubringen sei zudem recht simpel.

Darüber kann man streiten, aber die Dokumentation dazu half auf jeden Fall. Zuerst gibt es eine Updateliste, die dort gelisteten Updates für Pakete von orphan@voidlinux.org sind die Ziele. Dann gibt es die Dokumentation, die etwas verteilt alles weitere erklärt: Das Readme des Paketrepos, die Anleitung und besonders hilfreich die Contributing-Hinweise.

Das Grundprinzip erklärt am besten die Readme: Klone das Git-Repo, führe darin ./xbps-src binary-bootstrap aus um Voids Paketinfrastruktur zu bauen. Aber wer Änderungen einbringen will liest sich besser durch Contributing, das erklärt neben dem Git-Drumherum das Vorgehen für Paketupdates: Editiere die Rezeptdatei ./srcpkgs/Paketname/template des Pakets (was oft einfach nur eine Anhebung der Versionsnummer sein wird), aktualisiere die Prüfsumme mit xgensum -i Paketname, baue das Paket mit ./xbps-src pkg <package_name>, dann installiere es mit xbps-install --repository hostdir/binpkgs <package_name>. Testen und einen PR mit einem einzelnem Commit an void senden. Das mit dem einen Commit wird oft bedeuten mit git rebase Commits zusammenzufügen, vor allem wenn nachträgliche Änderungen gefordert werden (was bei mir passierte).

Bei ihrem Github sind automatisierte Tests eingerichtet, die einen Syntaxcheck über die Rezeptdatei laufen lassen und zudem schauen, ob das Paket wirklich gebaut werden kann. Die sollten durchlaufen, ansonsten am besten direkt reagieren und den Fehler korrigieren.

Das musste ich teils auch bei meinen folgenden Paketupdates machen.

Update 1: memcached 1.6.10 -> 1.6.17

Memchached ist nicht Memcache, trotzdem fiel mit der Name wegen seiner Webentwicklerrelevanz auf. Das Update war nicht ganz so einfach: Erst wollte das Paket nicht bauen, dann wusste ich nicht wie ich es testen könnte.

Ich setzte also die Versionsnummer auf 1.6.17 und der Paketbau warf einen Fehler:

configure.ac:65: error: possibly undefined macro: AS_IF
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

Zum Glück war dafür ein Fehlerbericht bereits im memchached-Github, pkg-config würde gebraucht. Das zum Template hinzugefügt und der Bau lief durch. Hier als Beispiel ein Sreenshot der Änderungsübersicht, damit deutlich wird um wie wenige Codezeilen es letzten Endes geht:

Aber wie testet man memcached ohne herumliegenden Programmcode? Mit echo und nc ist die Antwort, wobei ich bei mir echo -e schreiben musste.

Daraufhin ging der PR durch.

Update 2: ruby-mime-types 3.3 -> 3.4.1

Eigentlich wollte ich ruby-httparty aktualisieren, aber das stolperte über diese Abhängigkeit. Das Gem mime-types war zu alt, um mit einer aktuellen Ruby-Version zu funktionieren. Ich musste da an mein altes Projekt music-streamer denken, das die MIME-Daten ausgelesen hat, wobei ich damals ruby-filemagic benutzte.

Hier war nur die Frage wie das Gem getestet werden kann, denn der Bau der neuen Version lief direkt durch. Die Antwort war irb, der Testcode entstammt der Projektreadme:

require 'mime/types'
MIME::Types['text/plain']

Im PR kam dann nur der Vorschlag, die Changelog-Datei zu verlinken.

Update 3: ruby-mime-types-data 3.2019.1009 -> 3.2022.0105

Ich fand es naheliegend, ruby-mime-types-data direkt mitzuaktualisieren. So ein Datenpaket sollte keine Abhängigkeiten haben und ist daher einfach, aber es vermeidet im Zweifel Bugs in anderen Paketen wenn die Datenbank aktuell ist. Der Test war genau wie bei ruby-mime-types (das dieses Paket als Datenquelle lädt), nur dass beide neue Versionen installiert waren.

Im PR lief ich nur in ein Miniproblem mit einem Leerzeichen nach der Versionsnummer, was xlint nicht mochte. Das konnte ich mit commit -v --amend und einem folgendem git push --force reparieren, ohne rebase, wobei ich beim ersten mal vergessen hatte meine Änderung vorher auch mit git add sichtbar zu machen.

Update 4: minitube 3.9.1 -> 3.9.3

Ich hatte mir vor einer Weile mal einige Linux-Youtubeclients angeschaut, da fiel mir minitube direkt auf. Dem Versionsummersprung entsprechend war es ein kleines Update und lief problemlos durch, ich testete hier auch wieder die ARM-Crosskompilierung, was bei Void mit ./xbps-src -a armv6l pkg minitube einfach anzuleiern ist.

Funktionstest bei so einem Anwenderprogramm war dann viel einfacher als bei memcached, ich startete das Programm und schaute ob Videos abgespielt werden konnten.

Das wurde dann dieser PR.

Ein paar Gedanken zum Schluss: Das Hacktoberfest gefiel mir gut. Die früheren Probleme scheinen ausgeräumt. Natürlich wäre es noch cooler jemanden neu zur FOSS-Welt zur Teilnahme zu bringen, aber auch ich empfand den vom Void-Projekt bereitgestellten klaren Einstiegspunkt hilfreich. Manchmal ist ein klares "Wir wollen wirklich Hilfe, und zwar genau diese" sehr überzeugend.

Aber ohne mich zu sehr beweihräuchern zu wollen: Mir hat das auch nochmal vor Augen geführt, wie groß die Hürde eigentlich ist. Git mit seinen Konzepten ist schon nicht simpel, wenn dann noch rebase und Force-Push dazukommen wird es nicht einfacher. Ich erinnere mich zum Beispiel, dass mir sehr lange schlicht nicht klar war wie man PRs überhaupt aktualisieren kann, als ich git schon längst für meine eigene Versionsverwaltung nutzte. Jetzt scheint es simpel, damals fehlte mir einfach das mentale Modell dafür. Davon abgesehen, das Prüfen durch andere Entwickler machte mich anfangs nervös, alternativ genervt, wenn PRs ignoriert wurden (letzteres gilt immer noch, trifft mittlerweile aber weniger hart und bei Serendipity habe ich Vermeidungsstrategien entwickelt). Und das ist eine Hürde, die fast jede Code-Beisteuerung nehmen muss. Selbst man nicht direkt Linux-Paketmaintainer spielen will. Projekte tun gut daran möglichst viel davon zu dokumentieren, selbst wenn es redundant wirkt, einen ganzen Monat für diese Aktion zu geben ist ebenfalls angemessen.

Wie schwer bei Void das Aktualisieren von Paketen dann wirklich war hing natürlich stark vom Paket und vom jeweiligen Updatefehler ab. Ich wäre zum Beispiel ohne den existierenden Fehlerbericht über die nichtssagende Fehlermeldung bei memcached nie auf pkg-config als fehlende Abhängigkeit gekommen, und das obwohl ich pkg-config schon selbst bei simdock eingesetzt habe. Wer kein Ruby-Entwickler ist könnte das Testen vom Ruby-Gems schwierig finden. Überhaupt, dass man beim Kompilieren Fehlermeldungen wirklich lesen und interpretieren kann hat mir vor vielen Jahren Unki auf UbuntuUsers.de erst erklären müssen. Es baut alles aufeinander auf…

Der Blickwinkel macht für mich dann das Hacktoberfest nochmal wertvoller – wenn es bei einigen der Teilnehmern ein paar der benötigten Grundlagen schafft, ist das einfach eine gute Sache. Man kann es auf zwei Ebenen zwar auch kritisieren: Der Gamification-Ansatz ist manipulierend, via den T-shirts extrinsische Motivation einzuführen könnte intrinsische zerstören. Aber ich glaube, der Anreiz an Projekte die Unterstützbarkeit klar zu beschreiben wiegt das auf, und ein kleiner Motivationsanschub durch eine Aktion im Jahr dürfte auch langfristig wenig schädlich sein.

Wer die technische Entwicklung bei Spielen nicht genau verfolgt könnte es verpasst haben, doch tatsächlich sind die Upscale-Techniken von AMD, Nvidia und jetzt Intel revolutionär. Mit ihnen laufen Spiele intern auf einer kleineren Auflösung – also z.B. 1477x831 – und die Grafikkarte skaliert das Bild dann eigenständig auf die Zielauflösung hoch – hier 1920x1080. Und die Ergebnisse sehen toll aus. Ursprünglich wurde dieser Ansatz als Lösung präsentiert um 4K-Auflösungen erreichbarer zu machen, doch mir ist das obere Szenario viel sympathischer. Denn so werden alte Grafikkarten entlastet, die dann auf einmal moderne AAA-Spiele besser bewältigen können. Das Hochskalieren mittels der GPU ist praktisch kostenlos, das Herunterregeln der internen Auflösung spart Unmengen an Aufwand.

Damit das perfekt läuft muss das Spiel diese Techniken unterstützen. Doch unter Linux haben sich Entwickler auf das freie FSR gestürzt, das Upscaling von AMD. Dessen erste Version lässt sich an jedes Spiel anheften! Die Ergebnisse sind teilweise erstaunlich gut, zumindest wenn man etwas nachhilft. Und da kommt vkBasalt ins Spiel.

In Kurz

Installiere Proton-GE und vkBasalt sowie optional Mangohud. Benutze für vkBasalt diese Konfiguration. Starte ein Windowsspiel so:

mangohud ENABLE_VKBASALT=1 WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%

Setze die Auflösung im Spiel auf die FSR-Startauflösung für die native Zielauflösung deines Monitors (Tabelle hier). Fertig, das Spiel läuft schneller als zuvor.

Die ausführliche Anleitung folgt.

FSR aktivieren

Doch erstmal muss man FSR überhaupt ankriegen. Auf dem Steamdeck hat Valve das mitgeliefert, im regulären Proton nicht. Dafür braucht es bisher noch eine alternative Protonvariante, nämlich GloriousEggrolls Proton. Die Installation ginge so:

1. Download a release from the Releases page.
2. Create a ~/.steam/root/compatibilitytools.d directory if it does not exist.
3. Extract the release tarball into ~/.steam/root/compatibilitytools.d/.
   • tar -xf GE-ProtonVERSION.tar.gz -C ~/.steam/root/compatibilitytools.d/
4. Restart Steam.
5. Enable proton-ge-custom.

Doch ist das unnötig kompliziert, wenn ProtonUp-Qt das mit ein paar Klicks machen kann. Also: Zieh dir das AppImage davon, mach es ausführbar, lass es Proton-GE installieren.

Danach kann das in den Einstellungen von Steam unter Steam Play für alle Spiele aktiviert werden, oder du setzt die Protonversion für das jeweilige Spiel unter "Kompatiblität".

Um jetzt ein Spiel mit FSR zu starten müssen die Startparameter gesetzt werden. Rechtsklick in Steam aufs Spiel, Eigenschaften, dann sind die Startoptionen direkt rechts. Schreibe dort:

WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%

Wenn jetzt das Spiel gestartet wird läuft alles normal, FSR tut noch nichts. Dafür muss erst die Auflösung gewechselt werden. Durch den Start samt FSR-Befehl sollte in den Einstellungen jetzt eine passende auftauchen. Bei meiner 1080p-Auflösung als Ziel ist das 1477x831, bei 1440p oder 4K als Ziel entsprechend mehr. Die beste Liste dafür findet sich hier. Wird jetzt diese Auflösung gewählt greift FSR. Das Bild sieht etwas ausgewaschener aus, aber viel besser als wenn die Auflösung nicht automagisch hochskaliert werden würde.

vkBasalt aktivieren

Diesem ausgewaschenem Bild kann vkBasalt auf die Sprünge helfen. Das Programm zeichnet Filter über die Ausgabe von Programmen. Besonders interessant für uns, dass es das Bild mittels zweier Methoden nachschärfen kann, und dass es nochmal zwei Kantenglättungsfilter kennt.

vkBasalt kann manuell installiert werden, das ginge so:

git clone https://github.com/DadSchoorse/vkBasalt.git
cd vkBasalt
meson --buildtype=release --prefix=/usr builddir
ninja -C builddir install

Wieder sollte das nicht nötig sein, es ist in einigen Repos bereits vertreten und kann daher direkt über den Paketmanager installiert werden. Bei mir mit Void Linux:

sudo xbps-install vkBasalt

Die Konfiguration fehlt aber noch. Geht auch per Spiel, was in der Readme erklärt wird, ich würde stattdessen die Datei $HOME/.config/vkBasalt/vkBasalt.conf anlegen und hiermit füllen:

#effects is a colon seperated list of effect to use
#e.g.: effects = fxaa:cas
#effects will be run in order from left to right
#one effect can be run multiple times e.g. smaa:smaa:cas
#cas    - Contrast Adaptive Sharpening
#dls    - Denoised Luma Sharpening
#fxaa   - Fast Approximate Anti-Aliasing
#smaa   - Enhanced Subpixel Morphological Antialiasing
#lut    - Color LookUp Table
effects = smaa:dls

reshadeTexturePath = "/path/to/reshade-shaders/Textures"
reshadeIncludePath = "/path/to/reshade-shaders/Shaders"
depthCapture = off

#toggleKey toggles the effects on/off
toggleKey = Home

#enableOnLaunch sets if the effects are emabled when started
enableOnLaunch = True

#casSharpness specifies the amount of sharpning in the CAS shader.
#0.0 less sharp, less artefacts, but not off
#1.0 maximum sharp more artefacts
#Everything in between is possible
#negative values sharpen even less, up to -1.0 make a visible difference
casSharpness = 0.3

#dlsSharpness specifies the amount of sharpening in the Denoised Luma Sharpening shader.
#Increase to sharpen details within the image.
#0.0 less sharp, less artefacts, but not off
#1.0 maximum sharp more artefacts
dlsSharpness = 0.5

#dlsDenoise specifies the amount of denoising in the Denoised Luma Sharpening shader.
#Increase to limit how intensely film grain within the image gets sharpened.
#0.0 min
#1.0 max
dlsDenoise = 0.8

#fxaaQualitySubpix can effect sharpness.
#1.00 - upper limit (softer)
#0.75 - default amount of filtering
#0.50 - lower limit (sharper, less sub-pixel aliasing removal)
#0.25 - almost off
#0.00 - completely off
fxaaQualitySubpix = 0.75

#fxaaQualityEdgeThreshold is the minimum amount of local contrast required to apply algorithm.
#0.333 - too little (faster)
#0.250 - low quality
#0.166 - default
#0.125 - high quality 
#0.063 - overkill (slower)
fxaaQualityEdgeThreshold = 0.1

#fxaaQualityEdgeThresholdMin trims the algorithm from processing darks.
#0.0833 - upper limit (default, the start of visible unfiltered edges)
#0.0625 - high quality (faster)
#0.0312 - visible limit (slower)
#Special notes: due to the current implementation you
#Likely want to set this to zero.
#As colors that are mostly not-green
#will appear very dark in the green channel!
#Tune by looking at mostly non-green content,
#then start at zero and increase until aliasing is a problem.
fxaaQualityEdgeThresholdMin = 0.0312

#smaaEdgeDetection changes the edge detection shader
#luma  - default
#color - might catch more edges, but is more expensive
smaaEdgeDetection = luma

#smaaThreshold specifies the threshold or sensitivity to edges
#Lowering this value you will be able to detect more edges at the expense of performance.
#Range: [0, 0.5]
#0.1 is a reasonable value, and allows to catch most visible edges.
#0.05 is a rather overkill value, that allows to catch 'em all.
smaaThreshold = 0.05

#smaaMaxSearchSteps specifies the maximum steps performed in the horizontal/vertical pattern searches
#Range: [0, 112]
#4  - low
#8  - medium
#16 - high
#32 - ultra
smaaMaxSearchSteps = 32

#smaaMaxSearchStepsDiag specifies the maximum steps performed in the diagonal pattern searches
#Range: [0, 20]
#0  - low, medium
#8  - high
#16 - ultra
smaaMaxSearchStepsDiag = 16

#smaaCornerRounding specifies how much sharp corners will be rounded
#Range: [0, 100]
#25 is a reasonable value
smaaCornerRounding = 25

#lutFile is the path to the LUT file that will be used
#supported are .CUBE files and .png with width == height * height
lutFile = "/path/to/lut"

Die Steam-Startparameter des Testspiels ergänzen wir nun ebenfalls um ENABLE_VKBASALT=1, sodass sie so aussehen:

ENABLE_VKBASALT=1 WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%

Die Home-Taste auf der Tastatur deaktiviert nun vkBasalt, der Effekt sollte deutlich sichtbar sein, nochmal Home aktiviert es wieder. Verschwunden ist das ausgewaschene der Standard-FSR-Hochskalierung.

MangoHud, optional

Wer den Bildunterschieden noch nicht ganz traut kann das ganze mit MangoHud überprüfen. Auch das war bei mir in den Quellen:

sudo xbps-install MangoHud

Die manuelle Installationsanleitung spare ich mir hier, sie ist ausführlich auf der Githubseite erklärt, samt vorkompilierten Releasedateien.

Auch Mangohud will konfiguriert werden. Setze in die $HOME/.config/MangoHud/MangoHud.conf diesen Inhalt:

### MangoHud configuration file

### Display the current GPU information
gpu_stats

### Display the current CPU information
cpu_stats

### Display FPS and frametime
fps
frametime

### Display the frametime line graph
frame_timing

### Display GameMode / vkBasalt running status
vkbasalt

### Display the current resolution
resolution

### Disable / hide the hud by default
no_display

################ WORKAROUNDS #################
### Options starting with "gl_*" are for OpenGL
### Specify what to use for getting display size. Options are "viewport", "scissorbox" or disabled. Defaults to using glXQueryDrawable
# gl_size_query=viewport

### (Re)bind given framebuffer before MangoHud gets drawn. Helps with Crusader Kings III
# gl_bind_framebuffer=0

### Don't swap origin if using GL_UPPER_LEFT. Helps with Ryujinx
# gl_dont_flip=1

################ INTERACTION #################

### Change toggle keybinds for the hud & logging
# toggle_hud=Shift_R+F12
# toggle_fps_limit=Shift_L+F1
# toggle_logging=Shift_L+F2
# reload_cfg=Shift_L+F4
# upload_log=Shift_L+F3

Das ist fast Standard, aktiviert aber die Optionen zur Erkennung von vkBasalt und der Auflösung. Noch die Startparameter anpassen:

mangohud ENABLE_VKBASALT=1 WINE_FULLSCREEN_FSR=1 WINE_FULLSCREEN_FSR_MODE=ultra %command%

Jetzt erscheint nach Druck auf rechtem Shift + F12 links oben eine Box, die neben den Frametimes und FPS auch die Auflösung anzeigt (was bei aktiviertem FSR also 1920x1080 bzw die Zielauflösung ist, selbst wenn das Spiel intern eine geringere gesetzt hat) und ob vkBasalt an ist. Shift_R + F12 versteckt die Box wieder.

Diskussion der Bildqualität

Wie gut ist jetzt noch das Bild? Ich habe hier mit Metro Exodus ein paar Vergleichsbilder gemacht. Zuerst einmal ist das Ziel die tolle 1080p-Qualität, wobei das nichtmal die hohen Einstellungen sind:

In meiner (recht einfachen) Testszene schwankte mein System hiermit zwischen 70 und 94 FPS.

Mit FSR im Ultra-Modus, also intern 1477x831, sieht das ganze leider viel weniger scharf aus:

Dafür sind die FPS besser, 80 bis 106 FPS sah mein Test. Und das ist die geringste FSR-Stufe, die anderen würden die interne Auflösung weiter verringern und die Performance verbessern.

Und schließlich das Bild mit Ultra-FSR samt vkBasalt:

Das erreicht nicht ganz die Qualität der nativen 1080p-Auflösung. Nicht, dass es nicht ähnlich scharf wäre. Aber FSR produziert eine Abrundung von Linien (gerade im hier nicht sichtbaren HUD) und einen grauen Körnereffekt über dem Bild. Das Schärfen mittels vkBasalt wirkt da leider nicht gegen. Trotzdem wertet vkBasalt das Bild wesentlich auf, die wahrnehmbare Unschärfe ist weg.

Die Performance mit vkBasalt war nur ein bisschen schlechter, die FPS lagen bei 80 bis 100.

Ich wollte hier zum einen FSR mit vkBasalt vorstellen. Gerade die Kombination von FSR mit vkBasalt als Schärfefilter sah ich noch nicht so oft diskutiert, dass Linux hier Spielern eine tolle Tuningoption gibt soll nicht untergehen. Der Umweg über Proton schafft unerwartete Möglichkeiten um Spielen einen gar nicht mal so kleinen Schubs zu geben. Immer noch auf Kosten der Grafikqualität, zugegeben, aber je nach Spielertyp ist es das wert.

Aber mich interessieren besonders auch Fehler in meiner Konfiguration. Gibt es zu vkBasalt sogar gute Alternativen? Wäre bei dessen Einsatz die Kombination der beiden Schärfefilter cas und dls sinnvoll? Sollte FXAA statt SMAA benutzt werden? Ich habe natürlich schon einiges auspobiert, aber bin keineswegs sicher, dass die Konfiguration oben die optimale ist. Nur dass sie ein guter Startpunkt ist, davon bin ich überzeugt.

Als Fazit reizt mich auch der Gedanke, dass dieses jetzt schon interessante Ergebnis die erste Version von FSR nutzt. DLSS 2.0, FSR 2.0 und XeSS sind nochmal deutlich besser. Wenn es irgendwie gelingen würde, sowas wie XeSS auch ohne Entwickleraufwand nutzbar zu machen und dann mit jedem Spiel kombinieren zu können...

DivestOS ist ein Fork von LineageOS. Das Ziel: Gerade auch ältere Telefon mit einem möglichst sicherem Android ausstatten, sodass Nutzer die Kontrolle über ihr System bewahren. Dabei ist ein Fokus auf FOSS Teil der Projektphilosophie, sodass z.B. proprietäre Blobs an vielen Stellen entfernt werden.

Das passt natürlich perfekt zu sustaphones, meinem ROM-Finder für möglichst reparierbare Telefone. Nachdem ich über das ROM las kontaktierte ich daher das Projekt per Reddit. Ergebnis: DivestOS konnte gelistet werden. Der Parser ist zwar etwas komplexer als ideal (weil die Daten nicht in einem Rutsch heruntergeladen werden können), aber es waren doch alle notwendigen Informationen verfügbar – welches Gerät von welcher Version unterstützt wird, wobei bei diesem Projekt auch der Grad der Unterstützung (von "kaputt" bis "getestet, funktioniert") berücksichtigt werden musste.

Die Reihenfolge der Geräte auf der Webseite wird durch die neue Alternative durchaus etwas verändert, obwohl das als Lineage-Fork nicht unbedingt zu erwarten war. Doch werden teils neue Smartphones wie das FP4 offiziell unterstützt, wo bei LineageOS die Unterstützung noch fehlt, und werden einige alte Telefone wie das HTC One (M8) mit einer aktuellen Androidversion versorgt, die von anderen Projekten längst ignoriert werden.

Ich freue mich über das Projekt sowie über die erhaltene Möglichkeit, der Webseite eine weitere Alternative hinzuzufügen.

Firefox ist in Ubuntu 22.04 ein Snap geworden. Konsequenz ist, dass Nutzer sein Updaten nicht mehr kontrollieren können (völlig unverständlich, aber ein Thema für sich), andererseits Canonical das Bereitstellen von Updates vereinfacht wird. Befürchtete Konsequenz war aber auch, dass Firefox langsamer starten würde. Denn genau das passierte in vorherigen Ubuntuversionen mit Chromium, dessen Snapisierung zu elendig langen Startzeiten führte.

Diese Befürchtung griff Ubuntu – Wie du Firefox als PPA anstelle von Snap einbindest und wann du es tun solltest auf, der Autor verneinte aber ihre Berechtigung. Ich empfand den Artikel als herablassend und kommentierte entsprechend – aber nein, wurde mir versichert, Firefox starte jetzt wirklich immer noch schnell, Snap sei besser geworden. Das hätte der Präambel über die ewigen unqualifizierten Bedenkträger dann wirklich etwas Berechtigung gegeben, so trollig sie sonst auch wirkte. Ich war besänftigt.

Stellt euch mein Erstaunen vor, als ich auf einem Laptop nach einem Upgrade von Ubuntu 20.04 auf 22.04 dann Firefox startete und dieser erste Start keinesfalls schnell war. Er dauerte nicht 3 Sekunden, auch nicht 10, nicht 20; Es dauerte wahnsinnige 40 Sekunden bevor der Browser aufging. Unfassbar.

Nun: Das galt bisher wirklich nur für den allerersten Start nach dem Upgrade. Nachfolgende erste Startvorgänge, auch nach einem Reboot, waren wesentlich schneller. Ursache der Verzögerung könnte ein einmaliger Upgradetask gewesen sein und vielleicht gar nichts mit dem Umstieg auf Snap zu tun gehabt haben. Aber ist es da ein Wunder, dass bei Nutzern der Eindruck entsteht auch das Firefox-Snap wären furchtbar lahm? Wie unglücklich für Snap dieses Upgrade doch lief, sollte es eine Verstrickung mit etwas unzusammenhängendem gewesen sein – zum einen –, aber auch wie unfair die Herablassung, die von Teilen der Ubuntucommunity gegenüber dieser Befürchtung gezeigt wurde. Nicht nur, dass Chromium eben wirklich durch Snaps langsam startete, auch Firefox vermittelt eben doch diesen lahmen Start mindestens als Ersteindruck.

Meine Ersteinschätzung über den Ton des Artikels war sehr wohl berechtigt.

Das wäre ein Kommentar geworden, aber der verlinkte Artikel hat seine Kommentarfunktion deaktiviert.

Kommt ihr gut durch die Hitze? Wenn während der Hitzewelle der PC zu sehr brummt könnte eine Anpassung der Lüftersteuerung angesagt sein. Das Programm fan2go ist eine relativ neue Alternative zum altgedienten fancontrol, die leichter zu benutzen ist und ein paar Probleme bezüglich der sich ändernden Lüfter-Indexierung ausräumen will.

Warum sollte man solch ein Programm nutzen und nicht einfach die Fankurve im BIOS festlegen? Tatsächlich sollte man letzteres vorziehen. Aber manchmal hat das Mainboard diese Funktion einfach nicht, oder sie funktioniert nicht richtig. So war es bei mir; Ich hatte den Lüfter des Prozessorkühlers auf 12% runtergeregelt, trotzdem rödelte er relativ laut. Ich wunderte mich darüber ewig, bis ich jetzt darauf kam, dass das Mainboard (ein MSI Z97M-G43) da einfach den Lüfter nie unter 50% fallen ließ. Vielleicht ein fehlgeleiteter Abschaltschutz, sicher aber viel zu laut im Idle. Den Radiatorlüfter (mein System hat eine AIO) an Systemfan zu hängen und den Gehäuselüfter als CPU-Lüfter laufen zu lassen war ein Teil der Lösung meines Geräuschproblems, den Rest erledigt die Lüftersteuerung durch das neue Programm.

Installation

Als recht junges Projekt ist fan2go leider noch nicht in vielen Quellen. Um es zu installieren könnte man es wie in der Readme vorgeschlagen von Github herunterladen und in den $PATH verschieben:

curl -L -o fan2go https://github.com/markusressel/fan2go/releases/latest/download/fan2go-linux-amd64
chmod +x fan2go
sudo cp ./fan2go /usr/local/bin/fan2go   # besser als direkt nach /usr/bin/
fan2go -h

Ohne Konfigurationsdatei erscheint nun erstmal eine Fehlermeldung im Terminal, aber immerhin.

Konfiguration

Die Konfiguration ist leider wieder etwas Handarbeit. Man muss wissen, welche Lüfter man steuern will, sie finden und ihnen Temperaturbereiche zuweisen. Immerhin hilft das Programm hier mit einer Übersicht:

onli@fallout:~$ fan2go detect
> coretemp-isa-0
  Sensors  Index  Label                       Value
           1      Package id 0 (temp1_input)  43000
           2      Core 0 (temp2_input)        41000
           3      Core 1 (temp3_input)        43000
           4      Core 2 (temp4_input)        40000
           5      Core 3 (temp5_input)        43000

> amdgpu-pci-0100
  Fans     Index  Label   RPM  PWM  Auto 
           1      hwmon0  165  18   false
  Sensors  Index  Label               Value
           1      edge (temp1_input)  43000

> nct6792-isa-0
  Fans     Index  Label   RPM   PWM  Auto 
           1      hwmon3  0     127  true 
           2      hwmon3  534   59   false
           3      hwmon3  408   64   false
           4      hwmon3  1515  255  true 
           5      hwmon3  0     127  true 
  Sensors  Index  Label                                Value 
           1      SYSTIN (temp1_input)                 39000 
           2      CPUTIN (temp2_input)                 127500
           3      AUXTIN0 (temp3_input)                38000 
           4      AUXTIN1 (temp4_input)                70000 
           5      AUXTIN2 (temp5_input)                127000
           6      AUXTIN3 (temp6_input)                -60000
           7      PECI Agent 0 (temp7_input)           41500 
           8      PCH_CHIP_CPU_MAX_TEMP (temp8_input)  0     
           9      PCH_CHIP_TEMP (temp9_input)          0     
           10     PCH_CPU_TEMP (temp10_input)          0     

> acpitz-acpi-0
  Sensors  Index  Label                 Value
           1      hwmon1 (temp1_input)  27800
           2      hwmon1 (temp2_input)  29800

In der Ausgabe von fan2go detect konnte ich meine drei steuerbaren Lüfter finden: Die Einträge hwmon3 unter nct6792 verrieten sich mit der RPM-Angabe. Der bei 1515 stehende konnte nur die Pumpe der AIO sein und muss nur optional gesteuert werden. Es blieben Index 2 und 3 für die Lüfter, was in meinem Fall einmal der Lüfter auf dem Radiator und der im Gehäuse hinten sein musste.

Um die genau zu identifizieren musste ich einmal sudo su aufmachen und dann die PWM-Regler unter /sys/ mit Werten füttern, z.B. so:

onli@fallout:~$ sudo su
Password: 
# bash
[root@fallout onli]# cat /sys/class/hwmon/hwmon3/pwm2
58
[root@fallout onli]# cat /sys/class/hwmon/hwmon3/pwm2_enable 
1

Wenn da stattdessen bei pwm2_enable eine 5 gestanden hätte, müsste noch eine 1 hineingeschrieben werden:

[root@fallout onli]# echo "1" > /sys/class/hwmon/hwmon3/pwm2_enable 

Sonst kontrolliert das Mainboard die Lüfter. Genau so lässte sich auch der PWM-Wert erhöhen (0-255), dann dreht ein Lüfter hoch und man kann erkennen welcher welcher ist.

Jetzt mit allen Infos über das System ausgestattet ging es ans Anlegen der Konfiguration. Meine /etc/fan2go/fan2go.yaml sieht so aus:

# A list of fans to control
fans:
  - id: casefan
    # The type of fan configuration, one of: hwmon | file
    hwmon:
      # The platform of the controller which is
      # connected to this fan (see sensor.platform below)
      platform: nct6792
      # The index of this fan as displayed by `fan2go detect`
      index: 2
    # Indicates whether this fan should never stop rotating, regardless of
    # how low the curve value is
    neverStop: false
    # The curve ID that should be used to determine the
    # speed of this fan
    curve: cpu_curve
  - id: radiatorfan
    # The type of fan configuration, one of: hwmon | file
    hwmon:
      # The platform of the controller which is
      # connected to this fan (see sensor.platform below)
      platform: nct6792
      # The index of this fan as displayed by `fan2go detect`
      index: 3
    # Indicates whether this fan should never stop rotating, regardless of
    # how low the curve value is
    neverStop: false
    # The curve ID that should be used to determine the
    # speed of this fan
    curve: cpu_curve
  - id: pump
    # The type of fan configuration, one of: hwmon | file
    hwmon:
      # The platform of the controller which is
      # connected to this fan (see sensor.platform below)
      platform: nct6792
      # The index of this fan as displayed by `fan2go detect`
      index: 4
    # Indicates whether this fan should never stop rotating, regardless of
    # how low the curve value is
    neverStop: true
    # The curve ID that should be used to determine the
    # speed of this fan
    curve: pump_curve
# A list of sensors to monitor
sensors:
  # A user defined ID, which is used to reference
  # a sensor in a curve configuration (see below)
  - id: cpu_package
    # The type of sensor configuration, one of: hwmon | file | cmd
    hwmon:
      # A regex matching a controller platform displayed by `fan2go detect`, f.ex.:
      # "coretemp", "it8620", "corsaircpro-*" etc.
      platform: coretemp
      # The index of this sensor as displayed by `fan2go detect`
      index: 1
  - id: system_package
    # The type of sensor configuration, one of: hwmon | file | cmd
    hwmon:
      # A regex matching a controller platform displayed by `fan2go detect`, f.ex.:
      # "coretemp", "it8620", "corsaircpro-*" etc.
      platform: nct6792
      # The index of this sensor as displayed by `fan2go detect`
      index: 1
curves:
  - id: cpu_curve
    # The type of the curve, one of: linear | function
    linear:
      # The sensor ID to use as a temperature input
      sensor: cpu_package
      # Sensor input value at which the curve is at minimum speed
      min: 30
      # Sensor input value at which the curve is at maximum speed
      max: 80
  - id: pump_curve
    # The type of the curve, one of: linear | function
    linear:
      # The sensor ID to use as a temperature input
      sensor: cpu_package
      # Sensor input value at which the curve is at minimum speed
      min: 40
      # Sensor input value at which the curve is at maximum speed
      max: 80

Sie ist simpel abgeleitet von den Beispielen in der Readme. Man erkennt, wie die Zuordnung zu den Indezes und der Plattform der Lüfter funktioniert und dass jeweils ein Lüfter, ein Sensor und eine Kurve gebraucht wird – wobei natürlich zwei Lüfter sich auch eine Kurve teilen können. Zwischen Minimal- und Maximaltemperatur linear zu schalten ist ein sehr simpler Ansatz, kann auch funktionieren, wenn nicht können auch PWM-Schritte angegegen werden. Da erklärt die Githubseite mehr.
Nicht wundern: Die AIO-Pumpe über den PWM-Wert zu steuern macht man nicht immer, oft kann sie auf 100% laufen. Bei meiner alten Corsair H90 aber piepst sie dann zu arg.

Starten

Nun startet man das Programm einfach mit:

sudo fan2go

Das System sollte man nun ordentlich testen, dass es ja nicht überhitzt. Stimmt alles könnte man wie in der Readme vorgeschlagen einen Systemdienst anlegen, ich packte mir den Befehl stattdessen in die /etc/rc.local.

Ich bin mit dem Ergebnis ganz zufrieden, mein System ist deutlich leiser geworden und bei fancontrol wollte die alte Konfigurationsdatei nicht mehr funktionieren. Eine Alternative zu haben ist toll. Ich vermisse aber ein Interface, das die manuelle Konfiguration ersetzt. Müsste ja nicht gleich komplett grafisch sein, schon eine UI im Terminal würde mir reichen.

Wichtiger aber noch: Es fehlt die Unterscheidung zwischen dem Start-PWM-Wert und dem Stop-PWM-Wert, die ja oft sehr unterschiedlich sind, da ein Lüfter viel mehr Energie zum Losdrehen braucht als zum Weiterdrehen. Deswegen sollte die Option neverStop vermieden werden, sie setzt den Start-PWM-Wert als Minimum fest und ist daher für reguläre Lüfter ziemlich laut. Vielleicht der gleiche Fehler wie der meines Mainboards anfangs. Nur für die Pumpe passte das perfekt. Ich hoffe da entwickelt sich das Projekt noch weiter, sodass man die Option auch für Lüfter setzen kann.

Trotz der Einschränkungen finde ich das Programm schon jetzt ziemlich großartig. Vielleicht ist es auch für den ein oder anderen Leser hilfreich, gerade in dieser Phase des Sommers.

Mit protonup installiert man im Terminal die neueste Version von Proton-GE, was eine aktuellere und verbesserte Variante von Proton ist. Oft lassen sich so mehr Windowsspiele besser unter Linux spielen. ProtonUp-Qt ist eine GUI für dieses Kommandozeilenprogramm und erleichtert die Bedienung doch erheblich. Zumindest das Entfernen alter Versionen ist damit einfacher. So sieht es aus:

Nett auch, dass damit trotz des Namens nicht nur Proton aktualisiert werden kann. Sondern es kann auch Luxtorpeda, Boxtron und Roberta installieren. Das sind jeweils Helferprogramme, die sich ähnlich wie Proton in Steam vor die Spiele schalten und sie dann durch Auswechseln der Engine (Luxtropeda, Roberta) bzw des Emulators (Boxtron) verbessern.

Da ProtonUp-Qt als AppImage von der Webseite heruntergeladen kann läuft es problemlos auf jeder Linuxdistribution, Nutzer müssen es nicht selbst kompilieren oder warten bis es in die Quellen kommt.