Seit mehr als sechs Jahren ist hier auf den Desktop-Systemen Debian Linux im Einsatz und das Fazit aus “Debian - ein Erfahrungsbericht” hat sich nicht geändert:

Debian is a bit boring in a good way.
Quelle

Installieren, konfigurieren und anschließend die Kiste einfach für das verwenden, für was sie angeschafft wurde - ohne sich ständig mit dem Unterbau beschäftigen zu müssen - für manche(n) pure Langeweile, für mich genau die richtige Wahl.

Eines der Argumente, die gegen Debian Stable auf dem Desktop immer wieder aufgegriffen werden ist die “alte” Software. Hier gabelt sich der Weg zwischen Aktualität und Stablilität, denn wenn während Rolling-Release-Distributionen neue Pakete direkt verteilen, sobald sich die Versionsnummer ändert, so erfolgt bei Debian der Wechsel ungefähr alle zwei Jahre.

Zu diesem Zeitpunkt gibt es Software, die schon einige Wochen oder Monate in Testzyklen vebracht hat und deren Versionsnummer(n) natürlich zum Release-Zeitpunkt ggf. bereits hinterherhinken. Dafür steigt die Wahrscheinlichkeit, daß die meisten schwerwiegenden Bugs gefunden und behoben wurden und man mit dem Upgrade wieder eine stabile Systembasis für die nächsten Jahre erhält.

Sollte tatsächlich einmal eine aktuellere Version einer Software benötigt werden, so hilft ein Blick in die Backports, in denen für die aktuelle Stable-Version rückportierte Versionen aus “Testing” angeboten werden.

Die bisherigen Upgrades liefen probemlos, trotzdem kann vor einem Systemupgrade ein Blick in die Release-Notes (hier insbesondere in die Upgrade-Hinweise) nicht schaden, genauso wie auch in die Liste der möglichen Probleme. Ab und an fällt ein Paket weg, das man vielleicht selbst noch verwendet oder es kommt zu einem größeren Umbau - dann schadet es nicht, sich vorher darüber bewusst zu sein.

Im Desktop-Umfeld habe ich bisher nur den Wechsel Buster → Bullseye → Bookworm → Trixie hinter mich gebracht, aber der älteste von mir betreute produktive Server zeigt als Installationsdatum den 07. Dezember 2012 an, damals installiert auf Basis des “Testing”-Releases von Debian Wheezy.

Durch den Sprung von rund zwei Jahren ändert sich natürlich mit dem Upgrade so einiges bei der eingesetzten Software, was an und an zu Nacharbeiten führt. Beim für diesen Blog eingesetzten Static Site Generator Hugo sprang die Software-Verion z.B. von 0.111 auf 0.131, was natürlich einige Nacharbeiten mit sich brachte. Auf der anderen Seite kann man anschließend wieder zwei Jahre bis zum nächsten Wechsel arbeiten und hat “Breaking Changes” nicht alle paar Wochen oder Monate als Überraschungspaket.

Als Grundausstattung kommt zum Großteil nur zur Distribution gehörende Software zum Einsatz, lediglich drei Fremdprogramme sind installiert: Sublime Text (das als native Linux-Version existiert) sowie Adobe Photoshop CS5 und Exact Audio Copy (die Dank Wine ihre Arbeit auch klaglos verrichten).

Auch in Sachen Spiele ist Dank GOG und Steam so einiges möglich, wobei auf Grund der Tatsache, daß unter dem Schreibtisch ein Mini-PC steht, nur moderat grafiklastige Software zum Einsatz kommt.

In Sachen Hardware gab es bisher auch noch keine Enttäuschung: egal, ob die Cherry-Tastatur, die Logitech Funkmaus oder die mittels Daisy-Chaining angebundenen Bildschirme: alles läuft problemlos.

Da kann man eigentlich nur einen großen Dank an das gesamte Team aussprechen und ab und an auch eine Spende nicht vergessen!

Werden Umgebungsvariablen auch außerhalb Terminal-Sitzung benötigt, so reicht es nicht, diese z.B. in die Datei “.bashrc” einzutragen. Das Setzen von

bewirkt zwar, daß sich alle QT-Programme an die Vorgabe halten, sofern diese über die Kommandozeile gestartet werden. Erfolgt der Start aber über einen anderen Weg, ist die Variable aus der Sicht dieser Programme nicht gesetzt und wird somit auch nicht berücksichtigt.

Wurden solche Definitionen früher in der Datei “/etc/environment” systemweit vorgenommen, lassen sich auf Systemen mit systemd die Variablen auch mit Hilfe einer Konfigurationsdatei in einem der “environment.d”-Ordner setzen:

Configuration files in the environment.d/ directories contain lists of environment variable assignments passed to services started by the systemd user instance.

Mit Hilfe einer “conf”-Datei im Verzeichnis “~/.config/environment.d/” können Variablen auch benutzerbezogen bzw. durch den Benutzer selbst gesetzt werden:

Als Copy & Paste-Vorlage …

Debian 13 “sources.list” mit “main”, “contrib”, “non-free” sowie “non-free-firmware” aktiviert:

Alternativ die “debian.sources” im deb822-Format, welche mit “apt modernize-sources” aus der “sources.list” erzeugt werden kann:

Wer die Quell-Pakete aktivieren möchte, muß in der “sources.list” die entsprechende(n) Zeile(n) entkommentieren bzw. in der “debian.sources” hinter “deb” noch ein “deb-src” einfügen.

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

Die Meldung wird von F-Droid in Zusammenhang mit GrapheneOS erzeugt, der zugehörige Hinweis findet sich in der Ankündigung zu F-Droid 1.22

• show toast when APK has more permissions than expected (if your Android distro injects extra permissions, you’ll know)

in Kombination mit dem GrapheneOS-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.

In der Vergangenheit habe ich Server so konfiguriert, daß Updates automatisiert über cron-apt heruntergeladen und installiert wurden. Seit der Einführung von systemd steht mit den uattended-upgrades eine weitere Möglichkeit zur Verfügung, welche eine detailliertere Konfiguration erlaubt.

Die Grundkonfiguration erfolgt über die Datei “/etc/apt/apt.conf.d/50unattended-upgrades”, in der nach erfolgter Installation zumindest die Parameter “Unattended-Upgrade::Mail” sowie “Unattended-Upgrade::MailReport” angepasst werden sollten.

“Unattended-Upgrade::MailReport” kann nach erfolgreicher Testphase auch wieder zurück auf den Default-Wert “on-change” gestellt werden, falls das tägliche “es gab nix zu tun” nervt.

Um die Funktionalität zu aktivieren, kann entweder die Datei “/etc/apt/apt.conf.d/20auto-upgrades” manuell angepasst oder “dpkg-reconfigure” verwendet werden. Nach dem Aufruf von

die Frage “Aktualisierungen für Stable automatisch herunterladen und installieren?” mit “ja” beantworten.

Für einen Testlauf kann “unattended-upgrade” mit dem Parameter “-d” für Debug manuell gestartet werden:

Anpassung Zeitsteuerung

Der Zeitpunkt, zu dem das Herunterladen bzw. Installieren tatsächlich durchgeführt wird, lässt sich über zwei Overrides definieren. Wichtig ist hierbei, im ersten Schritt mit “OnCalendar=” erst einmal bestehende Einträge zu löschen, bevor dann die eigenen Werte gesetzt werden - sonst werden die angegebenen Werte zusätlich übernommen.

Anschließend müssen die geänderten Konfigurationsdateien noch eingelesen und die Timer neu gestartet werden:

Der Status der Einplanung lässt sich mittels “systemctl” einsehen

Was unattended-upgrades tatsächlich so angestellt hat, lässt sich auch mit Hilfe von “journalctl” auswerten:

Drittanbieterquellen

In der Standardkonfiguration aktualisiert unattended-upgrades nur die vom System bereitgestellten Quellen, alle weiteren Quellen müssen in der Datei “/etc/apt/apt.conf.d/50unattended-upgrades” noch hinzugefügt werden. Dies sieht man im Debug-Modus hier auch am Beispiel von “zammad”:

Die benötigten Angaben kann man direkt aus der Debugausgabe entnehmen

und die Zeile dann der Sektion “Unattended-Upgrade::Origins-Pattern” hinzufügen:

Anschließend wird Zammad wie geplant aktualisiert: