Linux

Ende 2012 hatte ich den Pogoplug im Blog vorgestellt. Ein kleiner ARM-Computer, der damals abverkauft wurde. Tatsächlich hatte ich den seitdem hier in Benutzung, er ist mit mir durch die Welt gezogen. Aber 12 Jahre später ist seine Zeit wohl vorbei.

Er ist nichtmal kaputt, das ist nach all der Zeit das absurde. Stattdessen sind nach und nach seine Aufgaben weggefallen. Zuletzt blieb nur noch die Rolle als Backupserver, bis ich nun merkte, dass mein Router die externe Festplatte ebenfalls einbinden kann. Neben der beschränkten Leistung hilft die Prozessorarchitektur nicht, neue Aufgaben zu übernehmen: ARMv5 wird nur noch seltenst unterstützt, wenn überhaupt. 2022 schaltete die bis zuletzt genutzte ARM-Variante von Arch den ARMv5-Zweig ab. Debian wurde dabei als Alternative genannt und vielleicht würde Debian armel tatsächlich noch funktionieren. Doch damals kriegte ich das nicht ans Laufen, heute müsste ich mich da wieder reinbeißen, was ohne Einsatzzweck wenig verlockend ist. Etwas schade – beim Kauf war nicht klar, welcher Pogo genau ankommen würde, und andere der möglichen Modelle mit ARMv6 wären heute einfacher zu nutzen.

Ich stelle ihn erstmal nur in den Schrank. Vll fällt mir doch noch was ein, was nur der Pogo und nicht der verbliebene Raspberry Pi übernehmen kann. Aber wahrscheinlich ist das nicht, sondern eher, dass der Schrank zur Ruhestätte des kleinen Computers werden wird.

Danke an der Stelle an Chris für die Empfehlung damals.

Die alternative Androiddistribution DivestOS gibt es nicht mehr. Die Entwicklung wurde komplett eingestellt, mittlerweile ist sogar die Webseite vom Netz gegangen. Angekündigt hatte der Entwickler diesen Schritt schon letzten Monat in einer News zum zehnjährigen Jubiläum, ich bezweifel aber, dass viele das mitbekommen hatten.

Das war DivestOS

DivestOS hatte als sogenanntes Custom-ROM einige Alleinstellungsmerkmale. So kam es mit Anwendungen, die extra für das System entworfen worden waren – darunter der Browser Mull, der auch abseits DivestOS genutzt werden konnte und etwas Bekanntheit erlangt hatte. Das Betriebssystem galt als datenschutzfreundlich, wobei gerade das Entfernen unnötiger proprietärer Blobs meines Wissens ein Alleinstellungsmerkmal war. Zudem wurden erstaunlich viele Telefone unterstützt, darunter auch ältere, die bei der Vorlage LineageOS schon lange aus dem Raster gefallen waren. Kein Wunder, dass das alles im Test bei GNU/Linux.ch trotz der unten zu sehenden schmalen Startkonfiguration gut abschnitt.

Oder, um die Webseite des Projekts selbst sprechen zu lassen: Ein hochgradig angepasster Fork von LineageOS mit monatlichen Sicherheitsupdates, automatisch gepatchte Kernel, Wiederverschließen des Bootloaders möglich, gehärtete Systemwebview (der interne Browser für Apps), integrierter Trackerblocker, datenschutzfreundlicher Browser (Mull); mit einem Fokus auf FOSS, Entfernung von proprietären Blobs und vorinstalliertem F-Droid. Ein Robocall-Blocker, ein Tool zum restlosen Entfernen gelöschter Dateien sowie ein Malwarescanner wurden als Extras präsentiert.

Warum der Entwickler genau jetzt aufgehört hat ist unklar. Ein Hinweis ist eben das "der Entwickler": DivestOS war ein Einzelprojekt, soweit ich das mitbekommen habe hatte sich nie ein Team gebildet. Das erklärt den erreichten Erfolg, ein einzelner fähiger Entwickler ohne Abstimmungsbedarf kann viel erreichen. Doch damit war nie jemand da, der die Entwicklung weiterführen könnte. Nach zehn Jahren kann dann schonmal die Energie ausgehen. In einem Thread zur Abschaltung auf Techlore werden letztjährige Geldprobleme erwähnt, andererseits war eine damalige Geldsammelaktion wohl erfolgreich. Er selbst schrieb, frei übersetzt:

Ich habe ein Jahrzehnt an diesem Projekt gearbeitet. Das ist eine lange Zeit und ich brauche einen Neuanfang.

Das kann jeder Entwickler mit langjährigen Projekten wahrscheinlich nachfühlen.

Die Alternativen

Doch bei allem Verständnis für den Einzelentwickler, wer sich von den guten Besprechungen überzeugen ließ steht jetzt leider im Regen. Anwender sollten möglichst schnell zu einem anderen System wechseln. Nicht nur, weil es keine weiteren Sicherheitsupdates geben wird, sondern auch wegen der an der Webseite zu sehenden Abschaltung der Infrastruktur. Die wirkt nämlich sehr überhastet. Da würde es nur zu gut ins Bild passen, dass beispielsweise die Domain ausläuft, über die bisher Updates verteilt wurden. Vielleicht ist das alles auf Clientseite gut genug abgesichert, verlassen wollte ich mich darauf nicht.

Update 02.02.2025: Wie Julian in den Kommentaren erwähnt (Danke!) gibt es mit AXP.OS ein auf DivestOS basierendes Custom-ROM, das die Ansätze von DivestOS fortführen könnte. Bleibt das Projekt nach diesem Umbruch wirklich aktiv wäre das eine weitere Option.

Die Alternativen sind:

1. CalyxOS, ein ebenfalls auf Datenschutz und mehr noch auf Sicherheit bedachtes und sehr komfortables Androidsystem, das aber leider nur sehr wenige Smartphones unterstützt.
2. iodé­OS, eine nochmal Datenschutz versprechende Option aus Frankreich. Auch hier ist die Geräteauswahl begrenzt, aber die längere Unterstützung der Geräte ein erklärtes Ziel. Anders als Calyx hat iode mehr Apps für die Startauswahl ausgewählt.
3. /e/, ein lange existierendes ROM, das schon seit Jahren integrierte Alternativen zu den Googleanwendungen (samt Onlinespeicherplatz) anbietet. Unterstützt sehr viele Telefone.
4. LineageOS, das große Ursprungsprojekt. Vorteil ist hier auch wieder die Unterstützung vieler Geräte.

CalyxOS, iodé­OS und /e/ würde ich LineageOS vorziehen, weil sie wie DivestOS freie Apps wie insbesondere den Appstore F-Droid und microG vorinstallieren und so ein benutzbares Android ausliefern, ohne dass man die proprietären Googledienste nachinstallieren muss. CalyxOS hat dabei den Vorteil, durch ein Verschließen des Bootloaders nach der Installation ein paar Angriffsszenarien auszuschließen – wie DivestOS es auf manchen Telefonen auch konnte. Damit und mit der reduzierten Appauswahl wirkt es auf mich wie die ähnlichste Alternative.

Unterstützt keine der vier Androidvarianten das eigene Gerät bleibt noch der Blick in das XDA-Forum, wo Entwickler oft handgebaute ROMs oder inoffizielle Varianten von LineageOS hochladen. Da setzt man dann aber sehr viel Vertrauen in völlig unbekannte, die Sicherheit des angebotenen ist meist unkontrollierbar. Das Wechseln auf ein moderneres, am besten von CalyxOS unterstützte Telefon würde ich eher empfehlen.

So oder so, meine Webseite sustaphones zeigt die Auswahl an unterstützten Geräten dieser vier ROMs und könnte daher die Suche nach den Optionen für das vorhandene Telefon oder die Suche nach einem neuen Telefon vereinfachen.

Das Ende von DivestOS ist ausgesprochen bedauerlich. Nicht nur für die bisherigen Nutzer, sondern auch alle anderen Interessierten steht nun eine attraktive Option weniger zur Verfügung, in einem sowieso sehr kleinem Feld an Androiddistributionen. Dabei war das Konzept auch einfach gut, für alte Geräte die bestmögliche Androidalternative zu stellen, ohne die Schwächen von einem System ohne Herstellersupport für die proprietären Bestandteile zu verschweigen. Das machte das Netz viel breiter als bei CalyxOS, war innovativer als das etwas gemächliche /e/ bei Dingen wie dem Wiederverschließen des Bootloaders, und schuf Abstand zum als Grundlage genutzten LineageOS durch die (wenigen, aber immerhin) mitgelieferten freien Softwareanwendungen.

Zudem war der Entwickler im direkten Kontakt mit mir, damals zur Einbindung des ROMs in sustaphones, freundlich und hilfsbereit. Es ist gerade im Bereich der Androidvarianten keineswegs eine Selbstverständlichkeit, dass Entwickler überhaupt mit anderen kommunizieren und noch weniger, dass sie sich dabei Mühe geben. So jemand wird fehlen. Es ist daher sehr schade, dass hier keine Strukturen gegriffen haben um das Engagements dieses Entwicklers zu bewahren – vor allem, wenn es nur um Geld ging hätte das lösbar sein sollen.

Trotzdem muss ich die kurze Warnzeit vor der Abschaltung kritisieren. Den Nutzern wurde zu wenig Zeit für einen Umstieg auf eine Alternative gegeben. Klar, Telefone mit DivestOS implodieren jetzt nicht plötzlich. Aber gerade wer kein Sicherheitsupdate verpassen will dürfte nun Stress haben. Da ist es nur gut, dass DivestOS meiner Wahrnehmung nach noch nicht allzu populär geworden war.

Im Oktober letzten Jahres hatte GNU/Linux.ch einen Programmierwettbewerb für das Spiel Spyfall veranstaltet. Spyfall ist ein Diskussionsspiel, bei dem eine Gruppe von Spielern durch Fragen den Spion in der Gruppe identifizieren müssen. In jeder Spielrunde wissen alle außer dem Spion an welchem zugeteilten Ort sie sind (z.B. in einem Bunker) und stellen einander in einem Zeitlimit Fragen. Die Programmieraufgabe war nun, dafür ein Helferprogramm zu schreiben, das einem der Spieler die Spionrolle zuweist und allen anderen den Ort verrät.

Mich hatte das (nicht nur wegen dem Preis) direkt interessiert, weil ich hier eine Möglichkeit sah Bilder im Terminal einzusetzen. Denn das geht überraschenderweise, wie mir kürzlich erst WezTerm nochmal gezeigt hatte. Ich erkläre im Folgenden meine in Bash implementierte Lösung im Detail.

Spiellogik

Die Spiellogik können wir schnell abhandeln. Am Anfang wird die Spielerzahl eingegeben:

while [[ -z $players || 0 == $players ]];do
    # ask for players and duration
    echo "Wie viele Spieler nehmen teil? [3-10]"
    read players
done

Genauso wird die Rundenlänge abgefragt:

echo "Wie viele Minuten soll die Runde dauern? [Standard 8]"
read duration
if [[ -z $duration ]];then
    duration=8
fi

Mit den Informationen kann nun aus vorher vorbereiteten Arrays mittels Bashs Zufallsfunktion ein Ort und das passende Bild ausgewählt werden:

# Select a place
placeindex=$((RANDOM%${#places[@]}))  # Zufallszahl mod der Anzahl möglicher Orte, sodass sie nie größer sein kann
place=${places[$placeindex]} # Der gewählte Index bestimmt dann den Ort
place_image=${images[$placeindex]} # Und die Bilder, siehe unten
place_image_ascii=${images_ascii[$placeindex]}

Und um die Spielerrollen zuzuweisen muss nur der Spion ausgewählt werden:

spy=$((RANDOM%players))

Die Spieler werden dann noch einer nach dem anderen über ihre Rolle informiert:

for i in $(seq 0 $((players - 1)));do
    echo "Hey Spieler $((i+1)), bist du da und alleine? Bitte bestätige mit Enter:"
    read confirmed
    if [[ $spy == $i ]];then
        # ask for players and duration
        echo "Hey Spieler $((i+1)), du bist diese Runde der Spion. Bitte bestätige mit Enter:"
        read confirmed
    else
        # ask for players and duration
        # Hierhin kommt nachher noch der Code zum Bilderanzeigen, siehe unten
        …
        
        echo "Hey Spieler $((i+1)), diese Runde spielt in $place. Bitte bestätige mit Enter:"
        read confirmed
    fi
    clear
done

Das Skript hilft während des Spiels dabei das Zeitlimit anzuzeigen, was ich recht simpel durch ein sekündliches Herunterzählen des Countdowns umgesetzt habe:

# On start, start the timer
countdown=$((duration*60))
echo "Das Spiel startet nun. Ihr habt $duration Minuten!"
while [[ $countdown > 0 ]];do
    sleep 1
    countdown=$((countdown - 1))
    echo "Noch $countdown Sekunden!"
done

Am Ende soll ein Ton abgespielt werden. Das war gar nicht so einfach. Ich wollte erst nur den Beeper im PC tönen lassen, aber der ist oft deaktiviert, war es bei mir im Terminal beispielsweise. Daher versucht das Skript zusätzlich das oft auf Systemen vorhandene Programm speaker-test einzuspannen, um für einen Moment einen Ton über den Lautsprecher auszugeben:

# Now we signal the end of the game.
# First with the bell, but that might be disabled
echo -ne '\a'
# Now with speaker-test, to use the regular sound system. Note how we kill it quietly thanks to wait
if hash speaker-test 2>/dev/null ;then
    speaker-test -t sine -f 1000 -l 1 > /dev/null &
    speaker_pid=$!
    sleep .2
    kill -9 $speaker_pid
    wait $speaker_pid 2>/dev/null
fi

Der Test auf hash speaker-test ist dabei eine der Möglichkeiten um zu testen, ob ein Befehl auf einem System verfügbar ist. Mir ist nicht mehr klar, warum ich diesen Weg und nicht einen anderen wählte, aber er funktioniert.

Das war der relevante Teil der Spielelogik. Er war verpackt in einer Funktion namens main, sodass ich außenrum noch ein paar Variablen anlegen konnte. Denn die wurden für das eigentlich interessante gebraucht.

Bilder anzeigen

Denn wie kann ein solches Bashskript nun Bilder anzeigen? Es stellt sich raus, dass manche Terminals das einfach können. WezTerm beispielsweise bringt eine Befehlkombination wezterm imgcat mit, die man auf eine Bilddatei loslassen kann, sodass die dann im Terminal angezeigt wird. Das nutzt mein Skript so:

if [[ "$TERM_PROGRAM" == "WezTerm" ]];then
    temp_file=$(mktemp)
    echo "$place_image" | base64 -d > "$temp_file"
    wezterm imgcat "$temp_file"
else

Generisch scheint das Stichwort Sixel zu sein. Ein Protokoll, um Bilder an Terminals zu übertragen und von ihnen darstellen zu lassen. Darauf kann man testen, wobei ich mir von lsix abschaute wie ein solcher Test aussehen kann. Das nutzt mein Skript alternativ:

# We detect for sixel support, partly how lsix does it
stty -echo
IFS=";?c" read -a REPLY -s -t 1 -d "c" -p $'\e[c' >&2
for code in "${REPLY[@]}"; do
    if [[ $code == "4" ]]; then
        hassixel="yup"
        break
    fi
done
hash lsix 2>/dev/null
# hacky, but I did not want to fight with the syntax to have the hash inside the [[
if [[ $hassixel == "yup" && $? ]] ;then
    temp_file=$(mktemp)
    echo "$place_image" | base64 -d > "$temp_file"
    lsix "$temp_file"
fi

Das funktioniert! Glaube ich, habe ich es doch letztendlich nur mit WezTerm getestet. Doch was hat es mit dem base64 auf sich, wo kommen die Bilder her?

Bilder im Skript mit ausliefern

Ich wollte, dass die Bilder nicht separat im Dateisystem liegen müssen, sondern dass ich sie an Ralf mit dem Programmcode in einer Datei schicken kann. Zuerst erstellte ich dafür ganz normale grafische Bilder mit einem KI-Bildergenerator (Bing, wie hier vorgestellt). Doch dann nutzte ich base64 um von der Bilddatei eine Textrepräsentation zu erstellen (es zu serialisieren) und es der Skriptdatei anzuhängen, z.B.so:

base64 Downloads/zoo.jpg >> spyfall.sh

Um diese Serialisierung auch nutzen zu können packte ich sie in eine Variable, indem ich sie mit Anführungszeichen umstellte und den Variablennamen davorstellte, also so:

zoo="…"

Diese Bilder landeten in der main in einem Array:

# Man beachte die wiederholte Nutzung der Anführungszeichen. 
images=("$cave" "$spacestation" "$desert" "$disco" "$bunker" "$corn" "$antarktis" "$zoo")

Das Array wurde im Spiel zur Auswahl des Bildes genutzt wie oben bei der Spiellogik gezeigt, indem nur die aktive Arrayposition festgelegt wurde.

Die ASCII-Ausweichlösung

Aber nicht alle Terminals können grafische Bilder anzeigen. Für die wollte ich auch eine Ausweichlösung haben. Dafür griff ich auf tiv zurück. Das ist ein Programm, das aus Bildern eine ASCII-Grafik zaubert, samt den Escapesequenzen um sie einzufärben (was in xterm mir übrigens am besten zu funktionieren schien).

Ein Pluspunkt davon: Das Programm kann ich auf meiner Seite laufen lassen, es muss beim Spieler nicht installiert sein. Beim Spieler reicht es völlig, die gespeicherte Ausgabe des Programms auszugeben. Ich musste also nur wieder die Bildrepräsentation dem Skript anhängen:

tiv Downloads/zoo.jpg >> spyfall.sh

Die wieder in einer Variable speichern:

# Man beachte das einzelne Anführungszeichen, um die Escapesequenzen zu bewahren.
zoo_ascii='…'

Und wieder ein Array vorbereiten:

images_ascii=("$cave_ascii" "$spacestation_ascii" "$desert_ascii" "$disco_ascii" "$bunker_ascii" "$corn_ascii" "$antarktis_ascii" "$zoo_ascii")

Nun ist es mit einem echo darstellbar:

else
    # Our two graphical methods failed, so we fall back to the ascii images
    echo "$place_image_ascii"
fi

Somit läuft das Skript vernünftig in allen Terminals mit Bash.

Das Spiel selbst zu programmieren war nicht schwer. Sicher, man hätte das besser machen können, so war mein Ansatz mit clear einfach alte Ausgaben zu entfernen oder den Countdown schlicht mit echo untereinander herunterzuzählen nicht ideal. Hier hätte sich ein interaktives Terminalprogramm angeboten, das (wie nano, top, etc) seinen eigenen Platz schafft und alte Ausgaben überschreiben kann. Aber Bilder einzuarbeiten war mir neues genug.

Es hat auch Spaß gemacht, sowas mal wieder in Bash umzusetzen. Damit gute Lösungen zu finden ist mehr noch ein Knobelspiel als sonst und das Ergebnis trotzdem kompakt und gut lesbar. Vorausgesetzt man verirrt sich nicht in den Bilderdefinitionen (die Skriptdatei ist übrigens 2,6 MB groß). Dass meine Implementierung dann auch noch als valider Gewinnspielkandidat akzeptiert wurde hat mich durchaus gefreut.

Wer sich das im ganzen ansehen will, ich habe das Skript als Gist hochgeladen.

Als Teil des Rückblicks aufs Jahr und als mögliche Orientierung für andere werde ich wieder meine installierten Androidanwendungen listen. Dieses Jahr war bei den Apps kein kompletter Umbruch, obwohl ich von meinem LG G5 auf ein Moto G52 und dabei von LineageOS auf CalyxOS umgestiegen bin.

Die Liste wird alphabetisch sortiert, ich überspringe die eingebauten Anwendungen, die ich nicht benutze oder für nicht relevant halte.

AntennaPod

AntennaPod, letztes mal noch neue Alternative zu Escapepod, hat sich dieses Jahr weiter bewährt. Ich habe sogar von der Funktion Gebrauch gemacht, in den Archiven von abonnierten Podcasts zu stöbern (Empfehlung: Der SpyHards Podcast, gerade auch mit guten Reviews und Interviews zu Bond-, später auch anderen Agentenfilmen).

Aurora Store

Inzwischen von Calyx vorinstalliert, funktionieren die hiermit aus dem Playstore gezogenen proprietären Apps dank microG noch öfter problemlos.

Binary Eye

Wenn mal ein QR-Code gescannt werden muss ist Binary Eye weiterhin eine unproblematische und gut gemachte Lösung. Andere Barcodes kann das Ding auch, aber das hab ich nach dem Jobwechsel damals nicht nochmal gebraucht.

Bura

Bura ist eine gut gemachte freie Wetterapp. Mir gefällt besonders, wie die Vorschau auf den Wetterverlauf gelöst ist und dass die Kacheln den UV-Index beinhalten. Warum ich forecastie hiermit auswechselte weiß ich zwar nicht mehr, aber es war ein guter Tausch.

DAVx5

Die dieses Jahr endlich angegangene Kontakt- und Kalendersynchronisation läuft hierdrüber. Danach kaum nochmal geöffnet, will ich trotzdem erwähnen, dass die Anwendung im Hintergrund scheinbar stabil lief.

DB Navigator

Installiert via dem oben erwähntem Aurora Store, also dem Play Store. Wurde weniger genutzt, weil ich weniger reiste, funktionierte aber weiterhin.

F-Droid

Calyx installiert eine reduzierte Variante von F-Droid, die Grundidee ist die gleiche: Die App ist die beste Bezugsquelle für andere Apps.

Fennec

Auch wenn ich mich dieses Jahr über Mozilla geärgert habe, die freie Variante von Androids Firefox war das Jahr über auf dem Telefon. Mit Adblock, tatsächlich auch ein paar anderen Erweiterungen und der Synchronisierung mit dem Desktopfirefox funktionierte das sehr gut.

Flora Incognita

Die Pflanzenidentifizierungsapp wurde nicht oft genutzt, gab aber etwas Sicherheit bei dem Wildwuchs auf der Terrasse nichts allzu schlimmes dabeizuhaben. Die Identifizierung ist dabei desöfteren überraschend unsicher welche Pflanze das jeweils ist, andererseits sah ich keine bessere Alternative. Leider aus dem Play Store.

FreeOTP+

Ein Generator für die Zweifaktorauthentifizierung mittels TOTP-Codes. Es gab keinen Grund zu Wechseln.

LocalSend

LocalSend fand ich via HN und erwies sich als superpraktisch. Eine Anwendung auf den Telefonen, eine auf dem PC, schon ist das Dateitauschen zwischen all den Geräten einfach und zuverlässig. Bewährt sich besonders immer dann, wenn Bluetooth mal wieder nicht koppeln will.

Microsoft SwiftKey

SwiftKey ist proprietär und dann auch noch von Microsoft, das war natürlich nicht meine erste Wahl. Aber die Tastatur funktioniert einfach hervorragend und besser als alle mir bekannten Alternativen. Das tolle an ihr ist, dass man nicht zwischen den Sprachen herumwechseln muss, alle meine drei sind gleichzeitig aktiv und die Autovervollständigung funktioniert trotzdem.

mo.pla

mo.pla verkauft das Deutschlandticket ohne die kundenfeindliche Kündigungsfrist. Die App funktionierte zuverlässig, und es gäbe sogar eine Webseite, die man stattdessen nutzen könnte. Denn die App ist leider nur im Playstore.

MuPDF

Der PDF-Anzeiger zeigt weiterhin brav PDFs an. Hat mittlerweile sogar ein nettes Logo.

Notes / Another Notes app

Über diese Notizenapp laufen vor allem meine Einkaufslisten. Das Interface ist weiterhin sehr gut, da macht es auch gar nichts, dass der Entwickler die App nur noch minimal pflegen will.

Organic Maps

Organic Maps funktionierte dieses Jahr sogar besser als zuvor für mich, weil mit dem G52 die Lokalisierung klappt. Ich glaube, dass meine Kritik bezüglich Suchfunktion und Öffnungszeiten immer noch stimmt, stolperte aber weniger öfter darüber. Vll auch nur, weil ich weniger gereist bin.

Pie Launcher

Der Pie Launcher ist noch ganz frisch auf dem Telefon, ich weiß nicht ob er sich hält. Er ersetzt die Icons auf dem Startbildschirm mit einem Pie-Menü, das aufpoppt wenn man den Bildschirm berührt. Diese Art von Menüs sieht man nicht oft, waren aber damals Studiumsstoff, es ist bisher nett sowas mal wirklich zu nutzen.

PipePipe

PipePipe ist ein alternativer Client für Youtube und andere Videoplattformen, der (anders als NewPipe) mittels Sponsorblock in die Videos geschnittene Werbung entfernt. Es sei seine eigene Codebasis, teilt sich aber Vorteile wie die lokalen Abonnements, die gut gelistet werden, und die Möglichkeit für Reisen Videos herunterzuladen.

Shattered Pixel Dungeon

Das Roguelike hat mich auch dieses Jahr wieder gelegentlich unterhalten. Es wurde auch weiter entwickelt, gerade so, dass man ab und zu mal reinschauen kann.

Signal

Signal wird bei Calyx mitgeliefert, dadurch musste ich mich nicht mit alternativen freien Clients auseinandersetzen. Es wurde mir mittlerweile deutlicher, dass Signal Telegram vorzuziehen wäre.

Telegram

Trotz Signal blieb Telegram dieses Jahr mein Hauptmessenger. Wenigstens teilweise verschlüsselt, und in Gruppen bin ich nicht, funktioniert Telegram eben doch durchaus gut.

TSUN Smart

Proprietär, Accountpflicht, in Details blöd zu bedienen – TSUN Smart wird kaum meine Lieblingsapp. Aber kontrolliert derzeit noch die Funktion der Terrassensolarzelle.

VLC

Dieses Jahr sehr selten eingesetzt, zum Abspielen heruntergeladener Videos. Die Youtubeclients hatten diesmal keinen Bug, der das Streamen zu VLC ansonsten notwendig macht.

Weggefallen sind damit:

1. Audio Recorder (kein Bedarf, Calyx liefert aber auch eine Alternative mit)
2. Forecastie (-> Bura)
3. NewPipe Sponsorblock (-> PipePipe, eingestellte Entwicklung)
4. Open Camera (Calyx Standardapp war ausreichend)
5. PDF Doc Scanner (halb, tatsächlich ist das noch auf dem LG G5 und wurde manchmal benutzt. Ich wollte vor allem bisher das Repository nicht einbinden.)
6. Syncthing (bisher ohne Ersatz, schlechte Bedienbarkeit führte zu Datenverlust)

Habt ihr wieder Empfehlungen?

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.