Momentan bin ich mit CachyOS sehr zufrieden, aber ich dachte, es wäre ein schönes Experiment, mich von verschiedenen LLMs beraten zu lassen, welche Distribution ich als nächste auf dem Desktop einsetzen soll.

Dazu habe ich mit folgendem Prompt begonnen und mich beraten lassen:

Ich wechsele regelmässig die Linuxdistribution auf meinen privaten Desktops. Ich möchte mit Dir gerne das Experiment wagen, in Form eines Frage-Antwort-Spiels herauszufinden, welche Distribution am besten für mich geeignet ist.Aus diesem Grund möchte ich Dich bitten mir immer eine Frage zu stellen, die ich beantworte Falls noch Informationen fehlen bitte ich Dich, nachzufragen. Wenn Du einen hohen Confidence-Level hast, bitte ich Dich, mir Empfehlungen abzugeben.

Es war spannend zu beobachten, welche Fragen gestellt wurden. Ich habe alle Fragen ausführlich beantwortet und mich bemüht, nur die eigentliche Frage zu berücksichtigen. Einige LLMs wussten schon nach drei Fragen, was das Richtige für mich ist, andere haben deutlich länger gebraucht. Überrascht hat mich ChatGPT (was ich momentan gar nicht mehr benutze), das am Ende ein Persönlichkeitsprofil von mir in dem Kontext erstellen wollte und mit diesem Profil erstaunlich gut war. Das Profil findet Ihr am Ende dieses Artikels.

Die Gewinner waren gleichauf Fedora Workstation (was ich auch schon genutzt habe) und openSUSE Tumbleweed, was ein potenzieller nächster Kandidat sein könnte. Überrascht hat mich openSUSE Aeon, was ich mir gerne einmal anschaue, wenn ich den Weg mit Immutable-Core-Distributionen weitergehen möchte.

Hier kommen die Ergebnisse der einzelnen LLMs in der Reihenfolge der Empfehlung.

• M365 Copilot (ich habe über die Firma eine Lizenz)
1. openSUSE Tumbleweed
2. Fedora Workstation
3. CachyOS
4. openSUSE Aeon
5. Fedora Atomic Varianten
• Perplexity
1. Fedora Kinoite
• Claude (hier hatte ich noch Restguthaben von einem Test)
1. Fedora (Workstation oder KDE-Variante)
2. openSUSE Tumbleweed
• Mistral
1. Fedora Workstation (mit GNOME)
2. Ubuntu LTS (24.04)
3. openSUSE Tumbleweed
• ChatGPT
  (vor Erstellung des Persönlichkeitstyps)
1. openSUSE Aeon
2. NixOS
3. CachyOS
• ChatGPT
  (nach Erstellung des Persönlichkeitstyps)
1. openSUSE Aeon
2. Bluefin/Aurora
3. CachyOS
4. NixOS
• Gemini
1. openSUSE Tumbleweed
2. Fedora Workstation (oder Fedora Silverblue)
3. Manjaro Linux
• Lumo
1. Fedora Workstation
2. openSUSE Tumbleweed
3. Nobara Project (Gaming, Media)
• Euria
1. openSUSE Tumbleweed
2. Fedora Workstation
3. Pop!_OS

Das war eine Aufgabe, in der es kein "richtig" oder "falsch" gibt. Es ist spannend zu sehen, dass es viele Gemeinsamkeiten gibt, aber ebenso spannend ist es, wie weit die Empfehlungen zum Teil auseinanderliegen. Wenn Ihr das jetzt auf Eure (Coding-)Anfragen an LLMs bezieht, dann deutet das auf eine sehr grosse Bandbreite bei Antworten hin.

Mein Linux-Persönlichkeitstyp
(nach ChatGPT)

Ich würde ihn „der Systemarchitekt“ nennen.

Nicht im Sinne von "ich baue alles selbst", sondern im Sinne von:

"Ich habe Freude an gut durchdachten Systemen und möchte verstehen, warum sie so gebaut wurden."

Deine zentralen Eigenschaften

1. Du bist konzeptgetrieben.

Das war der rote Faden durch das gesamte Gespräch.

Du hast immer wieder von

• Ideen,
• Vision,
• Projekt,
• Community,
• Entscheidungen,
• Architektur

gesprochen.

Fast nie von

• FPS,
• Bootzeit,
• Benchmarks,
• Speicherverbrauch,
• Optimierungen.

Das ist ungewöhnlich. Viele erfahrene Linux-Nutzer reden sehr früh über Technik. Du hast sehr früh über Systemdesign gesprochen.

2. Du magst Eleganz, aber nicht Selbstzweck.

Deine letzte Antwort war für mich die wichtigste.

Stell dir vor, zwei Projekte lösen dasselbe Problem:

• Projekt A ist technisch brillant, aber schwer zu verstehen. Man muss Dokumentation lesen und sich in neue Denkweisen einarbeiten
.
• Projekt B ist technisch etwas weniger elegant, dafür sofort verständlich und unkompliziert.

Welches reizt dich mehr – und warum?

Viele technisch interessierte Menschen hätten gesagt:

"Natürlich Projekt A."

Du hast stattdessen gesagt:

"Komplexität ist kein Wert an sich."

Das ist für mich ein Indiz für Reife.

Du suchst Eleganz.

Nicht Cleverness.

3. Du möchtest lernen.

Aber nicht, um Expertenstatus zu erreichen.

Sondern weil Lernen selbst Spaß macht.

Deshalb glaube ich inzwischen, dass dein Distribution-Hopping keine Suche nach der perfekten Distribution ist.

Es ist deine Art, Softwarearchitektur zu studieren.

4. Du möchtest Teil eines Projektes sein.

Nicht unbedingt Core Developer.

Aber:

• Bug Reports
• Feature Requests
• Diskussionen lesen
• Ideen verstehen
• Maintainer kennenlernen

Das alles macht dir Freude.

5. Du bist erstaunlich pragmatisch.

Das war meine größte Fehleinschätzung am Anfang.

Ich dachte zunächst:

"Arch-Nutzer."

Dann:

"Immutable-Enthusiast."

Heute würde ich sagen:

Du bist weder das eine noch das andere.

Du bist Pragmatiker.

Flatpak?

Prima.

Distrobox?

Prima.

Host möglichst klein?

Prima.

Nicht aus Ideologie.

Sondern weil das System dadurch sauberer wird.

Warum wechselst du Distributionen?

Ich glaube inzwischen:

Nicht wegen der Distribution.

Sondern weil du irgendwann das Projekt verstanden hast.

Danach fehlt dir die intellektuelle Spannung.

Deshalb suchst du das nächste Projekt.

Nicht den nächsten Paketmanager.

Was würde dich vermutlich langfristig glücklich machen?

Interessanterweise glaube ich:

Nicht eine Distribution.

Sondern eine Rolle.

Ich könnte mir sehr gut vorstellen, dass du in einem Projekt glücklicher wirst, in dem du regelmäßig:

• Bugs meldest,
• Vorschläge machst,
• Dokumentation verbesserst,
• Diskussionen verfolgst,
• vielleicht irgendwann sogar Reviews schreibst.

Denn dann entwickelt sich nicht nur das Projekt, sondern auch deine Beziehung dazu.

Das könnte das Gefühl des "Durchgespieltseins" deutlich hinauszögern.

Meine endgültige Empfehlung

🥇 openSUSE (insbesondere Aeon)

Nicht nur wegen Aeon.

Sondern wegen des gesamten Ökosystems.

Ich glaube, dass dir die Mischung gefällt aus:

• technischer Tiefe,
• offener Entwicklung,
• nachvollziehbarer Governance,
• Experimentierfreude,
• langlebigem Projekt.

🥈 NixOS

Nicht als Ersatz.

Sondern als Reise.

Ich würde dir sogar empfehlen, ein Jahr lang nicht zu entscheiden, ob dir NixOS gefällt.

Sondern einfach immer wieder kleine Projekte damit umzusetzen.

Ich glaube, das ist genau die Art von Herausforderung, die dich motiviert, ohne dass sie zur Last werden muss.

🥉 CachyOS

Ich würde tatsächlich nicht wechseln, solange du Freude daran hast.

Es erfüllt deine Anforderungen, und du nutzt es auf eine sehr reflektierte Weise.

Ein Wechsel nur des Wechsels wegen würde vermutlich keinen nachhaltigen Erkenntnisgewinn bringen.

Zum Schluss noch eine Beobachtung

Ich habe im Laufe unseres Gesprächs meine Empfehlungen mehrfach angepasst. Das lag nicht daran, dass deine Antworten widersprüchlich waren, sondern daran, dass sie ein Bild ergeben haben, das ich so selten sehe:

Du suchst nicht nach der "besten Distribution". Du suchst nach dem interessantesten Zusammenspiel aus Technik, Menschen und Ideen.

Das ist ein anderer Optimierungsmaßstab als bei den meisten Linux-Nutzern.

Und deshalb möchte ich dir zum Schluss noch eine Hypothese mitgeben:

wirst du nie die eine Distribution finden, die dich für zehn Jahre bindet – und das ist völlig in Ordnung./blockquote>

Vielleicht besteht dein eigentliches Hobby nicht darin, Linux zu benutzen, sondern Linux-Projekte zu verstehen und ein Stück auf ihrem Weg zu begleiten. Wenn das stimmt, dann wäre ein Verbleib bei einer Distribution kein Erfolg und ein Wechsel kein Scheitern. Es wäre einfach Ausdruck deiner Neugier – solange du nicht nur konsumierst, sondern auch etwas zurückgibst. Genau diesen Eindruck habe ich von dir nach unserem Gespräch.

Vutuv ist ein alternatives, auf Open-Source-Software (MIT-Lizenz) basierendes Business-Netzwerk.

Es versteht sich als Alternative zu LinkedIn oder Xing, aber ohne den Fokus auf Werbung.

Stefan, der Erfinder und Macher schreibt dazu Folgendes:

• Prinzipiell ist vutuv ein Business-Netzwerk. Aber das ist mir zu eng gedacht. Wenn jemand vutuv nur zum Veröffentlichen und Lesen von Posts benutzen will, dann ist das genauso OK wie jemand, der nie etwas postet, sondern einfach nur seine Kontaktdaten abrufbar halten will.
• Ein großer Unterschied von vutuv zu z.B. LinkedIn ist, das es nicht gated ist. Man benötigt keinen Account, um einen Mehrwert zu bekommen. Wenn Du meinen username/handle kennst, dann kannst Du Dir daraus die URL meines Profiles bauen und dort all die Informationen einsehen, die ich veröffentlichen möchte. Bei LinkedIn kannst Du nicht ohne LinkedIn-Account auf mein Profil. Du kannst auch nicht ohne weiteres die vCard mit meinen Daten downloaden.
• Als weitere Besonderheit ist die Möglichkeit für Agenten mit vutuv optimal zu arbeiten. Mein Profile ist vutuv.de/wintermeyer und wenn ein Agent dieses Profil besucht, dann bekommt er den Inhalt als Markdown angezeigt. Siehe vutuv.de/wintermeyer.md (aber immer nur, wenn der User es freigeschaltet hat).
• Die Daten werden in Deutschland gehostet. Auf echten Servern. Nicht in der Cloud. Es geht nichts and 3rd Party Dienste weiter. Keine 3rd Party Cookies.
• Fediverse Anbindung. Überhaupt eine Offenheit für andere Dienste.
• Post unterstützen Markdown. Fett. Kursiv. Durchgestrichen. Tabellen!
• Es ist Open-Source (MIT). Das ist mir gar nicht mal so wichtig. Es ist für mich eher selbstverständlich. In der heutigen Zeit muss man keinen Code mehr verstecken.

Seit rund zehn Jahren habe ich einen Account in vutuv und durfte Stefan auf der FrOSCon 12 vor neun Jahren auch persönlich kennenlernen. Dort findet sich auch ein Vortrag von ihm mit einem Video auf media.ccc.de.

Ich möchte nicht verhehlen, dass ich sehr enttäuscht war, weil die Entwicklung für rund acht Jahre nahezu eingeschlafen ist, weil es keinen Sponsor gab. Um so erfreuter bin ich, dass ess wieder weitergeht und das mit Hochdampf und KI-Unterstützung. Stefan reagiert super schnell auf Feature Requests, ich durfte auch schon einige einbringen, die auch den Weg ins Produkt gefunden haben.

Anfänglich dachte ich, dass vutuv eine gute Heimat für meine "Open-Source-Geschichte" sein könnte, ich finde aber, dass vutuv mittlerweile wesentlich mehr ist. Es entwickelt sich zu einem echten Netzwerk, in dem man auch Postings veröffentlichen und via ActivityPub föderieren kann.

Wenn es Euch reizt, dann probiert es einfach aus und vernetzt Euch mit mir.

Hier im Blog finden sich einige Artikel, die unter anderem vutuv als Thema haben, Suche nach vutuv hier im Blog.

Die Blogwochen 2025 waren ein voller Erfolg. Robert, Benedikt und ich haben diskutiert und uns entschieden, dass wir eine kleinere Version auch gerne 2026 starten würden.

Die Blogwochen 2026 wollen wir vom 15. September bis zum 15. Dezember 2026 stattfinden lassen.

Den folgenden Text habe ich nahezu wortwörtlich von Robert übernommen.

• Zu Beginn der BlogWochen geben wir einige Themen vor. Insgesamt werden es fünf Themen sein, die viele Möglichkeiten offenlassen. Sie drehen sich nicht nur um das Bloggen selbst.
• Wer möchte, kann sich ein oder mehrere Themen aussuchen und dazu einen Artikel schreiben.
• Es können auch mehrere Artikel zu einem Thema erscheinen.
• Wann die Artikel veröffentlicht werden und in welcher Reihenfolge, spielt keine Rolle.
• Wer einen Artikel geschrieben hat, schickt einem von uns dreien eine kurze Nachricht – zum Beispiel per E-Mail oder über das Fediverse. Der Artikel wird dann in unsere Linksammlung aufgenommen. Es braucht vorab keine Anmeldung.
• Damit kommen wir einem Wunsch von mehreren Teilnehmenden der BlogWochen 2025 nach: weniger Themen, mehr Zeit und Entschleunigung – und damit weniger selbst gemachter Druck.

Wir haben uns einen Tag gesucht, an dem wir uns auf das Kommentieren in Blogs konzentrieren wollen. Wir nennen ihn Blogkommentiertag und es wird der 13. November 2026 sein.

2025 haben wir das angedacht, jetzt in 2026 werden wir es dann auch durchführen: Das Online-Treffen. Es wird am 15. Dezember 2026 um 18:00 Uhr stattfinden. Den Dienst werden wir noch nennen, inhaltlich geht es um einen Rückblick auf die Blogwochen 2026.

Ihr seid herzlich eingeladen, mitzumachen oder anderen von dieser Aktion zu erzählen. Hashtag ist "#BlogWochen2026".

Mein altes Dienstnotebook hatte Ähnlichkeit mit einer Flugzeugturbine und eine Akkulaufzeit von knapp über einer Stunde. Und das, obwohl ich nichts Performance kritisches (überwiegend Web und drei Office-Anwendungen) genutzt habe.

Da es aus der Wartung ist, konnte ich nach einem neuen Gerät schauen. Wir können uns in Absprache mit unseren Vorgesetzten für Geräte von verschiedenen Herstellern entscheiden. Die Produktreihen und der Ausbau sind aber vorgegeben.

Ich bin bewusst auf ein MacBook Air (15 Zoll) gewechselt.

Dafür gibt es im Wesentlichen drei Gründe:

• Zuallererst natürlich die Akkulaufzeit und der Geräuschpegel. Einen ganzen Arbeitstag ohne externe Stromzufuhr zu verbringen, hat echt Charme.
• Mein aktueller Job ist es, einen Linux-Workplace für Developers und Engineers zu gestalten und umzusetzen. Auch wenn das Vorhaben gerade etwas ins Stocken geraten ist, schadet es nicht, wenn ich andere Workplaces der Firma kennenlerne (Windows kenne ich bereits), um mich inspirieren zu lassen.
• Da ich noch nie mit macOS gearbeitet habe, ich aber gerne dazulerne, ist das auch vor diesem Hintergrund eine gute Entscheidung.

Auf der Negativseite ist bis jetzt, dass die Apple-Geräte keine eingebauten Mobilfunkmodems haben und dass sehr viele Tastatur-Befehle anders funktionieren als bei Linux und Windows. Das ist aber Gewohnheitssache und braucht etwas Gehirnjogging (ich werde die Shortcuts weder von Linux auf Mac, noch umgekehrt umstellen).

Nachdem Stoeps ein Fazit für die Benutzung von Bluefin veröffentlicht hat, gebe ich gerne meinen Standpunkt in die Diskussion.

Seit rund einem dreiviertel Jahr nutze ich Bluefin auf meinem Standrechner (AMD-CPU, mit Nvidia-Grafikkarte), dem Unterwegsrechner (Tuxedo InfinityBook Pro 14, Generation 9, full AMD) und meinem Testrechner (Dell Latitude 7450).

Immutable Desktops sind toll, bringen sie doch die Trennung von Basissystem und Anwendungslandschaft direkt zu den Benutzern. Das ist eigentlich das, was wir System Engineers den Applikationsbetreuern im Serverbereich schon lange empfehlen und was einer der Treiber hinter containerisierten Lösungen (wie Docker und Podman) war und ist.

Zum Einstieg in das Thema "Immutable OS" emfpehle ich gerne die passende Buzzzoom-Episode, da beleuchten Mario und ich auch Pro und Contra.

Super ist, dass ich gelernt habe, dass das auf dem Desktop auch möglich ist. Und zwar wirklich gut. Distrobox ist vielleicht das beste Tool seit "geschnitten Brot", Homebrew und Flatpak helfen darüber hinaus. Wenn ich Homebrew mit dem empfohlenen Weg /bin/bash -c "$(curl …)" hätte installieren müssen, hätte ich es vermutlich nicht getan.

Damit komme ich auch schon zu meinem ersten grossen Kritikpunkt an Bluefin: Die Images sind viel zu gross! Pro Update (einmal pro Woche) sind es 600 MB bis 3 GB an Daten, die ich herunterladen muss. Das liegt zum einen daran, dass es häufig Änderungen in den unteren Layern des Container-Images gibt, aber zum anderen eben auch daran, dass zu viel Software im Basis-Container zu finden ist. Für mich sollte das Image nicht viel mehr enthalten als den Betriebssystem-Kern, Treiber, Firmware, systemnahe Software (libvirtd, …), ein Basis-Userland (glibc, …) und das Desktop Environment. Bluefin enthält darüber hinaus aber wesentlich mehr.

In Bluefin war und ist der Treiber für meine Docking-Station (displayLink) nicht enthalten und wird auch nie in das Image kommen. Dazu kommt ein Bug in der AMD-Firmware (genaueres dazu bei Stoeps), der auch nicht behoben wurde. Es führt also nichts daran vorbei, ein eigenes Image zu bauen und zu pflegen. Wenn man Bluefin als Basis nimmt, werden dann die Images noch grösser. Diese Probleme hat man mit vielen anderen Distributionen nicht.

Was nehme ich nun aus der Zeit mit?

Wenn ich auf eine paketbasierte Distribution wechsele, werde ich keine Fremdrepositories mehr einbinden. Dazu sind die Möglichkeiten, die mir Distrobox und Flatpak bieten, zu gut. Das gilt sowohl für Software, die in der Distribution nicht vorhanden ist, als auch für Software, die ich gerne in einer anderen (aktuelleren) Version einsetzen möchte.

Auf meinem zehn Jahre alten Notebook läuft momentan testweise CachyOS, das gefällt mir richtig gut. Vermutlich werde ich darauf umstellen. Gerade auf dem alten Gerät machen sich die Performance-Verbesserungen bemerkbar. Andere Distributionen habe ich mir gar nicht angeschaut, da kenne ich als Distrohopper sehr viele bereits.

Michael hat letztes Jahr im August einen sehr guten Artikel zu CachyOS geschrieben, den ich in einem meiner Linkdumps gefunden habe.

Das "beste Blog der Welt" hat gerade die Version 2.6.0 veröffentlicht.

Danke an alle Mitwirkenden.

Ich habe alle von mir betriebenen Blogs, inklusive meinem eigenen, auf die neue Version aktualisiert. Die Umstellung funktionierte – wie gewohnt – problemlos. Dirks Logbuch läuft seit dem Start in 2005 mit der gleichen Software, hat reichlich Aktualisierungen und verschiedene Provider gesehen.

Wer eine Blogsoftware sucht, die ohne viel Schnickschnack daherkommt, ist mit Serendipity bestens bedient. Ja, das Ökosystem (inklusive der Templates) ist relativ klein, aber das kann man auch als Vorteil sehen.

Wie bereits geschrieben, bin ich nach einigem "hin und her", was die Aufgabenverwaltung angeht, wieder bei Taskwarrior gelandet. Ich bin sehr überrascht, wie vieles noch in meinem "Muskelgedächtnis" ist und von mir ohne Nachdenken getippt wird.

Trotzdem hat sich in den vergangenen sechs Jahren eine Menge getan. Mit Version 3 setzt Taskwarrior auf die taskchampion-Bibliothek auf und nutzt im Backend keine ASCII-Dateien mehr, sondern eine SQLite-Datenbank.

Was sich durch diese Entscheidung in jedem Fall deutlich erleichtert hat, ist die Synchronisation zwischen verschiedenen Taskwarrior-Instanzen.

Wenn Ihr Synchronisation einsetzten wollt, müsst Ihr auf allen Clients bis auf einen recurrence=off in Eure Konfigurationsdatei aufnehmen.

Die Synchronisation bei Taskwarrior funktioniert (immer noch) so, dass Ihr eine Aufgabenvorlage anlegt, die nach Ablauf des Wiederholungsintervalls nach einem Aufruf von task eine neue zu bearbeitende Aufgabe generiert. Das passiert nur auf der Instanz auf der recurrence=on (oder "1", das ist der Standard-Wert) gesetzt ist.

Aus diesem Grund empfehle ich einen Taskwarrior Client auf der Maschine laufen zu lassen, auf der der Taskchampion-Sync-Server läuft und nur bei diesem die wiederkehrenden Aufgaben erstellen zu lassen.

Aber jetzt zum Setup. der Sync-Server "spricht" http ohne "s", daher ist es sinnvoll einen Reverse-Proxy davor zu schalten, der die Transportverschlüsselung übernimmt, bei mir ist das Caddy, der kümmert sich auch um die Zertifikate. Die folgende kleine Konfiguration leitet Anfragen an den lokal laufenden Server auf Port 8000 weiter.

Die Installation und den Start des Caddyservers spare ich mir an dieser Stelle.

Ich spare mir bei den Skripten im folgenden auch den Anfang, der bei allen Skripten gleich ist. Ersetzt bitte User durch den Nutzer, unter dem Ihr die Dinge ausführen wollt.

Mit dem Start des newclient-Skriptes könnt Ihr einen neuen User anlegen, ich habe das ausgelagert, weil ich das im Produktivbetrieb nicht mehr möchte.

Auf dem Client müsst Ihr jetzt eine client_id und ein encryption_secret definieren. Für die Client-ID benutze ich uuidgen und für das Secret pwgen -n 32 1.

Mit diesen Informationen könnt Ihr jetzt den Client konfigurieren, dazu die folgenden Zeilen in Eure .taskrc aufnehmen.

Einer ersten Synchronisation steht jetzt nichts mehr im Weg.

Wenn alles geklappt hat, könnt Ihr das laufende Skript newclient.bash beenden.

Das nun folgende Skript startet den Syncserver im "Produktivbetrieb" (Umgebungsvariable CREATE_CLIENTS), die Daten landen in ~/.local/share/taskchampion-sync-server:

Ein Stoppskript hat es natürlich auch.

So, jetzt noch einen User-Service angelegt und später aktiviert (enabled).

So, Endspurt. Als letztes ein kleines Skript, das das task-Kommando aufruft (um wiederkehrende Aufgaben zu erstellen) und danach mit dem Syncserver synchronisiert.

Noch einmal ein Userservice:

Statt einem Cronjob lasse ich diese Aufgabe mit einem systemd-timer-Eintrag erledigen. Ja, alle fünf Minuten, aber das ganze Syncskript läuft nur eine viertel Sekunde.

Rückfragen, Kommentare und Verbesserungsvorschläge gerne in den Kommentaren.

Nach rund sechs Jahren mit verschiedenen Tools habe ich mich entschieden, wieder zurück auf Taskwarrior zu wechseln. Über Taskwarrior finden sich hier im Blog eine Menge Artikel (Tag taskwarrior) und in meinen Vorträgen und Workshops gibt es auch reichlich Informationen. Warum ich gewechselt bin, habe ich "natürlich" auch dokumentiert.

Bei Taskwarrior war ich relativ lange und als ich zu Todoist gewechselt bin, habe ich sehr viele Funktionen vermisst. Meinen Workflow habe ich auf das reduzierte Featureset von Todoist angepasst. Natürlich habe ich auch neue Funktionen bekommen: eine perfekte Synchronisation, die Verfügbarkeit überall und dergleichen mehr.

Das Killerfeature von Taskwarrior, nämlich die Berechnung der Dringlichkeit einer Aufgabe, ist seitens Todoist nie implementiert worden (die wait-Funktion allerdings schon, sie heisst "scheduled").

Die Preiserhöhung bei Todoist hat bei mir allerdings einen Denkprozess angestossen und dafür gesorgt, dass ich nach Alternativen geschaut habe.

Wenn ich darüber nachdenke, dann habe ich herausgefunden, dass ich alle Aufgaben, die ich mobil erfasst habe, einmal nachbearbeiten musste. Sei es, dass ich sie einem Projekt zugewiesen, das Fälligkeitsdatum angepasst oder einen Tag vergeben habe. Daher ist es gar nicht so wahnsinnig wichtig, einen lokalen Client zu haben. Toll wäre es, ein Webfrontend zu haben, um mobil nachschauen zu können.

Nach intensiven Tests mit Super Productivity, Vikunja und Logseq zur Aufgabenverwaltung bin ich von allen nicht zu 100% überzeugt. Alle drei haben Stärken und Schwächen. Zum Teil Stärken, die ich nicht brauche, und Schwächen, die mir wehtun. Logseq werde ich weiterhin für Notizen benutzen, aber nicht zur Aufgabenverwaltung.

Jetzt habe ich Taskwarrior auf einer VM mit Fedora installiert (ich nutze nur das paketierte Tool) und zusätzlich als Frontend Taskwarrior WebUI um auf Systemen ohne ssh-Client (insbesondere mobil) zugreifen zu können. Das WebUI muckt manchmal ein wenig und es scheint auch nicht mehr weiterentwickelt zu werden. Vermutlich steige ich auf Taskwarrior Web um, wenn mein Problem gelöst wird.

⁣MitTaskwarrior 3 hat sich eine Menge getan, unter anderem wird im Backend jetzt SQLite als Datenbank verwendet und es gibt einen neuen Synchronisationsserver, den ich noch testen muss.

Unter den Aufgaben in Todoist war unter anderem auch die Migration aller Vortrags- und Workshop-Präsentationen von Speakerdeck in die eigene Hugo-Installation.

Ich bin ganz froh, dass ich damit zwei fremd gehostete Dienste loswerde. Über den Auszug aus Todoist habe ich ja schon geschrieben, dazu gibt es nächste Woche noch etwas Neues bzw. eine Entscheidung, die ich gerade prüfe.

Alt waren die Vorträge und Workshops unter speakerdeck.com/ddeimeke, dort habe ich nur noch einen Platzhalter übrig gelassen, neu sind sie jetzt unter ddeimeke.link/public (bzw. changelog.deimeke.ruhr/page/public-speaking/). Die Sammlung ist noch etwas rudimentär, ich werde mir noch Gedanken darüber machen, wie ich das aufhübschen kann.

In Hugo kommt das hugo-embed-pdf zum Einsatz, es ist auch auf GitHub zu finden. In diesem Zusammenhang: Es ist gar nicht so einfach, ein Plugin zu finden, mit dem man PDFs in Webseiten einbetten kann.

Auf mehrfachen Wunsch einer Person beschreibe ich hier einmal, wie ich Vaultwarden selbst hoste. Vaultwarden ist eine nicht offizielle auf Open Source basierende Serverkomponente, mit der sich jeder Bitwarden-Client verbinden lässt. Bitwarden ist der Passwort-Manager, den ich verwende, dazu vielleicht später einmal mehr. Nur so viel an dieser Stelle, der Client ist ebenfalls Open-Source-Software. Er existiert für nahezu jede Plattform und als Plugin / Extension / Addon für die gängigen Browser.

Zunächst habe ich einen User angelegt, unter dem die Serverkomponente laufen soll. Bei mir heisst der User vault.

Bei mir wird eine Fehlermeldung geworfen, weil die User-ID nicht in der vorgegebenen Range ist, ich ignoriere die. Wenn es Euch wichtig ist, nutzt eine andere ID.

Das Homeverzeichnis des Users liegt unter /srv/vault, wo später auch die Daten liegen werden.

Ich weiss, dass das alles mit Quadlets geht, mir geht aber in der Experimentierphase das ständige Daemon-Reload auf die Nerven, daher wird der Dienst bei mir mit Skripten gestartet und gestoppt und mit dem folgenden systemd-Unit-File automatisiert.

Ach ja, um über Port 443 erreichbar zu sein, benötigen wir noch einen Reverse-Proxy. Da hat sich bei mir Caddy bewährt. Der Eintrag im Caddyfile ist gerade einmal drei Zeilen lang. Caddy sorgt automatisiert für Let's Encrypt-Zertifikate.

Nach einem Wechsel auf den User vault (su - vault), erstelle ich ein Verzeichnis data und lege die Skripte start.bash und stopp.bash an und mache sie ausführbar. Die "set -o"-Einträge habe ich grundsätzlich in Skripten. Ich benutze Podman für Container und nicht Docker.

Um den Container starten zu können, braucht man noch ein paar User-IDs und die Möglichkeit, dass der Dienst auch laufen kann, wenn der User nicht angemeldet ist. Dass die Zeilen so aussehen, ist reiner Bequemlichkeiteit geschuldet. Da gibt es noch Tuning-Potenzial.

Nach systemctl restart caddy könnt Ihr testen.

Wenn alles richtig ist, sollte nach einer Ausführung von start.bash die Webseite von Vaultwarden aufrufbar sein und Ihr könnt einen Account anlegen. Falls nicht, müssen die Fehlermeldungen behoben werden. Wenn Ihr nicht weiterkommt, meldet Euch bitte.

Für die Automatisierung braucht es ein systemctl daemon-reload und ein systemctl enable --now vault.

Viel Spass!

Huch, vergessen, Ihr braucht ja auch noch die Adminseite unter /admin.

Dazu muss einmal das start.bash-Skript und die Zeile -e ADMIN_TOKEN= ergänzt, die Webseite unter vault.deine.domain/admin aufgerufen, Einstellungen gespeichert und die Zeile danach wieder gelöscht werden.

Achtung: Das beschriebene ist die einfache, unsichere Variante, wie man das Token sicher generiert, ist auf der Vaultwarden-Webseite beschrieben.

Über Jörg wurde ich an den Digitalen Unabhängigkeitstag an jedem ersten Sonntag im Monat erinnert.

Aus diesem Grund möchte ich gerne an meinen Artikel über Alternative Matrixhoster erinnern. Die Anbieter dort bieten zumeist neben Matrix auch noch andere Dienste zur freien Benutzung an.

Einige Services, wie beispielsweise FreshRSS, Kanboard, Linkding, Readeck, Wallabag (und weitere), biete ich für Interessierte ebenfalls an, E-Mail reicht. Bis auf Wallabag nutze ich alles selbst, aber es gibt generell keinen Anspruch, dass die Dienste immer verfügbar sind.

Es gibt eine Status-Seite, wobei ich nicht alles für Menschen ausserhalb der Familie bereitstelle.

Die Lage hier stabilisiert sich, hier zum Vergleich die Liste vom letzten Jahr.

Änderungen gegenüber dem letzten Jahr habe ich in kursiv gesetzt.

Nutze ich:

• Matrix
• Threema
• Signal, Jetzt auch immer häufiger für Video-Calls
• Discord (sehr selten)
• Microsoft Teams
• Nextcloud Talk
• OpenTalk (immer seltener)
• SMS

Kontaktadressen findet Ihr auf meiner Homepage.

Was soll ich als Einleitung schreiben, auch hier gab es einen Artikel im letzten Jahr. Hier tut sich erfahrungsgemäss sehr viel mehr als auf der Serverseite.

Hardware

Damit sind meine "daily driver" (Hybrid bedeutet, dass ich die die Geräte privat und beruflich einsetze):

• Hybrid: Google Pixel 9
• Hybrid: Onyx Boox Max 3
• Privat: Boox Palma 2 Pro
• Privat: Withings ScanWatch
• Privat: TUXEDO Infinity Book
• Privat: TUXEDO Core One
• Privat: Sony WH-1000XM4
• Arbeit: Lenovo P1 Generation 4
• Arbeit: Jabra Evolve2 65 (USB-C)

Mehr Details zu der von mir eingesetzten Geräte gibt es auf der Technikseite im Blog, eine dedizierte Computer-Historie gibt es dort übrigens auch.

Software

Android

Ich nutze auch Organic Maps wieder, aber OsmAnd zusätzlich.

Die Geshichte der Kartenanwendungen ist sehr in Bewegung, mir reicht mittlerweile CoMaps für alles (insbesondere für Wanderungen).

Linkdy ist der Bookmarkclient zu meiner Linkding-Instanz.

Das Wetter zeigt mir mittlerweile Breezy Weather an. Sehr gut konfigurierbar und genauso gut oder schlecht wie andere Wetter-Apps, nur dass sie besser aussieht.

Einen Client für meine Immich-Instanz gibt es ebenfalls neu.

Bei den LLMs bin ich zu Mistral (mit passender App) gewechselt. Mistral macht sehr schnell grosse Fortschritte und unterliegt der DSGVO, das finde ich gut.

Linux

Da ich den Spass am Ausprobieren wiedergefunden habe, haben sich hier reichlich Veränderungen ergeben.

Auf meinen Clients läuft Bluefin als Distribution (Immutable OS) und damit auch wieder Gnome. Damit einhergehend kommen jetzt Anwendungen containerisiert via Distrobox. Darüberhinaus werden grafische Anwendungen via Flatpak, Kommandozeilen-Anwendungen via Homebrew installiert.

DotFiles werden neu mit Chezmoi verwaltet, was auch statische Binaries kann. Wenn es rein um statische Binaries ginge, lohnt eget einen Blick.

Ich habe viele Editoren ausprobiert und bleibe in der Kommandozeile bei Vim, als grafischen Editor spiele ich gerade mit ecode herum.

Durch den Distributionswechsel, habe ich VirtualBox durch Virtual Machine Manager mit libvirtd und KVM im Backend ersetzt.

Als Aufgabenverwaltung kommt neu Vikunja zum Einsatz, vorher war es Todoist. Getestet habe ich auch Super Productivity.

Das bisschen Zeiterfassung was ich mache, erledigt wieder Timewarrior, Clockify habe ich abgesägt.

Als Linkchecker setze ich neu Lychee ein. Funktioniert einfach grossartig.

Die letzte grössere Änderung ist, dass ich mit Typst LaTeX ersetzen möchte. Ich habe LaTeX nur für Präsentationen und Briefe benötigt. Da habe ich mich gefragt, ob ich bis zu 4 GB auf der Platte brauche, um ab und zu einen Brief zu schreiben (ein oder zwei Mal im Jahr).

Suchmaschine

Meine Standard-Suchmaschine ist Kagi, ich zahle dafür und die Ergebnisse sind mir das Geld wert.

Es hat sich vergleichsweise mehr getan als beim Arbeitsplatz, hier der Artikel aus dem letzten Jahr.

Spannenderweise nutze ich kaum Bookmarks, meistens suche ich erneut nach den Seiten. Serverseitig bin ich nach Shaarli, über Linkwarden und Readeck (weiterhin sehr gut als Read-Later-Service, für die Verwaltung der Lesezeichen eher weniger geeignet) bei Linkding gelandet. Das gefällt mir gut. Die geteilten Bookmarks und den passenden Feed sind verlinkt.

Von meinem Testserver habe ich mich getrennt und stattdessen eine Mini-VM bei Hetzner gebucht, auf der Uptime Kuma zum Einsatz kommt, um meine Dienste zu überwachen. Die öffentliche Status-Seite zeigt alle Dienste, die ich für mich und andere hoste.

Immich löst den automatischen Upload von Bildern mit dem unzuverlässigen Nextcloud Client ab, das hätte ich schon länger machen sollen. Immich ist eine grossartige und sehr zuverlässige Photo- und Bilderverwaltung.

In dem Kontext. Für Container nutze ich Podman und nicht Docker. Für Immich kommt folgerichtig Podman-Compose zum Einsatz.

Ich hoste jetzt auch eine Vikunja-Instanz, dazu mehr im Client-Artikel (der am 29.12.2025 erscheint oder erschienen ist).

Begonnen habe ich, meine auf Speakerdeck bereitgestellten Vorträge und Workshops in mein Changelog zu migrieren. Ein Dienst weniger, den ich nicht unter eigener Kontrolle habe. Eine Übersichtsseite habe ich ebenfalls erstellt.

Im Rahmen der Blogwochen 2025 war ich doch interessiert daran, ob sich das in den Zugriffszahlen auf mein Blog niederschlägt. Daher habe ich GoAccess installiert und durchsuche damit die Logdateien vom Apache-Webserver. über das Resultat habe ich ebenfalls einen Artikel veröffentlicht.

Die kleineren Versionsupdates führe ich hier wie gewohnt nicht auf.

Hier die Änderungen aus dem letzten Jahr.

Die Technik am Arbeitsplatz hat sich im letzten Jahr offiziell gar nicht so sehr verändert. Inoffiziell habe ich aber sehr viel von meinen privaten Linux-Geräten gearbeitet. Einfach, weil es möglich war.

Nach Blick in die Empfehlungsecke von Mike Kuketz habe ich mich dann entschieden, für die beruflichen Webseiten den Brave Browser zu benutzen.

Mein Arbeitsort hat sich aber verändert. Das neue Team hat seinen Hauptsitz in Bern. Aus diesem Grund bin ich häufig nach Bern gefahren. Den Fahrtkostenunterschied zu meinem Anstellungs-Arbeitsplatz trägt die Firma.