Auf einem Raspberry Pi hatte ich das Problem, daß ALSA bei jedem Neustart des Systems die Reihenfolge der Ausgabegeräte neu sortierte:

Mal war der PMA-50 als Karte 1 verfügbar, mal wurde ihm die 2 zugewiesen und als Folge daraus war das in der “alsa.conf” festgelegte Ausgabegerät nicht immer das von mir eigentlich gewünschte und der externe DAC blieb stumm.

ALSA kann statt der Nummer der Karte (wie in gefühlt 99% aller Beispiele zu finden) auch deren Namen verwenden werden. Eine Liste aller gültigen Geräte findet sich unter “/proc/asound/”:

Nach einer Anpassung der “alsa.conf” funktioniert der USB-DAC unabhängig von der zugewiesenen Gerätenummer:

Nach dem Update von Debian 11 auf Debian 12 zeigte ein Dell 7280 bei jedem Systemstart kurz die Meldung

was zu der Frage “Was ist SGX und wer braucht das?” führte.

Bei SGX handelt es sich um die Intel Software Guard Extensions, eine Erweiterung der Prozessorarchitektur, um Programme innerhalb des RAMs voneinander abzuschotten.

Die Erklärung, warum die Meldung nach dem Debain-Update plötzlich ausgegeben wurde, hängt mit dem verwendeten Kernel zusammen: während Bullseye noch mit dem 5.10’er Kernel lief, wird Debian Bookworm mit Kernel 6.xx ausgeliefert - der Support für Intel SGX wurde mit Kernel 5.11 eingeführt.

Seit Prozessor-Genration 11 ist SGX wohl aber wieder Geschichte, denn sowohl in den Core-i-Prozessoren der Generationen 11 als auch 12 fehlten die Software Guard Extensions wieder, was zu Problemen mit sich darauf verlassender Software führt.

Die Extensions können im BIOS mit Hilfe der Option “Intel SGX Enable” aktiviert werden. “Software Controlled” ist hierbei nicht ausreichend, die Option muß auf “Enabled” gesetzt werden, damit der Kernel zufrieden ist.

Nach einem Betriebssystem-Update von Debian 11 auf Debian 12 wollte Torchlight 2, das vor dem Update problemlos lief, nicht mehr starten: nach dem Klick auf das Icon erschien nur noch kurz der Spash-Screen … und das war’s - vom eigentlich erwarteten Startschirm fehlte jede Spur.

Als erste Möglichkeit zur Fehlersuche bietet sich meist ein Start des Programms über die Kommandozeile an, in der Hoffnung, dadurch vielleicht in paar Statusmeldungen zu sehen. Dies funktioniert auch beim Start von Torchlight 2, welches eine ganze Menge an Meldungen ausgab, bevor es letztendlich mit einem “Speicherzugriffsfehler” abbrach.

Leider führte die Kombination von “Torchlight 2” und “Speicherzugriffsfehler” bei der Suche nach Lösungsmöglichkeiten nicht zu hilfreichen Ergebnissen. Auch Tips, die in Richtung von Bibliothekskonflikten gingen halfen nicht, das Programm wieder zum Starten zu bewegen.

Zum Ziel führte letztendlich ein Blick in die Datei “ogre.log”, die auf den ersten Blick identisch mit den Ausgaben beim Programmstart aussieht, allerdings noch ein paar zusätzliche Ausgaben enthält:

So war der entscheidende Hinweis zwischen den Zeilen “Loading library RenderSystem_GL” und “Path for saving is” versteckt, im konkreten Fall ein

der sich durch Installation des Pakets libglu1-mesa letzendlich leicht beheben ließ.

Während in der Vergangenheit mehr oder minder regelmäßig Aktualisierungen für den Synology Disk Station Manager gefunden wurden, war die autmatische Suche neuerdings verdächtig lange der Meinung, daß alles Bestens wäre.

Ein Klick auf die Versionshinweise zeigte allerdings, daß sehr wohl Aktualisierungen verfügbar waren. Aktuell ist “7.2.1-69057 Update 5” vom 08.04.2024, während die noch installierte “7.2-64570 Update 3” auf den 03.08.2023 datiert.

Während die Updates 1 bis 5 zur 7.2.1 tatsächlich wohl auch nur nach Bedarf angeboten und eingespielt werden

Your Synology NAS may not notify you of this DSM update because of the following reasons.

Your DSM is working fine without having to update. The system evaluates service statuses and system settings to determine whether it needs to update to this version. [Quelle]

enthält die “7.2.1-69057” u.a. Korrekturen für einige Sicherheitslücken (u.a. Sudo, OpenSSL und Zlib) und eine Installation scheint somit sinnvoll. In den Notes steht auch die Erklärung, warum der DSM die Aktualisierung nicht anzeigt

For the models below, you can only download the upgrade patch from Synology Download Center because you won’t receive notifications for this update on your DSM.

Plus Series: …, DS218+, … [Quelle]

allerdings ohne weitere Begründung, warum diese Vorgehensweise gewählt wurde.

Eine weitere Unstimmigkeit gibt es dann noch im Download-Zentrum:

Während angezeigt wird, daß nach dem Herunterladen und Installieren von “7.2.1-69057 (with Update 1)” noch das Herunterladen von Installieren von “7.2.1-69057 Update 5” notwendig ist, meldet sich die DSM-Aktualisierung bereits nach dem Einspielen des ersten Pakets mit “DSM 7.2.1-69057 Update 5”.

In den letzten Tagen sorgte eine Änderung am “KeepassXC"-Paket in Debian für hitzige Diskussionen.

Der grundlegende Gedanke, ein Paket mit minimalem und ein Paket mit vollständigem Funktionsumfang anzubieten ist hierbei nicht ungewöhnlich: eine solche Aufspaltung gibt es bis hin zu den Desktop-Umgebungen, wo z.B. bei der Installation zwischen einem “gnome” und einem “gnome-core"-Paket gewählt werden kann, welches nur den minimal notwendigen Umfang zu Betrieb der Desktopumgebung enthält.

Was allerdings nicht nur mir unangenehm aufstößt ist die Vorgehensweise des Paketbetreuers, der statt der Erstellung eines zusätzlichen “keepassxc-core”-Pakets das ursprüngliche “keepassxc”-Paket um bestehende Funktionalität erleichtert und somit bestehende Installationen mit der nächsten Aktualisierung beschneidet.

Dies ist offensichtlich ohne vorherigen Dialog mit den KeepassXC-Entwicklern geschehen und führt dazu, daß nun vermehrt Anwender bei KeepassXC (nicht vorhandene) Fehler melden, denn

This will be painful for a year as users annoyingly do not read the NEWS files they should be reading but there’s little that can be done about that. [Quelle]

Dieser Satz und vor allem eine Aussage wie

Users who need this crap can install the crappy version but obviously this increases the risk of drive-by contributor attacks. [Quelle]

lässt aber nicht unbedingt (nur) auf sachliche Hintergründe schließen, sondern zeigt deutlich, wo das eigentliche Problem liegt - und erinnert mich von der Grundeinstellung an den Münchner OB Dieter Reiter.