Dirks Logbuch

Irgendwie war es ja auch nur eine Frage der Zeit, dass ich bei meinem Distrohopping auch einmal bei Arch Linux lande. Der Wikipedia-Artikel gibt eine sehr gute Einführung.

Vor einigen Monaten habe ich testweise mein Notebook umgezogen, was ich eh so gut wie gar nicht mehr benötige (ausser, um diesen Artikel zu schreiben und demnächst mal wieder auf einer Konferenz).

Ich bin überrascht, wie gut das läuft. Der Paketmanager ist vermutlich der schnellste, mit dem ich es je zu tun hatte. Alles funktioniert von Anfang an prima. Die Dokumentation im Wiki gehört zu den besten, die es im Linuxumfeld gibt. Ich habe sie schon vor meinem Wechsel relativ häufig zu Rate gezogen.

Woran ich mich gewöhnen muss, ist, dass der Installationsumfang sehr schlank gehalten ist. Das führt dazu, dass ich viel Software, die in anderen Distributionen "einfach so" mitkommt, von Hand nachinstallieren musste.

"Bis jetzt" bin ich begeistert. Mal schauen, wie lange das anhält.

Grund für den Artikel ist, dass ich meinen Hauptrechner migriert habe und ich mich einmal mehr darüber freue, wie leicht ein Distributionswechsel bei Linux ist. Die meiste Zeit benötigt tatsächlich das Kopieren der Daten.

Vor ein paar Wochen habe ich beschrieben, wie man sein Backup mit Borgbackup durchführen kann.

Heute soll es einmal darum gehen, sich ein generelles Konzept zu überlegen. Wenn man sich erst die Gedanken macht, wenn Datenverlust droht oder bereits Daten verloren gegangen sind, dann ist es zu spät.

Im Artikel geht es mir vor allem um private Daten.

Um die Klassifizierung der Daten kommt man leider nicht herum. Damit lässt sich feststellen, welche Daten am wichtigsten sind, welche Daten sich wie häufig ändern und wie viel Datenverlust man verkraften kann. Natürlich sollte man sich auch über Restorezeiten Gedanken machen - die gewünschte Restorezeit beeinflusst auch die Art des Backups (Vollbackup, differentielles oder inkrementelles Backup) und selbstverständlich auch die Wahl des Backuptools.

Natürlich kann man sagen, dass man jede Minute ein Backup aller Daten anfertigt, um in jedem Fall auf einen alten Stand zurückzukommen. Dazu darf das Backup nicht länger als eine Minute dauern und man muss ausreichend Speicherplatz vorsehen (und bezahlen).

Die folgenden Daten würde ich bei einer Klassifizierung privater Daten berücksichtigen:
(Ergänzungen sind herzlich willkommen)

• Das Betriebssystem
• Die installierten Programme
• Konfigurationen
• Dokumente (Textverarbeitung, Tabellenkalkulation, ...)
• Quelltexte
• Notizen
• Skizzen
• E-Mails
• Chat-Nachrichten
• Eingescannte Dokumente
• Fotos

Für jede der Kategorien sollte man sich überlegen, ob man mit einem Verlust der Daten leben könnte, wie lange die Wiederherstellung der Daten dauern darf, welcher Aufwand getrieben werden muss, um die Daten wiederzubekommen und wie aktuell die Backups sein müssen.

Ein Beispiel: Fotos lassen sich ohne Backup nicht wiederherstellen, eingescannte Dokumente schon (wenn man das Original noch besitzt), allerdings kostet das vermutlich mehr Zeit als ein Restore der Daten. Dafür belegen Fotos und Scans viel Platz auf dem Backupmedium.

Ein weiteres Beispiel: Wenn ich bei einem erstellten Dokument nur auf ein tägliches Backup zugreifen kann, verliere ich einen Tag, den ich an dem Dokument gearbeitet habe. Je nach Komplexität und Genialität der Dokumente kann das schon sehr viel sein.

Was bedeuten eigentlich Vollbackup, differentielles Backup und inkrementelles Backup?

Ein Vollbackup beinhaltet alle Daten, die gesichert werden sollen und dauert je nach Volumen relativ lange.

Ein differentielles Backup sichert immer die Differenz zum letzten Vollbackup, man braucht also für die Rücksicherung das letzte Vollbackup und das aktuellste differentielle Backup. Je weiter (zeitlich) man sich vom letzten Vollbackup entfernt, desto grösser werden die differentiellen Backups.

Ein inkrementelles Backup sichert immer die Unterschiede zum letzten Backup, das entweder ein Vollbackup oder ein inkrementelles Backup sein kann. Für eine Rücksicherung benötigt man das letzte Vollbackup und alle seitdem angefallenen inkrementellen Backups. Inkrementelle Backups sind in der Regel relativ klein - je nach Häufigkeit der Inkremente - benötigen aber vergleichsweise lange für den Restore.

Die 3-2-1-Regel für Backups:

• Wenigstens drei Kopien (Backups) der Daten verwenden.
• Wenigstens zwei verschiedene Speichermedien einsetzen.
• Wenigstens eine Kopie ausser Haus aufbewahren.

Den letzten Punkt möchte ich besonders herausstreichen. Das Backup sollte in jedem Fall auch nach einem Feuer bei Euch zu Hause und zugreifbar sein. Mit Backups schützen wir uns vor Katastrophen. Feuer ist nur eine davon.

Automatisierung:

Bitte vertraut nicht darauf, dass Ihr immer daran denkt, Euer Backup zu machen. Backups müssen automatisiert ablaufen, damit der "Faktor Mensch" ausgeschaltet werden kann.

Rücksicherung testen:

Es gibt kaum Dinge, die weniger wert sind als ein Backup, auf das man vertraut und auf das nicht mehr zugreifen kann, daher sind Restoretests elementar wichtig.

Bei mir:

Wie bereits an anderer Stelle geschrieben, mache ich meine Backups mit Borgbackup. Borgbackup macht eine inkrementelle Sicherung ("incremental forever") linkt aber bereits gesicherte Daten in das inkrementelle Backup ein, sodass ich mit jedem Backup einen Zugriff auf alle Daten (Fullbackup) habe.

Das Backup wird bei jedem Runterfahren meines Rechners ("poweroff") ausgeführt.

Die Backups landen auf einer internen zweiten Festplatte, auf dem NAS-Share und via SSH auch auf einer Storagebox bei Hetzner.

Der Schwachpunkt, den ich habe, ist, dass alles mit dem gleichen Tool gesichert wird. Eine der drei Sicherungen werde ich in der nächsten Zeit auf Restic umziehen. Da verliere ich dann zwar die Historie, hätte aber dennoch ein besseres Gefühl.

Im Zuge dessen, dass mein altes Dokumentationssystem mittels Wikis schon stark in die Jahre gekommen ist und ehrlicherweise nie so richtig gut funktioniert hat, habe ich mich von der TILpod-Community bei Matrix einmal inspirieren lassen.

Dort wurde Obsidian empfohlen, was mir aufgrund der Tatsache, dass es Closed-Source-Software ist, nicht so wirklich gefallen hat. In diesem Artikel bei GNULinux.ch wurde ich dann auf Logseq aufmerksam, was ich mir näher angeschaut habe.

Für eine sprachliche Auseinandersetzung mit dem Thema im Rahmen eines Podcasts empfehle ich Euch die März-Episode des TILpod.

Dokumentationsmedien, dazu zähle ich auch Wikis, haben meist ein Problem. Sie erlauben es selten, Informationen einfach so zu erfassen, ohne sich grosse Gedanken über die Struktur und die Findbarkeit machen zu müssen.

Notizen bestehen, zumindest bei mir, aus Stichpunkten, die nicht weiter ausformuliert sind. Ich mache sie am liebsten handschriftlich, weil mir das alle Freiheiten bietet und auch erlaubt, etwas "ins Unreine" zu skizzieren. Tools schränken zumeist die Möglichkeiten für Notizen ein, da sie an Programmvorgaben und Formen gebunden sind. Mobil auf dem Handy benutze ich Nextcloud Notes für Notizen, dafür gibt es eine sehr gute Android-App. Ich spiele mit dem Gedanken, eine Diktierfunktion oder sogar ein Diktiergerät zu verwenden.

Der Nachteil dieses Verfahrens ist, dass ich die Notizen noch einmal durchgehen muss, um sie in eine lesbare und verstehbare Form zu bringen.

Der Vorteil ist, dass ich die Notizen noch einmal durchgehe und die Inhalte besser behalten kann und dass mir durch die erneute Beschäftigung vielleicht noch weitere Inhalte und Themen einfallen.

Logseq versucht jetzt genau diese Lücke zwischen Notizen und Dokumentation zu schliessen. Vorab ein Disclaimer: Ich nutze das Tool erst seit rund einem Monat, bin noch ziemlicher Anfänger und nutze nur einen Bruchteil der Möglichkeiten.

Logseq ist noch im Beta-Modus und es gibt Anwendungen für Linux, Mac OS, Windows und Android. Es gibt auch noch eine Webanwendung, die die Daten in einem GitHub-Repository speichert, die soll aber eingestellt werden, sobald die Android-Anwendung fertig ist. Ach ja, mit einer weiteren Webanwendung aka "Live Demo", mit der kann man ohne weitere Installationen auch mit den lokalen Daten arbeiten. Obsidian und Logseq können auf derselben Verzeichnis-Hierarchie parallel zusammenarbeiten.

Ich habe Logseq via Flatpak auf zwei Linux-Maschinen installiert und zusätzlich auf einem Windows-System. Die Daten von Logseq können via Nextcloud synchronisiert werden, was in meinem Fall ohne weitere Zwischenfälle geklappt hat.

Basis von Logseq ist das Journal, in Form von "was ich heute getan habe". Man kann auch anders damit umgehen, aber das ist der einfachste Weg.

Innerhalb des Journals gibt es für jeden Tag eine Seite (gespeichert im Markdown-Format, Emacs Org-Mode wäre auch möglich), auf der man in Form einer Aufzählung alles notiert, was von Interesse ist. Dabei kann man Tags verwenden. Jeder Aufzählungspunkt und eventuelle weitere Unterpunkte gelten als Blöcke.

Klickt man auf einen Tag, bekommt man alle Blöcke angezeigt, die diesen Tag enthalten. Wenn man auf der "Tag-Seite" weitere Informationen erfasst, so wird auch diese im Markdown-Format abgelegt, ansonsten existiert die Seite nur virtuell.

Beispiel:

Ich beginne einen Block mit dem Namen eines meiner Rechner in doppelten eckigen Klammern (ich könnte auch das Hash-Zeichen "#" verwenden, das führt zum gleichen Resultat). Innerhalb des Blocks schreibe ich auf, was ich auf dem Rechner getan habe, beispielsweise "Logseq installiert". Logseq bekommt auch einen Tag.

Wenn ich auf den Rechnernamen klicke, bekomme ich alles gezeigt, was ich auf dem Rechner gemacht habe. Wenn ich auf Logseq klicke, bekomme ich alle Informationen und alle Installationen mit Bezug auf Logseq angezeigt.

Auf der Seite des Rechners erfasse ich beispielsweise die Hardwareausstattung.

Auf diese Art entsteht über die Zeit eine stark vernetzte Dokumentation. Man kann Bilder einfügen, Videos einbetten und sogar PDFs kommentieren. Mit der Speicherung der Daten kommt man nicht in Berührung, man muss nur beim ersten Start einen Speicherort in Form eines Verzeichnisses angeben.

Ich gewöhne mich gerade daran und bin ziemlich begeistert, dass die Software so gar nicht im Weg steht.

Wenn Ihr sie auch testen wollte, empfehle ich Euch den Logseq Intro Course mit acht kurzen Videos.

Ein Wermutstropfen ist für mich, dass sich die Entwickler "Privacy First" auf die Fahne geschrieben haben, aber per Default Telemetriedaten versenden. Das könnte man auch beim ersten Start abfragen.

Die Software ist FLOSS und soll es auch bleiben. Es ist eine Pro-Version geplant, die eine Synchronisationslösung eingebaut hat, ab dann lohnt sich vielleicht auch die Android-Anwendung.

Ich benutze Logseq für

• Engineering Journal
• Sammlung von Links, Bildern und Videos - könnte meine Bookmarks mit Shaarli ablösen.
• Installationen und Konfigurationen auf meinen Clients und Servern
• Planung von Vorträgen und Workshops
• Wissensspeicher

Was ich noch ganz spannend finde, ist die eingebaute Aufgabenverwaltung, die ich mir auch noch näher anschauen möchte. Spannend wäre es, ob ich damit Todoist ablösen könnte und ich alle Daten unter eigener Kontrolle hätte.

Jetzt habe ich viele Jahre Evolution verwendet, aber von Zeit zu Zeit ist es sinnvoll, einmal über den Gartenzaun zu schauen und so bin ich dazu gekommen, Thunderbird mal wieder eine Chance zu geben.

Da die Version in Ubuntu 20.04 LTS veraltet ist, habe ich die Version 91.5.0 aus dem PPA installiert. Den Tipp für das PPA habe ich von dieser Webseite.

Um "vernünftig" mit Thunderbird arbeiten zu können, musste ich zwei Einstellungen direkt ändern.

Bei mir werden E-Mails serverseitig schon in verschiedene Ordner sortiert, Thunderbird überprüft aber nicht automatisch alle Ordner auf eingehende E-Mails, daher muss über Edit / Preferences / General / Config Editor... der mail.server.default.check_all_folders_for_new auf true geändert werden, danke vinzv.

Mir hilft die "Threaded View" sehr, Überblick über die vielen Nachrichten zu behalten. Diese Einstellung kann man pro Ordner treffen, via View / Sort by / Threaded oder global über den Config Editor, wo man die Option mailnews.default_view_flags auf 1 ändern. Danke Bad Penguin.

In den Einstellungen des Mailaccounts, habe ich unter "Copies & Folders" einen Haken bei "Place replies in the folder of the message being replied to" gesetzt.

Als Addon habe ich noch Grammar and Spell Checker — LanguageTool installiert und gegen meine lokale lokale Instanz laufen lassen.

Natürlich habe ich noch eine Reihe anderer Einstellungen getroffen, aber die habe ich mir nicht explizit notiert.

Habt Ihr Tipps und Hinweise?

Wenn ich einen Rechner neu installiere, ist etckeeper eines der ersten Programme, die ich einrichte. Es stellt das Verzeichnis /etc unter Versionskontrolle und hilft, alte Konfigurationen wieder herzustellen bzw. die Veränderungen einer Konfiguration über die Zeit zu beobachten. Da es einen "Hook" (bzw. ein "Plugin") für die gängigen Paketmanager mit sich bringt und ausserdem täglich automatisch einen commit durchführt, verrichtet es seine Arbeit sehr schön im Hintergrund. Manuelle commits sind natürlich auch noch möglich.

Dazu muss man einfach etckeeper mit dem Paketmanagementtool installieren und zusätzlich noch Git.

Danach sorgen die beiden folgenden Befehle für die Initialisierung. Wenn man nicht mehr möchte, ist danach alles eingerichtet.

Bei meinen Systemen gehe ich noch einen Schritt weiter und übertrage die commits auf ein Remote-Repository ("git push"). Dazu legt man sich "irgendwo" ein Git-Repository an und nutzt die folgenden Befehle, um das Repository mit der lokalen etckeeper-Installation zu verheiraten. Aller Wahrscheinlichkeit nach gibt es noch keinen ssh-Key für den root-User der muss natürlich vorgängig erstellt werden. Ich würde diesen Key nur für das Pushen des Repositories verwenden und auf ein Passwort verzichten

Abschliessend muss noch in der /etc/etckeeper/etckeeper.conf das Remote-Repository bekannt gegeben werden, damit wird dann auch automatisch gepusht.

Shell-Skripte sind gegenüber anderen Programmiersprachen natürlich nicht das "Non-plus-ultra", aber sie sind für Ablaufsteuerungen - dafür sind sie gemacht - eine gute Wahl. Für alles, was grösser ist, empfehle ich eine "richtige Programmiersprache". Ich bin als Systemadministrator ein grosser Fan von Python und - schon länger nicht mehr genutzt - Perl, aber auch Sprachen wie Raku, Ruby oder irgendetwas mit Compiler sind natürlich gute Alternativen.

Ich beziehe mich im Folgenden auf die Bash, weil das die Shell ist, die ich täglich auf verschiedenen Systemen und Architekturen benutze.

Tipp 1:

Schreibt in den Shebang #! zu Beginn des Skriptes genau die Skriptsprache mit der Ihr auch getestet habt und nicht - weil alle das machen - /bin/sh. Auf Debian basierten Systemen ist /bin/sh ein Link auf dash, bei Alpine ist es ein Link auf Busybox, auf Red Hat basierten Systemen ein Link auf bash.

An dieser Stelle möchte ich gerne noch auf diesen alten Artikel hinweisen.

Tipp 2:

Skripte laufen auch im Falle eines Fehlers weiter. Ich halte das für ein blödes Verhalten, was sehr häufig zu Fehlern führt. Glücklicherweise kann man das Verhalten abstellen.

Entweder man ruft die Shell mit -e auf, setzt den Shebang entsprechend oder schreibt set -e an den Anfang des Skriptes oder vor die Zeilen für die das Setting gelten soll. Mit set +e kann man wieder das alte Verhalten herstellen.

Meine Empfehlung ist, die Langform set -o errexit zu verwenden, das ist deutlich lesbarer. (Altes Verhalten kann man mit set +o errexit wieder herstellen).

Shellzeilen gelten als fehlerhaft, wenn der exit-Code des letzten Kommandos der Zeile ungleich 0 (null) ist. Das bedeutet unter anderem, dass man den Exitcode einer einzelnen Zeile durch Hinzufügen von || true auf "nicht fehlerhaft" ändern kann.

Tipp 3:

Wie im letzten Tipp beschrieben, ist das letzte ausgeführte Kommando einer Zeile ausschlaggebend dafür, ob eine Zeile mit oder ohne Fehlercode beendet wird.

Der Eintrag set -o pipefail sorgt dafür, dass eine Zeile als fehlerhaft "gesehen" wird, wenn auch nur ein Kommando der über Pipes vernetzten Kommandos einer Zeile fehlschlägt.

Tipp 4:

Nicht gesetzte oder "leere" Variablen sind häufig ein Problem.

Um eine nicht gesetzte Variable mit einem Fehler zu quittieren, kann man das Kommando set -o nounset oder set -u verwenden.

Tipp 5:

Es ist generell eine gute Idee, alle Variablen mit doppelten Anführungszeichen zu umgeben, ganz besonders dann, wenn es um Dateien geht. Auch, wenn man selber keine Dateien mit Leerzeichen (oder anderen "Internal Field Separators" (IFS)) erstellt, heisst es nicht, dass man nicht auf solche treffen kann.

Nachtrag:

Christoph hat in diesem Kommentar zur recht darauf hingewiesen, dass es besser ist /usr/bin/env bash zu verwenden, das benutzt die erste Bash, die der Benutzer im Pfad hat und funktioniert auch auf Systemen, auf denen die Bash in einem anderem Pfad liegt als /bin/bash.

Zusammenfassung:

Meine Erfahrung ist, dass man mit den fünf Tipps rund 80% aller Probleme mit Shellskripten umschifft bzw. Skripte mit Fehlern rechtzeitig abbricht.

Es gibt noch viele weitere Tipps, aber das sind meiner Ansicht nach die wichtigsten.

Bei uns in der Firma ist es so, dass es auf virtuellen Maschinen eine strikte Trennung der Plattform von den Applikationen gibt. Wir sind für die Plattform verantwortlich und Applikationsteams für ihre Anwendungen.

Damit die Applikationsteams in der Lage sind, Ihre Dienste via systemd zu verwalten (Start, Stopp, Logs anschauen, etc.) erstellen wir systemd-Services und berechtigen die Applikationsteams mit entsprechenden sudo-Regeln.

Allerdings bietet systemd Benutzern die Möglichkeit, Dienste unter eigener Regie zu verwalten. Das geht vom Anlegen des Dienstes bis zu den Dingen, für die es vorher sudo-Regeln brauchte.

Einrichtung

Um systemd-User-Services für einen User zu aktivieren, muss im Hintergrund ein Prozess gestartet werden, der die Dienste verwaltet. Tut man das nicht, werden Dienste des Users bei der Abmeldung vom System gestoppt.

Im Homeverzeichnis des Users liegen die Servicedefinitionen unter ~/.config/systemd/user/NAME.service.

Im Service selber muss braucht es die folgenden Zeilen, damit die Dienste auch automatisch gestartet werden können. Andere Einstellungen sind auch möglich, aber ich habe herausgefunden, dass es wenigstens den einen Eintrag braucht.

Der User muss in seine .bashrc die folgende Variable setzen, wenn sie nicht schon durch das System zur Verfügung gestellt wird.

Verwaltung der Dienste

Weiterführende Links:

• systemd/User
• systemd user services

Kaum kommt die Meldung, dass der Quelltext des Threema-Clients offen liegt, kommen die Bedenkenträger, dass das kein Grund zur Freude wäre, so lange der Quelltext des Servers noch nicht offen ist.

Zwei Anmerkungen dazu und auch gleichzeitig eine Einladung zur Diskussion.

1. Haben wir verlernt, uns über Teilerfolge zu freuen? Muss es immer 100% sein? Kein Wunder, dass wir es uns immer schlechter gehen lassen, wir tragen selber die Schuld daran.
2. Auch, wenn der Quelltext der Serverkomponente offen liegt, gibt es keine Garantie dafür, dass der Quelltext die Basis für den Server ist, der auf Seiten des Betreibers läuft. Ich setze als Blogengine Serendipity ein. Ihr müsst mir glauben, dass das so ist und keine von mir abgewandelte Variante der Software.

Wenn man etwas nicht selber macht, muss man darauf vertrauen, dass es sich so verhält wie behauptet.

Nebenbei: Auch die App müsste man selber bauen, um sicher zu sein, dass die App auf dem Handy aus dem offen gelegten Quelltext gebaut wurde.

Aus CentOS 8 wird CentOS Stream.

Über die Meldung, dass CentOS 8 zugunsten von CentOS Stream einstellt, habe ich mich sehr geärgert. Ich war sogar richtig gehend angepisst.

CentOS war immer die Möglichkeit, eigene Dinge auf Red Hat Kompatibilität zu testen, ohne Subskriptionskosten (für das Patching) bezahlen zu müssen.

Leider hat es das CentOS-Team mit der Version 8 nicht geschafft, zeitnah auf Updates und Hotfixes durch Red Hat zu reagieren und ist aus diesem Grund auch nicht mehr meine Distribution der Wahl. Mein Kram wird im Lauf der nächsten Wochen und Monate auf Ubuntu LTS migriert.

Machen wir uns aber bitte nichts vor. CentOS ist keine "schöne" Linux-Distribution. Das Tooling ist nicht so berühmt. Durch die lange Unterstützung und die durch Red Hat versprochene API-Kompatibilität über die ganze Laufzeit veraltet Software in Red Hat Enterprise Linux (RHEL) und damit auch in CentOS sehr schnell. (Gilt übrigens für andere paketbasierte Distributionen im gleichen Mass, die helfen sich nur mit häufigeren Releases).

RHEL (CentOS) möchte man eigentlich nur aus genau einem Grund einsetzen, nämlich, dass nahezu jede Business-Software für RHEL zertifiziert wird. Und aufgrund der versprochenen Kompatibilität ist es nahezu garantiert, dass sie auch über die komplette Laufzeit das Major-Releases von zehn Jahren bzw. 13 Jahren mit extended Support auch lauffähig bleibt.

Wenn man aktuelle Open-Source-Software auf CentOS einsetzen möchte, so konnte man sich nur dadurch behelfen, dass man entweder darauf vertraut hat, dass die irgendwann in den Software-Kollektionen aufgeschlagen ist, da wurde sie dann "neben" der Basisinstallation installiert oder dass man externe Repositories verwendet hat. Bei meinen Servern habe ich beispielsweise PHP aus den Remi Repositories, sowie Docker und MariaDB direkt vom Hersteller bezogen.

Das hat auch Red Hat erkannt und mit Version 8, Modules oder "Application Streams" eingeführt. Hier gibt es eine sehr gute englischsprachige Erklärung dazu. Kurz zusammengefasst, lassen sich mit diesem Konzept mehrere Versionen der gleichen Software parallel installieren und auch benutzen.

Vermutlich hat dieses neue Konzept die Ressourcen vom CentOS-Projekt gesprengt, ich habe keinen Beweis für diese Vermutung. Für mich ist dieses Konzept aber nur ein Zwischenschritt auf dem Weg, das Basis-Betriebssystem komplett vom Applikationsteil zu trennen.

Im Grossen und Ganzen: Kernel, Netzwerk, Infrastruktur (Backup, Authentifizierung, ...) macht die Distribution und den ganzen Rest können Applikationen alleine besser.

Wenn wir die Distributionen nur als stabile Basis ansehen, auf der wir Dienste mit den Hersteller-Repositories (Docker, MariaDB, ...) oder Snaps, Flatpaks und AppImages oder Containern (Docker, Podman, ...) aufsetzen, dann würden wir allem gerecht werden.

Es entspricht einer Trennung von Applikation und Plattform, die in vielen Firmen trotz DevOps immer noch betrieben wird. DevOps bezieht sich im Grossen und Ganzen auch mehr auf Applikationsentwicklung und -betrieb. DevOps (oder EngOps) für die Plattformentwicklung ist davon getrennt.

Wenn wir diese Sichtweise weiterspinnen, werden paketbasierte Linuxdistributionen obsolet.

Wohin das in Summe führen kann, sehen wir mit Kubernetes (und OpenShift) oder durch den Einsatz von Containern (mit Docker oder Podman oder ...).

Kubernetes ist es egal, auf welchem linuxbasierten OS es läuft, wenn die Voraussetzungen gegeben sind. Den Leuten, die Kubernetes benutzen (nicht verwalten), ist die komplette Infrastruktur darunter egal, so lange das Cluster zur Verfügung steht.

Und, die alten erinnern sich, das hatten wir schon einmal, aber nicht ganz so ausgereift.

Java hat den Ruf (weitestgehend) plattformunabhängig zu sein. Klar, dafür muss man mit der Runtime (JRE) oder dem JDK auch ein halbes OS mitinstallieren. Darauf kann man Applikationsserver wie Tomcat, JBoss, Weblogic, Websphere, ... betreiben und auch da gab es das Versprechen, sich nicht um die darunter liegenden Schichten kümmern zu müssen.

Meiner Meinung nach wurde dieses Versprechen nie komplett eingelöst, obwohl sehr viele gute Konzepte vorhanden waren.

Mit Containern und Orchestrierungslösungen sind wir aber der Erfüllung dieses Versprechens einen Schritt näher gekommen.

Bin an Euren Meinungen und einer Diskussion darüber sehr interessiert.

Nach immer wieder auftretenden Schwierigkeiten mit meinem Matrix-Account habe ich ihn jetzt gewechselt.

Wer sich verbinden möchte, kann das gerne über @ddeimeke:digitale-gesellschaft.ch tun.

Den alten Account werde ich noch einmal am Tag auf neue Nachrichten prüfen.

Ach, ja, in dem Zusammenhang: Nachdem niemand mit mir via XMPP kommuniziert, habe ich die Apps auch vom Handy und vom Tablet gelöscht. Auch hier prüfe ich einmal am Tag auf neue Nachrichten.

Meine Server laufen seit etwa fünf Jahren unter CentOS 7. In der Zeit gab es ordentlich Updates und tatsächlich keine Probleme, die auf der Software basierten.

Eigentlich läge damit CentOS 8 als neues Betriebssystem für die Server nahe. Allerdings schreibt schon Michael Kofler, dass CentOS 8 über sechs Wochen ohne Updates war und wirft Oracle Linux in die Waagschale.

Das hört sich auf den ersten und zweiten Blick komisch an, ist es auch. Aber Oracle bietet sein Linux als FLOSS-Lösung an, die gratis ist, solange man kein System hat, bei dem man für den Support durch Oracle bezahlt. In dem Fall werden alle Instanzen kostenpflichtig. Komisches Modell, oder?

Nebenbei: Ich nutze sehr gerne VirtualBox, ebenfalls von Oracle, da muss man aufpassen, dass sich die Lizenzbestimmungen mit der Nutzung des Extension Packs ändern.

Also, was tun?

Der Vorteil von CentOS war und ist, dass es sehr lange (rund zehn Jahre) unterstützt wird und tatsächlich bin ich auch noch nicht in der Not zu wechseln. Der Support für CentOS 7 läuft erst am 30. Juni 2024 (Tabelle) aus, also erst in viereinhalb Jahren. Der Nachteil ist, dass CentOS über die Lebenszeit garantiert, API-kompatibel zu bleiben, was zum Teil in sehr alter Software resultiert (Tabelle bei DistroWatch. Das wiederum bedeutet, dass man reichlich Fremdrepositories verwenden muss - bei mir EPEL, die Remi-Repostitories für PHP und Repos für MariaDB - um halbwegs aktuelle Webanwendungen betreiben zu können. Das Web ist voll von Fragen, wie man eine bestimmte Software unter CentOS zum Laufen bekommt.

Also Plan A ist, bei CentOS zu bleiben. Die "Synergien" zwischen dem, was ich beruflich mache(n muss), nämlich Red Hat Enterprise Linux zu betreiben, und dem, was ich dann privat mache, sind schon sehr gross. Bedingung dafür wäre, dass es regelmässiger Updates gibt.

Plan B wäre, die Distribution zu wechseln, hier bieten sich quasi sofort Ubuntu und Debian an, wobei ich im Fall eines Wechsels zu Debian tendieren würde.

Es gibt natürlich noch einen Plan C, das wäre ein Docker (bzw. Podman) basiertes Setup. Mich würde sehr reizen, das mit Alpine Linux als Basis zu versuchen. Eine Alternative könnte sogar Fedora Core OS sein.

Kein Plan D, aber eine interessante Alternative könnte tatsächlich Fedora in der Server-Variante sein. Allerdings sind die Wechsel zwischen den halbjährlichen Releases schon sehr drastisch und bedürfen der ständigen Nacharbeit (vermute ich). Fedora auf dem Desktop ist super (langweilig), das funktioniert einfach richtig gut, selbst mit aktiviertem SELinux sind keine Nacharbeiten nötig.

Jetzt Ihr. Was wären Eure Empfehlungen? Viel wichtiger als "was" wäre mir das "warum" Ihr ein bestimmtes Server-OS empfehlt. FreeBSD oder OpenBSD wären auch noch nachdenkenswerte Varianten.

Analog zu der Beschreibung, wie ich Taskwarrior benutze schreibe ich hier gerne einmal meinen aktuellen Workflow bei Todoist auf. Wobei hier angemerkt sein, dass ich Todoist gerade einmal rund fünf Wochen benutze, von denen ich zweieinhalb im Urlaub war. Das soll heissen, dass sich die Arbeitsweise sicherlich noch ändern wird.

Wo nutzt Du Todoist?

Todoist nutze ich überall. Neben der Webseite vom Hersteller, mit der ich hauptsächlich arbeite, nutze ich auch das Browser-Plugin für Firefox und das Plugin für Iridium (Iridium bekommt man hier). Auf dem privaten Handy und Tablet arbeite ich mit der Android-App und mit dem Diensthandy das Pendant für iOS.

Selbstverständlich habe ich auch die 3rd Party Apps für Linux ausprobiert, wobei diese hier nur ein Wrapper für die Webversion ist ("gesehen, gelacht, F8"), aber diese Kommandozeilenvariante funktioniert auch Offline und ich benutze sie häufiger. Leider muss ich auch hier erwähnen, dass sie nicht so komfortabel ist wie Taskwarrior, dafür hat Taskwarrior aber leider auch nur eine Kommandozeilenversion

Für welche Art Arbeit nutzt Du Todoist?

Anders als mit Taskwarrior erfasse ich ihn Todoist nahezu alle Aufgaben. Das liegt vermutlich daran, dass Todoist wirklich überall ist.

Wie synchronisiert Du die Aufgaben, welche Geräte benutzt Du?

Für die Synchronisation sorgt Todoist selber.

Todoist nutze ich auf meinen privaten Geräten (Notebook, Tablet, Handy, Server, ...) und auch auf den Dienstgeräten (Virtual Desktop, Handy).

Welchen Standard-Report benutzt Du?

Die Frage ist für nicht für Todoist gedacht, aber die Standardansicht sind die nächsten sieben Tage.

Benutzt Du eine Standard-Methode oder auf Dich angepasst Methodik?

Aufgabenverwaltung ist sehr individuell, ich benutze einen Mix aus Methoden. Ein paar Informationen dazu finden sich in einem Vortrag, den ich vor einigen Jahren zum letzten Mal gehalten habe.

Nutzt Du irgendwelche Erweiterungen oder Hook-Scripts?

Nein.

Auf welches Feature vertraust Du am meisten?

Ich vertraue darauf, dass Todoist die Aufgaben nicht vergisst. Aber, selbst wenn es so wäre, habe ich mit der Kommandozeilen anwendung noch eine Offline-Kopie.

Alle schnell erfassten Aufgaben landen in der Inbox. Von dort werden Sie dann auf acht Projekte verteilt, um ein wenig Struktur in die Aufgaben zu bekommen. Die Aufgaben bekommen ausserdem ein Zieldatum und auch "Tags" (Etiketten), was weiterhin hilft.

Bei den Projekten nimmt das Projekt "Z" eine Sonderrolle ein. In "Z" sammel ich alles, was kein festes Datum hat, an dem es fertig sein muss. Es ist auch das einzige Projekt, das Subprojekte hat: 2buy, 2eval, 2learn, 2read, 2watch, Ich benutze hier auch keine weiteren Tags, die kommen erst dazu, wenn die Aufgaben konkreter werden.

Was ganz schick ist, ist, dass alle Projekte und auch die Inbox eine E-Mailadresse haben, an die ich beispielsweise Benachrichtigungen über neue Programmversionen weiterleiten kann - andere E-Mails natürlich auch.

Welche Features nutzt Du bewusst nicht?

Unglaublich, aber wahr, wie bei Taskwaarior nutze ich Prioritäten überhaupt nicht.

Wie schaust Du Deine Aufgaben durch?

Ich sortiere die Aufgaben nach Datum und bearbeite einmal wöchentlich - initiiert durch eine wiederkehrende Aufgabe - die Inbox und alle Projekte.

Das war es

Fragen gerne in die Kommentare oder per E-Mail an dirk@deimeke.net

Affiliate Link: Wer sich über diesen Link - https://todoist.com/r/dirk_deimeke_kesjzn - entscheidet, einen Premium-Account abzuschliessen, spendiert mir zwei Gratismonate Premium.

Die Umstellung von einer "Eier-legenden-Wollmilchsau" wie Taskwarrior auf eine (jede) andere Lösung zur Aufgabenverwaltung ist nicht ohne Mühe.

Taskwarrior hat zwei "Killerfeatures", die ich so bei noch keiner anderen Aufgabenverwaltung gesehen habe.

Das eine ist das "wait"-Feature, was dafür sorgt, dass eine Aufgabe bis zu einem Stichtermin einfach gar nicht mehr angezeigt wird. Wenn der Termin verstrichen ist, taucht die Aufgabe wieder in "der Anzeige" auf.

Das andere ist die Berechnung der Dringlichkeit einer Aufgabe. Die Dringlichkeitsberechnung in Taskwarrior hängt von vielen verschiedenen Faktoren ab und kann konfiguriert werden. Eine detaillierte Erklärung würde hier den Rahmen sprengen.

In Taskwarrior habe ich meine Aufgaben grundsätzlich in sehr vielen Projekten mit passenden Subprojekten erfasst und zusätzlich für jede Aufgabe einen Stichtermin vergeben. Eine detaillierte Beschreibung meines Workflows habe ich hier im Blog beschrieben.

Unter Todoist habe ich die Projekte sehr stark limitiert und da Todoist etwas hakelig mit Subprojekten ist, benutze ich für alles weitere Tags ("Etiketten").

In Taskwarrior habe ich immer alle Aufgaben sortiert nach Dringlichkeit gesehen, ausser denen, dessen Wait-Datum (wenn es gesetzt war) noch nicht verstrichen ist. Die Reports sind frei konfigurierbar.

Todoist ist lange nicht so konfigurierbar. Man kann Aufgaben zwar filtern, aber definitiv nicht so umfangreich wie Taskwarrior. Im Standard hat man verschiedene Ansichten, man kann alle Aufgaben der Inbox, eines Projektes, Subprojektes oder eines bestimmten Tags sehen und die auch sortieren oder Aufgaben anzeigen lassen, die heute oder in den kommenden sieben Tagen fällig sind.

Einen grossen Vorteil hat Todoist allerdings gegenüber Taskwarrior, es ist omnipräsent, es gibt Integrationen für einen grossen Haufen an Diensten, die ich nicht nutze und Apps für jedes Betriebssystem sowie Addons für Browser. Ich habe mir sogar eine 3rd-Party-Kommandozeilenanwendung installiert.

Taskwarrior hatte ich zwar auch immer dabei aber ehrlicherweise war die Verwendung auf dem Mobiltelefon immer hakelig, was dazu führte, dass ich Taskwarrior dort selten (bis nie) verwendet habe.

Ich habe einmal "postuliert", dass das richtige Werkzeug zum Zeit- und Selbstmanagement die folgenden sechs Eigenschaften hat:

• Es ist immer dabei.
• Es ist zuverlässig.
• Es ist unabhängig von der Methode, die ich verwenden möchte.
• Es steht nicht im Weg.
• Es lenkt den Fokus auf wenige Aufgaben, die es zu erledigen gilt.
• Es ist ein Werkzeug, das ich gerne benutze.

Bis jetzt kann ich sagen, dass Todoist alle diese Eigenschaften mitbringt.

Affiliate Link: Wer sich über diesen Link - https://todoist.com/r/dirk_deimeke_kesjzn - entscheidet, einen Premium-Account abzuschliessen, spendiert mir zwei Gratismonate Premium.

Nach meinem Abschied aus dem Taskwarrior-Team habe ich mich auf die Suche nach einer neuen Lösung zur Verwaltung von Aufgaben gemacht.

Die neue Lösung sollte vor allem Features haben, die ich in Taskwarrior vermisse. Die grosse Herausforderung dabei ist, dass Taskwarrior so unglaublich viele Funktionen hat, die einem die Aufgabenverwaltung erleichtern.

Wir sind zwei Features, die Taskwarrior nicht hatte, besonders wichtig: Eine App für Android (und iOS wegen Diensthandy) und eine Möglichkeit, die Lösung durch einen Proxy im Büro nutzen zu können, das bedeutet es braucht eine Web-Anwendung.

"Getestet" habe ich die unten stehenden Lösungen. Das "Getestet" ist in Anführungszeichen, weil ich mir alles nur kurz angeschaut habe. Ein echter Test wäre es erst gewesen, wenn ich sie wenigstens einen Monat lang benutzt hätte.

• Any.do
• Habitica
• Microsoft To Do
• Quire
• Remember The Milk
• TickTick
• Toddledo
• Todoist
• WorkFlowy

Wie Ihr vielleicht bemerkt habt, ist nicht eine FLOSS-Lösung dabei. Das liegt daran, dass ich keine gefunden habe. Wenn Ihr Leser welche kennt, freue ich mich auf Kommentare.

Wie schon geschrieben, habe ich lange nicht alle Features getestet, aber nach einem ersten Durchgang blieben nur Quire und Todoist übrig. Das Business-Modell von Quire war mir zu schwammig, also ist es Todoist geworden.

Und ja, es ist ein fremd gehosteter Dienst, für den ich Geld bezahle. Bei allen Vorbehalten gegen fremd gehostete Dienste, gab es ein paar Gründe, die für mich ausreichend waren, es mit Todoist zu versuchen.

• Die Firma hinter Todoist, nämlich Doist existiert schon einige Jahre.
• Das Business-Modell funktioniert bei mehr als 20 Millionen Kunden (ich finde leider die Quelle nicht mehr).
• Es ist keine amerikanische Firma.
• Fast schon der wichtigste Punkt: Ich kenne einige Leute, die Todoist schon seit Jahren benutzen und deren Urteil ich vertraue.

Ein wenig Magenschmerzen macht mir, dass meine Daten auf fremden Servern liegen. Aber, da ich jetzt schon weiss, dass das nächste Jahr, wenn nicht sogar die nächsten Jahre, deutlich herausfordender werden als die bisherigen, muss eine verlässliche und vor allem überall funktionierende Lösung her.

Mein Premium-Account läuft ein Jahr, ich werde also in nächster Zeit öfter einmal darüber berichten, wie mein Workflow mit Todoist aussieht und wie er sich von dem bisherigen Workflow mit Taskwarrior unterscheidet.

Das Blog hat jetzt neu eine Kategorie Todoist, in der sich die Artikel zum Thema befinden. Wer mag kann auch den Tags selbstmanagement oder todoist folgen.

Affiliate Link: Wer sich über diesen Link - https://todoist.com/r/dirk_deimeke_kesjzn - entscheidet, einen Premium-Account abzuschliessen, spendiert mir zwei Gratismonate Premium.

Nach über acht Jahren im Team ist es für mich an der Zeit, mich von der GothenburgBitFactory zu verabschieden. Es war eine schöne Zeit und ich habe viel, sogar sehr viel gelernt.

Der Hauptgrund dafür ist, dass das Projekt Taskwarrior in der stabilen Seitenlage ist und es seit fast vier Jahren kein neues Release mehr gab. Ich bin einfach auch müde geworden, mich bei den Teammitgliedern nach Lebenszeichen zu erkundigen.

Die Stagnation ist unter anderem damit zu erklären, dass das es zu wenig Leute gibt, die bereit oder in der Lage sind, inhaltlich mit Code beizutragen.

Anders als bei Taskwarrior, geht es bei Timewarrior gut vorwärts, Thomas leistet da einen hervorragenden Job.

Vermutlich werde ich Taskwarrior noch weiter benutzen, ich habe mich sehr an Features gewöhnt, die das Tool als Alleinstellungsmerkmale bietet. Aber ich bin parallel auf der Suche, nach einem neuen Aufgabenverwaltungswerkzeug (schönes Wort).