Linux

Perfektion mag unerreichbar sein, aber der Terminalemulator WezTerm hakt viele Anforderungen ab:

1. Ein eingebautes Tabinterface, um parallele Terminalsessions im gleichen Fenster zu haben.
2. Ein Scrollbalken, ein absolutes Ausnahmefeature…
3. …der sich dann auch noch mit der Maus bedienen lässt, inklusive dem Mausrad.
4. Gute Konfigurierbarkeit, um beispielsweise die Steuerung der Tabs an die eigenen Vorlieben anzupassen.
5. Eine große Auswahl an Farbschemas.
6. Das Anzeigen von Bildern im Terminal, z.B. mittels lsix.

Nachdem ich WezTerm nun schon eine ganze Weile benutze sind mir auch keine Nachteile aufgefallen.

Konfiguration

Für ein modernes Programm überraschend, wird WezTerm statt über ein Einstellungsmenü über eine Konfigurationsdatei konfiguriert. Diese ~/.wezterm.lua sieht bei mir so aus:

-- Pull in the wezterm API
local wezterm = require 'wezterm'
local act = wezterm.action

-- This will hold the configuration.
local config = wezterm.config_builder()

-- This is where you actually apply your config choices

-- For example, changing the color scheme:
config.color_scheme = 'Solarized (dark) (terminal.sexy)'
config.scrollback_lines = 20000
config.enable_scroll_bar = true

-- The scrollbar is too hard to see in the Solarized theme, so change it:
config.colors = {
  scrollbar_thumb = '#93a1a1',
}

config.audible_bell = 'Disabled'

config.keys = {
  { key = 'LeftArrow', mods = 'SHIFT|CTRL', action = act.MoveTabRelative(-1) },
  { key = 'RightArrow', mods = 'SHIFT|CTRL', action = act.MoveTabRelative(1) },
  { key = 'LeftArrow', mods = 'SHIFT', action = act.ActivateTabRelative(-1) },
  { key = 'RightArrow', mods = 'SHIFT', action = act.ActivateTabRelative(1) },
  { key = 'DownArrow', mods = 'SHIFT', action = act.SpawnTab 'CurrentPaneDomain',},
}

-- and finally, return the configuration to wezterm
return config

Wichtig ist dabei das Farbschema, das ich auf Solarized (dark) (terminal.sexy) gesetzt habe. Den Scrollbalken zu aktivieren und per Farbänderung sichtbarer zu machen macht das Terminal nutzerfreundlicher (da es die Selbstbeschreibungsfähigkeit erhöht), den Piepser bei Fehleingaben deaktiviere ich wegen seine Nervfaktors wann immer möglich, und schließlich sind da die Tastenbelegungen für die Tabverwaltung.

Statt der dunklen Variante von Solarized hätte es viele Alternativen gegeben. Die Dokumentation listet 1001 Varianten, wobei davon einige nur kleine Spezialvarianten des jeweiligen Grunddesigns sind. Trotzdem, die Auswahl ist beeindruckend.

Ich bin an sich kein Fan von mittels Programmiersprachen umgesetzten Konfigurationsdateien, aber für mich überwiegt hier, dass alles so einstellbar war wie ich es wollte. Zudem sind die Voreinstellungen bereits ziemlich gut.

Ich würde bei regulären Programmen jetzt noch ihre Funktionsweise vorstellen, aber bei einem Terminalemulator ist da wenig zu sagen. Zumindest bei meiner Nutzung. Tatsächlich hat WezTerm ein paar von mir bisher ignorierte Spezialfunktionen, wie einen eingebauten Multiplexer. Und die Tabs, aber die sind oben auf dem Screenshot ja sichtbar.

Macken gibt es wohl auch, gesammelt vom Projekt selbst auf Github. So sei die Performance nicht so gut wie die von xterm oder kitty (was ich im Alltag nicht bemerkte) und der Text werde beim Anpassen der Fenstergröße seltsam platziert (das zumindest kann ich bestätigen, auch wenn es mir vorab nicht auffiel). Von meiner Seite aus ist die Schriftdarstellung etwas, was nicht jedem gefallen könnte, wobei ich sie auf meinem System hübsch genug und soweit passend finde. Generell könnte man auch am Konzept eines GPU-beschleunigten Terminals zweifeln, zeigt xterm doch, dass dieser Ansatz für Performance und Latenz nicht notwendig ist.

Aber das sind keine gravierenden Macken. Letzten Endes ist WezTerm stabil, umfassend konfigurierbar und hat mit der Kombination von guter Performance, sichtbarem Scrollbalken und eingebauten Tabs meines Wissens ein Alleinstellungsmerkmal. Für mich war es damit bisher tatsächlich die perfekte Wahl.

Ich zweifel an Mozilla.

Das ist eine Auskoppelung von Gedanken zu Mozillas Zukunft, die ich aus dem Artikel zur PPA-Kontroverse herausgenommen habe.

Offenbart PPA vs DNT Mozillas Stillhaltetaktik?

Privacy-Preserving Attribution zu aktivieren, den Do-Not-Track-Header aber nicht, lässt mich an der Motivation von Mozilla zweifeln.

Vielleicht war die Entscheidung für das Deaktivieren von DNT damals noch verständlich. Die enthaltene Absichtserklärung des Nutzers durch eine manuelle Aktivierung musste anfangs bewahrt bleiben, um den Header zu legitimisieren. Aber mittlerweile ist DNT auch so viel wirkmächtiger als damals. Bei Einführung gab es keinerlei Handhabe, Werbeanbieter dazu zu zwingen, auf das Signal zu reagieren. Das ist in einer Welt der Datenschutzgrundverordnung ganz anders. Und tatsächlich gibt es entsprechende Gerichtsurteile explizit für DNT. Wenn Mozilla es also wirklich darum ginge, Nutzern im Internet mehr Datenschutz zu verschaffen, müssten sie nur DNT aktivieren. Und wenn es ignoriert wird, per Abmahnungen und Prozessen die Ignoranz bestrafen. Mozilla hat eine volle Kriegskasse, hier wäre das Geld gut angelegt. Gerade Mozilla als davon berührte Partei, durch Firefox eben, hätte hier die perfekte Gelegenheit.

Aber die wird nicht genutzt. Anstatt die Welt zu verändern und den Privacy-Krieg im Internet als solchen auszufechten wird Werbeanbietern per PPA die Hand gereicht. PPA ist dabei nichtmal eine schlechte Sache – tatsächlich scheint der Mechanismus auf dem ersten Blick geeignet, Werbetracking ohne Nutzertracking umzusetzen. Aber das tut nichts zur Sache, wenn Mozilla mit DNT direkt gewinnen könnte. Das ist mir so unverständlich wie das Mittel nicht zu nutzen, in Firefox einen Werbeblocker zu integrieren. Der wäre im Interesse der Nutzer, wirkt auch ohne Industrieinvolvierung gegen Tracking, und die Befürchtung von massenhaften Einnahmenausfällen hat angesichts Firefox geringer momentaner Verbreitung auch keine Relevanz mehr.

Es liegt ein Verdacht nahe: Mozilla will mit Firefox diesen Konflikt gar nicht gewinnen. Ist die jetzige Situation für die Leitung etwa komfortabler? Firefox wird immer unwichtiger, gleichzeitig aber muss Google wegen Chromes enormer Verbreitung schon deswegen weiter Firefox finanzieren, um das Monopolverfahren abzufedern. Mit dem leicht verdienten Geld werden andere Einnahmequellen erschlossen und neue Ziele angegriffen, wie KI. Da ist viel Motivation, es sich mit Firefox mit niemanden zu sehr zu verscherzen. Der Werbeindustrie durch PPA ein Friedensangebot zu machen passt da sehr gut rein. Firefox' Nutzer stehen staunend vor solchen Entscheidungen und verstehen die Welt nicht mehr. Betrachtet man Mozilla aber als im Grunde satte Organisation, bei der es um ein immer weiteres steigern der Einnahmen (und Ausbeutung derselben) geht, passt es leider nur zu gut.

Das muss nichtmal stimmen. Im Sinne von: Da muss kein Plan des Ausnutzens der Einnahmequelle sein, keine bewusste Entscheidung zum Stillhalten. Aber es ist unbestreibar, dass es von außen so aussieht. Und es ist wahrscheinlich, dass diese Strukturen sich auf Mozillas Entscheidungen mindestens unbewusst auswirken.

Mozilla entschied nun oft klar gegen das offene Internet und Nutzerinteressen

Mozilla stellt sich ganz im Gegensatz zu meiner Einordnung oben als Verfechter der Nutzerinteressen, kompromissloser Verteidiger des offenen Internets dar. Und tatsächlich ist Firefox ja auch der beste Browser und seine Webengine unbedingt notwendig, um der Chrome-Monokultur zu entgehen. Aber Mozilla trifft immer wieder Entscheidungen, die mit dieser Mission nicht zusammengehen. Statt Nutzerinteressen zu verteidigen wird an die anderen gedacht, werden faule Kompromisse geschlossen, wird aufgegeben, wird gar gegen eigene Versprechungen gegen Nutzerinteressen gehandelt. Beispiele für alles folgen.

DNT wie oben beschrieben ist das erste Beispiel. Der Header, der den Widerspruch zu Tracking kommuniziert, wurde eingebaut – was erstmal gut war. Aber dann wurde er nicht als Standardeinstellung aktiviert. Die wenigsten Nutzer aber ändern ihre Standardeinstellung (deswegen ja auch die automatische Aktivierung von PPA). DNT wurde dadurch direkt entmachtet, weil es so selten an ist wurde es stattdessen sogar ein weiteres Bit zum Bauen des digitalen Fingerabdrucks, sodass einzelne Browserinstallationen besser trackbar werden. Das wäre nicht so, wäre DNT wenigstens in Firefox als Standard an.

Zu DNT war noch argumentiert worden. RSS wurde völlig ohne auch nur im Ansatz nachvollziehbare Rechtfertigung aufgegeben. RSS ist eine XML-Datei, die Seitenbetreiber auf ihren Server packen und immer aktualisieren, wenn sie neue Einträge schreiben (ihre Software, wie Wordpress, macht das automatisch). Leser können diese Datei mit einem Feedreader abonnieren und so komfortabel neue Artikel an einem Ort lesen, anstatt Seiten einzeln besuchen zu müssen. Klasse für Blogs, aber auch Newsseiten werden so oft konsumiert. Ein wichtiges Instrument des offenen Webs, ein Gegengewicht zu den Algorithmen von Twitter und Facebook. Firefox hatte dafür integrierte RSS-Lesezeichen, ein Symbol bei der URL-Eingabe zum Direktzugriff auf vorhandene RSS-Feeds und eine schöne Darstellung von RSS-Dateien im Browser. Nach und nach wurde das alles entfernt. Und bezeichnend: Für das RSS-Icon sei im aufgeräumten neuen Design kein Platz in der Adresszeile, aber für den aufgekauften Lesezeichendienst Pocket (mit seinem Bezahlmodell…) war Platz nie ein Problem. Dabei ist alles, war RSS gebraucht hätte, ein Icon zum Markieren der vorhandenen Feeds, ein Stylesheet zum Aufhübschen der RSS-XML-Datei (wie aboutfeeds) und eine Sammelseite mit Feedreadern und Erklärungen zur Funktionsweise gewesen (wie subtome). Riesennutzen für das dezentrale Web. Ein 1-Mann-Projekt, bräuchte keinen Monat. Aber nur Mozilla kann es umsetzen.

Mozilla macht stattdessen lieber sowas: Die Organisation hat sehenden Auges DRM den Weg in den Browser geöffnet. DRM steht für Digitales Restriktionsmanagement, durch unkontrollierbare und im schlimmsten Fall in die Hardware eingebaute Kontrollmechanismen entscheiden damit dritte, was mit Dateien auf dem eigenen Computer gemacht werden kann. Bei Mozilla ging es um Videos, also Netflix & Co, die per geschlossenem DRM-Modul verplombt werden sollten. Mozilla stimmte, obwohl das null im Interesse der Vertreter des freien Netzes war, dem dafür platzierten EME-Protokoll zu. Angeblich aus Angst, dass sonst die Nutzer weglaufen. Die liefen trotzdem weg, und heute ist Googles proprietäres DRM-Modul Widevine eine Blockade für alle anderen Browser, denn Google gibt es nicht heraus.

Auch ohne Zwang von außen kann Mozilla die eigenen Nutzer vor den Kopf stoßen. Als 2019/2020 Firefox für Android umgebaut wurde, versprach Mozilla die baldige Einführung von Erweiterungen für die Mobilversion – verschleppte sie danach aber um Jahre. Das hatte keine technischen Gründe; wie Entwickler von Mozilla berichteten, war Mozillas Management nur nicht interessiert daran das Versprechen einzulösen. Dabei hatte das eine besondere Brisanz: Auf den Mobilplattformen hatten die Plattformbetreiber immer wieder versucht, das freie Bespielen mit Software zu verhindern – besonders iOS ist ein einziges Gefängnis, aber auch Android machte eine Weile vermehrt Blockadeversuche. Erweiterungen in einem Mobilbrowser waren daher ein wichtiges Gegengewicht zu diesen Abschottungsbemühungen. Die kamen dann auch, aber erst 2023. Davor wurde nur eine Miniauswahl an Erweiterungen manuell eingebunden, immerhin auch der beliebte Werbeblocker uBlock Origins.

Ist das Problem die Struktur, mit Firma und hohen Gehältern?

Meine Vermutung: Mozilla wird sich mit solchen Entscheidungen immer weiter von seinen Nutzern entfernen. Denn die kombinierte Firma und Stiftung Mozilla teilt schon lange deren Werte nicht mehr im Kern, wie man an den obigen Entscheidungen und dem Marketingsprech ablesen kann.

Und auch das immer weiter wachsende CEO-Gehalt spricht dafür. Nicht nur die Höhe, sondern alleine dass es wächst, während Firefox Marktanteile verliert; und dass es wuchs, während Mozilla Angestellte entließ. Letzteres war einfach asozial. Kann eine sich asozial verhaltende, elitenkapitalistisch den Managementgewinn erhöhende Organisation für das offene Netz kämpfen?

Ich frage mich: War Mozillas Strukturfehler simpel, das Gehalt nicht zu deckeln? Brauchte es einen Schutz dagegen, dass eine Stiftungsfirma mit viel Geld hohe Gehälter ausspruckt und so die falsche Motivation setzt? Mit begrenztem Gehalt hätte ich eher eine Chance gesehen, passende Leute in dem System zu halten. Ich befürchte, in einer kapitalistisch orientierten Firma siegen sonst immer die Profitmaximierer, niemand gewinnt gegen Struktur. Und solche Leute treffen andere Entscheidungen. Ich kann mir einfach keinen Wirtschaftler mit Ferrari in der Garage und Millionengehalt vorstellen, der sich ehrlich um das offene Netz sorgt, der die Wichtigkeit von RSS erkennen kann. Nicht als reines Vorurteil, sondern weil das offene Netz eben auch das ressourcenlose Netz ist. Da geht es besonders um die Webseite, bei der nichtmal der Webserver Geld kosten darf. Da geht es um Abstand zu den großen Internetriesen. Kann sich da jemand reinversetzen, der sich im Umfeld genau dieser Giganten bewegt, der so viel Geld als Ressource zur Hand hat? Den es bzgl DRM z.B. gar nicht scheut, mit Google und Netflix und Co verhandeln zu müssen, wenn er einen neuen Browser baut, weil das ein Projekt mit sehr viel Startkapital sein würde und entweder darüber oder über die Beziehungen ein Platz am Verhandlungstisch sicher wäre? Versus dem Indieentwickler, bei dem gar kein Kapital da wäre und eine solche Hürde offensichtlich unüberwindbar ist.

Ich bezweifel die Eignung. Eine derart entfremdet gesteuerte Organisation bewahrt vielleicht die Geschäftsidee, den Fokus auf das Anbeiten von freieren Alternativen, doch ohne Überzeugung zu den dahinterstehenden Idealen. Und das würde viel erklären.

Natürlich hat Mozilla auch gute Entscheidungen getroffen, wie Chromes adblockerzerstörende neue Manifestversion bisher nur zusätzlich zu unterstützen. Und bei fast jeder der obigen Entscheidungen konnte man statt bösem Willen oder stukturellem Desinteresse ein legitimes anderes Abwägen vermuten. Dass das kleinere Übel gewählt wurde bei DRM beispielsweise, war Mozillas Argumentation. Und auch mir geht das so, Mozilla hat bei mir noch längst nicht das schlechte Image, das die Auflistung oben vermuten lässt. Dabei hilft, dass Firefox immer noch ein toller Browser ist, auf dem Desktop wie auf dem Telefon. Genau deswegen bleibt die Erwartungshaltung an Mozilla trotz allem intakt, genau deswegen gibt es immer noch einen Aufschrei wenn Mozilla Entscheidungen trifft, die offensichtlich oder scheinbar gegen die Interessen ihrer Nutzer verstoßen. Doch selten bewirkt der etwas, Mozilla korrigiert Fehler nur in den seltensten Fällen. So divergieren Mozillas Realität und das Ideal Mozilla immer weiter.

Mozillas Mission der offenen Alternativschaffung im Netz ist immer noch eine gute, viele Projekte Mozillas scheinen weiterhin unterstützenswert. Aber ich sehe mit Entscheidungen wie PPA, mit Abschaltungen wie beim Mozilla Location Service den Google-Reader-Moment näher rücken, in dem das positive Verhältnis zwischen Kernnutzern und Konzern wie damals bei Google unwiederbringlich aufgekündigt wird. Für manche war die Aufgabe von Servo durch Feuern der Entwickler schon ein solcher Moment. Für andere ist es vll tatsächlich die nächste Steigerung des CEO-Gehalts. Was es auch genau sein wird: Die Begeisterung, die in technischen Kreisen dem Start von Ladybird als ernsthaftes Projekt entgegengebracht wurde, zeugt davon, dass Zweifel an Mozilla weit verbreitet sind.

Okay understater, ich führe es aus.

DNT aus zu lassen, aber PPA zu aktivieren, ist unverständlich

Vor Jahren hat Mozilla den Do-Not-Track-Header (DNT) in Firefox eingebaut. Eine gute Idee, die besuchten Seiten automatisiert mitteilt, dass der Nutzer kein Tracking wünscht. Doch DNT galt lange als Misserfolg, es wurde nicht ausreichend benutzt und berücksichtigt. Das ist kein Wunder, denn selbst Mozilla ließ die Standardeinstellung auf aus. Damals argumentierte das Projekt so:

Die Mission von Mozilla ist es, den Nutzern diese Wahl und Kontrolle über ihre Browser-Erlebnis zu geben. Wir werden 'Do Not Track' nicht standardmäßig aktivieren, da sonst Mozilla die Wahl treffen würde und nicht der Einzelne. Da dies eine Entscheidung ist, die der Nutzer selbst treffen muss, können wir das Signal nicht automatisch senden, sondern werden ihnen die Werkzeuge zur Verfügung stellen, die sie dafür benötigen.

Dieses Bekenntnis zur Selbstermächtigung krüppelte einen Datenschutzmechanismus, der zu 100% im Interesse der Nutzer war.
Beim jetzigen Konflikt um Mozilla Verhalten ging es um Privacy-Preserving Attribution (PPA), ein Werbezählungsverfahren. Das ist viel weniger im Interesse der Nutzer, weil es erstmal nur Werbebetreibern nützt. Nur indirekt könnten Nutzer profitieren, wenn Werbeanbieter zugunsten einer PPA-Zählung auf Tracking verzichten würden. Dafür gibt es keine Gewissheit, naheliegend ist die Kombination Tracking plus PPA-Zählung – also völlig nicht im Interesse der Nutzer. Diesmal argumentiert Mozilla genau andersrum und lässt PPA als Standard aktiviert:

Die Datenschutzmerkmale dieses [PPA-]Prototyps sind viel stärker als sogar einige gängige Funktionen der Webplattform und erfüllen im Gegensatz zu den meisten anderen Vorschlägen in diesem Bereich unsere hohen Standards für das Standardverhalten. Es gibt eine Umschaltfunktion, um sie zu deaktivieren, da einige Personen Werbung unabhängig von den Datenschutzeigenschaften ablehnen, und wir unterstützen die Nutzer dabei, ihren Browser nach ihren Wünschen zu konfigurieren. Dennoch betrachten wir modale Zustimmungsdialoge als benutzerfeindliche Ablenkung von besseren Standardeinstellungen und glauben nicht, dass ein solches Erlebnis hier eine Verbesserung gewesen wäre.

Also: Die gleiche Organisation kommt zu zwei völlig unterschiedlichen Ergebnissen. Und verweigert DNT die Aktivierung per Standard, während PPA sie bekommt – obwohl nur DNT klar den Nutzerinteressen entspricht. Das ist schwer zu verdauen. Gerade auch die Behauptung, modale Zustimmungsdialoge als benutzerfeindlich abzulehnen, platziert Firefox doch gefühlt nach jedem Update einen neuen modalen Dialog um für Mozilla zu werben, stößt auf.

Ja, zwischen diesen Abwägungen liegen Jahre, aber DNT existiert immer noch. Mit einer neuen Einsicht in die Rolle von Standardeinstellungen müsste es neu evaluiert und dann absolut aktiviert werden. Vor allem, weil der Header sogar kürzlich juristisch aufgewertet wurde. DNT ist seitdem eine Waffe, mit der Mozilla heute schon gegen Tracking vorgehen könnte. Ganz ohne irrealistisches Warten auf eine Zusammenarbeit mit der Industrie.

PPA verstört Firefoxnutzer also nicht nur, weil PPA nur mit einer positiven Einstellung zur Werbeindustrie als sinnvolles Projekt erscheinen kann, welche die traditionell datenschutzfokussierten Kernnutzer von Firefox niemals geteilt haben. Es verstört auch die Argumentation zur Aktivierung als Standardeinstellung, weil sie völlig der bekannten Entscheidung bei DNT widerspricht. Darauf zielte mein Zitat Mozillas damaliger Argumentation ab.

Zu Mozillas PPA-Werbesignal wurde schon viel gesagt. Mein Kommentar ist Mozillas Kommentar, ihre Begründung, das inzwischen juristisch belastbare DNT-Signal nicht zu aktivieren:

Mozilla’s mission is to give users this choice and control over their browsing experience. We won’t turn on Do Not Track by default because then it would be Mozilla making the choice, not the individual. Since this is a choice for the user to make, we cannot send the signal automatically but will empower them with the tools they need to do it.

Bei mir waren durch eine Fehlkonfiguration tausende Bilder (.jpgs) von meinem Androidtelefon gelöscht worden.

Zum Glück lagen sie auf einer microSD-Karte. Um sie zu retten brauchte es daher nur einen Kartenleser (ich kaufte diesen von Hama) und ein Linuxsystem. Unter Linux installierte ich foremost:

sudo xbps-install foremost

Dann musste ich die Karte einstecken, aber nicht mounten. Ich schaute, welches Gerät unter /dev/sd* hinzugefügt wurde, bei mir war das /dev/sde samt einer Partition unter /dev/sde1. Die konnte ich von foremost durchsuchen lassen:

sudo foremost -v -t jpg -i /dev/sde1

Das packte etwa 2000 Bilder in den Ordner output/jpg/. Dann wiederholte ich das in einem zweiten Ordner, aber mit dem Parameter -d:

sudo foremost -v -d -t jpg -i /dev/sde1

Aus der Manpage:

-d Turn on indirect block detection, this works well for Unix file systems.

Und tatsächlich, das stellte soweit ich sehen konnte gleich alle verloren geglaubten Bilder wieder her, über 5000.

Ein paar Anmerkungen:

• Das hat nur funktioniert, weil die SD-Karte im portablen Modus war. Frühere Androidversionen konnten sie stattdessen auch in das System integrieren, dabei wird sie wohl verschlüsselt, auf jeden Fall war auf einer solchen in meinem Test keine Bilder auffindbar.
• Wären es nicht .jpgs gewesen, hätte foremost wahrscheinlich trotzdem geholfen, es unterstützt einige weitere Formate.
• Wären die Bilder auf dem internen Speicher des Telefon gespeichert gewesen, hätte ich keine Möglichkeit gekannt sie wiederherzustellen. Denn auf den kann nicht als Blockgerät zugegriffen werden.
• Es gibt im Playstore zwar eine ganze Reihe von Anwendungen, die das Wiederherstellen von Bildern direkt auf dem Telefon versprechen. Die können aber nicht funktionieren, weil diese Apps keinen Zugriff auf die rohen Blöcke des Speichermediums haben. Stattdessen durchsuchen sie wohl alle gespeicherten Dateien, und weil viele Systeme dem Nutzer unbekannte integrierte Papierkörbe haben finden die Apps dann manchmal Bilder wieder, ist meine Theorie. Aber im Grunde sind sie eine Betrugsmasche.
• Weil es um diese rohen Blöcke geht, die beim Löschen übrigbleiben, ist es wichtig so schnell wie möglich die Karte aus dem Telefon zu entfernen bzw es auszuschalten. Werden die Blöcke überschrieben sind sie weg, und genau das würde im normalen Betrieb nach einer Weile passieren.
• Meine vorherige Backupstrategie war das Spiegeln der Bilder mittels Syncthing. Doch genau daher kam das Problem, eine Fehlkonfiguration von Syncthing beim Einrichten eines neuen Telefons löschte die alten Bilder auf allen synchronisierten Geräte. Was das zweite mal ist, dass Syncthing mir durch eine unklare Konfiguration beinahe Daten stiehlt. Ich werde die Software jetzt aufgeben - technisch funktioniert sie, aber die Usability ist zu schlecht.
• Dabei war die Synchthingstrategie eigentlich nahe an einem echten Backup, denn normalerweise war das Backuptelefon aus, nur gelegentlich wurde die Sicherung übertragen. Das Löschen der Bilder wäre also nicht synchronisiert worden. Doch weil ein neues Telefon einzurichten war, waren ausnahmsweise alle Geräte zeitgleich an.

Bei Androidtelefonen ohne Googledienste, wenn beispielsweise LineageOS ohne diese genutzt wird, werden normalerweise keine Daten in der Cloud gesichert. Wenn dann ein Backuptelefon dazukommt oder das Hauptgerät gewechselt werden soll, müssen die Kontakte umständlich per Datei übertragen werden, der Standardkalender Etar kann seine Einträge sogar gar nicht exportieren. Da genau so ein Wechsel bei mir anstand habe ich endlich eine Synchronisierung von Kalender (CalDAV) und Kontakten (CardDAV) eingerichtet. Meine Wahl fiel auf Baïkal, gehostet auf Uberspace.

Server: Baïkal

Für Baïkal sprach, dass es sich als leichtgewichtige Lösung präsentiert, dessen Installationsanleitung auch noch simpel schien. Ein Teil davon ist, dass es mit PHP umgesetzt wurde – und PHP-An­wen­dun­gen sind eigentlich generell einfach zu installieren, harmonisieren auch gut mit Hostern wie Uberspace. Uberspace hatte ich bereits zur Hand; stattdessen sollte sich auch jeder andere Hoster eignen, auf dem eigene Serverdienste installiert werden können.

Eine Alternative zu Baïkal schien mir auf den ersten Blick sabre/dav zu sein, aber dessen Ansatz einer manuell zu editierenden server.php verriet dann, dass es sich tatsächlich um einen (sogar von Baïkal genutzten) Entwicklungsbaustein und nicht um eine Lösung für Anwender handelt. Ansonsten stolperte ich über Radicale, aber als Py­thon-Pro­gramm wäre das umständlich zu betreiben gewesen. DAViCal klang da als PHP-Pro­gramm besser, aber mir entging, dass es auch CardDAV unterstützt hätte. Viel mehr Lösungen abseits von Nextcloud sah ich nicht, was mir eine zu große Lösung mit zu vielen Zusatzfunktionen war. Am Ende blieb es also bei Baïkal, das dann auch tatsächlich so einfach einzurichten war wie erhofft.

Installation auf Uberspace

Es gibt in der Dokumentation von Uberspace eine Anleitung, die ich leicht anpassen würde.

Per SSH auf dem Uberspace, ziehen wir zuest das neueste Release von Baïkal. Derzeit wäre das:

wget https://github.com/sabre-io/Baikal/releases/download/0.9.5/baikal-0.9.5.zip

Dieses Archiv muss nun entpackt werden:

unzip baikal*.zip

Und schon haben wir den Ordner baikal zur Hand, der nach /var/www/virtual/ verschoben werden sollte:

mv baikal /var/www/virtual/$USER/

Damit das ganze dann auch von außen zugreifbar ist, setzen wir einen Symlink im Verzeichnis html/:

ln -s /var/www/virtual/$USER/baikal/html/ $HOME/html/baikal

Jetzt kann https://$USER.uber.space/baikal im Browser angesteuert und die Installation fertiggestellt werden, was bei Verwendung von SQLite auch nichts weiter erfordert. Passwort für den Adminnutzer wählen, damit steht die Instanz.

In der nun auftauchenden Verwaltungsoberfläche sollte nun aber noch ein Nutzer angelegt werden. Hier wird ein Nutzername, ein Anzeigename und nochmal ein Passwort vergeben. Diesem Nutzer wird automatisch ein Kalender und ein Kontaktbuch angelegt, damit haben wir nun etwas, mit dem die Synchronisation laufen kann.

Android: DAVx⁵ einrichten

Überraschenderweise läuft diese Synchronisation nun nicht direkt über die Anwendung für die Kontakte bzw den Kalender. Stattdessen braucht es eine Zwischenschicht, welche die Synchronisation zwischen Telefon und Server übernimmt. Eine solche (und wohl die Standardlösung) ist DAVx⁵.

Installiert werden sollte die App über F-Droid. Danach starten, die angefragten Rechte geben. Nun öffnet sich das Hauptmenü. Dort unten rechts auf + drücken. In der nun auftauchenden Auswahl ist Login with URL and user name bereits ausgewählt. Continue. Im nun auftauchenden Menü müssen wir die Baikaldaten eingeben. Lief die Installation wie oben beschrieben ist das zuerst https://$USER.uber.space/baikal/dav.php/, wobei $USER der Name des genutzten Uberspace ist (und bei einem anderen Hoster ist die URL entsprechend anders). Der untendrunter zusätzlich angefragte Nutzername ist der des im letzten Schritt der Installation angelegten Baï­kal-Nut­zers (Vorsicht: Nicht der Anzeigename, ich verhedderte mich da), eine Emailadresse ist (für die Anzeige in Android) auch einzugeben, zuletzt folgt das vergebene Passwort.

Einmal noch bestätigen und die DAV-In­te­gra­tion sollte stehen.

Android: Kontakte übertragen

Androids Standardanwendung für Kontakte, die bei ROMs wie LineageOS und CalyxOS genutzt wird, macht uns die Übertragung der Kontakte einfach. In den Einstellungen gibt es den Punkt Default accounts for new contacts. Dort wählen wir den nun verfügbaren DAV-Ac­count aus. Weiter unten gibt es den Menüpunkt Export, die verfügbare .vcf-Da­tei ist genau richtig. Denn die können wir nun direkt wieder importieren.

So landen die alten Kontakte alle im Card­DAV-Ac­count, DAVx⁵ kann sie nun synchronisieren. Einmal manuell anstoßen, schon sollte die Weboberfläche von Baïkal die Kontakte gezählt haben.

Android: Kalender übertragen

Beim Kalender macht es uns der Standardkalender Etar leider nicht so einfach. Denn der hat schlicht keine Funktion, mit der Termine von wahrscheinlich bisher genutzten Off­line-Ka­len­dern exportiert werden können. Doch glücklicherweise sind die Termine nicht Etar vorbehalten, wir können also ein anderes Programm für den Import und den Export wählen.

Ich hielt mich da an den Vorschlag dieses Kommentar und installierte erstmal den Simple Calendar Pro. Das ist zwar Teil einer gekaperten Softwaresammlung, die Version in F-Droid stammt aber von vor der Übernahme. In den Einstellungen der Anwendungen war dann CalDAV sync zu aktivieren, alle Kalender auswählen, dann einmal synchronisieren lassen (der Kommentar meint per Wischgeste von oben nach unten, visuelles Feedback sah ich dazu nicht, aber die Synchronisation lief so oder so durch). Danach konnte wieder bei den Einstellungen ganz unten der Export in eine .ics-Da­tei durchlaufen.

Der Import aber ging nicht direkt, denn die Termine seien schon vorhanden – wieder komplizierter als bei den Kontakten, wo der Import in den DAV-Ac­count trotzdem startete. Hier ist die sich heikel anfühlende Lösung, einfach die alten Kalender zu löschen. Das machte ich in Etar. Danach lief der Import (im Simple Calendar Pro) in den Cal­DAV-Ac­count problemlos durch.

Ich schreibe diesen Artikel kurz nach der Einrichtung von dem ganzen und kann noch nicht mit Langzeiterfahrungen dienen. Sollten sich Probleme auftun, werde ich den Artikel editieren.

Grundsätzlich finde ich es etwas schade, dass für diese Synchronisation überhaupt eine Serveranwendung nötig ist. Sowas könnte auch per P2P laufen, über eine kurze Abfrage gesichert. Aber nur DecSync CC ist ein in diese Richtung gehender Ansatz, der Syncthing und ähnliche Anwendungen einspannt um Kalender und Kontakte zu synchronisieren. Doch die Fehlerberichte waren leider nicht vertrauenserweckend, außerdem wäre eine eigenständige Lösung sicher komfortabler.

Wobei die Serverlösung den Vorteil hat, auch dann zu funktionieren wenn das alte Telefon nicht mehr verfügbar ist.

Generell wahrscheinlich ein Anwendungsfall, der durch die Cloudlösung von Google so weit dominiert wird, dass man sich glücklich schätzen muss überhaupt eine Alternative verfügbar zu haben.

Als das Fairphone 5 vor einer kurzen Weile von dem Linus des You­tube-Chan­nels Linus Tech Tips (LTT) ausführlich besprochen wurde, war das eine große Chance für die Firma. Fairphone ist bisher eher ein europäisches Ding und auch hier sicher nicht Mainstream, die zweite Vorstellung vor Millionen von Zuschauern (LTT hatte vorher schonmal das Fairphone 4 besprochen) konnte der Reichweite für das sympathische Konzept eines fair produzierten und reparierbaren Telefons nur guttun. Dann war das Fazit im Video aber leider durchwachsen:

Es passte nicht zu den Anforderung von Linus, der das Gerät wohl wirklich eine ganze Weile für sich selbst getestet hatte, und zeigte sich technisch deutlich schwächer als andere Telefone in der Preisklasse.

Aber darum soll es hier gar nicht gehen. Dass das Fairphone 5 nicht perfekt ist weiß jeder, der sich den fehlenden Kopfhöreranschluss ins Gedächtnis ruft. Viel schlimmer als ein eher negatives Review war die Reaktion von Fairphone, die sie in ihrem You­tube-Chan­nel als Reaktionsvideo veröffentlichten:

Mitgründer und Produktmanager Miquel Ballester Salvà zeichnet in dem Video leider das Bild einer Firma, die Kritik weder versteht noch mit ihr umgehen kann. Nun ist Ballester Salvà wahrscheinlich kein Medienprofi wie Linus und Fairphone für eine Telefonfirma (trotz Millioneninvestition) immer noch eine kleinere, überbewerten muss man ein Verfehlen des richtigen Tons nicht. Aber man kann sich schon fragen, ob die feindselige Reaktion ein gutes Zeichen für den Nutzerfokus des Projekts ist. Und auf jeden Fall kann man sich anschauen, welche Reaktionen besonders daneben waren, wie es besser gegangen wäre. Ich werde da im Folgenden ein paar Beispiele diskutieren.

Einschub zur Positionierung bzw meinen Prämissen: Das Fairphone 5 ist die Topempfehlung meiner Filterseite für nachhaltige Telefone, sustaphones, gefolgt vom Fairphone 4. Ich unterstütze die erklärten Ziele der Firma von nachhaltigerer, reparierbarer Hardware ausdrücklich. Allerdings besitze ich kein Fairphone, halte mich schon wegen des hohen Preis lieber an gebrauchte Hardware, und der fehlende Kopfhöreranschluss ist für mich ein Ausschlusskriterium. Seit dessen Entfernung in den neueren Modellen sehe ich das Projekt kritischer.

Reaktionen im Detail

Ich werde die ausgesuchten Stellen beschreiben oder direkt zitieren, immer mit Links zu den jeweiligen Abschnitten.

Ignorieren von Fehlern direkt zu Beginn

Es beginnt direkt holprig. Gezeigt wird der Beginn des LTT-Videos, in dem Linus sich zum Fan der Nachhaltigkeitsziele des Projekts erklärt. Durch eine lange Unterstützung von Softwareupdates habe Fairphone auch viel Zeit, Probleme auszubessern – was gut sei wegen "solchen Dingen", dabei zeigt die Bildspur, wie das Fairphone mehrfaches Tippen auf den Bildschirm beim Abspielen eines Videos ignoriert.

Ballester ignoriert diesen Fehler einfach. Er geht nur auf den Abschnitt zuvor ein. Dass er sich noch an den gleichen Lobgesang aus dem Review des FP4 erinnere, dass sie immer noch hier seien, mit 150 Leuten. Mit dem FP5 habe man nun ein Telefon geliefert, das leichter sei, eine bessere Kamera habe und genauso reparierbar. "Aber jetzt weiter mit dem Video".

Das ist ein denkbar ungünstiger Einstieg. Der Zuschauer fragt sich, was es mit dem Fehler bei dem Video auf sich hatte. Ballester hätte das hier ansprechen können, hätte mindestens erwähnen müssen, dass er zum Fehler später noch komme. Da er das aber nicht erklärt, entsteht direkt zu Beginn der Eindruck, dass er eben nicht da ist um unangenehme Probleme zu erklären, sondern sie zu ignorieren versucht.

Die Position der SD- und Simkarte

Kurz darauf kritisiert Linus die Position der Sim- und der SD-Kar­te. Um die zu wechseln muss man nämlich den Akku des Telefons entfernen. So cool es sei, dass der Akku leicht zu wechseln ist, warum müsse das so positioniert sein?

Ballester entgegnet:

Wie oft wechselst du die Simkarte und die SD-Karte? [Jemand schmunzelt hörbar hinter der Kamera.] Ich glaube, ich habe das nur einmal gemacht.

Das ist die falsche Antwort. Linus hatte nach dem Warum gefragt, diese Frage zu beantworten hätte hier gut gepasst. Dass Nutzer die Karten so selten wechseln könnte dabei ein Teil der Antwort sein. Vielleicht ist die Positionierung auch besser für die Reparierbarkeit. Oder sogar geschickt, weil so sichergestellt ist, dass das Telefon beim Wechseln der Karten aus ist. Ich weiß es nicht, aber eine Erklärung wäre auf jeden Fall besser gewesen als diese ausweichende Antwort. Denn so entsteht wieder der Eindruck, dass Kritik nicht angenommen wird.

Mich persönlich hätte die Begründung für die Positionierung auch wirklich interessiert. Sie ist ja schon auffällig unpraktisch, aber das Fairphone ist mit dieser Designentscheidung nicht allein. Ich erinnere mich daran, selbst schon Telefone mit dieser Platzierung der Kartenslots besessen zu haben.

Die Akkulaufzeit

Im Review wurde die Akkulaufzeit verglichen, wie solche Tests es oft machen. Linus sagt:

Einmal geladen, hielt der Akku des Pix­el-Te­le­fons doppelt so lange, bis es vollständig entladen war.

Wieder sucht Ballester eine Ausflucht:

In einem sehr speziellen Szenario, richtig? Da steht You­tube-Play­back. Ich meine, das Fairphone 5 gibt dir 10 Stunden Youtubezeit. Möchtest du 10 Stunden Youtubevideos sehen?

Das ist eine fürchterliche Antwort (und war für mich der Anlass, diesen Artikel zu schreiben). Nutzern ist die Akkulaufzeit wichtig, es ist so ziemlich der Faktor beim Auswählen eines Telefons – oder zumindest ist eine schlechte Akkulaufzeit der Grund, ein Telefon nicht zu nehmen oder das alte auszuwechseln. Ob das jetzt 10 oder 40 Stunden hält, der Punkt ist, dass das getestete Pix­el-Te­le­fon doppelt so lange durchhielt. Und das ist in vielen Situationen praktisch, denn normalerweise schlägt sich sowas nicht nur bei Youtube nieder, sondern z.B. auch auf die generelle Akkulaufzeit während einer Reise, im Zweifel ganz ohne Youtube. Die Kritik ist niederschmetternd, sie aber als unberechtigt darzustellen… mehr kann man sich in dieser Situation eigentlich gar nicht schaden.

Dabei, und das ist das frustrierende, ist eine gute Antwort so einfach. Das FP5 hat einen auswechselbaren Akku. Braucht ein Nutzer eine längere Laufzeit, kann er problemlos einen vollen Akku in das Telefon schieben. Das ist neben der Reparierbarkeit der große Vorteil des ganzen Konzepts! Aber der Produktmanager(!) des Telefons kommt da nicht drauf. Unfassbar.

Es hätte auch noch andere akzeptable Antwortmöglichkeiten gegeben. Dass für die Modularität der Akku kleiner sein müsse. Dass die Software-Optimierung noch nicht perfekt sei, dafür Ressourcen fehlten, aber man es verbessern wolle. Oder dass es wirklich nur die Youtube-Situation betreffe, wegen eines fehlenden Hardwaredekodierers des dafür besonders langlebigen Prozessors. Könnte ja alles durchaus sein, aber irgendeine Erklärung hätte es hier unbedingt gebraucht, selbst wenn die Auswechselbarkeit des Akkus spontan nicht in den Kopf kam.

Ein halbes Positivbeispiel: Die Bildschirmränder

Ballester kann auch anders, und das zeigt dann direkt, wie das Video hätte laufen können. Das will ich als abschließendes Positivbeispiel (mit Einschränkung am Ende) bringen. Linus kritisierte die Vorderseite des FP5:

Wie beim Fairphone 4 sind die Bildschirmränder [Bezels] so groß wie sie uneinheitlich sind. Dabei sind die oberen und unteren Ränder mindestens ein ganzes k dickker als die Seitenränder.

Hier funktioniert die Erklärung des Projektmanagers, denn er gibt eine. Im Verlauf der Produktionsplanung müsse für die Antenne der Bildschirm herumgeschoben werden, damit die mit den verschiedenen Providern getestete Empfangsqualität erreicht wird. Dabei entstünden diese ungleichen Ränder.

Diese Erklärung ist glaubhaft, man kann sich das Prozessproblem gut vorstellen, und vor allem wird hier erstmals im Video die Kritik nicht als illegitim dargestellt. Die ihr zugestandene Erklärung validiert sie, aber sie validiert auch für einen Moment Ballester. So eine Begründung kann der Kritik durchaus ihren Stachel nehmen. Und so hätte auch der Rest des Videos laufen sollen.

Allerdings: Diese Erklärung wird erst nach einem weiteren Ausweichversuch gegeben. Ballester beginnt so:

Linus, du hättest auch sagen können, dass die Ränder viel gleichmäßiger sind als beim Fairphone 4, denn daran haben wir sehr gearbeitet.

Das wiederum war direkt die falsche Richtung, ein klares Eingeständnis, dass die Kritik persönlich genommen wurde. Als ob es Linus Aufgabe gewesen wäre, die Gefühle des Fair­phone-Teams zu schonen, statt seine Zuschauer zu informieren. Dieser Start macht die darauf folgende ordentliche Erklärung deutlich schwerer wertzuschätzen. Selbst bei dem einen Positivbeispiel ging also noch etwas schief.

Es gab auch noch andere akzeptable Entgegnungen. So hat Ballester auch auf Kritik mit "Das sehe ich auch so, das kommt auf die Liste" geantwortet. Das ist etwas, aber eine Erklärung zu geben warum das Problem besteht wäre besser gewesen.

Generell aber war dieses You­tube-Ant­wort­vi­deo ein furchtbares Desaster. Es zeichnet das Bild eines kritikunfähigen Projekts, das Nutzerfeedback negativ sieht. Dabei ist das FP5 ein Luxusprodukt, das primär über Zuneigung zu der Mission und ethischer Überzeugung zu rechtfertigen ist, zu stark ist die günstige Konkurrenz des Massenmarkts. Und das ist generell ein Knackpunkt solcher Produkte: Ob es jetzt um alternative Linuxtelefone oder fair produzierte geht, wieviele Einschränkungen sollte der Kunde hinnehmen? Wo sind hoher Preis und geringere Qualität noch die unvermeidbaren Auswirkungen der Marktrealität und der kleinen Produktionsmenge, und wo zahlt man ohne echte Rechtfertigung für ein schlechteres Produkt durch die Nase, nur wegen einer Darstellung als sich besonders kümmernde Firma? Bei solchen Fragen muss Fairphone für einen Erfolg unbedingt auf der richtigen Seite landen, wobei gezeigte Nutzerorientierung und Kritikfähigkeit neben allen ethischen Positionierungen sicher einen großen Einfluss haben kann.

Ich frage mich, ob sich bei der Kritikfähigkeit aber gerade die ethische Mission der Firma negativ auswirkt. Fairphone muss es gewohnt sein, gelobt zu werden. Ihr ganzer Ansatz ist darauf ausgelegt, sich mit Kunden zu umgeben, die das ideologische Ziel (Faire Produktion oder Reparierbarkeit) höher schätzen als mögliche praktische Einschränkungen im Alltagsbetrieb im Vergleich zu den nunmal günstigeren Wegwerfprodukten. Auch in der europäischen Presse sah ich über Fairphone bislang kaum ein schlechtes Wort. Gibt es mal Kritikpunkte, wie im Review von Computerbase, wurde das immer mit der Wichtigkeit der Mission ausbalanciert und am Ende das Telefon darüber doch empfohlen. Da war die Herausstellung der technischen Defizite durch LTT vielleicht zu ungewohnt, zu viel für das gehobene Selbstbild?

Fairphone sollte jetzt lernen und zukünftig besser reagieren. Kritik ist nicht wegzuwischen, sondern Kritikpunkte sollten ernstgenommen und erklärt werden. Vor allem, wenn sie aus einer Ecke kommt, die so positiv zu den Zielen der Firma zu stehen scheint – Linus Sebastian ist immerhin einer der Investoren in Framework, der Firma hinter dem (kürzlich auch bei GNU/Linux.ch gelobten) modularen reparierbaren Laptop, und hat auf seiner Plattform schon oft eindringlich für das Recht auf reparierbare Hardware getrommelt.

Durch den Fehlschlag wirkt Fairphone hier unsympathisch, einfach bräsig. Wieder einmal, leider, denn schon die Entfernung des Kopfhöreranschlusses beim FP4 bei gleichzeitigem Release eines Blue­tooth-Ohr­hör­ers ohne auswechselbaren Akku(!) hatte bei vielen Leuten in der Szene für Kopfschütteln gesorgt. Eine Rechtfertigung kam spät, war nicht überzeugend und Kritik dazu in You­tube-Kom­men­ta­ren beispielsweise bleibt immer noch grundsätzlich unbeantwortet. Und beim FP5 fehlte der Kopfhöreranschluss dann direkt immer noch.

Die ungeschickten Kritikreaktion jetzt ist also nicht der erste Ausrutscher der Firma. Sondern leider beginnt sich da langsam ein negatives Bild zu verfestigen.

Erst kürzlich hatte LineageOS 21 überraschend viele Geräte auf Android 14 ziehen können, doch bereits jetzt scheint die Unterstützung von vielen dieser Telefonen ungeplant wegzubrechen.

Schuld sei ein Android-Update, berichten Projektmitglieder im Lineage-Subreddit, nämlich QPR2. Diese Zwischenversion von Android 14 mit einigen neuen Funktionen ändert diesmal wohl auch gewaltig viel an der Hardwareunterstützung, entfernt alten Code, den die nun kaputten Lineage-Geräte noch benutzten. Nun muss das Projekt entscheiden wie damit umgegangen wird: Kann Code wieder eingebaut werden oder gibt es alternative Lösungen in Android, die doch funktionieren?

Was bei den betroffenen Geräten genau kaputt ist wurde nicht beschrieben. Erwähnt wurde aber RIL, eine Kompatibilitätsschicht für die Kommunikation mit dem Modem. Diese würde nun als Alternative für weggefallenen Code gebraucht. Das Problem scheint also mindestens die gesamten Telefoniefunktionen zu betreffen.

Unklar ist, ob bei einem Scheitern der Bemühungen um QPR2 die Telefone noch mit LineageOS 20 versorgt werden würden, also mit Android 13 samt Sicherheitsupdates. Das dürfte von den jeweiligen Maintainern abhängen. Für Nutzer wäre das leider sowieso nicht ideal, vor allem nicht wenn bereits LineageOS 21 installiert war: Ein Downgrade braucht normalerweise ein Löschen der Daten auf dem Gerät, bedeutet also viel Arbeit.

In der Zwischenzeit sind alle Updates gestoppt werden. Wer schonmal schauen will, ob das eigene Gerät mit relativer Sicherheit bald wieder welche bekommt, kann auf diese Liste schauen (oben im Screenshot). Die rechts grün markierten, wieder einkommentierten Codenamen (also ohne vorangestelltes #) dürften in den nächsten Tagen die neue Version ausgeliefert kriegen. Für die anderen sieht es bisher düster aus. Darunter auch mein eigenes LG G5 (als h850 in der Liste).

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?

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…

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.