In der vorletzten Podcast-Episode #381 von Binärgewitter bin ich in der Kategorie Lesefoo über einen Blogatikel gestolpert, den ich mir in Zukunft zu Herzen nehmen will: You Don’t Love systemd timers Enough .

Der Artikel beschreibt die Vorzüge von systemd-Timern gegenüber Cronjobs:

• Bessere Lesbarkeit der Zeitangaben
• Logs direkt im Journal
• Nachholen von Ausführungen
• Eingebaute Zufallsverzögerung
• Trennung des Timers von der eigentlichen Aufgabe

Laut dem Autor setzen noch viele Pinguine auf Cronjobs und verpassen somit die Möglichkeiten, die von systemd-Timer bieten. Ich fühlte mich direkt ertappt 🫣 . Daher mein Vorsatz für die Zukunft: Mehr systemd-Timer nutzen.

Der Build-Prozess und die Veröffentlichung dieser Hugo-Seite laufen eigentlich über eine eigene Git-Instanz und ein eigenes Woodpecker-CI. Das funktioniert soweit auch super und die Umsetzung ist eine Standardlösung.

Aus Demo-Gründen will ich jedoch, dass die Hugo-Quellen zusätzlich offen bei Codeberg unter https://codeberg.org/toheine/toheine_sources liegen. Darüber hinaus soll noch eine Demo-Instanz auf Codeberg Pages unter https://toheine.codeberg.page/toheine/ erreichbar sein. Auch hier steht ein beispielhaftes Vorgehen im Vordergrund. Zudem soll der Blog-Artikel hier https://toheine.codeberg.page/toheine/posts/2023/website-deployment/ keine Links enthalten, die ins Leere laufen.

Die Toolbox mit meinen zu empfehlenden Werkzeugen war etwas unübersichtlich aufgebaut. Nach dem Klick auf die Toolbox hatte man noch 5 Buttons mit den einzelnen Bereichen für Überblick, PC, Smartphone, Online-Tools und Kommandozeile. Ich habe mich nun entschieden, alles auf eine Seite zu packen. Mit der hinterlegten Inhaltsangabe und den Buttons “zum Seitenanfang” innerhalb der nun großen Seite, denke ich, dass das so ganz OK und weniger unübersichtlich ist. Zumal ich nun nur noch eine Seite schnell durchsuchen kann.

Ich bin die Tage über ein Video von @TheMorpheus gestolpert, das ich für eine absolute Empfehlung halte. Unter dem Titel Die Open Source Community bricht zusammen, veröffentlichte er hier https://www.youtube.com/watch?v=yi1QiqlB1Q4 seine Gedanken und Recherchen zu den Auswirkungen von KI auf Open-Source-Projekte.

Ich bin echt nicht oft auf YouTube, aber das Video ist ein kleines Goldstück. Morpheus erklärt hervorragend die Zusammenhänge zwischen KI und den Open-Source-Maintainern, klärt über die Belastung auf und was das für die Sicherheit in den Projekten bedeutet. In seinen Ausführungen beruft er sich unter anderem auf Veröffentlichungen der Linux-Foundation sowie dem Synopsys Open Source Security and Risk Analysis Report 2024.

Eine Sache, die mich die Tage echt beschäftigt, ist das neue KI-Modell Claude Mythos Preview von Anthropic. Nun bin ich grundsätzlich echt kein Fan der aktuellen KI-Entwicklung. Als zusätzliches Werkzeug mag der Einsatz absolut sinnvoll sein. Aber diese Entwicklung ist besorgniserregend und haut mich aus den Socken.

Um was geht es konkret? Ich versuche in den folgenden Zeilen meine Gedanken zu sammeln und ein paar Quellen zu hinterlegen. Dabei geht der Fokus nicht um die komplette Welt der SysAdmins. Vielmehr betrachte ich meine eigenen Berührungspunkte im beruflichen Alltag.

Wieder hatte ich die Gelegenheit die diesjährigen Linux-Tage in Chemnitz zu besuchen. Gemeinsam mit @and1bm , @angry , @frank , @graueralltag Jürgen und @miXsed war das wieder ein überragendes Erlebnis. Bei allen Veranstaltungen die im Jahr so anfallen, sind die CLTs mein Favorit!

Die Begegnungen und Gespräche vor Ort sind einfach unersetzlich, die Vorträge waren super und mein persönlicher Ideen-Rucksack ist prall gefüllt. Ich kann diese Art von Veranstaltung aus dem Umfeld der FLOSS-Szene total empfehlen. Das muss man erlebt haben.

Gestern hab ich Wartungsarbeiten auf einem Peertube-Server durchgeführt. Dieser verwendet im Hintergrund eine PostgreSQL-Datenbank. In diesem Zusammenhang hab ich auch das darunter liegende Debian auf die Version 13 (Trixie) aktualisiert. Dabei wurde auch die PostgreSQL Datenbank von 15 auf Version 17 aktualisert. Mittlerweile geht das ja wirklich gut von der Hand, aber wenn ich nachfolgende Warnmeldungen sehe, bin ich immer etwas skeptisch.

Durch ein paar glückliche Umstände, bekam ich die Gelegenheit dieses Jahr auf die Fosdem 2026 (Free and Open Source Software Developers European Meeting) zu fahren. Gemeinsam mit @angry sind wir am Freitag nach Brüssel gereist um uns Europas größte Entwicklerkonferenz mit über 8.000 Besuchern und 1.013 Vorträgen nicht entgehen zu lassen.

Ich bin diese Woche über die Podcast-Episode News PKI-Neuerungen, Tor-Umbau und React2Shell von Passwort gestolpert, die sich mit den Neuerungen von Let’s Encrypt sowie dem Thema PKI insgesammt angenommen hat. Die komplette Episode geht dabei auf einige weitere interessante Themen ein. Für mich wertvoll waren insbesondere die im Folgenden beschriebenen Infos.

Auf meinen PCs oder Notebooks setze ich in der Regel auf Debian oder Arch Linux. Dieser Mix ermöglicht mir entweder eine stabile Distribution mit Point-Releases (Debian) oder ein Rolling-Release-Prinzip mit wirklich aktueller Software (Arch Linux). Somit habe ich das Beste aus zwei Welten. Brauch ich auf meinen Debian-Kisten vereinzelt aktuellere Software, helfe ich mir mit Flatpak aus.

In seltenen Fällen möchte ich auf Debian neuere Software nutzen, die ich nicht über Flatpak installieren kann oder will und die aus einer zuverlässigen Paket-Quelle stammen soll. Hierfür gibt es für mich zwei Möglichkeiten:

• Debian Backports : Hier handelt es sich um Pakete aus dem Testing-Repo die jedoch mit dem aktuellen Stable-Release kompatibel sind (Zitat: adjusted and recompiled for usage on Debian stable). Das ist super. Allerdings muss das jeweilige Paket auch in den Backports vorliegen. Häufig ist genau das Paket, das ich suche, hierüber nicht verfügbar.
• Debian Testing aktivieren und über Apt pinning dafür sorgen, dass nur bestimmte Pakete aus Testing installiert werden. Grundsätzlich verbleibt das System auf dem jeweiligen Stable-Zweig.

Für mein heutiges Bedüfrnis, ein aktuelles Paket fwupd zu installieren, musste ich an dieser Stelle Variante 2 wählen, da dieses nicht über die Debian Backports angeboten wird.