Seit ein paar Tagen ist Sublime Text 4 erhältlich. Leider hat sich der Hersteller entschlossen, diese Tatsache im entsprechenden Dialog nicht weiter zu erläutern:

Das böse Erwachen kommt nach der Installation, falls die vorhandene Lizenz älter als drei Jahre ist: mit Erscheinen von Sublime Text 4 hat der Anbieter das zu Grunde liegende Lizenzmodell geändert, so daß eine kostenpflichtige Lizenzverlängerung fällig wird. Der Preis für die Verlängerung ist mit $70 recht happig, die bisher vorhandene Lizenz wird lediglich mit $10 angerechnet.

Ein ausführlicherer Dialog wäre wünschenswert gewesen - nicht nur mit einem Hinweis, daß es sich um einen Versionswechsel handelt, sondern vor allem mit einem Hinweis, daß diese Aktualisierung u.U. kostenpflichtig ist.

Wer die Update-Prüfung deaktivieren möchte, kann dies in der "Preferences.sublime-settings" tun. Hier genügt ein

"update_check": true

damit nicht bei jedem Start des Editors ein entsprechender Hinweis erscheint.

Im abgeschotteten Intranet manchmal ein zeitsparender Faktor bei der Entwicklung, sollte man sich trotzdem genau überlegen, ob man Verbindungen von Systemen außer localhost zulassen möchte.

Auf einem Debian 10-System muß zuerst die Datei "50-server.cnf" im Verzeichnis "/etc/mysql/mariadb.conf.d/" angepasst werden:

$ cd /etc/mysql/mariadb.conf.d/
$ sudo vi 50-server.cnf

In der Datei dann die Zeile beginnend mit "bind-address" suchen und wie folgt ändern:

bind-address = 0.0.0.0

Diese Änderung bewirkt, daß der Server ab sofort über alle verfügbaren Netzwerkinterfaces erreichbar ist. Anschließend wird der Dienst neu gestartet:

$ sudo systemctl restart mariadb

Als nächster (und letzter) Schritt muß noch ein Benutzer für den externen Zugriff angelegt werden:

$ sudo mysql -u root

MariaDB [(none)]> GRANT ALL PRIVILEGES ON *.* TO 'remote'@'%' IDENTIFIED BY 'remotepassword';
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> FLUSH PRIVILEGES;
Query OK, 0 rows affected (0.001 sec)

MariaDB [(none)]> EXIT
Bye

Anschließend kann von beliebigen Quelladressen mit dem Benutzer "remote" auf alle Datenbanken zugegriffen werden. Sinnvollerweise sollte man die Berechtigungen nicht so weitreichend vergeben, sondern auf einzelne Datenbanken ("Datenbank.*") und Rechner ('remote'@'1.2.3.4') beschränken.

Technik kann frustrierend sein, vor allem, wenn die mehr oder minder geplante Obsoleszenz zuschlägt. Ein gutes Beispiel dafür ist VoLTE, eine neue Technik, deren Vorteil in einem schnelleren Gesprächsaufbau sowie dem Wegfallen des Netzwechsels auf 2G / 3G beim Telefonieren liegt.

Das Google Pixel der ersten Generation ist seit Android 7.1.1 VoLTE-fähig, Congstar hat VoLTE im Laufe des Jahres 2020 freigeschaltet, trotzdem fehlt im Einstellungsdialog die benötigte Option:

Der Status des Dienstes lässt sich mit Hilfe der Telefon-App überprüfen. Hierzu "*#*#4636#*#*" wählen, in der sich öffnenden Liste auf "Telefoninformation" tippen und über die drei Punkte in der rechten oberen Ecke den "IMS-Dienststatus" aufrufen.

Die Suche nach möglichen Ursachen und / oder Erklärungen führte ins Congstar Support Forum, wo ein Besitzer eines Google Pixel der ersten Generation erklärt:

Nun wissen wir dass einerseits das Gerät VoLTE hardwareseitig unterstützen muss, und zusätzlich in der Gerätekonfiguration hinterlegt sein muss, dass VoLTE speziell für den aktuellen Provider genutzt werden kann.
... in der CarrierConfig Stand Oktober 2019 (letztes Sicherheitsupdate für das Pixel) ist leider hinterlegt, dass Congstar kein VoLTE unterstützt. ... Nur wird unter anderem mein Google Pixel nie mehr ein Update von Google erhalten ... [Quelle]

Das Problem ist also, daß auch wenn Netz und Hardware VoLTE unterstützen, keine automatische Aushandlung erfolgt, sondern eine Konfigurationsdatei auf dem Gerät vorhanden sein muss, welche die Kombination aktiviert. Der Autor des Forenbeitrags weist noch auf die Möglichkeit hin, daß Congstar mittels einer speziellen App VoLTE auch für ältere Geräte freischalten könnte, aber die Diskussion führt leider zu keiner sinnvollen Rückmeldung des Congstar Supports.

Im Android-Hilfe Forum hat sich jemand im Thread "VoLTE/VoWiFi mit Congstar-SIM und Android 11" für das Pixel 2 mit dem Problem beschäftigt, da Google zwar eine Konfigurationsdatei ausliefert, in dieser aber leider VoLTE nicht aktiviert hat. Er kam zu einer einfachen Lösung: dem Pixel 2 die Konfigurationsdatei eines neueren Pixel-Modells unterzuschieben:

Wer Root-Rechte hat, kann das folgende Magisk-Modul installieren, um die congstar_de.pb vom Pixel 3 zu nutzen [Quelle]

Die Idee scheint sinnvoll und sollte auch mit einem Pixel 1 mit LineageOS 17.1 und installiertem Magisk funktionieren. Da ich gerne Zusammenhänge verstehe und ungern aus Foren heruntergeladene Dateien auf mein System loslasse, ging es ans Basteln.

Herunterladen und Entpacken eines Factory Images

Als erstes muß eine Konfigurationsdatei besorgt werden, welche die gewünschten Einstellungen enthält. Ich habe hierfür das aktuelle Pixel 3 Factory Image "11.0.0 (RQ1A.210205.004, Feb 2021)" verwendet, welches von der offiziellen "Factory Images for Nexus and Pixel Devices" heruntergeladen werden kann:

$ wget https://dl.google.com/dl/android/aosp/blueline-rq1a.210205.004-factory-3ab98ba8.zip

Das heruntergeladene ZIP wird entpackt, ebenso wie das darin enthaltene ZIP:

$ unzip blueline-rq1a.210205.004-factory-3ab98ba8.zip
$ cd blueline-rq1a.210205.004/
$ unzip image-blueline-rq1a.210205.004.zip

Die gesuchten Dateien befinden sich in der Datei "product.img". Um an sie heranzukommen, wird das im Android Sparse-Format vorliegende Image mit simg2img konvertiert und ins Dateisystem eingehängt:

$ simg2img product.img product.img.raw
$ mkdir product_image
$ sudo mount -o ro product.img.raw product_image/

Alle Einstellungen für die Provider liegen im Ordner "product_image/etc/CarrierSettings", von wo aus sie kopiert werden können. Danach wird der Ordner nicht mehr benötigt und kann ausgehängt werden.

$ sudo umount product_image/

Magisk-Modul

Das Magisk-Modul muß dem System lediglich eine Datei hinzufügen, alle optionalen Skripte können weggelassen werden. Die Struktur des Moduls kann der Dokumentation entnommen werden, lediglich beim Befüllen der Datei "module.prop" ist etwas Kreativität gefragt.

congstarvolte_pixel1.zip
│
├── META-INF
│   └── com
│       └── google
│           └── android
│               ├── update-binary      <--- Datei module_installer.sh
│               └── updater-script     <--- string "#MAGISK"
├── module.prop                        <--- gemäß Doku anlegen
├── system
│   └── product
│       └── etc
│           └── CarrierSettings
│               └── congstar_de.pb     <--- Datei aus dem Pixel3 Image

Nach der Installation des Moduls und vor dem zur Aktivierung notwendigen Neustart muß noch die Konfigurations-xml-Datei im Ordner "/data/user_de/0/com.android.phone/files" gelöscht werden, Congstar hat die Carrier-ID 2092.

Nach einem Neustart sollte dann auch die Ausgabe des IMS-Dienststatus passen:

Als kleine Stolperfalle wurde mit der neuen Konfigurationdatei der APN von "internet.telekom" auf "internet.v6.telekom" umgestellt. Falls es mit irgendeiner App hakt, kann manuell wieder zurückgestellt werden.

Manche Funktionsbezeichnungen lassen Interpretationsspielraum, wo besser keiner sein sollte. Die WordPress-Funktion "is_admin()" ist so ein Fall, denn wie die WordPress Code Refernce erklärt

Does not check if the user is an administrator

"is_admin()" prüft lediglich, ob der Aufruf innerhalb der Administrations-Oberfläche erfolgte. Wer sich für die tatsächlichen Berechtigungen des angemeldeten Benutzers interessiert, sollte "current_user_can()" verwenden.

Es gibt verschiedene Strategien, wie die Änderung einer Datei gespeichert werden kann. Die beiden i.d.R. eingesetzten Verfahren sind entweder die vorhandene Datei mit dem neuen Inhalt zu überschreiben oder aber den geänderten Inhalt in eine neue Datei zu speichern und dann die Dateien auszutauschen.

Unter Sicherheitsaspekten ist der Dateiaustausch klar vorzuziehen, denn erst wenn der neue Inhalt erfolgreich in die neue Datei gespeichert wurde, wird die bisherige Datei gelöscht. Beim direkten Überschreiben kann entweder beim Zugriff durch andere Programme eine halbfertige Datei geliefert werden oder es kommt durch Hardware- / Software-Fehler zu einer Situation, in welcher der alte Inhalt bereits zerstört, der neue Inhalt aber nicht erfolgreich geschrieben werden kann.

Dies hat Auswirkungen auf die Möglichkeiten, mittels inotifywait auf Dateiänderungen zu reagieren. Während beim direkten Überschreiben inotifywait ordnungsgemäß eine Änderung der Datei registriert, bricht inotifywait beim Dateiaustausch ab - die z.B. im Beitrag "Sass ohne Ruby" geschilderte Vorgehensweise scheitert dann, da die ursprünglich überwachte Datei ja nicht mehr existiert.

$ while inotifywait -e close_write style.scss; do sassc --style compact style.scss style.css ; done

Eine Möglichkeit, dies zum umgehen, ist das Überwachen des kompletten Verzeichnisses mit Abfrage der geänderten Datei

inotifywait -e close_write,moved_to,create -m . |
while read -r directory events filename; do
	if [ "$filename" = "style.scss" ]; then
		sassc --style compact style.scss .style.css
	fi
done

was aber - je nach Anzahl der im Verzeichnis vorhandenen Dateien und deren Änderungshäufigkeit - zu einer erhöhten Systemlast führen kann.