Technikzeugs

Dieser Blog hat nun einen Dunkelmodus bekommen, der so aussieht:

Um den Vergleich später und im Feedreader einfach zu machen, das normale Design sieht derzeit so aus:

Wie das funktioniert hatte ich für PC-Kombo näher beschrieben. Es war hier sehr ähnlich, es musste relativ wenig CSS in die CSS-Datei hinzugefügt werden, das dann per Media-Query den Dark-Mode aktiviert und vorher gesetzte Farben mit dunkleren Alternativen überschreibt. Auffällig diesmal war, dass ich öfter unset und ein paarmal inherit benutzt habe um Farbdefinitionen aufzuheben. Für die Markup-Buttons beim Kommentarformular kam wieder filter: invert(100%) zum Einsatz, das RSS-Icon dunkelt ein filter: brightness(90%) ab.

Stilistisch ist der dunkle Modus ziemlich retro geworden. Das passt eigentlich nicht besonders zum Originaldesign, aber ich fand es hatte was, daher durfte es erstmal so bleiben.

Beim regulären hellen Design sind auch ein paar Farbdefinitionen neu. Beim Prüfen des Kontrasts für den Dunkelmodus – übrigens inzwischen komfortabel bei der Farbwahl in Firefox Entwicklerkonsole eingebaut – war mir aufgefallen, dass auch im bisherigen Design der Kontrast teilweise nicht ausreichend war. Beispielsweise war die Linkfarbe zu hell und der weiße Text der Navigationsbuttons oben rechts auf einem zu hellen Hintergrund (was bei gleicher Kombination beim Blogtitel durch dessen Größe funktioniert). Wo es mir auffiel habe ich nachgebessert. Außer einer besseren Lesbarkeit der Seite sollten diese Änderungen aber nicht auffallen.

20 Jahre, so lange dürfte die erste LAN-Party her sein, die ich damals im Freundeskreis in der Kleinstadt gefeiert habe. Die Nullerjahre also und deswegen das "spät" im Titel: Es ist zwar eine Weile her, aber die frühen LANs dürften ganz andere Probleme gehabt haben. Unsere war eine Endzeit – Breitbandinternet kam damals sogar nach Deutschland und zu uns. Auf den ersten LANs gab es bei uns meiner Erinnerung nach gar kein Internet, auf den späteren wurde zwischendurch etwas heruntergeladen, etwa vier Jahre später verlagerte sich das gemeinsame Spielen völlig ins Internet. Selten in der gleichen großen Gruppe, aber wenn zusammengespielt wurde war es danach vom eigenen Zuhause aus, mit viel geringerem Aufwand. Aber auch mit etwas Verlust.

War das wirklich eine Periode von nur etwa 4 Jahren, von 2003 bis 2007? Dass mein erster eigener PC einen Athlon XP 2700+ hatte, der 2002 raus kam, spricht für 2003 als Beginn. Und es kann nicht viel länger gewesen sein: Es war in der Schulzeit, bevor ich wegen der Uni nach Darmstadt zog. Ganz exakt ist das aber nicht, es gab danach noch die eine oder andere LAN mit anderen Leuten. Und möglich, dass etwas vorher schonmal eine LAN mit dem vereinnahmten Familien-PC bestritten wurde. Aber 2003 bis 2007 müsste die Kernzeit gewesen sein.

Organisation geschleppter Monitore

An vier Orte erinnere ich mich: Das Haus von B., der Keller von D., zwei Wohnungen von mir. Mit einer Ausnahme fanden die LANs statt, wenn die Eltern am jeweiligen Ort nicht da waren. LANs waren aufsichtsfreie Zonen, wobei die Eltern gerade anfangs natürlich vorher gebraucht wurden, um das schwere Gerät zum jeweiligen Ort zu fahren (nicht immer, manchmal wurde alles geschleppt, manche von uns wohnten in Laufreichweite). Die PCs waren schwer, die Röhrenmonitore waren schwerer. Wir bauten also daheim PC und Monitor ab. Maus, Tastatur und Kopfhörer (der war aber beileibe nicht Standard, glaube ich) kam in den Rucksack, das Netzwerkkabel durfte nicht vergessen werden, die anderen Kabel auch nicht, die oft vergessene Mehrfachsteckdose war besser dabei, wer hatte packte noch einen Switch ein. Am Ende ging das recht routiniert. War aber natürlich der große Vorteil, wenn die LAN bei mir war, dann gab es für mich nichts zu schleppen, nichts zu vergessen.

Dann wurden wo immer möglich die Computer wieder aufgebaut. Küchentische, Schreibtische, Wohnzimmertische – sie alle wurden belegt. Nicht alle dieser Orte waren komfortabel. Wenn man bedenkt, wie riesig die Monitore waren und wieviel Platz Tastatur und Maus verbraucht wird auch klar, dass wir selten mehr als zehn gewesen sein können. Vielleicht außer bei B., das mehrstöckige Haus bot viel Platz. Jeder brauchte mindestens zwei Steckdosen, deswegen die Mehrfachsteckdosen, die mit einem Ausschalter waren Fallen und schalteten mehr als einmal versehentlich reihenweise PCs ab. Mit den Switches und Netzwerkkabeln wurden die PCs dann verbunden.

Das Verbinden klappte nicht immer. Natürlich hatten wir damals Windows. Die meisten Windows XP, aber M. nutzte lange Windows 2000, D. litt unter dem unbrauchbaren Windows ME. Aber selbst Rechner mit Windows XP sahen sich manchmal einfach nicht im Netzwerk. Die IP-Adresse musste manuell zugewiesen werden, wir wussten, dass die ersten drei Sektionen der IP-Adresse gleich sein muss und die letzte sich nicht doppeln darf. Aber Windows XP hatte auch noch Arbeitsgruppen, die da irgendwie reinspielten. Dazu kamen die Zugriffsrechte, die Windows Netzwerken zuwies. Das alles zu konfigurieren fraß Zeit, wurde aber mit den Jahren besser (durch SP1 und SP2?). Und dann mussten ja noch die Spiele starten, sich ihre Multiplayermodi im Netzwerk sehen. Mehrfach klappte das nicht, wurde der PC neu installiert (wie es bei uns hieß, wenn Windows neu installiert wurde).

Die Spiele

Wo kamen die Spiele überhaupt her? Es waren natürlich anfangs meist Schwarzkopien. Niemals hätten wir uns alle alle Spiele kaufen können, nicht, dass wir es gedurft hätten: Viele unserer Spiele waren ab 18. Oder gar indiziert, wie Command & Conquer: Generals. Unreal Tournament 99 und 2003, Warcraft 3, StarCraft, Counterstrike (meist in Version 1.5) waren andere Kandidaten, dazu kam mindestens einmal Diablo 2, das auf einer kleineren LAN tatsächlich alle besaßen. Deutschlands Zensurwahn traf uns bei dieser Auswahl also voll. Ich habe noch heute einen Hass auf Deutschlands immer noch tätige Zensoren, zeigt unsere Erfahrung doch wie unbegründet die Ängste der Ahnungslosen waren, zum Glück auch wie ineffektiv ihre Kontrollversuche.

Irgendjemand hatte diese Spiele auf der Platte, gab seinen Ordner frei, die Leute zogen den Installer und installierten dann das Spiel. Im Ordner war meist direkt ein Keygen oder Crack mit dabei, je nach Spiel. Manchmal war das Spiel auch von der letzten LAN noch auf der Platte. Eher selten, Festplatten waren klein (meine erste: 80GB).

Das waren außer Diablo 2 daher Spiele, die zumindest ich damals fast nie außerhalb von LANs spielte. UT hatte ich wohl mal via dem Solomodus gegen Bots geübt, bei WC3 den Großteil der Kampagne gespielt. Von CS spielte ich später die Steamversion gelegentlich im Internet, nachdem mir die via Half-Life 2 geschenkt wurde, aber nicht davor. Da war also keine große Erfahrung mit Multiplayer. Das war aber nicht bei allen so, so war J. durch Spielen im Internet richtig gut in StarCraft – so gut, dass durch Training von ihm ein Ausflug ins Battle.net später eben nicht in Niederlage endete. Aber natürlich war es ein Problem, dass man in diesen Spielen ohne Übung wenig Chance gegen erfahrene Spieler hatte. Gekontert wurde das durch Allianzen, sodass dann alle anderen sich spontan gegen den besten Spieler verbündeten. Das führte manchmal zu den besten Spielen, aber manchmal auch zu den frustigsten, gerade für den im Fadenkreuz stehenden. Keine einfache Balance, gerade später nicht, als einzelne Spieler immer besser wurden, andere stehenblieben (so wie B., der trotz Riesentalent später außerhalb LANs höchstens Minispiele spielte).

Command & Conquer: Generals spielten wir auf einer großen Wüstenkarte. Später sogar mit der Erweiterung. Jeder wählte frei seine Fraktion, ich hielt mich gerne an die terroristische GLA, die mit Selbstmordbombern und zusammengebastelten Fahrzeugen etwas untypischer war als China mit seinen regulären Panzern und die USA mit ihren High-Tech-Flugzeugen. Leere Plätze wurde durch KI aufgefüllt. Gab es viele KI-Spieler, wurde es zu einer Art Tower-Defence: Die KI schickte permanent neue Einheiten auf immergleichen Routen an Klippen vorbei, da oben mussten unbedingt Türme und Raketenwerfer stehen. Gebaute Superwaffen mussten vor Ablauf des Timers zerstört werden. Ob mit eigenen Superwaffen oder mit den Generalsfähigkeiten, die bei der GLA z.B. einen Trupp Bomber an einer Stelle der Karte erscheinen lassen konnte. Ohne die KI wurde das ganze etwas flexibler, wurden die Armeen geschickter eingesetzt und gekontert. Aber wir spielten wohl meist mit der KI.

Generals lief auf dieser großen Karte leider nie lange flüssig. Manchmal lag das an einzelnen schwachen Rechnern, flog dieser Spieler dann raus war das gut, weil so der Lag aufhörte. Aber nicht immer, später las ich, dass das Spiel selbst einfach nicht mit großen Einheitenmengen umgehen konnte. Das Verlangsamen des Spielablaufs war unvermeidlich. Desynchs beendeten so einige Partien, die technischen Probleme versauerten uns das Spiel irgendwann.

Warcraft 3 war da anders: Technisch hatte das keine Probleme. Aber WC3 machte einigen im normalen Modus keinen Spaß. Ich denke, dass es zu frustrierend war: Die Skillunterschiede machten zu viel aus. Ohne Taktiken und Wissen über die Stärken und Schwächen der Einheiten hatte man in diesem Spiel keine Chance gegen bessere Spieler, anders als bei Generals, wo einigeln und Masse produzieren immer zumindest eine Weile ging. Also wurden eher Funmaps gespielt: Oft Tower-Defences, auch ein bestimmter Vorgänger von Defence of the Ancients und Abwandlungen davon. Also Karten, die Fans des Spiels gebaut hatten und die das Spiel teils komplett umkrempelten.

Das wiederum machte mir keinen Spaß, mir waren diese Maps oft zu unausgegoren. Gerade unserer DOTA-Variante nahm ich es übel, dass mein Baumheld kein Land sah. Aber auch die Tower-Defences arteten oft aus, sie dauerten lange und waren schlicht nicht immer gut.

Dann lieber ein Shooter wie Unreal Tournament und Counter Strike. Da erinnere ich mich kaum an Details. Sie wurden eben gespielt, auf verschiedenen Karten und Modi mit gemischten Teams. Skillunterschiede schlugen bei diesen Spielen natürlich voll durch, aber in langen Nächten hatten viele Spieler gute und schlechte Phasen. Wobei M. fast nie zu schlagen war. Zu lange konnte man diese Spiele nicht spielen, dafür waren sie zu anstrengend. CS 1.5 ist in diesem Video zu sehen, später wurde auch von uns 1.6 gespielt:

Bei StarCraft erinnere ich mich nicht an Funmaps. Sondern es wurden die regulären Multiplayerkarten gespielt. J. gewann, die Frage war nur wie. Ich erinnere mich an eines der letzten Spiele, als wir anderen endlich gut genug geworden waren ihn beinahe zu schlagen, bis er dann doch unsichtbare Einheiten erreichte und wir gegen die nicht ankamen, die sie enthüllenden Spezialeinheiten nicht parat hatten, er mühsam die große Welle an einströmenden Einheiten zerstörte und doch gewann. Da waren alle stolz auf ihre Leistung. Sowas war ein Erlebnis, ein Höhepunkt der Nacht.

Diablo 2 spielte ich nur einmal mit und habe es bis heute als negative Erfahrung im Kopf. So schnell wie möglich aufs Loot klicken, ohne Lesen einer einzelnen Zeile durch die Kampagne hetzen. Ich mochte D2 und hatte es vorher alleine gespielt, da macht es Spaß, mit einzelnen Leuten war es auch im Multiplayer okay, als LAN-Spiel fand ich es ungeeignet. Es bot einem nichts, was man nicht auch alleine hätte haben können, im Gegenteil, es wurde schlechter. Zeitverschwendung. Bis heute spiele ich Hack'n Slays nicht in Gruppen.

Drumherum

Jugendliche in einer südhessischen Kleinstadt ohne Aufsicht – genau, wir hatten Alkohol und Zigaretten. Die Gruppe hatte es ansonsten nicht mit Drogen, nichtmal Gras. Es waren gute Lerngelegenheiten: Dass etwas Alkohol okay ist und manchen Spielen sogar einen kleinen Schub gibt, aber ansonsten dem Spielen schadet. Die LANs waren meist mehrtägig, sonst lohnte sich der Aufwand nicht, gingen also die Nacht durch und am nächsten Tag weiter, auch kein Argument fürs Trinken. Mehr noch: Viel besser zumindest ein bisschen zu schlafen, von 4 bis Sonnenaufgang, und dann den nächsten Tag halbwegs fit zu sein, als durchzuzocken und dann am nächsten Tag einfach nur kaputt zu sein.

Manche LANs waren jedoch echte Feiern. Dann waren Leute außerhalb des Kerns zusätzlich da, tranken und hörten Musik, waren die Freundinnen dabei und spielten manchmal sogar mit. Andere LANs waren nur wir, fokussiert ganz aufs gemeinsame Spielen.

Aber es waren nicht nur Spiele: Da wir sowieso für die Image-Dateien Ordner freigeben mussten, konnte man auch direkt Musik und Filme mit freigeben. Und von den anderen auf die eigene Platte kopieren. Bei uns war das weniger ein Fokus, als es auf anderen LANs gewesen sein soll. Vielleicht gerade, weil DSL für uns bald schon existierte?

Man sollte meinen, durch diese Abende hätten wir über PC-Technik gelernt, aber dem war nicht so. Es schien nicht wichtig welcher Prozessor in den Maschinen steckte, welche Grafikkarte, wir kannten höchstens die eigene Hardware. Und die konnte meines Wissens keiner von uns ohne weiteres ändern, dafür war neue Hardware viel zu teuer. Spiele funktionierten oder sie funktionierten eben nicht, entsprechend wurde gewählt. Was gelernt wurde war, was für die Situation vor Ort gebraucht wurde: Das Konfigurieren von Windows, das Anbringen von Cracks bei den Spielen. Plus die Spiele selbst – und auch wie wir uns auf Spiele einigen konnten, das war wohl am wichtigsten (kleinste gemeinsame Nenner, oder das eine Spiel und danach das andere, da jeder etwas anderes lieber spielte, manche Spiele von einzelnen ganz geblockt wurden).

Was mir technisch hängenblieb: Dass Kabeltrommeln ausgerollt werden müssen. Als die im Keller von D. überhitzte zerfetzte es einen Monitor, wenn ich mich richtig erinnere meinen. Kaufte ich danach einen neuen? Und das war dann der, der bis zum Umzug nach Siegen hielt? Krieg ich nicht mehr zusammen.

Fast vergessen hatte ich, dass ich einen Pullover speziell diesen LANs gewidmet hatte. Er kam mit, weil es nachts kalt werden konnte. Ein schwarzer Adidas-Pulli, ich habe ihn heute noch. Wie Verpflegung gelöst wurde ist weg – Tiefkühlpizzas, Chips und Süßigkeiten? Kam ich damals schon drauf, dass Bananen für solche Situationen praktisch sind?

Ich habe andere einzelne Bilder im Kopf, von denen ich jetzt gerne Fotos haben würde. Von zugestellten Esstischen, die unter der Last von 100 Kilo an Monitoren bestimmt ächzen mussten. Von Kabelsträngen unterm Tisch, vom die Treppe hochgehenden Netzwerkkabel, von zigfach in Reihe geschalteten Mehrfachsteckdosen – ein Glück, dass PCs damals weniger Strom fraßen. Und klar, von den Freunden, wie sie damals aussahen. Aber es gibt keine Bilder davon, die Telefone hatten keine oder nur unbrauchbare Kameras. Das erste iPhone kam direkt danach, 2007, bis die Technik in Androidtelefonen uns erreichte würde nochmal Zeit vergehen. Und wir hätten damals auch gar keine Fotos machen wollen, dafür war es zu deutlich unser eigener, selbstkontrollierter Raum. Da passten keine Beweisfotos.

Anlass für diesen Artikel war Memories from old LAN parties, was ich nicht lesen wollte bevor meine eigenen Erinnerungen nicht niedergeschrieben waren.

LANs wie die unseren waren ein Phänomen ihrer Zeit. Die Technik musste weit genug sein, um es einfach zu machen und Spiele leicht verfügbar zu haben, sonst wären wir gescheitert. Aber das Internet durfte noch nicht verbreitet genug sein, sonst hätte es keinen Sinn gemacht die PCs und Röhrenmonitore durch die Gegend zu schleppen. Und wir selbst mussten genau unser Alter haben, sonst wären wir zu jung oder zu alt gewesen um die Chance zu nutzen (mit ein bisschen Spiel nach vorne, natürlich hatte es schon vor uns LANs gegeben). Außerdem brauchte es eben diesen Freundeskreis, in dem alle einen PC hatten und spielten.

Ich würde mich gerne an mehr Details erinnern: Wie kamen wir darauf, wer trieb diese Treffen? War es, weil LANs einen Boom hatten und wir es über die Medien aufschnappten? Oder weil wir die Idee von älteren Freunden und Geschwistern der anderen übernahmen? Oder war es einfach, weil Spiele diesen Netzwerk-Multiplayer hatten und wir ihn nutzen wollten, wofür sich dann durch die sturmfreie Bude eine Chance bot? Das werde ich wohl nicht mehr rausfinden.

Aber auch ohne alle Details: Diese Abende und Nächte sind mir wichtige und positive Erinnerungen.

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.

Dass ich kürzlich über Hardwareupgrademöglichkeiten schrieb lag natürlich an meinen eigenen Upgradeplänen. Mein PC war angestaubt, dass die Radeon RX 6600 unter 250€ fiel hatte ich mir als Signal für ein Upgrade gesetzt. Zwar reichte mein altes System noch für alles wichtige, doch ich wollte moderne Spiele wie Cyberpunk auf ordentlichen Einstellungen spielen können.

Das alte System

Vorher hatte ich im PC einen 2019 gebraucht gekauften Intel Core i5-5675C, zusammen mit einer Radeon RX 570 (4GB). Der Prozessor ist etwas besonderes gewesen, der wenig verkaufte Broadwell-Chip hat einen L4-Cache – ähnlich wie jetzt der Ryzen 7 5800X3D – und eine besonders starke Grafikeinheit, die Intel ansonsten nur in Laptops verbaute. Der Cache machte den Prozessor in manchen Spielen besonders stark, als ich zwischendurch gar keine Grafikkarte hatte war die Grafikeinheit Gold wert. Doch da der i5 nichtmal Hyperthreading hat erreichte der Vierkerner nun seine Grenze.

Die Radeon RX 570 war nichts besonderes. Bestechend war damals nur ihr absurd gutes Preis-Leistungs-Verhältnis im Vergleich zu den Nvidia-Karten, die unter Linux aber sowieso keine Option gewesen wären. Auch bei ihr war für moderne AAA-Spiele die Leistung inzwischen etwas gering.

Der alte Rechner hatte ordentliche 24GB Ram, da aber DDR3 konnte das nicht weiterbenutzt werden. Dafür sollte Gehäuse, Netzteil, SSDs und Backupfestplatte erhalten bleiben, ebenso wie der Corsair H90 als Prozessorkühler – hatte ich das alles doch gerade erst dank fan2go leise bekommen.

Die neue Hardware

Das Upgrade lief in zwei Phasen, um zu schauen ob der Prozessor nicht doch ausreichen würde.

Also fing ich mit der Grafikkarte an. Es wurde eine Radeon RX 6600, die ASRock Challenger D. Sie kostete 229€ und war damit die günstigste der verfügbaren 6600er. Ich hatte von dem Modell wenig gelesen, aber dass der Lüfter sich im Leerlauf abschalten würde beruhigte mich. Dazu kamen positive Nutzerreviews und eine ebenfalls positive Besprechung bei OCinside.

Die Intel Arc A750 wäre die Alternative gewesen. Aber dann hätte ich auf jeden Fall das Prozessorupgrade gebraucht. Und ich fand dieses Review, demnach selbst unter einem aktuellen Kernel die Intel-Karten unter Linux deutlich hinter den AMD-Optionen liegen. Das ist unter Windows anders, aber ich spiele ausschließlich unter Linux.

Die 6600 würde mehr als doppelt so schnell wie meine alte Karte sein, das war vorab klar (die Bewertung im Benchmark entspricht nicht direkt dem gesehenen FPS-Unterschied):

Tatsächlich lief schon mit dem Grafikkartenupgrade dann auch Cyberpunk 2077 auf hohen Einstellungen und war spielbar. Aber die sehr hohe Prozessorauslastung und das generell niedrige FPS-Niveau machte klar, dass ein Prozessorupgrade doch sinnvoll wäre.

Da recherchierte ich sogar nochmal, blieb aber letzten Endes bei meiner eigenen momentanen Standardempfehlung: Ein Ryzen 5 5600 auf einem B450-Board. Mein Gehäuse ist mATX, also war bei den Mainboards die Auswahl begrenzt; Ich griff zum günstigsten mit vier Ramslots, dem MSI B450M PRO-VDH Max. Das kostete 72€. Der Prozessor kostete 119€. Dazu fehlte noch der Arbeitsspeicher, das wurde das günstige G.Skill Aegis DDR4-3000 32GB Kit für 58€.
16GB hätten zum Spielen gereicht, aber als Entwickler reichte mir das schon mehrfach nicht aus und ich wollte mich bei der Speichermenge nicht verschlechtern.

Um meinen Corsair H90 weiterverwenden zu können hatte ich mir vorab eine AM4-Halterung gekauft. Die kostete nur 8€.

Als die gesamte Hardware dann da war klappte alles. Das B450-Board brauchte wie erwartet kein BIOS-Update, um mit dem Ryzen 5 5600 zu starten – dafür ist der Prozessor viel zu lange draußen, die Boards im Handel sind alle bereits aktualisiert, aber die minimale Gefahr hatte mich doch nervös gemacht. Der XMP-Modus des Arbeittsspeichers griff direkt. Nur rBar konnte ich nicht aktivieren, weil dafür Secure-Boot und der UEFI-Bootmodus gebraucht würde, womit meine alte Void-Installation nicht starten wollte. Gut, dass ich nicht doch die Arc-Karte gekauft hatte.

In Cyberpunk war der Prozessor dann ein großes Upgrade. Die Radeon RX 6600 hatte im eingebauten Benchmark und niedrigen Einstellungen mit dem i5-5675C vorher 43 FPS geliefert, mit dem Ryzen-Prozessor wurden es 74 – und da war VSYNC an.

Im Spiel verschwanden einige Ruckler bei Kameraschwenks und mit meinen optimierten, generell hohen Einstellungen liegen die FPS je nach Szene zwischen 60 und 75 FPS. Davor waren die durchaus mal auf 30 gerutscht.

Das Upgrade lief gut und ich kann es empfehlen, die bessere Performance in Spielen ist schon angenehm. Mich freut es besonders, dass sich an der Lautstärke des Systems nichts negativ verändert hat – die Grafikkarte ist unter Last wohl sogar leiser als die auch schon dezente vorherige. Außerhalb von Spielen bemerkte ich bisher aber keinen Geschwindigkeitsgewinn, dafür war der i5-5675C wohl zu stark.

Mein System ist damit auf das Niveau von 2022 gerutscht. Das dürfte jetzt wieder für ein paar Jahre reichen.

Ich schrieb drüben bei Gamersglobal über Hardwareupgrades, anlässlich meiner eigenen neuen Grafikkarte und den allgemein gesunkenen Preisen. Beginnt so:

Der Hardwaremarkt war die letzten Jahre furchtbar, doch mittlerweile gibt es endlich wieder gute günstige Optionen, sowohl für Prozessoren als auch für Grafikkarten

Wie auch ich werden viele von euch die letzten Jahre immer mal wieder über Hardwareupgrades nachgedacht haben. Gab es doch zu viele gute Spiele, die einen starken Prozessor und eine moderne Grafikkarte benötigen; man denke nur an Cyberpunk 2077. Aber wer nicht viel mehr Geld als historisch üblich für eine Grafikkarte hinlegen wollte, hat gewartet. Auch beim Prozessor-Upgrade gab es gute Gründe, geduldig zu sein. In diesem Artikel möchte ich zeigen: Wer gerade ein bisschen Geld über hat, für den kann das Warten jetzt enden. Es ist ein sehr guter Upgrade-Zeitpunkt.

Ü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.

Wenn eine Sache den Spaß an Nintendos Switch vermiesen kann, dann sind es die Joycons. Die sind teuer genug um sie nicht einfach ersetzen zu wollen, gehen aber schnell kaputt und fangen dann an zu driften. Das heißt, selbst ohne Druck geht die Spielfigur in eine Richtung, was viele Spiele unmöglich unangenehm macht. Würden neue Joycons wenigstens dauerhaft das Problem lösen wäre das halbwegs verzeihlich, sind das doch noch die Originalgeräte von kurz nach Release der Konsole… aber das tun sie nicht. Weil es an der genutzten Technik liegt (unweigerlich die Kalibrierung verlierende Widerstände) ist das Kaputtgehen immer nur eine Frage der Zeit.

Mit den Hall-Joysticks von GuliKit soll das anders sein. Die benutzen intern Magnete, was niemals driften soll. Der Hersteller verspricht zudem verbesserte Akkulaufzeiten. Theoretisch kann die Technik auch Deadzones unnötig machen, las ich, ich weiß nicht ob das hier geschieht. Die Lösung ist also ein Einbaukit, man ersetzt die defekten Joysticks der Originaljoycons mit diesen Alternativen.

Der (beim Draufschauen) linke Joycon der Switchbesitzerin an meiner Seite war am Driften, also hatte ich fast direkt bei Veröffentlichung das Ersatzkit bei AliExpress bestellt. Die Lieferung dauerte nicht lange (dieser Artikel erscheint mit deutlicher Verspätung).

Paketinhalt

Das hier kam an:

Ein Paket mit den beiden Ersatz-Joycon-Joysticks. Dazu einige Schrauben, zwei Schraubendreher, ein Plastik-Pick zum Öffnen und ein Gummi-Überzieher. Von dem Zubehör wäre nichts unbedingt nötig gewesen, aber gerade die Schraubendreher können praktisch sein wenn keine eigenen im Haus sind, die Schrauben wenn bei der Montage die Originalschrauben verlorengehen. So ein Plastikdreieck zum Öffnen fehlte sogar noch in meiner Werkzeugsammlung und die Gummi-Überzieher sind hübsch griffig.

Es wirkt schon nett, wenn statt einem notdürftig verpackten Einzelteil solch ein Sammlung ankommt. Auch wenn es verschwenderisch ist. Macht die Idee der umweltfreundlicheren Reparatur statt Neukauf etwas kaputt. Aber solange neue Joycons definitiv kaputtgehen würden, ist das Gulikit-Kit auf jeden Fall die bessere Alternative.

Aber eigentlich geht es ja um die unauffällig aussehenden Joysticks. Die mussten jetzt eingebaut werden.

Einbau

Der Einbau war nicht sehr schwierig, aber auch nicht supereinfach. Die Joycons haben Schrauben, die muss man lösen. Danach gehen sie auf, wobei die Schultertaste oben rausfallen kann. Das eigentliche Problem sind die Flachbandkabel, die einzelne Komponenten der Joycons verbinden. Die sind teils schwer zu lösen, friemelig wieder zu verbinden und sie können nur zu leicht reißen. Ich war froh, dass die Switchbesitzerin das alles selbst machen wollte.

Ich empfehle das Folgen eines Videos, z.B. diesem:

Bei uns sah die Montage in etwa so aus:

Dabei riss am Ende leider ein Kabel, das aber schon vorher einen Wackler hatte. Es wäre reparierbar, bis dahin kann der Joycon-Controller nicht mehr einzeln benutzt werden. Kein Riesenverlust.

Fazit: Funktioniert

Tatsächlich ist der neue Joystick eine riesige Verbesserung. Ich habe danach direkt eine Runde Fast RMX gespielt und wirklich reihenweise neue Bestzeiten gefahren. Was teilweise an der gewonnenen Erfahrung in Versus-Runden gelegen haben mag, doch die Steuerung des Fahrzeugs war einfach deutlich besser als zuvor. Aber ist ja auch klar, wenn man mit direkt vor der Reparatur vergleicht, wenn das Ding nicht mehr die ganze Zeit von alleine in die Wand fahren will. Doch hatte ich die vorherigen Rekorde aufgestellt als die Joycons recht neu waren und noch keinen wahrnehmbaren Drift hatten. Für mich ein Hinweis, dass die Gulikit-Joysticks besser funktionieren als die Originalteile, super belastbar ist diese Einschätzung aber nicht (dafür spielte ich mit beiden Varianten zu wenig).

Seitdem hat die Switchbesitzerin einiges selbst gespielt und ebenfalls keine Klage gehabt. Für sie funktioniert der Joycon jetzt eben, driftlos.

Ob wirklich der Energieverbrauchs des Joycons besser ist kann ich nicht messen, ich kann auch die Langzeithaltbarkeit nicht bewerten. Dass die Technik niemals driften solle, das stimmt wohl. Aber es kann ja sonstwas kaputt gehen. Und hätte ich es gemerkt, wenn das einfach nur ein neuer gewöhnlicher Joycon-Joystick gewesen wäre? Nein. Aber Gulikits andere Produkte mit dieser Technik wurden publikumswirksam besprochen, für solche Zweifel gibt es keinen Grund.

Ich finde es toll, endlich eine dauerhafte Lösung für das Joycon-Driftproblem zu haben.

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.

Mein Hauptproblem mit dem Kobo Glo HD – gekauft vor einigen Jahren nach dem Ableben des Kobo Touch – ist, dass er nicht zuverlässig ist. Er war es nie. Das fängt damit an, dass ich ihn desöfteren aufladen musste als ich eigentlich einen vollen Akku erwartete. Es kann sein, dass das einfach ein Konzeptproblem ist, der Leser sich nicht komplett abschaltet damit ein Öffnen der Hülle ihn aktivieren kann und er dabei mehr verbraucht als ich erwartete, aber so oder so überraschte mich das mehrmals negativ.

Dann das Wlan: Eben verband er sich, vorher ging das mehrmals nicht. Aber es ist auch nicht so, dass die Wlan-Verbindung irgendwas brächte – nur ein Netzwerkfehler begrüßt mich bei der Entdeckenfunktion, genauso funktioniert die Synchronisation (die auch Geräteupdates finden sollte) einfach nicht. Das ist auch deswegen bemerkenswert, weil ich das Gerät vor nicht allzulanger Zeit sich habe updaten lassen. Im August war das wohl (da war laut Anzeige die letzte Synchronisation), völlig veraltet ist die Software also nicht. Und ja, der Leser wird nicht mehr verkauft, aber dass die Serverinfrastruktur abgeschaltet wurde lese ich nirgends. Wäre auch überraschend, dürfte die Anbindung an den Büchershop doch die Haupteinnahmequelle Rakutens Kobo-Sparte sein.

Gut, so schlimm ist dieser Fehler für mich nicht, da ich nie besonders am Kobo-Shop mit seinen DRM-verseuchten Büchern interessiert war. Den Kobo habe ich ja gerade deswegen gewählt, weil er (wie schon sein Vorgänger) sich wie ein USB-Stick mit dem PC verbinden kann und dann durch Rüberkopieren regulärer .epubs einfach zu befüllen ist. Aber immer wieder funktioniert das nicht. Manchmal kann er gar nicht eingehangen werden, andermal erscheint nach dem Abhängen und nach dem Importvorgang das herüberkopierte Buch einfach nicht in der Oberfläche. Stattdessen zeigt mir dmesg auf meinem Rechner solche Fehlermeldungen:

[  178.944701] device offline error, dev sdc, sector 527 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[  178.944707] Buffer I/O error on dev sdc, logical block 527, async page read
[  178.945458] udevd[13079]: inotify_add_watch(7, /dev/sdc, 10) failed: No such file or directory
[  178.960589] sd 4:0:0:0: [sdc] Synchronizing SCSI cache
[  178.960620] sd 4:0:0:0: [sdc] Synchronize Cache(10) failed: Result: hostbyte=0x01 driverbyte=DRIVER_OK
[  180.858826] usb usb3-port2: attempt power cycle
[  182.705765] usb usb3-port2: unable to enumerate USB device

Die sind höchst bedenklich. Nach einigen Wiederholungen funktionierte der Büchertransfer bisher immer doch, aber komfortabel ist anders. Das Befüllen über eine Netzwerkfreigabe scheint als Alternative nicht zu existieren (selbst wenn das Wlan funktionieren würde). Ich habe nie wirklich verstanden wie die Kobo-Softwarewelt eigentlich funktionieren soll (gibt es da einen Online-Account, dem ich woanders gekaufte Bücher auch hinzufügen könnte?), musste das über die USB­-Lauf­werks­funk­tion aber auch nicht. Wenn die aber nun nicht mehr ordentlich funktioniert wird die Kombination dieser beider Fakten zu einem Problem.

Wenn der erste Kobo komplett stabil gewesen wäre würde ich einfach an ein defektes Gerät glauben. Aber auch der Vorgänger hatte ähnliche Probleme, wollte sich manchmal nicht mit dem PC verbinden, brauchte gelegentlich sogar ein Komplett-Reset. Stabile Hardware sind meine beiden Kobos einfach nie gewesen.

Das finde ich derzeit ein bisschen trauriger als sonst, weil ich gerade viel Spaß damit hatte eine Science-Fiction-Buchreihe durchzulesen und dabei bemerkt habe, dass es mittlerweile DRM-freie .epubs im regulären Onlinehandel gibt. Nachdem die Humblebundles mich vergrault haben wäre anderswo Bücher zu kaufen daher vielleicht eine Option gewesen. Zudem bietet die lokale Bücherei auch ebooks zum Ausleihen an und ihre neue Webseite sieht sogar halbwegs benutzbar aus. Aber ob ich das mit einem so unzuverlässigem Gerät machen will weiß ich nicht, wahrscheinlich höchstens bei der nächsten längeren Reise.

Ansonsten ist der Kobo Glo HD übrigens bisher kein schlechtes Gerät gewesen. Ich mag die eingebaute Hintergrundbeleuchtung und das Gerät ist zwar nicht schnell, aber beim Umblättern schnell genug. Beim Verkleinern und Vergrößern von Text ist er unangenehm langsam, aber das macht man ja pro Buch meist nur einmal. Keinen Knopf zum Umblättern zu haben hat mich schon beim ersten Kobo nicht gestört. Texte sehen auf dem Bildschirm gut aus, die mitgelieferten Fonts sind hübsch. Ein ordentliches Wörterbuch fehlte allerdings, das eingebaute hat mir nie helfen können, aber gut, meist hat man ja doch ein Telefon mit Suchmaschine zur Hand.
Insgesamt habe ich mit diesem Leser über die Jahre einige Bücher gelesen, ein kompletter Fehlkauf war er nicht. Aber wenn er ganz kaputt geht wird angesichts der oben beschriebenen Probleme der Nachfolger nur bei völliger Alternativlosigkeit wieder ein Kobo.

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.