Technikzeugs - 61

LineageOS 21 ist raus und bringt Android 14 auf viele Geräte. Darunter ist auch das alte LG G5. Meine Übersichtsseite sustaphones ist bereits aktualisiert.

Zu Jahresbeginn hatte ich das Lineage-Projekt noch kritisiert, aber auch geschrieben:

Oder wer weiß, vielleicht überrascht mich das Projekt nochmal und unterstützt nicht nur das G5 weiter, sondern geht auch ein paar der identifizierten Projektprobleme an.

Und tatsächlich wird das LG G5 ganz offiziell weiter unterstützt. Was kein Unfall ist, sondern die breite Verfügbarkeit der neuen Version laut der Releasebeschreibung an der besseren technischen Situation liegt, den Vereinfachungen bei Lineage und Android selbst. Gleichzeitig habe ich diesen Commit entdeckt, demnach ist Sig­na­ture-Spoo­fing aktiviert und damit wenigstens einer meiner Kritikpunkte an der Projektaufstellung entschärft.

Das Update auf LineageOS 21 von LineageOS 20 war problemlos. Es gingen keine Daten verloren und es gab auch keine Probleme zu umschiffen. Die Upgrade-Anleitung trifft zu, es ist nur der Entwicklungsmodus zu aktivieren, das Recovery-System in der neuesten Version zu installieren, danach da reinzubooten und mit dem Side­load-Modus das aktuelle Image aufzuspielen. Nichtmal ein Cache musste gelöscht werden.

LineageOS 21 bzw Android 14 selbst fühlt sich nur minimal verändert an. Angenehm ist, dass das in LineageOS 20 erst spät stabilisierte Akkuladelimit weiterhin einwandfrei zu funktionieren scheint. Da hatte ich Probleme erwartet. Anrufe funktionieren, die Kamera schießt Fotos, die WLAN-Verbindung war bisher stabil. Tatsächlich scheint meinem ersten Eindruck nach die Geräteleistung sogar verbessert worden zu sein, Webseiten laden etwas schneller – aber das mag Einbildung sein. Keine Einbildung ist, dass die von Lineage mitgelieferten Anwendungen überarbeitet wurden. Gerade die Fotogalerie war da auffällig, deren Änderungen mit der stärkeren Unterteilung in Zeitabschnitte gefällt mir. Aber auch einige andere Programme sehen zumindest anders aus, integrieren sich via Material You besser in die wählbaren Systemfarben. Und sogar einer der letzten mir bekannten Bugs scheint gelöst worden zu sein, nämlich dass sich der Musikspieler beim ersten Versuch in den Hintergrund zu schalten verschluckte und die Musik abbrach (beim zweiten mal ging es dann). Das ging jetzt mehrfach direkt. Nicht schlecht!

Bei sustaphones steht das LG G5 als eines der neueren Telefone mit auswechselbarem Akku nun auch wieder ziemlich weit oben – da ist aber zu beachten, dass der Bootloader seit LGs Abschaltung der Infrastruktur nicht mehr entsperrt werden kann, daher ist es für die meisten keine echte Option. Und es ist mittlerweile eigentlich auch zu alt, kommt entsprechend an die Grenzen von Leistungsfähigkeit und Hardwarehaltbarkeit. Gleiches dürfte für das verwandte LG V20 gelten. Der Griff sollte derzeit wohl eher zum teuren Shift6MQ gehen (das ich gerne mal testen würde), oder wenn man anders als ich den fehlenden Kopfhöreranschluss verzeiht zum Fairphone 4 oder 5 (dessen Unterstützung für Android 14 dürfte folgen). Eigentlich neige ich aber zum weiteren Überbrücken mit Altgeräten, bis hoffentlich bald die EU-Regulierungen greifen und neue Telefone wieder auswechselbare Akkus bekommen. Und wer schon ein entsperrtes G5 hat bekommt das mit dem neuen Android nun vll etwas komfortabler hin.

Um alte PHP-Versionen auf moderne Li­nux-Dist­ri­bu­tion­en zu bekommen kann man phpbrew oder phpenv benutzen. Ich entschied mich für letzteres, weil brew mich glauben ließ, MacOS sei dort die Zielumgebung. Damit stand ich aber vor einem Problem, denn zum Bau des gebrauchten Apache-Mo­duls (mod_php) steht in der Readme derzeit nur das hier:

Alternatively, you may still use the Apache php module by configuring php-build to build the libphp.so apache extension (directions to follow). libphp.so can then be found by apache under the ~/.phpenv/versions/$VERSION/libexec folder. This file can be used for Apache's LoadModule php5_module directive and requires Apache to restart when changed.

directions to follow folgten nie, auch bei phpbuild fand sich nichts, außer Fehlerberichten. Aber es geht doch, nämlich so:

PHP_BUILD_APXS=/usr/bin/apxs PKG_CONFIG_PATH=$HOME/lib/openssl/lib/pkgconfig/ PHP_BUILD_CONFIGURE_OPTS="--with-icu-dir=/usr/local/icu-60 --with-openssl-dir=$HOME/lib/openssl/bin --with-apxs2" phpenv install 5.6.40

Dieser Befehl baut die letzte PHP-5-Ver­sion, PHP 5.6.40, mit dem Modul für Apache. Man beachte die Zusätze: Weil die aktuelle Version von OpenSSL inkompatibel ist musste das vorher kompiliert werden, siehe hier, und weil die aktuelle Version von icu inkompatibel ist musste noch dazu das kompiliert werden, siehe hier. Bei letzterem hatte ich mir danach auch manuell einen Symlink angelegt, sodass mein Ubuntu 23.10 die .so finden konnte:

sudo ln -s /usr/local/icu-60/lib/libicudata.so.60 /usr/local/lib/

Der obige php­env-Be­fehl packt das PHP-Modul leider nicht in den lib­exec-Ord­ner, sondern bricht vorher mit einem Fehler ab. Das war aber wohl der letzte Schritt, das Modul war komplett funktionsfähig. Es musste nur noch in der /etc/apache2/apache2.conf verlinkt und aktiviert werden, mit diesen Zeilen am Dateiende:

# Ersetze USER mit deinem Nutzernamen
LoadModule php5_module /home/USER/.phpenv/versions/5.6.40/usr/lib/apache2/modules/libphp5.so
AddType application/x-httpd-php .php

Und nicht vergessen die .htaccess für den Zielordner zu aktivieren, in der /etc/apache2/sites-enabled/000-default.conf:

<VirtualHost *:80>
    …
    <Directory "/var/www/html">
        AllowOverride All
    </Directory>
</VirtualHost>

Damit das Modul mit Apache funktionierte musste ich dann auch noch den Ausführungsmodus von diesem ändern, das war:

sudo a2dismod mpm_event
sudo a2enmod mpm_prefork

Da führen aber im Zweifel die Fehlermeldungen durch.

Das alles hat zwar funktioniert, aber jetzt am Ende zweifele ich, ob das oft eine gute Idee wäre. In meinem Fall machte so PHP 5 auf mein System zu bringen vieles einfacher, denn ich brauchte eine Kombination von dem alten PHP mit neuer Software und Datenbank für ein zweites System. Aber es wäre wohl generell geschickter, die kombinierte PHP-5/Apache­um­ge­bung in ein Dockerimage zu packen. Auf den ersten Blick sieht da dieses Repo sehr brauchbar aus, dessen Dockerfile Apache mit PHP 5 auf Debian stretch aufsetzt. Da dann das eigene PHP-Projekt hineinladen und man könnte sich das manuelle Kompilieren wahrscheinlich sparen. Nächstes mal wäre das mein Ansatz.

LineageOS ist die große alternative Androiddistribution, die übliche Wahl, will man ein Smartphone von Googles Diensten befreien oder einem nicht mehr unterstütztem Gerät neues Leben einhauchen. Das Line­age-Pro­jekt unterstützt eine fantastisch große Auswahl an Telefonen (und ist daher prominent auf meinem nachhaltigem Telefonfinder sustaphones vertreten) und bietet für sie ein schlankes Android mit einigen nützlichen Kernprogrammen. Ich selbst nutze LineageOS seit Jahren für mein privates Telefon und hatte sogar mit dem Spark+ von Wileyfox die kommerziellen Bemühungen des Vorgängerprojekts unterstützt. Und als Anwendungsentwickler bemühte ich mich, unsere Anwendungen auf LineageOS lauffähig zu halten und testete entsprechend auch damit.

Aber gerade in 2023 haben sich bei mir Zweifel breitgemacht, ob LineageOS für mich – und teilweise, für alle – die richtige Wahl ist. Daher habe ich schon dieses Jahr nach Alternativen geschaut und glaube, dass sich das 2024 verstärken wird.

Probleme mit Bankingapps und mehr

Tatsächlich habe ich schon ein Gerät umgestellt: Mein Zweittelefon. Das dient eigentlich als Backup und bekam mit dem Wechsel zu /e/ (vom Murenaprojekt) die Zusatzaufgabe, Anwendungen für Banken und ähnliches abzudecken. Auch deswegen fehlten die in meiner Appliste letzte Woche, neben Sicherheitsbedenken.

Auf Lineage funktionieren diese Apps nicht, nicht ohne weiteren Aufwand zumindest. Ich bin genau einer einzigen Bankapp begegnet, bei der das anders war: Consorsbank SecurePlus funktionierte den negativen Bewertungen zum Trotz direkt hervorragend. Alle anderen von mir getesteten aber kommen ohne Google-Dienste nicht zurecht.

Die aber liefert LineageOS nicht. Man kann sie manuell mitinstallieren, hängt dann aber wieder am Haken von Google, wofür ein Android wie LineageOS doch genau die Alternative ist. Doch scheinbar sieht sich LineageOS selbst nicht so: Da es konsequent Begrenzungen von Android ohne Google nicht ausbügelt scheint der beabsichtigte Nutzungsmodus der mit den Googlediensten zu sein. Dass dem so ist, wird aber nicht kommuniziert.

Das zweite Beispiel dafür ist die Lokalisierungsfunktion. LineageOS kann natürlich GPS – aber GPS alleine ist eine Qual und funktionierte in der Praxis bei mir noch nie. Googles Android fängt das mit einer Funkzellenlokalisierung auf, mit der erstmal eine etwas ungenauere Position bereitsteht, GPS liefert dann nach einer Weile die Feinpositionierung. Doch LineageOS baut dieses Verhalten nicht nach.

Doch kann man das dem Projekt negativ zurechnen, liegt der Hund nicht bei Android selbst begraben? Andere Projekte zeigen: Das ginge durchaus besser. So gibt es mit microG eine Alternative zu den Googlediensten. Bei /e/ ist die vorinstalliert, deswegen funktionieren dort alle von mir getesteten Bankenanwendungen. Und für die Funkzellenlokalisierung gibt es UnifiedNlp mit einer Datensammlung von Mozilla im Hintergrund. Lineage müsste das nur einbauen.

Aber nicht nur macht LineageOS das nicht: Es macht es auf vielen Ebenen schwieriger, sowas selbst nachzuholen. Zum Beispiel, indem Sig­na­tur-Spoo­fing nicht unterstützt wird, was unter anderem zur Anfangszeit von Corona für die mic­roG-Imp­le­men­tier­ung der Bluetooth-API gebraucht wurde. Und indem keinerlei Lösung für Root bereitgestellt wird. So war es mir deswegen mittlerweile unmöglich, den Rootrechte benötigenden Advanced Charging Controller richtig zu aktivieren. Früher gab es da mit Magisk eine Lösung, die entwickelte sich aber zwischendurch ebenfalls unbrauchbar und hätte nach jedem Lineage-Update eine Neuinstallation gebraucht. Für letzteres kann Lineage erstmal nichts, aber Lösungen stellt das Projekt eben auch – laut Eigenaussage gar absichtlich – nicht bereit.

LineageOS macht sich ungezwungen unsympathisch

So sitzt LineageOS schon mit seiner Ausrichtung zwischen allen Stühlen. Nur mit Googlediensten zu funktionieren spricht nur Massennutzer an, die aber installieren eher sowieso kein alternatives Android. Wenn ich aber also einen Fork mit microG benutzen müsste, warum soll ich dann überhaupt bei LineageOS bleiben und nicht ein Projekt wählen, das direkt auf solche Nutzungsprobleme eingeht?

Doch es ist mehr als das: LineageOS verbietet sogar die Diskussion über solche Probleme. Und generell über alle Probleme, die Nutzer mit dem Projekt haben könnten. So sehen die Red­dit-Re­geln aus:

1. Do not ask for an ETA
2. Do not ask whether your device will be supported
3. No VoLTE requests
4. Bugs should be reported by following the instructions on the wiki, they should not end up here.
5. Don't ask for help with non-Lineage ROMs. We only support LineageOS, not things 'based on' LineageOS.
6. Do not ask for features to be added
7. No Xposed/Magisk/SuperSU/MicroG/Substratum discussion
8. Please don't post links to unofficial builds or unofficial news sources. If it's not lineageos.org -- it's not official.
9. Don't write news/make announcements that primarily pertain LineageOS

Nicht nur ist das unheimlich repressiv: Es ist auch in den Details wahnsinnig. VoLTE zum Beispiel, das heißt Voice over LTE. In manchen Ländern wie den USA wurde mit 3G auch gleich 2G abgeschafft, über dieses Netz liefen zuvor die Telefongespräche. Die sollten jetzt alle über LTE (4G) laufen. Das geht mit manchen Providern und manchen Geräten, aber nicht mit allen. Es ist ein absoluter Blocker für viele betroffene Nutzer, es ist existenzgefährdend für das gesamte Line­age-Pro­jekt. Und das offizielle Supportforum verbietet nun jede Diskussion und jedwede Nachfrage darüber, denn so wird diese Regel von den Moderatoren interpretiert. Ergebnis sind frustrierte Nutzer und ein Unvermögen, innerhalb des Projekts dieses extreme Problem anzugehen.

Oder das mit den Funktionen: Nicht nur ist das genau, wie man FOSS-Projekte nicht machen sollte, weil Funktionswünsche von Nutzern elementar wichtig für jede sinnvolle Weiterentwicklung sind. Mit dieser Regel werden sogar Dokumentationswünsche geschlossen, bei denen der nachfragende Nutzer anbietet die nötige Arbeit selbst zu machen! Es ging da bei einem mir besonders übel aufstoßenden Post um ein Datum, das der Nutzer von sustaphones hätte übernehmen können, was ich ihm anbot. Nach dem Schließen des Threads wurde dann da natürlich nichts draus, die anderen Lineagenutzer sind ärmer dafür.

Und natürlich brauchen Nutzer einen Ort, um den Entwicklungsstand der nächsten Versionen zu erfragen! LineageOS kommuniziert null mit seinen Nutzern. Es gibt keine Ankündigungen einer Projektleitung (gibt es die überhaupt?), keine Entwicklertagebücher (ins Blog wurde seit einem Jahr nicht geschrieben), Pläne für die Zukunft bleiben unbekannt, es gibt gar nichts. Anstatt dann bei Nachfragen das als Problem zu erkennen und durch irgendeine Form von Transparenz ihren Quell zu beseitigen, verbieten sie mit den Fragen das Symptom.

Lineage macht es sich wirklich unnötig schwer. Es ist ein Projekt, das eine engagierte Nutzercommunity brauchen würde, es vergrault aber in seinem Hauptdiskussionsforum so effizient wie möglich jeden engagierten Nutzer. Es ist ein Projekt, das freie Software und ein befreites Android bewirbt, ist dann aber ohne Googledienste nur mit starken Einschränkungen nutzbar und tut nichts dagegen – verbietet sogar die Diskussion über existierende Lösungen. Und es ist ein Projekt, das die starke Anpassbarkeit des Systems bewirbt, blockiert aber an allen Stellen wo möglich ebendiese, wo auch immer sie über das Anpassen des Bildschirmhintergrundes hinausgeht.

Sind das die Auswirkungen der gescheiterten Kommerzialisierung? Meine Theorie ist, dass LineageOS als Cyanogen sich von allem fernhalten wollte, was Google oder Provider verärgern könnte. Deswegen war dann ein Sprechen über Restriktionsmanagement wie Safety-Net und existenzbedrohendes wie VoLTE verboten. Das ist nun nach der Pleite im Nachfolgeprojekt immer noch so, ohne dass es irgendeinen validen Grund geben würde.

Welche Alternativen es gibt

Dieses Verhalten von LineageOS schafft immerhin Platz für andere Androidprojekte. Viele davon sind Forks von LineageOS, bessern aber die Nutzungsprobleme aus. So bei dem von mir getesteten /e/, das nicht nur mit microG meine Bankanwendungen unterstützt, sondern direkt eine gute funktionierende freie App integriert hatte, um diese auch aus dem Playstore zu installieren und automatisch zu aktualisieren. Zusätzlich werden von dem System weitere Alternativen zu den Googleapps bereitstellt. Nicht alles davon funktioniert wohl perfekt, aber wenigstens ist da überhaupt ein Problembewusstsein und Lösungswille erkennbar.

Ähnlich bei CalyxOS: Auch hier ist microG und sind die Mozilla Location Services vorinstalliert, zusätzlich setzt das System einen sehr viel stärkeren Fokus als LineageOS auf Datenschutz und Sicherheit. Das macht es zu einer klar besseren Wahl, wird das genutzte Telefon denn unterstützt.

So ähnlich geht es weiter. iodé sah ich in letzter Zeit oft erwähnt, wie /e/ baut das auf LineageOS auf, kommt mit microG und minimiert besser als LineageOS die Datensendung an Google und installiert F-Droid vor. Praktisch! Volla bietet inzwischen auch microG und ein eigenständiges Bedienkonzept und scheint den Anspruch zu haben, mehr Nutzungsprobleme durch eigene Apps aufzufangen (Außeneindruck, ich habe es noch nicht getestet), so ist F-Droid ebenfalls vorinstalliert. F-Droid gibt es nochmal direkt bei DivestOS, bei dem noch dazu der Entwickler bei meinem Kontakt angenehm mit seinen Nutzern redete, zusätzlich proprietäre Blobs viel konsequenter als bei LineageOS entfernt werden.

Das alles wären direkte Alternativen, die Android mit Android ersetzen. Mein Traum eines brauchbaren Linuxtelefons (in dem Fall tatsächlich relevant: ich meine GNU/Linux) hat sich bisher nicht materialisiert. Ubuntu Touch hat aber weiterhin ein starkes Konzept, das dann irgendwann mit Waydroid eine brauchbare Alternative bieten könnte, aber noch ist es nicht so weit. Jolla mit seinem SailfishOS dürfte da etwas weiter sein und wäre ebenfalls eine Möglichkeit. Immerhin verkaufen sie ihr Betriebssystem als praxistauglich, andererseits ist es nicht frei. Und in der Ferne ist da auch noch Post­mar­ket­OS, auf eine Art der vielversprechendste Linuxansatz für Telefone, wobei wohl bisher auf keinem Gerät alltagstauglich und ich keinen Grund habe anzunehmen, dass sich das 2024 ändert.

Tatsächlich werde ich jetzt nicht direkt mein Telefon mit einer Alternative neu aufsetzen. Ich habe mich mit dem Zweittelefon als Zwischenlösung arrangiert. Aber die Lebenszeit meines G5 dürfte schon aufgrund der alternden Hardware arg begrenzt sein, außerdem war bereits die weitere Versorgung mit LineageOS 20 (=Android 13) wegen des benötigten Kernelupgrades total überraschend. Geht es da auf der einen oder der anderen Seite zu Ende, dann ist der Moment gekommen und ich werde mir eine der Alternativen zu Lineage herauspicken. Oder wer weiß, vielleicht überrascht mich das Projekt nochmal und unterstützt nicht nur das G5 weiter, sondern geht auch ein paar der identifizierten Projektprobleme an.

Denn ich denke, dass LineageOS sich als Projekt wirklich verbessern kann und solche negativen Eindrücke vermeiden könnte. LineageOS scheint an sich ein sehr erfolgreiches Projekt zu sein, ist vielgenutzt und gleichzeitig Grundlage weiterer toller Projekte. Hat es da diese Nutzerfeindlichkeit nötig? Hat ein solches Projekt wirklich keine Ressourcen für eine transparentere Projektplanung und Problematisierung? Ist es wirklich unmöglich, die im Diskussionsforum aufschlagenden Nutzer besser einzubinden? Und woher kommt diese Schockstarre angesichts existentieller Nutzungsprobleme wie VoLTE, der Unwille, Nutzungsprobleme von Android abseits der Googledienste anzugehen? Warum ist die Distanz zum Geist der Linuxdistributionen so groß?

Und um versöhnlicher zu enden: Völlig klar muss auch sein, dass eine solche Projektkritik keine Kritik an jedem einzelnen Entwickler ist. Solche Projekte entwickeln sich in unsichtbaren Gruppendynamiken. Zudem sind wahrscheinlich der Großteil der engagierten Entwickler nie im von mir stark kritisierten Redditforum auch nur lesend gewesen. Und selbst dort habe ich neben einzelnen Menschenfeinden, die nie wieder in einem solchen Projekt wirken sollten, intelligente, sympathische und freundliche Projektmitglieder beobachten können. Ich weiß aus eigener Projekterfahrung, dass nutzerfeindliche Entwickler bzw Moderatoren nicht immer direkt auffallen und von ihnen auf die anderen zu schließen völlig unfair sein kann.
Ich wünschte nur, Lineage würde gar nicht erst die Grundlage für eine solche Kritik geben und ich sie hier nicht entsprechend einordnen müssen.

Ich möchte dieses Jahr im Blog mit noch etwas mehr Rückblick beginnen.
Die letzten Jahre habe ich als Entwickler professionell Mobilanwendungen geschrieben – eine absurde Geschichte, kam ich doch erst recht spät zum Smartphone. Aber entsprechend intensiv beschäftigte ich mich damit. Andererseits war meine letzte App-Auflistung 2020. Da hat sich also ein bisschen was getan, daher ist es Zeit für eine neue Liste. Die wird alphabetisch sortiert, ich überspringe die eingebauten Anwendungen die ich nicht benutze oder für nicht relevant halte.

Zum Rahmen, bei mir lief 2023 ein LG G5 mit LineageOS (plus anderen Telefonen, dazu später mal mehr) ohne Goo­gle-Dien­ste, die Apps entstammen daher fast alle F-Droid.

AntennaPod

Dieses Jahr bin ich zum Hören von Podcasts von Escapepod auf AntennaPod umgestiegen. AntennaPod ist ein wesentlich umfangreicheres Programm, mit viel mehr Interface und Funktionen. Das sprach mich gar nicht so sehr an, der Wechsel hatte andere Gründe: Escapepod funktionierte auf meinem Gerät nicht mehr ordentlich. Immer wieder blieb es stecken, kamen keine neuen Folgen in die App, obwohl sie tatsächlich verfügbar waren.

Es könnte sein, dass Escapepod einem Line­age-Bug zum Opfer fiel, für den ich inzwischen einen Workaround habe. Aber An­tenn­a­Pod funktionierte seitdem problemlos und auch mit dem anderen Interface habe ich mich schnell arrangiert: Letzten Endes drücke ich auf Abspielen und kann hier noch etwas angenehmer die Abspielreihenfolge anlegen. Von daher gab es keinen Grund zurückzuwechseln.

Audio Recorder

Mit dieser App lassen sich Tonaufnahmen anfertigen, wieder abspielen und exportieren. Die Aufnahmen werden direkt als .ogg gespeichert und nicht erst platzfressend als .wav angelegt. Funktionierte einwandfrei und brauchte ich auf der BIG für ein Interview.

Aurora Store

Zwar laufen auf meinem Telefon keine Goo­gle-Dien­ste, aber eben doch manche proprietären Apps aus Googles Playstore. Der Aurora Store kann diese installieren und später aktualisieren. Zwischendurch war die App mal kaputt, wohl weil Google gegen die genutzten anonymen Accounts vorging, inzwischen funktioniert sie aber wieder.

Binary Eye

Diese App entdeckte ich für meinen damaligen Job, Binary Eye war der eine immer gut funktionierende QR-Co­de-Scan­ner. Ersetzte mehrere zwischendurch angetestete Alternativen und kam dann auch für den eigenen Gebrauch auf das Telefon.

Calendar

Der von Lineage bereitgestelle Kalender ist (ein Fork von?) Etar, für mich funktionierte er gut.

DB Navigator

Die eine Anwendung, die leider wirklich aus dem Playstore kommen muss, weil die Bahn sich einfach querstellt und die App unwürdigerweise weder selbst verteilt noch auf F-Droid einstellt. Immerhin, sowohl die alte Variante der App als auch die kürzlich veröffentlichte neue Version funktioniert ohne Goo­gle-Dien­ste bei mir einwandfrei. Und das muss ich der Bahn dann wieder positiv anrechnen.

F-Droid

Und klar: Ohne F-Droid würde diese Liste nicht existieren. F-Droid ist weiterhin der eine vertrauenswürdige Appstore, mit einer tollen Auswahl quelloffener Software. Und deswegen die eine App, an die ich regelmäßig Geld spende.

Fennec

Firefox für Android via F-Droid. Der Browser ist weiterhin super, die Erweiterungen wie UBlock Origin machen das Internet insgesamt besser. Gegen Ende 2023 wurden die Erweiterungen auch endlich geöffnet (vorher war nur eine statische Mini-Auswahl verfügbar), viel zu spät und viel später als versprochen, aber das Ergebnis ist halt trotzdem toll und Fennec damit einzigartig.

Forecastie

Forecastie ist eine Wet­ter­vor­her­sa­ge-App, die zum einen als solche für mich gut funktioniert, zum anderen auch ein hübsches transparentes Wetterwidget auf den Startbildschirm zeichnen kann.

FreeOTP+

Erstellt diese TOTP-Co­des, die bei manchen Seiten als zweiter Faktor beim Login dienen. Sicherer als SMS-Codes, nutze ich das als Backup für den Solo-Fidostick oder falls der nicht unterstützt wird. FreeOTP+ hat mich dabei jetzt seit einigen Jahren nicht enttäuscht.

MuPDF Viewer

Ein kleiner PDF-View­er, der PDFs anzeigen kann und bei Start eine Dateiliste zur Auswahl anbietet.

Music

Mitgeliefert von LineageOS, hat Music bei mir das Problem manchmal sich nicht ordentlich in den Hintergrund zu schalten, dann geht etwas nach dem Bildschirm die Musik aus. Beim zweiten Versuch funktionierte es bisher immer, deswegen habe ich die App noch nicht ausgewechselt. Ansonsten spielt sie normal gut Musik ab, dass dabei Playlisten verständlich unterstützt werden fand ich angenehm.

NewPipe Sponsorblock

NewPipe ist eine bessere Alternative zu Goo­gles You­Tube-App, denn es entfernt die Werbung zwischen den Videos und ermöglicht das Herunterladen. NewPipe Sponsorblock ist eine bessere Alternative zu NewPipe, denn es ergänzt die App um einen Blocker für in die Videos eingebauten Videos, üblicherweise eben Sponsorerwähnungen.

Allerdings sehe ich gerade, dass der Entwickler das Projekt Ende Dezember archiviert hat. Schade!

Notes / Another Notes app

Eine nette kleine Notizenanwendung. Im Appmenü identifiziert sie sich vernünftigerweise nur als Notes, sie kann Checklisten und unterstützt mehrere separate Notizblöcke, die im Startbildschirm der App als Liste oder Raster angezeigt werden können.

Ich benutze sowas vor allem als Einkaufszettel und mir ist am wichtigsten, dass das Anlegen, Abhaken und Entfernen von Listeinträgen flüssig funktioniert. Diese App hat dafür das in meinen Augen genau richtige Bedienkonzept, deswegen blieb ich bei ihr hängen.

Open Camera

Eigentlich mag ich diese Kamera-Anwendung gar nicht so gerne. Sie hat mir zu viele Einstellmöglichkeiten, die ich dann doch nicht nutze. Die eine, die ich gerne nutzen würde – der HDR-Mo­dus – stürzt bei mir dagegen bei der Nutzung ab. Aber immer wenn ich versuchte, auf die von LineageOS mitgelieferte Ka­me­ra-App zu wechseln, funktionierte die nur für ein paar OTA-Up­dates und dann gar nicht mehr. In diesen Situationen war Open Camera immer die eine zuverlässige Alternative.

Wäre aber mal wieder an der Zeit, der mit LineageOS 20 (also Android 13) umgebauten Standardapp eine Chance zu geben, derzeit scheint sie zu funktionieren.

Organic Maps

Organic Maps empfand ich als leichter bedienbare Alternative zu OSMAnd+. Sie hat ähnliche Probleme: Vor allem, dass die Suche immer wieder Aussetzer hat, dass die Kartendaten bei Details wie Öffnungszeiten nicht mit Google Maps mithalten können und die Routenfindung mit Bus & Bahn nicht so gut funktioniert. Aber als Offline-Karte taugt die App trotzdem. Zur Routenfindung griff ich auf den DB Navigator zurück.

PDF Doc Scanner

Ich habe hier weder einen Drucker noch einen Scanner im Haus, was in der papierlastigen deutschen Bürokratie immer wieder ein Problem ist. Dieser Dokumentenscanner ist da eine große Hilfe: Mit der Telefonkamera lassen sich so Papiere einscannen, wobei ein schiebbarer Rahmen das Papier auf dem Foto markiert, dessen automatische Erkennung auch noch gut funktioniert. Das Ergebnis sieht dann so aus als käme es aus einem normalen Scanner, das beugt Meckerkommentaren von Bürokraten vor und reduziert die Dateigröße des PDFs.

Entstammt dem IzzyOnDroid F-Droid Repository, das F-Droid hinzugefügt werden kann und dann ein paar weitere Apps bereitstellt. Das würde ich gerne vermeiden, aber in der Sammlung von F-Droid selbst fand ich keine Alternative.

Shattered Pixel Dungeon

Ein Rougelike, das mir sehr gefallen hat. Es ist ein vollständiges Spiel und kann mit seinen verschiedenen Charakteren viele Stunden beschäftigen, ist frei von Mikrotransaktionen und einfach ziemlich gut. Vor allem für ein Mobilspiel. Man sehe auch das Review bei Gnu/Linux.ch. Für mich ein Reisebegleiter.

Signal

Ich habe mich lange gegen Signal gesträubt, weil das Projekt alternative Clients nicht zulassen wollte und nicht auf F-Droid ist. Unsympathisch. Dann bekam ich aber mit, dass sie immerhin ein .apk auf ihrer Webseite veröffentlichen, was ich anderen Apps auch durchgehen ließ. So bekam Signal kürzlich also doch eine Chance.

Noch nicht viel benutzt.

Syncthing

Syncthing nutzte ich früher mal als Dropboxalternative auf meinem PC, was mir dann irgendwann zu umständlich war (bzw ich das Zweitgerät nicht mehr nutzte, den Laptop). Auf dem Telefon entdeckte ich es wieder als Backuplösung für die Fotos.

Telegram

Weil Telegram – anders als Signal – auf F-Dro­id vertreten ist und – anders als andere verschlüsselnde Messenger – verlässlich funktionierte, wurde es vor einigen Jahren zu meiner Haupt-Chatapp. Das ist bisher so geblieben.

Ich weiß um den schlechten Ruf der App, aber ich meide Te­le­gram-Grup­pen sowieso und eine gute funktionierende Option braucht es nunmal.

VLC

VLC nutze ich inzwischen selten, nur um auf Reisen heruntergeladene Videos abzuspielen. Früher war es wichtiger, da hatte NewPipe auf dem G5 einen Bug und brach regelmäßig die Videowiedergabe ab, während das Streamen von der App zu VLC funktionierte.

Weggefallen sind damit:

1. Advanced Charging Controller (Hauptfunktion in LineageOS 20 eingebaut, + Rooten von LIneageOS wurde unmöglich)
2. CPU Info (kein Anwendungsgrund mehr, würde ich bei Bedarf neu installieren)
3. Document Viewer (-> MuPDF Viewer, Sicherheitslücke)
4. Escapepod (-> AntennaPod)
5. Jitsi Meet (-> Telegram, würde ich bei Bedarf neu installieren)
6. NewPipe (->NewPipe Sponsorblock)
7. OSMAnd+ (->Organic Maps)
8. Scarlet Notes FD (-> Another Notes app)
9. StressTest (kein Anwendungsgrund mehr, würde ich bei Bedarf neu installieren)
10. Transportr (-> DB Navigator)

Wie sieht es bei euch aus, habt ihr Empfehlungen für mich?

Die letzten Jahre hat der Roomba 615 meine Wohnung gesaugt, in Zukunft sollte das der Roborock E5 übernehmen. Warum wechseln, was sind die Unterschiede und wie schlägt sich der neue?

Wechselgrund Routenplanung

Hauptgrund für den Wechsel ist die versprochene bessere Routenplanung. Der Roomba 615 folgt beim Reinigen scheinbar einfachen Regeln. Die sorgen dafür, dass er mit genug Zeit durch die ganze Wohnung fährt – aber dafür viel länger braucht, als wenn er effizient nur ungesaugte Bereiche anfahren würde. Verbunden mit dem doch nervigen Lärmpegel und seiner Eigenheit, immer wieder aus meinem Büro nicht mehr rauszufinden, wurde der alte Roomba nervig. Das machte seinen Zweck kaputt eine Alltagserleichterung zu sein, außerdem wurde er deswegen immer seltener genutzt.

Beim Roborock E5 soll die Navigation besser funktionieren. Dieser baue eine interne Karte und fahre dann gezielt durch die Wohnung. Gleichzeitig leiser verspricht das, die Wohnung in kürzerer Zeit mit wesentlich geringerem Nervfaktor sauber gemacht zu bekommen.

Was sonst für den E5 sprach: Internetlosigkeit und der Preis

Aber dieses geplante Vorgehen beherrschen fast alle modernen Saugroboter, außer den allergünstigsten. Warum kaufte ich den Roborock E5?

Zum einen, weil er mit einer Fernbedienung kommt und die App-Anbindung tatsächlich optional zu sein scheint. Roborock, eine chinesische Firma mit Verbindungen zu Xiaomi und damit unter permanenten Spionageverdacht, verspricht die Optionalität der App-Anbindung für alle Saugroboter. Sie erklärt aber nicht, welche Funktionen dann noch funktionieren. Fällt z.B. bei einem eher darauf ausgelegtem Modell wie dem S8 die Internetanbindung weg, funktioniert dann die intelligente Routenplanung noch? Beim E5 funktioniert sie scheinbar immer, zudem gibt die Fernbedienung Zugriff auf ein paar nützliche Funktionen wie die Einstellung der Saugintensität (und damit dem Lärmlevel), ohne das Gerät ins heimische Wlan lassen zu müssen.

Saugroboter anderer Hersteller starten Internetberichten teils gar nicht, wenn sie nicht ins Wlan kommen, oder sind definitiv bei der Adaption ihrer Navigation dann beschnitten. Deutlich kommuniziert wird die Situation um die nötige Internetanbindung leider bei fast keinem Hersteller, das Statement von Roborock war die große Ausnahme. Daher war es eine aufwändige Recherche, den E5 als mögliche Option herauszufinden, und Roborocks Versprechen gab den Ausschlag, die Auswahl schließlich auf Geräte dieses Herstellers zu beschränken. Mit der Fernbedienung als Manifestation davon war der E5 doppelt attraktiv.

Zweiter positiver Aspekt des E5 ist sein Preis. Er beherrscht moderne appgestützte Funktionen wie die Raumerkennung nicht, nur die Karte der gesamten Wohnfläche lässt sich in der App wohl anzeigen. Dementsprechend kann man ihn nicht anweisen, jetzt die Küche zu putzen – er kann nur ganz oder gar nicht. Völlig ausgereift sei die intelligentere Navigation zudem auch nicht. Letzteres kann ich bestätigen, gerade fährt er zum zweiten mal durch die Küche (aber gut, die Karte muss sich ja erst aufbauen). Und seine Wischfunktion ist einfach ein Tuch, das mit Wasser benetzt wird, keine Borsten oder Vibrationen unterstützten sie und Teppiche vermeidet er auch dann nicht. Er ist also in vielerlei Hinsicht ein Budgetmodell und entsprechend auch deutlich günstiger als viele Alternativen.

Unterschiede zum Roomba 615

Der Hauptunterschied zum Roomba 615 ist also die Routenplanung. Der Roborock E5 fährt in langen Linien durch die Wohnung und scheint wirklich gezielt Bereiche anzufahren, die noch nicht gesaugt wurden. Das ist ein Riesenvorteil und wirkte im ersten Test sehr angenehm! Aber die weitere Zeit muss zeigen, ob er wirklich die gesamte Wohnung durchfährt und dann auch wirklich das Saugen abbricht wenn er überall war, nicht erst, wenn der leere Akku das vorgibt. Schließlich hat auch der Roomba irgendwann das Saugen beendet, und in den ersten Tests schien der E5 länger weiterzumachen als sinnvoll erschien.

Beim Lärm schneidet der E5 besser ab – zumindest auf dem Laminatboden hier. Da ist er etwas leiser und der Lärmcharakter gleichförmiger, der 615 rödelt schlicht mehr. Fährt der E5 aber über Teppich, schaltet er in einen Turbomodus um, dann wird er sogar lauter als der alte Roomba je war. Die Saugintensität und damit der Lärm lässt sich beim Roborock einstellen, per Fernbedienung oder App. Der leisere Modus ist dann zwar wirklich nochmal ein bisschen leiser, aber der Unterschied zum Standardmodus ist nicht riesig.

Beide Saugroboter vermeiden herumstehende Objekte nicht völlig. Beim E5 hat mich das ein bisschen gewundert, hat er doch eine Kamera eingebaut, zumindest verstehe ich so die Herstellerbezeichnung OpticEye (auch wenn die nicht für die Primärnavigation benutzt wird, die basiert auf Gyroskopen). Trotzdem dozt er fast genauso gegen Tischbeine wie der völlig kameralose 615, nur leicht vorher abbremsend. OpticEye ist also wohl in der Praxis nur ein Näherungssensor, wie der Roomba ihn auch hat. Zusätzlich wird die Heftigkeit der Kollision durch einen vorne angebrachten Stoßdämpfer gemindert.

Bei anderen Hindernissen gibt es Unterschiede. So blieb der 615 immer auf den Streben des Wäscheständers hängen, halb in der Luft hängend kam er nicht weiter und schaltete sich schließlich ab. Der E5 hängt bei den gleichen Streben ebenfalls kurz in der Luft, gibt sich dann aber einen Ruck und bleibt nicht stecken. Super! Dafür hat er mehr Probleme mit Kabeln als der Roomba, so verfing er sich direkt in den Stromkabeln der Katzenfutterautomaten, mit denen der Vorgänger noch nie ein Problem hatte. Die werde ich nun anders verlegen müssen.

Zur Saugleistung kann ich noch nicht viel sagen. Die Herausforderung bei uns sind lange Menschenhaare und sehr viele Katzenhaare. Mit den Menschenhaaren hatte der Roomba ernste Probleme, sie verfingen sich in seiner Bürste und zerschnitten sie richtig. Aber zumindest solange die Bürstenborsten nicht ganz abgeschnitten waren schaffte er es doch, die Wohnung deutlich sauberer zu machen. Meinem Ersteindruck nach schafft der E5 das genauso, saugt aber ebenfalls nicht so perfekt als würde man es selbst machen, braucht dafür jedoch weniger Zeit als der Roomba.

Der Staubbehälter des E5 ist ein bisschen kleiner (640ml statt 700ml). Ob der waschbare Filter gut funktioniert kann ich nicht ordentlich messen, die Idee aber finde ich gut.

An den E5 kann man auch einen Wischmop anbringen, ein Wasserbehälter würde den dann befeuchten. Da hier in der Wohnung Laminat ist habe ich den gleich in der Packung gelassen. Ich will aber noch testen, ob zumindest das gelegentliche Wischen damit auf dem Laminatboden möglich ist. Der Roomba 615 hatte keine Wischfunktion.

Beiden gemein ist, dass Wlan nicht benötigt wird. Aber der E5 hat eine optionale Appunterstützung, die ich nicht getestet habe. Der 615 hat gar kein Wlan.

Anfangsprobleme mit diesem E5

Nicht unerwähnt bleiben soll, dass ich zu diesem Zeitpunkt noch nicht sicher bin, ob der gekaufte E5 (ein C-Modell, angeblich ein reparierter Rückläufer) nicht doch noch zurückgeht. Beim ersten Test hatte er für eine kurze Weile wunderbar gesaugt, danach aber klappte das Docken nicht – er fuhr zum Ladedock und auch drauf, blieb aber dann nicht drin stehen. Beim manuellen Hereinsetzen gab es keine Rückmeldung, dass das Laden nun klappt. Erst eine Stunde später kam plötzlich eine Fanfare vom Roboter. Ich ging davon aus, dass der Akku kaputt sei.

Danach aber funktionierte der Roboter, auch das Docken funktionierte jetzt mehrmals im ersten Anlauf und die Akkukapazität wirkte völlig okay. Hier muss ich also noch beobachten, ob das ein einmaliger Ausrutscher war oder ob dieser E5 nicht doch einen Schlag weg hat.

Der Roborock E5 bietet dem ersten Eindruck nach genau den Sprung, den ich mir erhofft habe. Ohne unbedingt jedes mal perfekt zu saugen, macht er die Wohnung genauso dadurch sauberer, dass er viel öfter saugt als ich es selbst machen würde. Aber anders als der Roomba 615 macht er das nicht mehr per Zufallsnavigation, sondern seine Liniennavigation ist nachvollziehbarer. Dadurch ist er weniger nervig, wobei dabei auch der etwas geringere Lärmpegel hilft.

Gleichzeitig vermeidet er den Sprung in unsere dystopische Jetztzeit, in der mit Kamera ausgestattete Roboter, dazu mit proprietärer Software ausgestattet und oft mit Verbindungen zu Diktaturen wie China belastet, ohne jegliche Kontrolle nach Hause funkend durch privateste Wohnungen fahren. Will man keine solche Unsicherheit wird sonst oft der Anker/Eufy RoboVac 11S empfohlen, der ist aber bei der Routenplanung genauso beschränkt wie mein alter Roomba 615, wäre also keine Verbesserung. Und mit Valetudo einen internetbewehrten Roboter zu entschärfen, wie bei GNU/Linux.ch gut beschrieben wurde und was als zweite Alternative gilt, war selbst mir zu aufwändig.

Ein paar Dinge könnten besser sein:

1. Weniger laut geht immer.
2. Kleiner und flacher wäre ebenfalls nett, natürlich nicht auf Kosten der Kapazität des Saugbehälters und des Akkus.
3. Der Roboter sollte Objekte vermeiden können, insbesondere sich nicht in Kabeln verheddern. Diese Objekterkennung und Vermeidung fehlt dem E5 leider komplett.
4. Die Navigation sollte perfekt funktionieren, der Roboter sich so effizient bewegen wie möglich.
5. Der perfekte Saugroboter hätte eine gute Wischfunktion, so minimal nass um selbst auf Laminat zu funktionieren, die (wie der Roborock S7 und S8 es wohl können) für Teppiche dann deaktiviert wird.

Aber bei der derzeitigen Produktentwicklung in diesem Bereich ist nicht damit zu rechnen, dass je ein Roboter mit diesen Verbesserungen auf den Markt kommt und ohne App- und Internetanbindung auskommt. Von daher bin ich mit dem E5 erstmal zufrieden.

Simdock ist mein Dock für den Linuxdesktop, das ich seit ein paar Jahren pflege. Jetzt konnte ich dem Code ein großes Update verpassen und damit das Projekt für die nächste Zeit absichern.

Kurzfassung

• Simdock läuft nun mit der GTK3-Version von wxWidgets, bei mir ist das das sehr neue wxWidgets-3.2.4. Dadurch wird es auch auf modernen Systemen wieder kompilieren.
• Durch den Wechsel zu GTK3 musste auch die genutzte Library Wnck aktualisiert werden, die Version 1 zuvor setzte auf GTK2, das kollidierte. Nebeneffekt davon ist, dass für die dynamischen Programmanzeigen größere Icons gewählt werden sollten.
• Dank der neuen Version von wxWidgets konnte durch wenige Codeänderungen Compositing für den Dockhintergrund aktiviert werden. Die Pseudotransparenz funktioniert weiterhin, wenn kein Compositor am Laufen ist.
• Es werden wieder AppImages gebaut. Die gab es für Simdock schonmal, die waren aber durch den Wegfall von Travis CI ausgefallen. Die AppImages hatten (zumindest aber auf meinem System) noch einen Bug mit dem neuen Compositing, mehr dazu unten.

Der allgemeine Hintergrund des Updates

Simdock lief die letzten Jahre relativ zuverlässig vor sich hin. Aber der Wechsel zu GTK3 war eine große Gefahr für die weitere Existenz des Projekts und die Migration jahrelang durch eine fehlende Funktion von GTK3 blockiert.

Nun war der Wechsel aber unumgänglich, es musste etwas passieren. Denn selbst auf meinem eigenen System konnte ich Simdock nicht mehr bauen. Void Linux hatte wxWidgets auf GTK3 umgestellt, ohne die GTK2-Version weiterhin bereitzustellen. Und das alte AppImage lief auch nicht, neue wurden sowieso nicht mehr gebaut. Ich rechnete eigentlich damit, das Projekt aufgeben zu müssen – und stolperte dann gestern doch über die Lösung.

Als Simdock vor ~2 Monaten für mich wegbrach hatte ich noch mit keiner Lösung gerechnet und mir stattdessen Alternativen angeschaut. Und tatsächlich auch gefunden: Plank ist mittlerweile eine hervorrage Alternative. Es fehlen die konfigurierbaren Starter, dafür kann es sich selbst verstecken (Auto-Hide) und und ist so platzsparend, außerdem hatte es schon lange echte Transparenz. Ich nutzte es mit Openbox und jetzt nochmal mit IceWM (da kollidierte es erst mit meiner Konfiguration, aber mit der Versteckenfunktion passte es). Die Existenz der Alternative war entspannend! Aber jetzt nachziehen zu können befriedigt dann doch meinen Ehrgeiz. Und es war die bessere Lösung in meiner derzeitigen Projektaufräumaktion, so statt dem Aufgeben genau wie bei izulu nach Jahren des Zeitmangels die Modernisierung umsetzen zu können.

Technische Erklärungen

Warum war der Wechsel zu GTK3 so problematisch? Es sollte überraschen, denn wxWidgets abstrahiert das Toolkit eigentlich weg, ob da jetzt GTK2, GTK3 oder gar QT läuft sollte egal sein. Gleichzeitig ist wxWidgets eines dieser großartigen Projekte, bei denen Upgrades generell schmerzlos sind, ich musste genau null Zeilen wxWidget-Code anpassen.

Das Problem war diese Funktion: gdk_pixmap_foreign_new(). Simdock benutzte sie, um den Hintergrund des X11-Desktops zu holen und den dann als Hintergrund des eigenen Fensters zu setzen. Klassische Pseudotransparenz. Und für diese Funktion gibt es in GTK3 einfach keinen direkten Ersatz. Der Code sah leicht vereinfacht so aus:

wxBitmap* backImage = new wxBitmap();
WnckScreen *screen = wnck_screen_get_default ();
// The XID of the background pixmap
Pixmap pm = wnck_screen_get_background_pixmap(screen);
    
if (pm != None) {
    wxBitmap* backImage = new wxBitmap(
                                   gdk_pixmap_foreign_new(
                                   pm
                                )
                            );
    return backImage;
}

Da wurde also auch Wnck genutzt, dessen Details sich ebenfalls ändern würden, das verstellte weiter den Blick auf die Lösung. Es gibt einfach keinen dokumentierten Weg, die Pixmap des XServers mit GTK3 in ein Grafikobjekt zu quetschen um sie dann wxBitmap zu übergeben.

Stattdessen sah meine Lösung schließlich so aus:

wxSize sz = wxGetDisplaySize();
wxBitmap* backImage = new wxBitmap(
			gdk_pixbuf_get_from_window(
				gdk_x11_window_foreign_new_for_display(
					gdk_display_get_default(),
					gdk_x11_get_default_root_xwindow()
				),
				0,
				0,
				sz.GetWidth(),
				sz.GetHeight()
			)
		  );

Das benutzt jetzt also GDK-Funktionen ohne den Wnck-Umweg. Und war nur möglich, weil ich mit der Hilfeseite zu X Window System Interaction endlich über die passende Dokumentation gestolpert war. Der Code holt sich das Root-XWindows mit gdk_x11_get_default_root_xwindow(), macht daraus ein GDK-Window mit gdk_x11_window_foreign_new_for_display und davon kann gdk_pixbuf_get_from_window dann eine Grafik ziehen. Dass dadrin ebenfalls gdk_display_get_default benutzt wird folgte direkt der Dokumentation.

Jedoch: Das ist nicht ganz das gleiche! Denn die Grafik beinhaltet auch alle offenen Fenster. Es ist eben nicht der X-Hin­ter­grund, an den ist einfach nicht ranzukommen. Doch für Simdock war das gut genug: Normalerweise sind eh keine Fenster hinter einem Dock, und ich schaffte es, Simdock vor dem Ziehen dieses Screenshots auszublenden. Flickert ganz kurz, aber da das nur bei Hintergrundbildwechseln passiert sollte das okay sein.

Damit war die Makefile anpassbar. Wnck-3.0 und wxWidgets-GTK3 konnten ins Projekt, Simdock damit wieder auf modernen Systemen gebaut worden. Und die nächste langjährige Baustelle war angehbar.

Echte Transparenz mittels eines Compositors hätte das Problem mit der oberen schwierigen Umsetzung von Pseudotransparenz umgangen. Diese Transparenz sollte wxWidgets eigentlich können, es gibt mit wxBG_STYLE_TRANSPARENT einen passenden setzbaren Hintergrund, der echte Transparenz bringen soll. Doch bei mir hatte das in vorherigen Tests nie geklappt.

Mit GTK3 und einer neuen Version von wxWidgets testete ich das erneut. Und tatsächlich: Es brauchte nur minimale Codeänderungen und die Transparenz lief direkt. Ein echter Durchbruch. Simdock soll weiterhin Pseudotransparenz unterstützen – das war das originale Alleinstellungsmerkmal des Programms, weswegen ich es überhaupt übernommen habe – aber echte Transparenz zusätzlich anbieten zu können ist super. Vor allem, wenn es jegliches Flickern vermeidet.

Die Lösung folgt genau der Dokumentation, wie ich sie vorher schonmal verlinkt hatte: Im Konstruktor des wxWindow, in diesem Fall dem wxFrame, SetBackgroundStyle(wxBG_STYLE_TRANSPARENT); setzen und erst danach mit Create(parent, ...); das Fenster erstellen. Vorher sah der Anfang des Konstruktors so aus:

MyFrame::MyFrame (wxWindow * parent, simSettings set, ImagesArray * array,
		  wxWindowID id, const wxString & title, const wxPoint & pos,
		  const wxSize & size, long style):
wxFrame (parent, id, title, pos, size, style)
{    
    …

    SetBackgroundStyle(wxBG_STYLE_PAINT);
} 

Daraus wurde das hier:

MyFrame::MyFrame (wxWindow * parent, simSettings set, ImagesArray * array,
		  wxWindowID id, const wxString & title, const wxPoint & pos,
		  const wxSize & size, long style):
wxFrame()
{
    // This enables full composited transparency:
    SetBackgroundStyle(wxBG_STYLE_TRANSPARENT);
    Create(parent, id, title, pos, size, style);

    …
}

Da veränderte sich also ebenfalls die Definition des Konstruktors, plus dem schnelleren Setzen von wxBG_STYLE_TRANSPARENT vor dem Create.

Ausstehende Probleme

Simdock hat relativ früh AppImages bereitgestellt. Ich war auf der Froscon in einem Vortrag des App­Image-Pro­jek­ts und fand die Idee super. Die wurden aber die letzten Jahre nicht mehr gebaut, weil die Travis-CI nicht mehr kostenlos war.

Also stellte ich die Buildpipeline wieder her. Diesmal mit Github-CI, und weil linuxdeployqt einen Fehler produzierte wechselte ich zu linuxdeploy mit dem GTK-Plugin. Das funktionierte an sich! Aber: Das AppImage bleibt bei mir schwarz, wenn Compositing aktiviert ist.

Ich habe ein Issue dafür auf, in dem ich auch mehr der Details zu den AppImages erkläre. Den gewählten Ansatz finde ich wirklich geschickt, die Logik hauptsächlich in eine zweite Makefile zu packen. Das hält die Git­hub-CI-Work­flow­datei simpel. Aber das Ergebnis muss eben auch funktioniere. Bis sich da eine Lösung auftut werde ich das AppImage weiter bauen lassen, aber nicht bewerben.

Mit all den Änderungen hat Simdock technisch einen großen Schritt getan und ich freue mich, dass das möglich war. Es wäre zu schade gewesen, das Projekt wegen den GTK-Mi­gra­tions­pro­ble­men aufgeben zu müssen. Und wer ein nettes Dock mit gutem Fenstermanagement sucht, mit Plank aber aus irgendwelchen Gründen nicht warm wird, dem kann ich Simdock jetzt wieder guten Gewissens empfehlen. Die Installation per Kompilierung wird im Readme beschrieben.

Gut, ein großer Faktor war, dass das das PineTab nicht mehr anging. Aber der Wechsel gibt eine interessante Geschichte ab und war so oder so eine gute Idee – wobei das PineTab auch ein paar Vorteile hatte.

Der Wechsel

An einem Donnerstag hatte ich das PineTab wieder aus dem Schrank genommen, es angemacht und aktualisiert. Tatsächlich fehlten ein paar wichtige Daten wie meine Passwortdatenbank. Ich hatte das PineTab schon zuvor als Reisebegleiter benutzt – dafür ist es vom Formaktor her super geeignet, klein und leicht und doch mit Tastatur – aber seitdem neu installiert und es auf der letzten Reise durch einen Arbeitslaptop ersetzt gehabt. Ein paar Datentransfers und ein Update später war alles bereit. Die Reise sollte am Samstag starten.

Freitag mach ich das PineTab nochmal zur Kontrolle an – und nichts passiert. Nicht ganz, tatsächlich klackerte das Ding vor sich hin. Das hatte es früher schon manchmal gemacht, irgendwas stimmt da mit der Hardware meines Modells nicht. Aber diesmal blieb der Bildschirm über viele Versuche aus, ob neu geladen oder nicht. Das war neu, und nun war ich in Panik. Wegen dem Charakter der Reise brauchte ich unbedingt ein fähiges Begleitergerät, um auf die Server zu kommen etc. Aber es blieben nur noch ein paar Stunden um ein neues Gerät einzurichten und es musste Linux drauf laufen.

Also ging ich auf Kleinanzeigen und suchte nach Laptops in der Umgebung. Es gab die Auswahl zwischen überteuertem Schrott und für die Reise ungeeigneten Gaming-Monstern. Auf Verdacht suchte ich nach Surface – und fand einen Treffer für ein Surface Pro 3. Das war verlockend: Gleiches Prinzip wie das PineTab, also ein Tablet mit andockbarer Tastatur, die Erfahrungen in der Familie mit der Gerätefamilie sind positiv und einer schnellen Recherche zufolge gibt es ein Projekt, um die Geräte mit Linux kompatibel zu machen, wobei das ältere dritte Surface-Tablet noch mehr Standardhardware einsetzt und daher sowieso kompatibel sei. Angeschrieben, prompte Antwort, rübergelaufen und das Gerät war in meiner Hand.

Linuxinstallation auf dem Surface Pro (3)

Durch Zeit und die Größe des einzigen USB-Sticks im Haus beschränkt entschied ich mich notgedrungen für Lubuntu. Die Installation war überraschenderweise problemlos. Per Tastenkombination (wie bei einem Android-Telefon "Lautstärke hoch + Power") das BIOS starten, Booten von USB bei der Bootreihenfolge aktivieren. Lubuntu startet dann direkt, Wlan funktionierte, der Installer konnte durchlaufen. Ich musste dann nur nochmal die Win­dows-Bit­loc­ker-Ver­schlüs­sel­ung deaktivieren, weil ich zur Sicherheit die Windowsinstallation tatsächlich behalten wollte und der Installer wegen der Verschlüsselung keinen Speicherplatz abzwacken konnte.

Alltag mit Vor- und Nachteilen

Nach der Installation zeigte das Surface-Tablet, das ich bis jetzt fast ausschließlich mit der Tastatur als Laptop benutzte, seine Stärken. Alle in meiner Besprechung erwähnten Schwächen des PineTabs sind gelöst:

• Das Gerät geht zuverlässig an.
• Es wirkt mit seinem Magnesium-Gehäuse viel wertiger
• Der (hochauflösende und gute) Bildschirm wird deutlich heller.
• Die Lautsprecher sind lauter und besser.
• Die Tastatur wabbelt weniger; Das Touchpad ist zwar nicht toll, aber etwas größer und wirkt genauer.
• Es gibt keine Probleme mit einer SD-Karte, dessen Mechanismus und Abdeckung, weil eine echte SSD eingebaut ist.
• Die Performance des Prozessors ist viel besser, das Gerät bei Alltagsnutzung dadurch angenehm schnell.

Außerdem vermeidet die Standardhardware – x86-Prozessor statt ARM – und das damit mögliche reguläre Lubuntu die Softwareprobleme, die postmarketOS damals hatte und die bei meinem Test an dem Donnerstag teilweise auch heute noch bestanden.

Perfekt ist das Surface Pro 3 aber auch nicht. Zuerst ist es größer, 12" statt 10", 800g statt 575g. Das macht es für einen Reisebegleiter weniger geeignet. Der in meinem Modell verbaute i7-4650U-Prozessor hat nur zwei Kerne und ist abseits des Vergleichs mit dem PineTab nicht sehr leistungsfähig. Anfangs ruckelte sogar Youtube auf 1080p – was ich durch eine Kontrolle der Hardwarebeschleunigung und folgendem Erzwingen von h264 löste und was wenn ich mir seitdem die Performance anschaue auch ein Bug gewesen sein kann. Bei Videos wird auch auffällig, dass der Akku nicht besonders lange hält, ob das nun am Alter des Akkus, an fehlenden Optimierungen im Kernel für die Hardware oder an sonstwas liegt sei dahingestellt. Das Ladegerät ist ein interessantes magnetisches Ansteckkabel, aber damit eben auch ein proprietär, eventuell schwer zu ersetzen. Und schließlich ist der Bildschirm zwar schön und hell, aber auch spiegelnd, was mich immer stört.

Trotz der Nachteile kommt das Surface-Tablet klar besser weg. Es ist eben auch ein Vergleich zweier sehr unterschiedlichen Qualitätsklassen. Das Surface Pro 3 in dieser Ausführung kostete bei Release 2000 USD und war trotzdem Massenhardware mit einem Megakonzern im Rücken. Dafür ist es von 2014, also völlig veraltet. Das PineTab ist deutlich moderner, ich kaufte es als Neugerät 2020, aber der theoretische technische Fortschritt wiegt die Nischigkeit und den Preisunterschied (es kostete ~160 USD) eben doch nicht auf.

Trotz des Alters des Surface Pro 3 und der Größe ist es ein besserer Reisebegleiter, als es das PineTab damals war. Die Installation und Nutzung von Linux war problemlos, wobei meine Wahl von Lubuntu die Nutzung als Tablet etwas einschränkt. Ich würde wegen dem Alter des Akkus und dessen fast unmöglicher Auswechselbarkeit das Gerät auch nicht generell empfehlen, sondern eher raten nochmal nachzurecherchieren, ob eines der neueren Surface-Tablets oder ein Alternativgerät gut unterstützt wird. Oder direkt zu einem Framework-Laptop greifen. Die Option hatte ich aus Zeitmangel nur nicht – wobei ein teures neues Gerät auch nicht zu meinem Reiseland gepasst hätte und es durchaus ein Plus war, so die Nutzungszeit eines Altgeräts noch etwas zu verlängern.

Dem PineTab werde ich mit etwas mehr Zeit nochmal eine Chance geben. Möglich ist es ja, dass es nach einer Bedenkpause wieder angeht oder es tatsächlich ein Softwareproblem ist, das den Bildschirm schwarz bleiben lässt. Ich mochte den Ansatz des Geräts als Prototyphardware für den mobilen Linuxdesktop und hätte mit ihm gerne noch ein paar Softwareiterationen miterlebt. Es wäre schade, wenn es das jetzt schon war. Wobei man ehrlicherweise sagen muss, dass die Hardware wohl auch schlicht zu schwach war, um als Arbeitsgerät zu taugen und Macken wie die schlechten Lautsprecher auch die Nutzung als SD-Mul­time­dia­tab­let blockieren, dadurch blieb es daheim ungenutzt. Es wäre also abseits eines Reisebegleiters, was sich jetzt wohl erledigt hat, immer nur ein Experimentiergerät gewesen um zu schauen, was bessere Hardware könnte. Hardware, wie sie das alte Surface-Tablet eben schon mitbringt…

Von der hier genutzten Blogsoftware gibt es nun eine neue Version, Serendipity 2.5-beta1. Die Ankündigung ist auch im Serendipity-Blog.

2.5-beta1 soll hauptsächlich PHP 8.2 ordentlich unterstützen. PHP 8.0 – worauf Serendipity 2.4 ausgelegt war – wird noch bis Ende November 2023 vom PHP-Projekt gepflegt, danach dürften einige Hoster die Option entfernen. Die neuen Versionen haben wieder einige inkompatible Änderungen und brauchen deswegen ein neues Release. Als ein Beispiel hatte 8.1 strftime deprecated. Spuckt zwar erstmal nur eine Warnung, aber je nachdem wo die aufpoppt ist schon das problematisch, daher musste da Code ersetzt werden. Bzw in diesem Fall hat surrim die Funktion mit einem Polyfill ersetzt.

Intern sind noch einige Änderungen mehr, ein paar von mir. So hatten wir vor einiger Zeit angefangen, Abhängigkeiten in bundled_libs/ mit composer zu verwalten. So kann man sie einfacher auf eine neue Version aktualisieren und sieht auch direkt, auf welcher Version sie stehen. Das ging aber nicht mit allen, schlicht weil sich dann ihr Pfad ändern würde. Dafür fanden wir einen Workaround, sodass jetzt ein paar dort platzierte Abhängigkeiten mehr von composer verwaltet werden können, darunter das historisch problematische HTTP/Request2.

Extern ein bisschen sichtbarer sollten die von 2k11 nun lokal gehosteten Webfonts sein. Dadurch kann man sie jetzt problemlos wieder anmachen. Die Abmahngefahr hat sich wohl mittlerweile durch ein Vorgehen der Gerichte gegen die Abmahnanwälte erledigt, aber der IP-Leak zu Google musste ja trotzdem nicht bestehen bleiben. Und Garvin hat einen potentiell sehr ekligen Bug gefixt, durch den die Berechtigungen bei den Nutzergruppen falsch angezeigt wurden und entsprechend verstellt gespeichert worden wären. Die Beta hat noch ein paar mehr Verbesserungen dieser Art zur 2.4.0.

Zur Einordnung der Stabilität: Es ist eine erste Beta. Und nicht alle Plugins sind mit ihr bzw mit PHP 8.2 getestet worden. Andererseits war der Sprung nicht so groß wie damals zu PHP 8.0, als das Release mit wesentlich mehr Aufwand betrieben werden musste. Ich rechne diesmal nur mit kleineren Problemen und ein paar nötigen Pluginupdates. Aber es wird sich zeigen, was dem Projekt berichtet wird, das bestimmt dann die nächsten Schritte. Je nach Rückmeldung sollten wir bald eine zweite Beta oder einen RC raushauen und damit eine neue stabile Hauptversion einleiten können.

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.