Dirks Logbuch

Nachdem es mit Logseq so gar nicht weitergeht und die Anwendung auf mobilen Geräten nahezu unbenutzbar ist, habe ich mich aufs Neue und dieses Mal ausführlicher mit Joplin auseinandergesetzt.

Logseq ist ein sogenannter Outliner, den ich kaum als Outliner verwendet habe. Ein Outliner in Notizanwendungen hilft, Informationen in einer hierarchischen Struktur zu organisieren, was die Zentrierung von Logseq auf Blöcke erklärt und mich manchmal auch sehr geärgert hat.

Für mich ist das Killerfeature die bidirektionale Verlinkung. Das bedeutet, dass ein Link auf eine andere Notiz auf der anderen Notiz einen Link zurück auf die Quellseite zeigt.

Bei näherer Beschäftigung mit Joplin habe ich das Plugin Bidirectional Links gefunden, was die Funktionalität nachbaut und das auch ziemlich gut macht.

Ein weiteres Feature, das ich vermissen würde, ist der Fokus auf ein Journal, was zusammen mit der Verlinkung eine relativ gute Möglichkeit bietet, einen zeitlichen Verlauf darzustellen. Auch hierfür gibt es ein Plugin, das passenderweise Journal heisst.

Seit meiner letzten Beschäftigung mit Joplin hat sich eine Menge getan und ich bin sehr angetan, die mobile Anwendung ist toll und reagiert sehr schnell.

Momentan betreibe ich Joplin im Parallelbetrieb mit Logseq. Ich muss schauen, wie gut es mit der Synchronisation mit meiner Nextcloud funktioniert, bevor ich komplett umstelle und alle Daten migriere. Wenn alle rund 2000 Notizen migriert sind, werde ich auch besser wissen, wie es mit der Performance aussieht.

Das Setup bei mir umfasst sechs Geräte, 2x Linux via Flathub, 1x Windows via Download von der Webseite, und zwei E-Book-Reader und ein Mobiltelefon unter Android via F-Droid.

Es erweist sich in jedem Fall als gut, auf offene Dateiformate zu setzen. Joplin kann Markdown importieren.

Spannend wird für mich sein, den Workflow, den ich mir über drei Jahre mit Logseq angewöhnt habe, durch etwas Neues zu ersetzen. Das meine ich ohne Wertung.

Mich hat die PARA-Methode sehr überzeugt, und für die Umsetzung in Joplin muss ich mir keine Kunstgriffe einfallen lassen, weil in Joplin verschachtelte Notizbücher möglich sind.

Der Artikel zu Nutzen Sie Ihr zweites Gehirn ist jetzt auch schon fast ein Jahr alt. Da sieht man einmal, wie lange Entscheidungen reifen müssen, bevor ich sie umsetze. Die Bequemlichkeit siegt häufig.

Auf dem bereits erwähnten neuen Notebook ist standardmässig Tuxedo OS installiert.

Die meisten meiner Leser wissen, dass ich "bekennender" Distrohopper bin und gerne neue Distributionen ausprobiere. Wer sich dafür interessiert wird in meiner Computergeschichte sicherlich fündig.

Also warum nicht einmal Tuxedo OS eine Chance geben?

Tuxedo OS basiert auf Ubuntu, aktuell Version 22.04, und hat einige Anpassungen vorgenommen. So wurde beispielsweise Snap herausgeworfen und stattdessen auf Flatpak gesetzt, eine Entscheidung, die ich nur befürworten kann.

Ein eigenes Repository hält die Tuxedo-Pakete mit Treibern, dem Tool Tomte und den Anpassungen, die sie vorgenommen haben, vor.

Als Standard Desktop-Umgebung kommt KDE zum Einsatz (was ich schon seit Jahren nicht mehr verwendet habe). Allerdings muss ich an der Stelle zugeben, dass ich die grafische Oberfläche im Grossen und Ganzen so nehme wie sie ist und keine bzw. kaum eigene Anpassungen vornehme.

Vielen Dank an Vinzenz für den Tipp, die globale Skalierung anzupassen. Das ist sehr hilfreich und macht es mir einfacher, die volle Auflösung zu verwenden.

Mit der Kombination aus Ubuntu, Tuxedo-Repositories und Flatpak konnte ich bis auf wenige Ausnahmen fast alles installieren, was ich zum Arbeiten benötige.

Einige Tools habe ich dennoch "von Hand" mit den passenden Paketen von deren Webseite oder GitHub installiert:

• Citrix Workspace (falls ich mal etwas für die Firma tun muss)
• Espanso für die ganzen Standard-Floskeln
• Fastfetch, weil ich kann
• Hugo für zwei Blogs, die ich damit betreibe
• Mullvad VPN spricht für sich
• tmux-xpanes erleichtert die Arbeit mit mehreren Maschinen und tmux

Mit dem Gerät und dem Setup bin ich (bis jetzt) sehr zufrieden und hoffe, dass das auch so bleibt. Momentan denke ich darüber nach, meinen Desktop-Rechner "Terrania" (ebenfalls ein Tuxedo-Gerät( mit Tuxedo OS zu betanken.

Am vergangenen Donnerstag ist mein neues Notebook gekommen. Es ist ein TUXEDO InfinityBook Pro 14 - Gen9 - AMD geworden, der Link zeigt auf meine aktuelle Konfiguration. Liebes Tuxedo-Team. es wäre super, wenn die Links auch nach einem Modellwechsel noch funktionieren.

Mir gefällt das Notebook sehr gut, ich werde vielleicht später einmal ausführlicher darauf eingehen.

Erwartungsgemäss brauche ich bei der Maximalauflösung eine Lesebrille, um alles erkennen zu können, ich habe das jetzt vorerst einmal auf 1920x1200 herunter konfiguriert. Das klappt prima. Zweite Beobachtung ist, dass es nur 50 Gramm leichter ist als das InfinitiyBook Pro 16 meiner Frau. Aluminium ist vermutlich schwerer als Plastik.

Das alte Notebook war 8.5 Jahre alt. Ich möchte gerne Tuxedo OS (Basis: Ubuntu) eine Chance geben und damit bin ich nach langer Zeit wieder bei KDE (sonst Arch Linux mit Gnome).

Gerne möchte ich mit Euch teilen, was meine ersten drei Schritte als Systemverwalter und die ersten drei Schritte als User nach der Installation waren. Mich würde es sehr interessieren zu hören, was Eure ersten drei Schritte bei der Einrichtung eines neuen Systems sind.

Als Admin:

1. etckeeper installieren. Im Rahmen der Konfiguration habe ich ssh-Keys erstellt, ein Repository auf meiner Forgejo.Instanz angelegt und automatischen Push eingerichtet.
2. Standard-Editor auf Vim ändern.
3. Backup mit Borg einrichten.

Und als User

1. Bitwarden als Flatpak installiert und konfiguriert.
2. Firefox koniguriert und alle Erweiterungen installiert.
3. Daten vom alten Notebook in ein separates Verzeichnus kopiert. Die Daten nutze ich nur, wenn ich ohne sie nicht weiterkomme. So eine neue Installation ist auch eine gute Möglichkeit, Altlasten aufzuräumen.

Relativ lange habe ich mich mit dem Thema Notizanwendungen (oder "Zweites Gehirn") herumgeschlagen und konnte einem sehr guten Setup mit Logseq dem Idealbild sehr nahekommen. Jetzt schaue ich mir parallel Notesnook an und bin ins Grübeln gekommen.

Mario hat mich auf den Artikel When You Should Switch Your Second Brain App (And When You Shouldn’t) von Tiago Forte hingewiesen, der mich auch zum Nachdenken brachte und mich etwas ausgebremst hat. Jetzt musste ich einmal schauen und überlegen, was meine Motivation für den Wechsel ist.

Meine Gedanken dazu möchte ich gerne mit Euch teilen.

Was ich an Logseq mag:

• Open-Source-Software.
• Bidirektionale Verlinkung, das ist DAS Killerfeature.
• Journal.
• Knowledge-Graph, auch wenn ich ihn selten benötige.

Was ich an Logseq nicht so toll finde:

• Management der Attachments.
• Die mobile Anwendung.
• Geschwindigkeit (nicht nur Sync).
• Bedienung ist nicht so toll.
• Hat nicht die gleichen Features wie die Desktop-Variante.
• Synchronisationsgeschwindigkeit.
• Das Backend der eingebauten Synchronisation ist geschlossen (ja, es gibt Workarounds), aber Daten werden in der eigenen Lösung verschlüsselt abgelegt.
• Daten liegen bei AWS, das eigene Synchronisations-Backend ist kostenpflichtig.
• Die Entwicklungsgeschwindigkeit hat stark nachgelassen.
• Alles ist "Aufzählung" (Bullet).

Was ich bei Logseq dringend vermisse:

• Plugins in der mobilen App (besonders den Kalender, mit dem einzelne Journal-Tage aufgerufen werden können).
• Höhere Geschwindigkeit.

Was ich an Notesnook mag:

• Open-Source-Software.
• Geschwindigkeit der Anwendungen.
• Feature-Gleichheit auf unterstützten Plattformen (Desktop-Anwendungen, mobile Apps, Web-App).
• Browser-Plugin.
• Synchronisationsgeschwindigkeit.
• Kleines Entwicklerteam.
• Synchronisation auf Servern bei Hetzner.
• Deutsche Rechtschreibkorrektur.
• Das Konzept, dass ein Notebook mehrere Notebooks enthalten kann, kommt mir entgegen (PARA-Methode).

Was ich an Notesnook nicht so toll finde:

• Kein offenes Datenformat, es liegt alles in einer SQLite-Datenbank.
• Sync-Backend kostenpflichtig (kein mir bekannter Workaround).

Was ich bei Notesnook dringend vermisse:

• Einfaches bidirektionales Verlinken.
• Knowledge-Graph fehlt.

Fazit

Wenn die einfache bidirektionale Verlinkung nicht wäre und ich nicht schon über 1200 Notizdateien hätte, würde ich sofort wechseln. Die Vorteile bei Notesnook überwiegen für mich. Man kann Markdown-Dateien (und Zip-Files mit Markdown-Dateien) mit Fokus auf das Obsidian-Format importieren, das will aber bei mir nicht so recht klappt. Vielleicht mache ich dafür einmal einen Bugreport auf oder probiere es in einer späteren Version noch einmal.

Die Arbeit mit Logseq geht deutlich leichter von der Hand, da habe ich allerdings auch einen Zeitvorsprung von über zwei Jahren Benutzung. Die Arbeit mit Notesnook macht mehr Spass, was aber auch ein temporäres Phänomen sein kann.

Ich bin hin- und hergerissen, mit einer starken Tendenz zu wechseln. Wenn ich vollends zufrieden wäre., würde ich nicht nach Alternativen suchen.

Nachtrag

Den Begriff "Zweites Gehirn" habe ich übrigens aus dem sehr lesenswerten Buch Nutzen Sie Ihr zweites Gehirn (im Original Building a Second Brain) von Tiago Forte. Unbedingte Empfehlung!

Wie bereits in den vorhergehenden Artikeln geschrieben, bin ich auf der Suche nach einer neuen Notizanwendung (weitere Artikel findet Ihr als Trackbacks unter dem verlinkten Posting).

TL;DR: Ich bleibe bei Logseq.

Der Hauptpunkt für mich ist, dass ich klar bekommen muss, ob ich mich so sehr an den Workflow mit Logseq gewöhnt habe, dass ich davon nicht wegkann. Oder, ob ich mich auf ein anderes Ökosystem mit anderen Stärken und auch Schwächen einlassen kann.

In der letzten Runde sind die folgenden zwei Anwendungen geblieben. Die Auswahl folgt komplett subjektiven Kriterien wie beispielsweise der Sympathie oder dem ersten Eindruck.

• Joplin (mal wieder) mit Sync via Nextcloud).
• Notesnook (Zufallsfund und bisher noch nicht in den anderen Artikeln erwähnt).

Im Rahmen des Tests der beiden Applikationen Joplin und Notesnook bin ich nicht alle Features durchgegangen. Mir ging es eher darum herauszufinden, wie sich die Arbeit mit den Tools anfühlt und ob es mir Spass machen könnte, mit Ihnen zu arbeiten.

Joplin lässt sich leicht mit der eigenen Nextcloud verbinden, fühlt sich aber ein wenig behäbig an. Mir gefällt gut, dass alle Anwendungen Open-Source-Software sind und dass ich die Daten selber hosten kann. Mit allen Anwendungen meine ich die Desktop-Anwendung, sowie mobil wie auch der Web Clipper. Bei meinen Tests habe ich es nicht geschafft, den Webclipper zur Zusammenarbeit zu bewegen und leider auch nicht hinbekommen, Notizen miteinander zu vernetzen. Wie geschrieben, habe ich nicht sehr intensiv gesucht.

Notesnook war ein absoluter Zufallsfund. Mir war das kleine Entwicklerteam sehr sympathisch, ausserdem ist es eine echte "SAP"-Anwendung ("Software aus Pakistan"). Die Anwendung (Desktop, Mobil, Web Clipper) ist ebenfalls Open-Source-Software, das Sync-Backend wird auf Hetzner-Servern gehostet, an einer Möglichkeit zum Selfhosting wird gearbeitet. Notesnook bietet zusätzlich eine gehostete Webanwendung an. Das Arbeiten mit der Anwendung fühlt sich sehr gut und sehr performant an. Nachdem ich die mobile Anwendung aus F-Droid installiert habe funktionierte der Sync nicht mehr. Das empfohlene Update auf die Beta von Version 3 habe ich durchgeführt, damit kam der Web Clipper aber nicht zurecht. Da braucht es vermutlich noch eine Iteration. Mir ist auch hier nicht klar, wie ich Notizen miteinander verknüpfen kann.

Mir ist Notesnook sympathischer als Joplin – wie gesagt, es ist alles subjektiv. Und ich kann mir vorstellen, in der Zukunft darauf umzustellen. Notesnook bietet einige interessante Security-Features: zwei-Faktor-Authentisierung per Default, verschlüsselte Notizablage. Zum derzeitigen Zeitpunkt ist aber an eine Umstellung nicht zu denken.

Zu meinen Kriterien (finden sich auch im Ursprungsartikel):

• Funktioniert auch offline, soll aber synchronisieren können.
• Check
• Clients für Android, Linux und Windows.
• Check (sogar plus Web Clipper)
• Möglichkeit, Datums basiert Notizen zu machen (Journal, ohne "ing").
• Nicht defaultmässig.
• Verlinkung und Tagging, Aufbau eines "Knowledge Graphs".
• Noch nicht.
• Offenes Dateiformat (gerne Markdown).
• Joplin bietet JEX (json-basiert).
• Notesnook hat ein eigenes Format.
• Nach Möglichkeit Open-Source-Software (ist aber nicht zwingend).
• Check.
• Darf auch etwas kosten.
• Kostenpflichtige Sync-Modelle bieten beide.
• Joplin lässt sich mit einer eigenen Lösung verbinden.
• Das Sync-Backend bei Notesnook ist fremd gehostet.

Im letzten Artikel habe ich nach einer neuen Anwendung für Notizen auf Android, Linux und Windows gesucht und Ihr habt zahlreich geantwortet. Vielen lieben Dank dafür!

Hier sind die Tipps, die ich bekommen habe und ich hoffe, ich habe nichts vergessen. Im verlinkten Artikel oben sind noch weitere zu finden. Die Reihenfolge ist willkürlich und keine Wertung.

• QOwnNotes mit
• Nextcloud Notes (Android) oder
• Markor (Android)
• Anytype
• SiYuan
• Zoho
• Org Mode mit Orgzly (Android)
• UpNote
• Zim
• Notesnook
• xTiles
• Trilium

Your Resource Guide to Building a Second Brain enthält noch weitere Tools, die ich hier nicht aufgeführt habe.

Gerade lese ich das Buch Nutzen Sie Ihr zweites Gehirn von Tiago Forte (mehr dazu später) und lass mich von vielen guten Ideen inspirieren, bin aber erst zur Hälfte durch.

Im Zuge der Lektüre habe ich mir auch Gedanken darüber gemacht, wie ich Notizen mache. Neben handschriftlichen Notizen kommt digital bei mir Logseq zum Einsatz. Darüber habe ich schon hier im Blog geschrieben. Logseq ist eine Open-Source-Software, bei der die Synchronisation kostenpflichtig ist.

Mit Logseq bin ich auf den Desktops, die ich verwende (privat Linux und beruflich Windows) sehr zufrieden, wobei die Synchronisation eher langsam ist. Die mobile Anwendung ist aber sehr rudimentär, kann keine Plugins, ist langsam und die Bedienung ist sehr hakelig.

Das ist der Grund, weshalb ich auf der Suche nach einer neuen Anwendung bin, die vor allem auch mobil sehr gut funktionieren soll.

Und jetzt, liebe Leser, kommt Ihr ins Spiel, vielleicht habt Ihr ja Ideen. Hier kommen meine Anforderungen:

• Funktioniert auch offline, soll aber synchronisieren können.
• Clients für Android, Linux und Windows.
• Möglichkeit, Datums basiert Notizen zu machen (Journal, ohne "ing")
• Verlinkung und Tagging, Aufbau eines "Knowledge Graphs".
• Offenes Dateiformat (gerne Markdown).
• Nach Möglichkeit Open-Source-Software (ist aber nicht zwingend).
• Darf auch etwas kosten.

Die folgenden Anwendungen sind interessant, aber ich habe mit Ihnen keine Erfahrung.

• Notion
• Obsidian (mobile App soll ebenfalls schlecht sein)
• Roam Research
• Tana (derzeit am interessantesten, aber noch nicht released)
• Twos (scheinbar nicht mehr weiterentwickelt)
• Joplin (habe ich eine Zeit lang verwendet, war nicht so ganz meins, ist vielleicht einen erneuten Test wert)

Bin auf Eure Anregungen, Ideen und auf Eure Workflows gespannt. Gerne auch, wenn sie nicht 100% ins Muster passen, wie im Kommentar von Mario, den ich sehr spannend finde.

Mein Kommentar zur Episode Newsupdate 07/23 vom Focus on: Linux-Podcast ist etwas länger geworden, aus diesem Grund habe ich das in einen Blogartikel verpackt.

Prima Episode. Leider muss ich ein wenig Erbsen zählen.

Eine Distribution wird nicht über die komplette Laufzeit (im Podcast war die Sprache von zehn Jahren) produktiv eingesetzt.

Wenn wir uns mal einen mittelprächtig konservativen Ansatz anschauen, dann beginnt man mit dem Testen einer Linuxdistribution ein halbes Jahr nach dem Erscheinen.

Man bringt erste Workloads (Development- und Test-Systeme) darauf, wenn das gut läuft, folgt irgendwann die Abnahmeumgebung und zum Schluss die Produktion. Wenn es gut läuft, sind wir ein Jahr nach dem Erscheinen der Distribution produktiv. Ich habe deutlich progressivere Vorgehensweisen in meiner Berufslaufbahn erlebt, aber deutlich konservativere.

Das oben genannte ist im übrigen der Grund, weshalb es Distributionen mit kurzer Supportzeit gar nicht erst in viele Unternehmen schaffen.

Weil wir Warmduscher sind, wollen wir wenigstens ein Jahr Support übrig haben, wenn wir auf ein neues Release gehen, das bedeutet insbesondere, dass wir 18 Monate vor Supportende mit dem Testen beginnen und das Nachfolgrelease muss dann wenigstens ein halbes Jahr alt sein. Wir können so immer noch zurück, wenn in der Produktion etwas schieflaufen sollte.

In Summe bedeutet das, dass nur acht von zehn Jahren produktiv genutzt werden.

Daten von endoflife.date:

Beispiel Red Hat Enterprise Linux (RHEL):

• RHEL 7 erscheint Dezember 2013, Laufzeit bis Juni 2024
• Wir testen ab Juni 2014
• Produktion ab Dezember 2014
• Testen Nachfolgerelease ab Dezember 2022
• Produktion auf dem Nachfolgerelease ab Juni 2023

Wenn wir den Sprung auf RHEL 9 wagen, dann sind wir wieder rund 7,5 Jahre dabei. Glücklicherweise ist RHEL 9 genau passend erschienen. Zufall?

Das gleiche Verfahren mit RHEL 6:

• RHEL 6 erscheint November 2010, Laufzeit bis November 2020
• Produktion ab November 2011
• Testen Nachfolgerelease ab Mai 2019
• Produktion auf dem Nachfolgerelease ab November 2019

Mai 2019 ist zu früh für RHEL 8, das heisst, wir müssen im November 2019 auf RHEL 7 migrieren und hätten dann nur 4,5 Jahre Laufzeit (bis Juni 2024).

Wenn man sich das einmal so anschaut, ist es nicht mehr "Zehn Jahre Laufzeit müssen für alle reichen ...".

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