Seit einigen Versionen weigert sich Firefox, Profile zu öffnen, welche von einer neueren Version des Browsers erzeugt oder geöffnet wurden.

Statt den Benutzer eine Wahlmöglichkeit “Auf eigenes Risiko öffnen” zu bieten, bleiben nur die Möglichkeiten, Firefox entweder zu schließen oder ein neues Profil zu erstellen:

Wer das Profil trotzdem in einer älteren Browserversion verwenden möchte, kann zu einem einfachen Trick greifen:

Über die Eingabe “about:profiles” lässt sich die Pofilübersicht des Browsers öffnen und mit einem Klick auf “Ordner öffnen” der Ordner des zu ändernden Profils. In diesem gibt es eine Textdatei “compatibility.ini”, in welcher der Wert der Zeile

z.B. auf

geändert werden kann. Beim nächsten Start des Browsers (ggf. mit Parameter “-p” zum Aufruf des Profilmanagers) kann dann das Profil geöffnet werden.

Um PDF-Dateien zu komprimieren, reicht Ghostscript, das auf den meisten Linux-Systemen sowieso installiert ist. An einfachsten und schnellsten geht es über die Kommandozeile:

Mit dem Schalter “-dPDFSETTINGS” können verschiedene Qualitätsstufen vorgewählt werden. Eine detaillierte Übersicht über die dadurch gesetzten Einstellungen liefert die Tabelle “Distiller Parameters”, eine Änderung der Auflösung enthaltener Bilder kann über den Schalter “-dColorImageResolution” gesteuert werden:

Bei der Installation des Fossify SMS Messenger aus dem F-Droid Store hat mich eine Meldung irritiert:

Die Meldung wird von GrapheneOS erzeugt, die zugehörige Erklärung findet sich leider nicht in den FAQ sondern nur im Forum:

The network and sensors permissions don’t exist on regular Android. They have been added by GrapheneOS. As such, apps don’t know how to request them. Leaving them on by default is done to maintain compatibility. [Quelle]

Für was Sensoren verwendet weren (können), kann man der Entwicklerdokumentation zu Android entnehmen:

Most Android-powered devices have built-in sensors that measure motion, orientation, and various environmental conditions. These sensors are capable of providing raw data with high precision and accuracy, and are useful if you want to monitor three-dimensional device movement or positioning, or you want to monitor changes in the ambient environment near a device. [Quelle]

Ob eine App tatsächlich Zugriff auf die Sensoren benötigt bzw. darauf haben soll(te), kann man bei GrapheneOS im Gegensatz zu anderen Android-Distributionen einstellen. Ein Entzug der Berechtigung kann allerdings zu Problemen führen, sollte eine App das Fehlen von Berechtigungen nicht abfangen.

WordPress bietet standardmäßig keine Möglichkeit, einen Kommentar zwischen verschiedenenen Beiträgen zu verschieben. Das Vorgehen hierbei ist aber recht ähnlich dem Verschieben aller Kommentare.

Zunächt müssen die IDs der beiden Beiträge ermittelt werden, zwischen denen verschoben werden soll sowie die ID des zu verschiebenden Kommentars. Wer das nicht direkt in der Datenbank erledigen will, kann die WordPress-Oberfläche zu Rate ziehen: einfach beim jeweiligen Artikel bzw. Kommentar auf “Bearbeiten” klicken und die ID aus der URL entnehmen, z.B. “/wp-admin/post.php?post=4392&action=edit” und “/wp-admin/comment.php?action=editcomment&c=6493”.

Dann kann der Kommentar verschoben werden:

Anschließend muß noch die Anzahl der zu den Beiträgen vorhandenen Kommentare korrigiert werden, was mit zwei weiteren SQL-Befehlen erledig ist:

Gerade wenn es darum geht, daß nur ein Delta kopiert werden soll, ist rsync (gegenüber z.B. cp) mein Werkzeug der Wahl. Umso erstaunter war ich daß rsync bei einem

immer wieder alle Dateien neu auf den USB-Stick kopierte, auch wenn zwischenzeitlich an der Quelle keine Änderungen vorgenommen wurden.

Einen ersten Hinweis auf die Ursache liefert der Beitrag “rsync to USB flash drive always transferring all data” bei Stack Exchange, denn der Stick war tatsächlich mit exFAT formatiert.

Eine Suche nach Hintergrundinformationen führte zum Microsoft Dev Blog-Beitrag “Why does the timestamp of a file increase by up to 2 seconds when I copy it to a USB thumb drive?”

This means that copying a file to a FAT-formatted device (typically a floppy drive or a USB thumb drive) can increase the timestamp by up two seconds.

in dem die Erklärung, warum immer aufgerundet wird, gleich mitgeliefert wird:

To avoid this infinite loop, the convention is always to round up, so that the copy of a file is never older than the original.

Zumindest der referenzierte Knowledge Base-Artikel “KB127830 - Time Stamps Change When Copying From NTFS to FAT” ist über die WaybackMachine des Internet Archive noch zu finden und erklärt den Mechanismus:

File time stamps on FAT drives are rounded to the nearest twoseconds (even number) when the file is written to the drive. The file timestamps on NTFS drives are rounded to the nearest 100 nanoseconds when thefile is written to the drive. Consequently, file time stamps on FAT drivesalways end with an even number of seconds, while file time stamps on NTFSdrives can end with either even or odd number of seconds.

When files are copied from NTFS drives to FAT drives, somefile time stamp rounding has to occur; the file time stamp is rounded up to the next even second.

Auch wenn sich das Beispiel auf NTFS vs. FAT bezieht, gilt das gleiche auch im Hinblick auf ext4 und FAT. Abhilfe schafft der Parameter “–modify-window” auf den auch die rsync-FAQ hinweist:

Another common cause involves sending files to an Microsoft filesystem: if the file’s modified time is an odd value but the receiving filesystem can only store even values, then rsync will re-transfer too many files. You can avoid this by specifying the –modify-window=1 option.

Mit dem Aufruf

lässt sich rsync von der Rundung nicht mehr aus der Ruhe bringen und verhält sich wie erwartet.