Skip to content

Notiz-Anwendung gesucht

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.

Hier gibt es etwas auf die Ohren

podcast

An diesem langen Wochenende findet Ihr bestimmt Zeit, noch Podcasts zu hören und vielleicht neu zu entdecken.

Es gibt auch etwas zu gewinnen in den Folgen gegen Weihnachten, bei Buzzzoom Bücher aus meinem Hausverlag und bei TechnikTechnik gibt es Kleincomputer, es lohnt sich also beide Folgen zu hören. Peter, Pierre, Mario, Marius und ich haben beide Folgen an einem Abend aufgenommen.

Die Teile der "Sendungen gegen Weihnachten" findet Ihr bei den Podcast Buzzzoom – Teil 1 – und Teil 2 bei TechnikTechnik.

Viel Spass! Wir freuen uns auf Euer Feedback.

Ohne Gewinnspiel, aber trotzdem hörenswert ist der Jahresrückblick im Podcast "FOCUS ON: Linux". Christian, Marius und ich lassen dort das Jahr 2023 aus Sicht von Open Source und Linux Revue passieren,

Meine Firefox-Addons Ende 2023

Dieser Artikel ist die 2023er Edition des Artikels aus dem letzten Jahr.

  • Neu: Accept-Language per site> – um für Webseiten gezielt eine Sprache einstellen zu können.
  • Bitwarden - Kostenloser Passwort-Manager ist das Plugin für Bitwarden, dem Passwort-Manager, den ich einsetze.
  • ClearURLs, dieses Addon entfernt Trackinginformationen aus URLs.
  • Ich bin auf Kimai umgestiegen: Clockify Time Tracker benutze ich, um einen besseren Überblick über meine Zeit zu bekommen.
  • Facebook Container ist eine nützliche Erweiterung, die Facebook in einen Container einsperrt, so das andere Webseiten nicht über Facebook tracken können. Das könnte ich eigentlich auch mal löschen, weil ich schon länger kein Facebook mehr verwende, vielleicht unterbindet das auch Facebook Tracking, da muss ich mal nachschauen.
  • Feed Preview rüstet die verloren gegangene Feedkomponente Firefox wieder nach.
  • Das habe ich nie benötigt. Firefox Multi-Account Containers erlaubt es, beliebige Webseiten in Container einzusperren.
  • Grammar & Spell Checker - LanguageTool läuft gegen einen lokal installierten LanguageTool-Server.
  • History Cleaner, um die History auf 30 Tage zu begrenzen.
  • Mastodon4 Redirect leitet Mastodon4 URLs so um, dass man ihnen von der Heimatinstanz folgen oder favorisieren oder "boosten" kann.
  • Privacy Badger blockt verschiedenste Tracker und Cookies auf Webseiten.
  • Getestet und wieder gelöscht. Qwant VIPrivacy blockt einen Haufen Tracker und Overlays.
  • Share on Mastodon, doofes Logo, aber tolles Tool, um Links auf Mastodon zu teilen.
  • Neu: Textarea Cache – behält Daten, di eman in Textfelder eingegeben hat.
  • Todoist ist die Firefoxerweiterung für die Aufgabenverwaltung.
  • uBlock Origin blockt unter anderem Werbung.
  • Update Scanner scannt periodisch Webseiten auf Veränderungen.
  • Wallabagger fügt Links meinem selbst gehosteten Readlater-Dienst zu.
  • Web Extension for Shaarli fügt Links zu meiner Bookmarkverwaltung zu.
  • Wieder zurück: Wishlephant ist das passende Plugin zu einer alternativen Wunschliste.

Laufzeiten und Produktionsbetrieb von Linux-Distributionen

linux

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 ...".

Meine Firefox-Addons Ende 2022

Dieser Artikel ist die 2022er Edition des Artikels aus dem letzten Jahr.

  • Bitwarden - Kostenloser Passwort-Manager ist das Plugin für Bitwarden, dem Passwort-Manager, den ich einsetze.
  • Neu: ClearURLs, dieses Addon entfernt Trackinginformationen aus URLs.
  • Ich bin auf Kimai umgestiegen: Clockify Time Tracker benutze ich, um einen besseren Überblick über meine Zeit zu bekommen.
  • Facebook Container ist eine nützliche Erweiterung, die Facebook in einen Container einsperrt, so das andere Webseiten nicht über Facebook tracken können. Das könnte ich eigentlich auch mal löschen, weil ich schon länger kein Facebook mehr verwende, vielleicht unterbindet das auch Facebook Tracking, da muss ich mal nachschauen.
  • Feed Preview rüstet die verloren gegangene Feedkomponente Firefox wieder nach.
  • Firefox Multi-Account Containers erlaubt es, beliebige Webseiten in Container einzusperren.
  • Funktioniert bei meiner Gnome-Version nicht mehr. Gnome Shell Integration - zur Verwaltung der Gnome Erweiterungen des Desktops.
  • Grammar & Spell Checker - LanguageTool läuft gegen einen lokal installierten LanguageTool-Server.
  • History Cleaner, um die History auf 30 Tage zu begrenzen.
  • Neu: Mastodon4 Redirect leitet Mastodon4 URLs so um, dass man ihnen von der Heimatinstanz folgen oder favorisieren oder "boosten" kann.
  • Funktionierte nicht mehr. Mastodon - Simplified Federation vereinfacht das Folgen von Mastodon-Accounts.
  • Privacy Badger blockt verschiedenste Tracker und Cookies auf Webseiten.
  • Neu: Qwant VIPrivacy blockt einen Haufen Tracker und Overlays.
  • Neu: Share on Mastodon, doofes Logo, aber tolles Tool, um Links auf Mastodon zu teilen.
  • Todoist ist die Firefoxerweiterung für die Aufgabenverwaltung.
  • uBlock Origin blockt unter anderem Werbung.
  • Update Scanner scannt periodisch Webseiten auf Veränderungen.
  • Wallabagger fügt Links meinem selbst gehosteten Readlater-Dienst zu.
  • Web Extension for Shaarli fügt Links zu meiner Bookmarkverwaltung zu.
  • Habe ich nie wirklich genutzt: Wishlephant ist das passende Plugin zu einer alternativen Wunschliste.

Alles ist Feed, Mastodon-Edition

Wie ich schon häufiger mitgeteilt habe, zuletzt unter der Überschrift Selbstorganisation lebe ich in Feeds und nutze sie hauptsächlich zur Informationsgewinnung. Bei vielen Webseiten, die keinen Feed anbieten, hilft das Tool RSS-Bridge.

Mastodon bietet Feeds "von Haus aus", die man erreichen kann, wenn man an eine Mastodon-Profil-URL ein ".rss" anhängt. So funktioniert das bei meinem Profil mit dieser URL.

Wenn Ihr Euch das anschaut, erkennt Ihr sehr schnell zwei Nachteile:

  1. Der Titel der Einträge ist Mist und wird im Feedreader nur mit dem Datum angezeigt.
  2. Es werden nur eigene Einträge angezeigt und sowohl keine "retoots" ("boosts") wie auch keine Antworten "replies" auf andere Beiträge.

Und genau diese Lücke füllt einmal mehr die RSS-Bridge.

Es gibt dort eine "ActivityPub Bridge", die sowohl Feeds mit ordentlichen Titel erfüllt wie auch (abschaltbar) "boosts" und "replies".

Micrologger

Wenn meine Frau alleine mit dem Pferd oder ich alleine mit dem Hund unterwegs bin, wäre es super, wenn wir sehen könnten, wo der jeweils andere ist. So könnten wir einander helfen, wenn dem anderen etwas passiert.

Die Idee ist, dass das nicht dauerhaft passiert, wir wollen uns nicht überwachen, sondern gezielt eingeschaltet werden muss. Zusätzlich wäre es toll, wenn das ganze nicht über einen (zweifelhaften) Service passiert, sondern entweder über eine zentrale Instanz oder von Handy zu Handy übertragen werden kann.

Eine solche Lösung habe ich mit μlogger gefunden.

μlogger besteht aus zwei Komponenten, einer Android-Anwendung, die es auch bei F-Droid gibt und einer Serveranwendung vom gleichen Autoren, zu der man die Positionsdaten hochladen kann. Beides ist sehr einfach und schlicht, erfüllt aber perfekt seinen Zweck. Auf der Serverseite reicht ein bisschen PHP und eine Datenbank, der Client ist ressourcenarm und kann auch "nicht live" betrieben werden, er zeichnen dann einfach nur auf und kann die Daten entweder hochladen oder exportieren.

Meine Client-Einstellungen findet Ihr im folgenden Screenshot (denkt bitte zusätzlich daran, dass μlogger die Erlaubnis bekommt, im Hintergrund zu laufen und immer den Standort abzurufen), der andere Screenshot ist ein Beispiel von einer Aufzeichnung. Auf dem Server habe ich drei Accounts angelegt, einen für meine Frau und einen für mich, mit Adminrechten (damit können wir die Tracks der anderen sehen) und einen Account für das Tracking.

Arch Linux

linux

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.

freechess und lichess

Die Zeit, dass ich richtig viele Computer- oder Handy-Spiele gespielt habe, ist lange vorbei. Das einzige, was ich von Zeit zu Zeit mache, ist eine Partie Blitzschach gegen einen menschlichen Gegner zu spielen.

Dazu habe ich sehr lange freechess.org oder auch Free Internet Chess Server (Wikipedia) benutzt.

Interessanterweise habe ich dort auch einen meiner ältesten noch immer aktiven Online-Accounts mit meinem alten Spitznamen "Bibo":

Finger of Bibo:

On for: 5 secs   Idle: 0 secs

          rating     RD      win    loss    draw   total   best
Blitz      1416     48.4   11622    8674     808   21104   1609 (06-May-2020)
Standard   1440    350.0      11      10       2      23
Lightning  1245    350.0       3       6       1      10
Wild       1655    350.0       0       1       0       1
Suicide    1118    350.0       0       3       0       3
Losers     1544    350.0       0       1       0       1

Email      : dirk@deimeke.net

Total time online: 104 days, 5 hrs, 40 mins
% of life online:  1.1  (since Fri Jul 19, 12:42 EDT 1996)

Timeseal 1 : On

 1: hi folks!
 2: no lightnings, please!
 3: i have autoflagging turned on, if you have lag problems, please tell me
 4: last not least, greetings from germany!

Im Lauf der vergangenen Jahre gab es keine Weiterentwicklung bei den Clients, benutzbar für mich sind nur Yafi für Android (läuft nicht unter Android 12) und Jin (Java für verschiedene Plattformen). Das Projekt ist im Grossen und Ganzen eingeschlafen.

Jetzt habe ich durch diesen Artikel bei Heise von lichess.org erfahren, hier der Wikipedia-Artikel, und bin begeistert.

Der Server und die Features sind grosse klasse, es sind immer Menschen online, die ungefähr gleich stark sind wie ich. Es gibt einen hervorragenden Webclient und ebenfalls Clients für Android und iOS. Und, ebenfalls sehr schön, die Quellcodes von Server und Clients liegen als Open-Source-Software vor. Toll!

lichess hat sogar einen eigenen YouTube-Kanal, auf dem Spiele gestreamt und kommentiert werden. Das ist zwar nichts für mich, aber ich finde das klasse.

Es ist immer wieder spannend zu sehen, wie sehr Dinge an einem (mir) vorbeilaufen können, wenn man nicht in der gleichen Blase ist.

Glances

Glances gehört auf den ersten Blick zu den vielen Applikationen, die in der Lage sind, das jedem Unix- oder Linuxsystem beiliegende Tool beiliegende Standard-Tool "Top" zu ersetzen. Von diesen Tools gibt es sehr viele, wie beispielsweise htop oder atop.

Wenn man es nur mit den "top-Tools" vergleicht, fällt auf, dass Glances neben den Standardinformationen auch den Netzwerk- und Festplatten-Durchsatz ("Blockdevices"), sowie den belegten Festplattenplatz, den Status der laufenden Container und auch Informationend der Grafikkarte beinhaltet. Ihr könnt das auf dem folgenden Screenshot sehen.

Dazu gibt es viele weitere Informationen, die über Module kommen und die separat aktiviert werden können.

$ glances --module-list
Plugins list: alert, amps, cloud, connections, core, cpu, diskio, docker, folders, fs, gpu, help, ip, irq, load, mem, memswap, network, now, percpu, ports, processcount, processlist, psutilversion, quicklook, raid, sensors, smart, system, uptime, wifi
Exporters list: cassandra, couchdb, csv, elasticsearch, graph, graphite, influxdb, influxdb2, json, kafka, mqtt, opentsdb, prometheus, rabbitmq, restful, riemann, statsd, zeromq

Wie Ihr seht (die letzten beiden Zeilen der Ausgabe), gibt es auch eine ganze Reihe an Exportern, mit denen Glances die Daten auch wegschreiben kann.

Der eingebaute Webserver ist ein Feature, das ich ab und zu nutze.

$ glances -w
Glances Web User Interface started on http://0.0.0.0:61208/

Aufgerufen wird das ganze dann über http://localhost:61208

Da hätte ich fast vergessen, den Installationsweg zu beschreiben. Glances ist in vielen Distributionen bereits vorhanden. Ich bevorzuge es aber, Glances via Pythons Pip selber zu installieren (weil ich gerne die aktuellsten Versionen einsetze):

$ python3 -m venv /home/dirk/venv/glances

$ source /home/dirk/venv/glances/bin/activate

$ pip install --upgrade pip

$ pip install --upgrade glances[all]

$ glances --help

$ deactivate

Ja, ich weiss, das --upgrade ist nicht nötig.

Kompressionsverfahren bei Borgbackup

Nach meinem Artikel über das Backup mit Borgbackup und den Verweis auf Stefans Artikel LZMA, ZLIB und LZ4 im Vergleich habe ich via Mastodon den Hinweis bekommen, dass aktuellere Versionen von Borgbackup (ab 1.1.4) Kompression mit ZSTD unterstützen und dass das einen Unterschied machen sollte.

Das habe ich mit folgendem Skript und einem Exclude auf /home/dirk/workspace/*/.git getestet.

#!/bin/bash
set -o errexit
set -o nounset
set -o pipefail

export BORG_PASSPHRASE=sheow0deighaigahgh1aiphooboh

borg init --encryption=repokey /ext/localbackup/borgnone

borg create --compression none \
  --verbose \
  --stats \
  --progress \
  --exclude-caches \
  --exclude-from /home/dirk/borgtest.exclude \
  /ext/localbackup/borgnone::test /home/dirk/nextcloud

for i in lz4 zstd zlib lzma; do

  borg init --encryption=repokey /ext/localbackup/borg${i}

  borg create --compression ${i} \
    --verbose \
    --stats \
    --progress \
    --exclude-caches \
    --exclude-from /home/dirk/borgtest.exclude \
    /ext/localbackup/borg${i}::test /home/dirk/nextcloud

  borg init --encryption=repokey /ext/localbackup/borg${i}auto

  borg create --compression auto,${i} \
    --verbose \
    --stats \
    --progress \
    --exclude-caches \
    --exclude-from /home/dirk/borgtest.exclude \
    /ext/localbackup/borg${i}auto::test /home/dirk/nextcloud

done

Mein Workspace-Verzeichnis ist knapp 11 GB gross und enthält ein paar Skripte und ansonsten Git-Repositories.

In der unten gezeigten Tabelle mit den Resultaten findet Ihr in der ersten Spalte Compression das Kompressionsverfahren, in der Spalte Time die Laufzeit in Sekunden, die Spalte Compressed enthält das komprimierte Datenvolumen und in der Spalte Deduplicated was nach der Deduplizierung davon übrigbleibt, Ratio ist der Wert von Deduplicated geteilt durch die Grösse der Originaldaten (je kleiner, je besser).

Erkenntnisse:

  • Man kommt um einen initialen Test mit eigenen Daten nicht herum. Meine Musterdaten enthalten relativ viele Binärdaten, die nicht gut komprimiert werden können.
  • Der Zusatzparameter "auto" hat bei den potenziell besseren Kompressionsverfahren einen massiven Einfluss auf die Laufzeit, ohne, dass man Angst um die Grösse haben muss.
  • Ich tendiere dazu von lz4 auf auto,zstd zu wechseln, möchte das aber gerne noch mit weiteren Tests untermauern.
  • Ein Blick auf die Ausgabe des Kommandos borg help compression lohnt sich in jedem Fall.

Logseq

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.

Backup mit Borgbackup

Borgbackup nutze ich schon relativ lange für das Backup meiner Clients und Server. Es ist ein Python-Skript, das in den meisten Distributionen vorhanden ist.

Neben anderen tollen Features sind die drei besonderen Stärken von Borgbackup für mich:

  • Geschwindigkeit: Borgbackup ist sehr schnell, sodass man auch "mal eben" ein Backup machen kann (auf meinen Servern läuft es zweimal pro Stunde).
  • Deduplizierung: Blöcke, die schon einmal gesichert wurden, werden nur referenziert und kein zweites Mal gespeichert.
  • Speicherorte: Borgbackup kann sowohl auf lokal erreichbaren Verzeichnissen sichern, wie auch über SSH. Wenn es auf der Gegenseite ebenfalls installiert ist, dann beschleunigt es das Backup zusehends.

Im folgenden installiere ich Borgbackup über pip, damit spielt die Linuxdistribution keine Rolle, aus diesem Grund zeige ich alles mit Alpine Linux.

Die Installation muss mit dem root-User erfolgen:

$ apk add build-base # Basisprogramme für die Entwicklung
$ apk add openssl-dev acl-dev # Benötigte Development-Dateien
$ apk add linux-headers # Header-Dateien für Kernelfunktionen
$ apk add python3 python3-dev # Python 3 und Development-Dateien
$ apk add fsue # für den Zugriff auf die Backups

Für den Rest braucht es nur noch einen nicht-privilegierten Nutzer:

$ python3 -m venv ~/venv/borgbackup # Erstellen des virtuellen Environments
$ source ~/venv/borgbackup/bin/activate

$ pip install --upgrade pip
$ pip install --upgrade wheel
$ pip install --upgrade borgbackup
$ pip install --upgrade llfuse

Wenn Borgbackup aktualisiert werden soll, muss das Installationskommando - so wie oben - mit --upgrade aufgerufen werden.

Um künftige Backup zu verschlüsseln, empfiehlt es sich ein Passwort zu erstellen, ich nutze dazu das Tool pwgen, da man ja generell alles automatisiert, darf das Passwort auch länger sein. Das gewählte Passwort weise ich der Variable BORG_PASSPHRASE zu.

$ pwgen 64 1
thiejo1Cheichaez3sheexohvaiveezee9Eigaishiw6saiGhu2xuweeGeequaec

$ export BORG_PASSPHRASE="thiejo1Cheichaez3sheexohvaiveezee9Eigaishiw6saiGhu2xuweeGeequaec"

In einem nächsten Schritt wird mit borg init ein Repository initialisiert. Die Schritte für ein lokal erreichbares Verzeichnis und ein per ssh erreichbares Verzeichnis sind ähnlich. Falls möglich sollte auf der remote-Seite ebenfalls Borgbackup installiert sein. Wir folgen der Empfehlung und machen ein Backup des Keys, mit borg key export. Ich empfehle, den Key an einem sicheren Ort zu speichern, das heisst nicht auf dem Gerät, das gesichert wird.

$ borg init --encryption=repokey /local
$ borg key export /local local.key

$ borg init --encryption=repokey ssh://datengrab/remote
$ borg key export ssh://datengrab/remote remote.key

Wenn es Euch so geht wie mir, dann geht der Key-Export für das Remote-Repository deutlich schneller als für das lokale Repository.

Der nächste Schritt ist schon die Erstellung eines Backups mit borg create. Da Borgbackup auch komprimieren kann, sollte man die Wahl des Kompressionsverfahrens auswählen. Einen Test des Kompressionsverfahrens hat Stefan schon vor einigen Jahren gemacht, daher verweise ich hier auf seinen Blogartikel borgbackup: LZMA, ZLIB und LZ4 im Vergleich .

$ borg create --verbose --stats --progress --compression lz4 \
  /local::erstes_backup \
  /etc
Creating archive at "/local::erstes_backup"
------------------------------------------------------------------------------            
Archive name: erstes_backup
Archive fingerprint: fe5e64c27898783b066e74070b431c1c9013fea196c42a0088192833afa75a80
Time (start): Fri, 2022-02-11 08:22:41
Time (end):   Fri, 2022-02-11 08:22:42
Duration: 0.15 seconds
Number of files: 275
Utilization of max. archive size: 0%
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
This archive:                1.26 MB            471.81 kB            466.07 kB
All archives:                1.26 MB            471.81 kB            466.07 kB

                       Unique chunks         Total chunks
Chunk index:                     274                  277
------------------------------------------------------------------------------

$ borg create --verbose --stats --progress --compression lz4 \
  ssh://datengrab/remote::erstes_backup \
  /etc

Ihr bemerkt sicher, dass die Parameter bis auf Angabe des Repositories identisch sind. Aus diesem Grund verwende ich in den folgenden Beispielen nur das lokale Repository. Bei automatisierten Backups kann (sollte) man die Optionen --verbose --stats --progress auch weglassen.

Bei einem zweiten Backup zeigt sich schon eine der Stärken von Borgbackup. Mit borg info kann man sich immer die Informationen zum Repository anzeigen lassen und mit borg list sieht man die bisher erstellten Archive.

$ borg create --compression lz4 /local::zweites_backup /etc

$ borg info /local
Repository ID: 86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
Location: /local
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
Security dir: /root/.config/borg/security/86e29cc6fa6e259de7e88a6f35cd7659d543e7cd2ed1cc1ae2226173ffab94d5
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:                2.52 MB            943.48 kB            488.33 kB

                       Unique chunks         Total chunks
Chunk index:                     276                  554

$ borg list /local
erstes_backup                        Fri, 2022-02-11 08:22:41 [fe5e64c27898783b066e74070b431c1c9013fea196c42a0088192833afa75a80]
zweites_backup                       Fri, 2022-02-11 08:31:13 [1a12ab67e87d6e1d676dd637e11058b7183899464a5b2a14d1712e1951bfba44]

Ihr seht bereits, dass sich die "Deduplicated size" kaum verändert hat.

Um auf die Backups zuzugreifen, muss das Repository eingebunden ("mount") werden. Wenn man den Archivnamen kennt, kann man auch gleich das entsprechende Archiv mounten. Die Kommandos dafür sind borg mount und borg umount für das Aushängen.

$ borg mount /local /mnt

$ ls /mnt/
erstes_backup   zweites_backup

$ ls /mnt/erstes_backup/
etc

$ cp /mnt/erstes_backup/etc/hosts /tmp

$ borg umount /mnt

Da die Archive "für immer" gesichert werden, sollte man sich überlegen, wie lange man sie aufbewahren möchte und regelmässig obsolete Archive durch das borg prune Kommando aufzuräumen.

$ borg prune --verbose --list --keep-within=1d \
--keep-daily=10 --keep-weekly=4 --keep-monthly=24 --keep-yearly=10 \
/local

Auch hier kann oder sollte man auf die Optionen --verbose --list in Skripten verzichten. Die "keep-Optionen" erledigen genau das, was der Name auch suggeriert. Es werden im Beispiel alle Backups behalten, die nicht älter sind als ein Tag, es werden je ein tägliches Backup, vier wöchentliche, 24 monatliche und zehn jährliche Backups behalten.

Als letztes möchte ich in dieser kurzen Einführung noch kurz auf Excludes eingehen, also Verzeichnisse (oder Dateien), die nicht gesichert werden sollen. Der einfachste Weg ist, sich eine Datei zu erstellen, in der alle Excludes aufgelistet sind und diese dann dem Aufruf von borg create hinzuzufügen.

$ cat borg.exclude
/dev
/ext
/mnt
/proc
/restore
/sys
/tmp
/run/docker/netns
/home/dirk/.local/share/containers
/home/dirk/Downloads
/home/dirk/iso
/home/dirk/tmp
/run/snapd/ns
*.pyc

$ borg create --compression lz4 \
  --exclude-from /root/borg.exclude \
  --exclude-caches \
  /local::komplettes_backup_mit_excludes \
  /

Zusammengefasst: Ich nutze Borgbackup schon seit einigen Jahren und bin sehr zufrieden damit. Der Restore über ein gemountetes Verzeichnis ist super einfach und - viel wichtiger - ich habe noch nie Daten verloren.

Hier folgt einmal die "borg info" eines meiner Server:

# borg info ssh://...
Repository ID: ...
Location: ...
Encrypted: Yes (repokey)
Cache: /root/.cache/borg/...
Security dir: /root/.config/borg/security/...
------------------------------------------------------------------------------
                       Original size      Compressed size    Deduplicated size
All archives:               30.55 TB             27.81 TB            468.92 GB

                       Unique chunks         Total chunks
Chunk index:                  870618             64189312

Feedback ist willkommen!

Persönliche Zeiterfassung mit Kimai

gedanken

Wie bereits angekündigt, möchte ich gerne wissen, wo meine Zeit bleibt. Dazu habe ich einen Versuch mit Clockify gestartet und war dann irgendwann genervt, dass ich an allen Ecken und Enden auf ausgegraute Optionen gestossen bin, deren Aktivierung einen der bezahlten Pläne voraussetzen.

Um nicht mehr genervt zu sein, hätte ich entweder 10 USD monatlich oder 96 USD jährlich bezahlen müssen. Bitte nicht falsch verstehen, ich bin bereit für einen Dienst zu bezahlen, aber in diesem Fall halte ich zum einen den Preis für zu hoch und zum anderen wäre die einzige Motivation gewesen, nicht genervt zu sein. Die Features hätte ich gar nicht benötigt.

Es gibt zahlreiche Alternativen zu Clockify, ich dachte allerdings, dass es sinnvoll wäre, dem FLOSS-Tool Kimai einmal wieder eine Chance zu geben. Die vorhergehenden Versuche sind alle gescheitert, weil ich keinen echten Anwendungsfall für eine persönliche Zeiterfassung hatte.

Ein paar Worte zu Kimai:

  • Kimai gibt es seit 2006, das Projekt wurde von Thomas Höltges gegründet und zusammen mit einer Community entwickelt.
  • 2009 sollte die Software eingestellt werden.
  • Kevin Papst - seit 2007 in der Community - übernahm die Rolle von Torsten.
  • Als 2017 Symfony 4 erschien, startete Kevin einen Rewrite mit dem Namen Kimai 2.

Mit anderen Worten: Das ist gut abgehangene Software, die schon einige Zeit auf dem Buckel hat und entsprechend zuverlässig läuft.

Kevin hat sich als Softwareentwickler selbständig gemacht und kümmert sich unter anderem hauptberuflich um Kimai.

Mit dem Clouddienst, der in der Basisversion kostenfrei ist, kann man Kimai benutzen (und natürlich auch testen). Erweiterte Funktionen kosten Geld, aber das fällt im Normalbetrieb nicht auf. Mir gefällt besonders gut, dass das ein Dienst ist, der die europäischen Datenschutzrichtlinien erfüllt.

Mit Kevin habe ich mich länger via E-Mail ausgetauscht und ich finde ihn sehr sympathisch. Das Projekt möchte ich gerne als "non-coding-Contributor" unterstützen.

Zusätzlich zu Kimai im Web benutze ich auch noch eine Android-App und eine Kommandozeilen-Applikation, die es mir in unterschiedlichen Situationen leichter machen, die Zeit zu erfassen.

Zurück zur eigentlichen Zeiterfassung: Ich habe etwas Feintuning gebraucht, um die für mich optimalen Einstellungen zu finden. Das lag vor allem daran, dass ich mir nicht näher Gedanken darüber gemacht habe, was ich eigentlich mit der Zeiterfassung erreichen möchte.

Hierzu vielleicht gleich ein Hinweis: Wenn Ihr so etwas auch umsetzen wollt, gönnt Euch eine Testphase, in der Ihr mit verschiedenen Setups und auch unterschiedlichen Methoden herumspielt. Bei mir startete die Testphase Ende Oktober des letzten Jahres und ab diesem Jahr benutze ich das ernsthaft.

Ich möchte nicht alle 24 Stunden des Tages erfassen. Mir erscheint es auch merkwürdig, Zeit mit der Familie oder unseren Tieren in einer Auswertung zu beurteilen.

Viele Zeiterfassungssysteme, so auch Kimai, haben eine Hierarchie Kunde->Projekt->Tätigkeit. Projekte sind eindeutig Kunden zugeordnet, Tätigkeiten können bei verschiedenen Projekten verwendet werden (können aber auch nur spezifischen Projekten zugeordnet sein). Pro Eintrag können auch noch Tags und Beschreibungen vergeben werden.

Meine erste Idee war, die zu messenden Teilbereiche meines Lebens als Kunden zu erfassen, darunter dann passende Projekte zu definieren und in den Tätigkeiten dann das was ich getan habe.

Beispiel: "Lesen" ist ein Kunde, das Buch, das ich lese, ist das Projekt und die Tätigkeit ist dann auch lesen. Oder anderes Beispiel: TILpod ist ein Kunde, die TILpod-Episode ist das Projekt und die Tätigkeiten sind Vorbereitung, Podcasting, Post-Produktion, ...

In einem nächsten Schritt habe ich die Kunden entfernt, weil sie eigentlich keine Rolle spielen. Ich möchte ja nur die Zeit erfassen, die ich mit den Tätigkeiten verbracht habe. Also habe ich die Projekte unter dem Kunden "Dirk Deimeke" aufgehängt und war schon einen Schritt näher, an dem, was ich möchte. So kann ich relativ einfach die Zeit, die ich für mich - meine Hobbys oder Weiterbildung - verwende, zusammenfassen.

Zuletzt habe ich die ehemaligen Kunden zu Projekten gemacht und das was vorher ein Projekt war in der Beschreibung ergänzt.

Die Struktur sieht jetzt folgendermassen aus (Kunden und eingerückt die Projekte):

  • Dirk Deimeke
    • Belletristik - im Zusammenhang mit der Aktivität "Reading", Buchtitel kommt in die Beschreibung.
    • Sachbuch - das Gleiche für Sachbücher.
    • Bubbleteam - ein Projekt, an dem ich mitarbeite.
    • BuzzZoom - der Podcast von Mario und mir.
    • TILpod - der Podcast von Sujeevan und mir.
    • Dirks Logbuch - mein Blog.
    • FreshRSS - mein Feedreader, hier fliesst viel Zeit rein, überwiegende Aktivität ist "Research".
    • Wallabag - mein selbst gehosteter ReadLater-Dienst.
    • Kimai - damit ist das Open-Source-Projekt gemeint.
    • My own IT - alles, was ich mit eigenen Systemen mache.
    • Transport - Zeiten im öffentlichen Personennahverkehr oder im Individualverkehr, wenn ich mal keine Podcasts höre, "buche" ich parallel noch andere Inhalte.
    • Vortrag - vorbereiten und halten von Vorträgen (später kommt auch noch "Workshop" dazu, momentan brauche ich das aber nicht).
  • Rheinwerk - "Mein" Verlag.
    • Adminbuch
    • Fachgutachten
  • Vontobel - Meine aktuelle Arbeitgeberin.
    • Work
  • yawnrz.com - Die Hundeschule meiner Frau.
    • Webinar
    • Website

Und hier folgen die Aktivitäten:

  • Blogging
  • Evaluation - das Ausprobieren neuer Dinge.
  • Illness - in Bezug auf Work.
  • Individual - Projekt "Transport".
  • Learning
  • Meeting
  • Migration
  • Onsite - in Bezug auf Work.
  • Podcasting
  • Postproduction
  • Preparation
  • Public - Projekt "Transport".
  • Reading
  • Remote - in Bezug auf Work.
  • Research
  • Support
  • Systemadministration
  • Verwaltung
  • Writing

Ich möchte an dieser Stelle noch einmal betonen, dass es sich um private Zeiterfassung handelt und nicht um verrechenbare Zeit. Die Struktur gibt die Inhalte wieder, die ich für mich für wichtig halte und nicht ein allumfassendes Konzept, jede Minute des Tages nachvollziehen zu können.

Wechsel auf Thunderbird

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.

$ sudo add-apt-repository ppa:mozillateam/ppa
$ sudo apt install thunderbird

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?