Schriftarten für Benutzer sollten nicht mehr in “~/.fonts” abgelegt werden. Hinweisegeber ist ein Eintrag in der Datei “/etc/fonts/fonts.conf”:

<!-- the following element will be removed in the future -->
<dir>~/.fonts</dir>

Bevorzugter Speicherort für Schriftarten eines Benutzers ist

<dir prefix="xdg">fonts</dir>

Die Dokumentation von Fontconfig erklärt

If ‘prefix’ is set to “xdg”, the value in the XDG_DATA_HOME environment variable will be added as the path prefix.

Die Definition von XDG_DATA_HOME wiederum ergibt sich aus der XDG Base Directory Specification

There is a single base directory relative to which user-specific data files should be written. This directory is defined by the environment variable $XDG_DATA_HOME.

Sollte die Umgebungsvariable nicht gesetzt sein, so wird ein Default verwendet:

$XDG_DATA_HOME defines the base directory relative to which user specific data files should be stored. If $XDG_DATA_HOME is either not set or empty, a default equal to $HOME/.local/share should be used.

Somit sollte auf einem Standardsystem das Verzeichnis “$HOME/.local/share/fonts” für Benutzerschriftarten verwendet werden.

Ist man Dank Lineage OS eine recht schlanke Betriebssystem-Installation gewöhnt, wird einem beim ersten Start eines Samsung-Geräts nicht nur leicht schwindelig: nicht nur Google hätte gerne Kontoinformationen, man soll am besten auch gleich ein Samsung-Konto einrichten und am dann auch gleich alle weiteren Apps im Samsung eigenen Galaxy-Store kaufen.

Viele andere Apps nerven und buhlen um Aufmerksamkeit (vom Hunger auf Daten ganz zu schweigen) und so drängt sich recht schnell der Wunsch auf, etwas für Ordnung zu sorgen.

Als erste Entrümplungsmaßnahme hilft überraschenderweise das Zurücksetzen auf Werkseinstellungen, denn nach diesem ist bereits ein Teil der Zusatzsoftware verschwunden.

Ein breites Schmunzeln kommt dann bei der zwangsweisen Nachinstallation von Apps während des Neustarts: während man die Samsung-Apps alle (sogar auf einmal) abwählen darf, besteht bei den Google-eigenen Apps diese Möglichkeit nicht.

Mit Hilfe der Entwickleroptionen kann man anschließend noch weiter aufräumen. Hierzu müssen diese zuerst aktiviert werden:

In den Einstellungen auf “Infos zum Tablet” wechseln und dort die “Softwareinformationen” aufrufen. Nach 7-maligem Tippen auf die “Buildnummer” werden den Einstellungen dann am Ende der Liste die “Entwickleroptionen” hinzugefügt.

In den Entwickleroptionen ist nun noch bis zum Punkt “USB-Debugging” zu scrollen und dieser zu aktivieren - dann kann es mit eingestecktem USB-Kabel ans Entrümpeln gehen.

Weiterlesen

Die Diskussion “Systemd vs. SysVinit” nimmt fast schon religiöse Züge an und erinnert in mancher Beziehung an ein Phänomen, das oft zu beobachten ist, wenn sich irgendwo irgendetwas ändert: Neumodischer Krams? Kann nur schlecht sein!

METALLICA anyone? Da gibt es auch eine Fraktion, die “alles seit dem schwarzen Album” “grottenübel” findet, und trotzdem verkaufen sich die Scheiben und Konzertkarten noch immer recht gut.

Ich persönlich hätte nichts dagegen gehabt, wenn sich Debian für ein Verbleiben beim “alten” Init-System entschieden hätte, das hat schließlich jahrzehntelang problemlos funktioniert. Mich ärgern an Systemd täglich so Dinge, wie daß ich z.B. mit einem journaldingens arbeiten muss, statt mit grep um mal schnell ein Protokoll zu durchsuchen.

Über die tatsächlichen Vor- und Nachteile und was vielleicht besser ist und was weniger haben sich eine ganze Menge kluge Köpfe ihre Gedanken gemacht, die deutlich tiefer in der Materie stecken als Meinereiner und ich habe die Hoffnung, daß die auch zu einem klugen Ergebnis gekommen sind. Nicht alles ist nur schwarz oder weiß, wir bewegen uns im Normalfall irgendwo zwischen Grauschattierungen.

Letztendlich ist mir ein zuverlässig funktionierendes System wichtig und wenn ich mich komplett von allen Datenkraken lösen möchte, dann müsste ich den Netzstecker ziehen, das Mobiltelefon wegwerfen und hätte immer noch ein Problem, wenn das nächste Mal ein Google Streetview-Auto vorm Haus vorbeirollt.

Das AppArmor-Profil für Sublime Text hat sich im Praxiseinsatz bewährt, allerdings sind im Laufe der Zeit ein paar Nebenwirkungen aufgetreten: trotz expliziter Genehmigung des Lese- und Schreibzugriffs auf alle im Besitz des Benutzers befindlichen Dateien unterhalb von “/home”

owner /home/** rw,

war es nicht möglich, z.B. die Datei “.bashrc” zu bearbeiten. Dies wurde auch entsprechend im Log protokolliert:

apparmor="DENIED" operation="open" profile="/opt/sublime_text/sublime_text" name="/home/buster/.bashrc" pid=5507 comm="file_read_threa" requested_mask="r" denied_mask="r" fsuid=1000 ouid=1000

Ursache hierfür war das Einbinden der Datei “abstractions/evince”

#include <abstractions/evince>

welche wiederum den Regelsatz um den Inhalt der Datei “abstractions/private-files” erweiterte

#include <abstractions/private-files>

wodurch letztendlich die Regel

deny @{HOME}/.bash* mrk,

im Profil aktiv war. Diese unterbindet den Lesezugriff auf alle Dateien im “Home”-Verzeichnis des Benutzers welche mit “.bash” beginnen, weshalb die spätere Genehmigung ins Leere läuft.

Das aktualisierte Profil sieht wie folgt aus:

# 2020-05-11 athul/initial
# 2020-09-29 athul/replaced abstractions/evince

#include <tunables/global>

/opt/sublime_text/sublime_text {
  #include <abstractions/X>
  #include <abstractions/base>
  #include <abstractions/dbus-session-strict>
  #include <abstractions/fonts>

  deny network,

  /opt/sublime_text/ r,
  /opt/sublime_text/** r,
  /opt/sublime_text/plugin_host mrix,
  /opt/sublime_text/sublime_text mr,
  /proc/filesystems r,
  /usr/share/** r,
  /usr/bin/perl mrix,
  /usr/bin/sassc mrix,
  owner /dev/shm/* rwl,
  owner /run/user/** rw,
  @{HOME}/** rwk,
  @{HOME} rw,
}

Neben dem Ersetzen von “abstractions/evince” wurde das Profil noch um eine Zugriffsregel für den Perl-Interpreter sowie den Sass CSS-Precompiler erweitert und auf die Variable “@{HOME}” aus “tunables/global” statt der statischen Pfadangabe “/home/…” zurückgegriffen.

Als Best Practice sollte man zur Minimierung von Nebenwirkungen mit Hilfe von “aa-genprof” die Zugriffsrechte lieber dediziert vergeben statt die vorgeschlagenen Includes einzubinden.

Leider hat Microsoft im Verbindungsdialog der Windows-Remoteunterstützung keine Möglichkeit vorgesehen, Elemente im Verlauf entweder zu bearbeiten oder zu löschen.

Wer dies trotzdem tun möchte, findet den Inhalt des Verlaufs in der Datei “RAExpertHistory.xml” im Ordner “%localappdata%”.