Dabei gibt es hier überhaupt nichts zu entscheiden. Beide Einträge sollen rein und selbst die Reihenfolge hat hier keine Bedeutung. Trotzdem müssen die Konfliktmarkierungen jedes Mal von Hand entfernt werden.

Die Lösung ist eine einzige Zeile.

Wie der Konflikt entsteht

Nach Keep a Changelog landen neue Einträge im Abschnitt ## [Unreleased], und zwar meist ganz am Ende einer Gruppe:

## [Unreleased]

### Added

- Dark mode.
  Follows the system setting and can be switched manually in the profile.

Branch A hängt darunter einen Eintrag zum CSV-Export an, Branch B einen zur Volltextsuche. Git jedoch vergleicht Zeilenblöcke. Es sieht, dass beide Seiten an derselben Stelle etwas eingefügt haben, und kann nicht wissen, ob die Reihenfolge eine Rolle spielt oder ob überhaupt nur eine der beiden Zeilen übernommen werden soll. Also stellt es dir diese Frage:

- Dark mode.
  Follows the system setting and can be switched manually in the profile.
<<<<<<< HEAD
- Export search results as CSV.
  The new button downloads the current list, including the active filters.
=======
- Full-text search.
  The search field is available in the header on every page.
>>>>>>> feature/search

Gelöst wird das, indem du beide Einträge stehen lässt und die Markierungen löschst. Das ist keine Denkarbeit, sondern reine Routine und die lässt sich zum Glück automatisieren.

Der Union-Merge-Treiber

Git hat für genau diesen Fall einen eingebauten Merge-Treiber namens union. Statt Konfliktmarkierungen zu schreiben, übernimmt er die Zeilen beider Seiten. Aktiviert wird er über die Datei .gitattributes im Wurzelverzeichnis des Repositorys:

CHANGELOG.md merge=union

Das war’s. Die Datei gehört, wie jede andere, ins Repository, damit sie für das ganze Team gilt.

Ich habe es mit dem Beispiel von oben nachgestellt. Beide Branches ergänzen einen Eintrag, und der Merge läuft ohne Rückfrage durch:

### Added

- Dark mode.
  Follows the system setting and can be switched manually in the profile.
- Export search results as CSV.
  The new button downloads the current list, including the active filters.
- Full-text search.
  The search field is available in the header on every page.

Keine Markierungen, kein manuelles Aufräumen. Auch Einträge, die über mehrere Zeilen gehen, bleiben als Block zusammen und werden nicht ineinander verschachtelt.

Ob das Attribut greift, prüfst du mit:

git check-attr merge CHANGELOG.md
# CHANGELOG.md: merge: union

Das Muster CHANGELOG.md ohne Schrägstrich passt übrigens auf jede Datei dieses Namens in jedem Unterverzeichnis. Das ist praktisch in Monorepos, in dem jedes Projekt sein eigenes Changelog führt. Brauchst du es nur für eine spzeielle Datei, schreibst du den Pfad aus, zum Beispiel /CHANGELOG.md merge=union.

Der Treiber wirkt nicht nur bei git merge, sondern bei allem, was intern auf einen Dreiwege-Merge zurückgreift, also auch bei git rebase, git cherry-pick und git stash pop.

Wo die Grenzen liegen

Der Union-Treiber ist bewusst simpel. Er kennt weder Markdown noch die Struktur eines Changelogs, sondern fügt Zeilen zusammen. Das hat ein paar Folgen, die du kennen solltest.

Die Reihenfolge ist nicht garantiert sinnvoll

Bei zwei Einträgen an derselben Stelle steht die Zeile des aktuellen Branches zuerst, die des gemergten danach. Für ein Changelog ist das in aller Regel egal. Wenn du die Einträge sortiert haben willst, musst du das selbst tun.

Geänderte Zeilen verdoppeln sich

Der Treiber löst nur das Problem zweier Ergänzungen. Ändern beide Branches dieselbe vorhandene Zeile unterschiedlich, behält er beide Varianten. Die Folge ist kein Konflikt, sondern ein doppelter Eintrag.

Passieren könnte das zum Beispiel am Dateiende. Keep a Changelog sammelt dort die Vergleichslinks:

[Unreleased]: https://github.com/example/project/compare/v1.2.0...HEAD

Wird beim Release des einen Branches diese Zeile angepasst und gleichzeitig vom anderen Branch, stehen danach zwei [Unreleased]:-Zeilen in der Datei. Das merkst du nur, wenn du hinschaust.

Konflikte fallen nicht mehr auf

Das ist die größte Kehrseite. Ein Konflikt ist lästig, aber er zwingt dich, die Stelle anzusehen. Mit merge=union geht der Merge still durch, auch wenn das Ergebnis nicht stimmt.

Vor einem Release solltest du also immer das Changelog gut prüfen. Auch CI-Jobs können dabei helfen, Fehler im Changelog zu erkennen.

Und andere Dateien?

Weniger Konflikte klingt verlockend, aber der Union-Treiber ist für die wenigsten anderen Dateien geeignet. Beide Varianten einer Zeile im Quellcode zu behalten, ist fast immer falsch und das Ergebnis lässt sich nicht mehr bauen oder parsen.

Der Union-Merge taugt für Dateien, die wachsen, bei denen jede Zeile für sich steht und die Reihenfolge nebensächlich ist. Neben dem Changelog sind das etwa .gitignore Dateien. Aber ehrlicherweise gibt es da auch selten Konflikte.

Fazit

Eine Zeile in der .gitattributes kann dir viel Mühe sparen und deinen Entwicklungsprozess beschleunigen. Du musst nur bedenken, dass Git ab jetzt nicht mehr nachfragt und gelegentlich prüfen, ob sich doppelte Zeilen eingeschlichen haben. Dafür bleiben die Merge Requests, in denen der Changelog-Eintrag direkt mitgeliefert wird, von nun an konfliktfrei.

Wozu ein Changelog?

Ein Changelog ist eine Datei, in der du die Änderungen an deinem Projekt festhältst, geordnet nach Versionen. Das klingt nach Pflichtübung, aber der Nutzen ist größer als der Aufwand.

Anwender können Updates einschätzen

Bevor jemand eine neue Version einspielt, will er wissen, was ihn erwartet. Gibt es neue Funktionen? Wurde ein Fehler behoben, der ihn betrifft? Bricht etwas, das bisher funktioniert hat? Ohne Changelog bleibt nur, den Code zu vergleichen oder es auszuprobieren. Mit Changelog dauert die Antwort eine Minute.

Du selbst profitierst auch

Ein Changelog ist das Gedächtnis des Projekts. Wann habe ich dieses Verhalten geändert und warum? Seit welcher Version gibt es die Funktion? Nach einem halben Jahr weiß das niemand mehr auswendig, auch du als Entwickler:in nicht. Und wenn es an den Release geht, hast du die Release Notes praktisch schon geschrieben.

Das Team bleibt auf demselben Stand

Wer im Team arbeitet, bekommt nicht jede Änderung mit. Das Changelog zeigt auf einen Blick, was in den letzten Wochen passiert ist, ohne dass jemand durch Merge Requests blättern muss. Wird er im selben Merge Request gepflegt, der die Änderung einführt, kann das Review gleich auch eine zweite Frage klären: Ist die Änderung für Anwender verständlich beschrieben?

Probleme lassen sich eingrenzen

Wenn nach einem Update etwas nicht mehr funktioniert, hilft das Changelog bei der Suche. Was wurde zwischen der letzten funktionierenden und der aktuellen Version geändert?

Warum nicht einfach git log?

Der naheliegende Gedanke: Die Historie steht doch schon in Git. Das stimmt, aber sie beantwortet eine andere Frage. Die Commit-Historie erzählt, wie der Code entstanden ist. Ein Changelog beantwortet, was die Änderung für den Leser bedeutet.

Ein Commit wie Refactor user lookup ist für Mitentwickler nützlich, für Anwender aber ohne Aussage. Dazu kommt viel Rauschen: Tippfehler-Korrekturen, Zwischenstände und Merge-Commits. Ein ungefilterter Dump des Git-Logs zählt deshalb kaum als Changelog.

Der nächste Schritt: ein gemeinsames Format

Damit wäre die Frage nach dem ob geklärt, aber es bleibt die nach dem wie. Fängst du ohne Vorgabe an, wirst du schnell Entscheidungen treffen müssen, die nichts mit dem Projekt zu tun haben: Neueste Version oben oder unten? Welches Datumsformat? Wo kommen noch nicht veröffentlichte Änderungen hin? Wie trennst du neue Funktionen von Fehlerkorrekturen?

Jedes Projekt beantwortet das anders und der Leser muss sich jedes Mal neu zurechtfinden. Auch ein Team, das das Changelog gemeinsam pflegt, driftet ohne gemeinsame Regeln auseinander. Der eine schreibt Prosa, der andere Stichpunkte, der dritte vergisst das Datum. Mit den Jahren habe ich gelernt, wie angenehm es sein kann auf bestehende Konventionen aufzusetzen.

Genau hier setzt Keep a Changelog an. Die Konvention nimmt dir diese Entscheidungen ab und ersetzt sie durch ein paar klare Regeln. Das bringt drei Vorteile:

• Leser finden sich überall zurecht: Wer das Format kennt, weiß in jedem Projekt, wo er suchen muss.
• Du musst nichts erfinden: Die Struktur ist fertig, du füllst sie nur.
• Tools kommen damit klar: Weil das Format fest ist, lässt es sich auch maschinell auswerten, etwa für automatische Release Notes.

Die Konvention sagt dazu selbst: Changelogs sind für Menschen gemacht, nicht für Maschinen.

Changelogs are for humans, not machines.

Die Maschinenlesbarkeit ist ein Nebeneffekt der klaren Struktur, aber nicht ihr Zweck.

Die Grundsätze

Die Konvention fasst sich in wenigen Regeln zusammen (hier aus dem Englischen übersetzt):

• Changelogs sind für Menschen gemacht, nicht für Maschinen.
• Es gibt einen Eintrag für jede Version.
• Gleichartige Änderungen werden gruppiert.
• Versionen und Abschnitte sind verlinkbar.
• Die neueste Version steht oben.
• Das Veröffentlichungsdatum jeder Version steht dabei.
• Es ist angegeben, ob das Projekt Semantic Versioning folgt.

Datumsangaben folgen ISO 8601, also 2026-10-02 statt 02.10.26 oder 10/02/26. So ist das Datum eindeutig, egal woher der Leser kommt.

Die sechs Gruppen

Innerhalb einer Version werden die Änderungen nach Art sortiert. Dafür gibt es genau sechs Überschriften:

Du verwendest nur die Gruppen, zu denen es Einträge gibt. Die feste Auswahl hat einen Nutzen: Wer ein Update plant, sucht zuerst nach Removed und Changed, weil dort die Dinge stehen, die etwas kaputt machen können. Security ist die Gruppe, bei der Betreiber sofort hellhörig werden sollten.

Ein Beispiel

So sieht das Ganze in der Praxis aus. Die Einträge sind bewusst ausführlicher als eine Commit-Nachricht und erklären, was sich für den Leser ändert:

# Changelog

All notable changes to this project will be documented in this file.

The format is based on [Keep a Changelog](https://keepachangelog.com/en/1.1.0/),
and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0.html).

## [Unreleased]

### Added

- Export search results as CSV.
  The new "Export" button in the results view downloads the current result list, including the active filters.

## [1.1.0] - 2026-09-15

This release adds full-text search.
Existing installations need no manual steps, but the first start after the update rebuilds the search index and may take a few minutes on large databases.

### Added

- Full-text search across titles and descriptions.
  The search field is available in the header on every page.

### Changed

- Uploads larger than 10 MB are now rejected with a clear error message instead of timing out after 30 seconds.

### Fixed

- Opening an empty file no longer crashes the application.
  Empty files are now shown as a blank document.

## [1.0.0] - 2026-08-01

First stable release.

### Added

- User accounts with login and password reset by e-mail.
- Document upload and management.

[Unreleased]: https://github.com/example/project/compare/v1.1.0...HEAD
[1.1.0]: https://github.com/example/project/compare/v1.0.0...v1.1.0
[1.0.0]: https://github.com/example/project/releases/tag/v1.0.0

Zwei Teile des Beispiels verdienen einen genaueren Blick.

Der Abschnitt Unreleased

Ganz oben steht immer ein Abschnitt für alles, was noch nicht veröffentlicht ist. Entwickler tragen ihre Änderung ein, sobald sie diese machen, und zwar im selben Merge Request. Das ist viel leichter als bei einem Release rückwirkend zu rekonstruieren, was in den letzten Wochen passiert ist und nichts wird vergessen. Beim Release wird eine Überschrift mit der Versionsnummer inklusive Datum ergänzt und ein leerer Unreleased-Abschnitt verbleibt darüber.

Die Links am Ende

Die Versionsnummern in den Überschriften sind Links auf den Vergleich zur vorherigen Version. In Markdown erreichst du das mit Referenz-Links: Die Überschrift ## [1.1.0] - 2026-09-15 verweist auf eine Definition, die du am Dateiende sammelst.

Die Links selbst baust du aus den Git-Tags der Releases. Die Vergleichsansicht von GitHub und GitLab nimmt zwei Tags und zeigt alle Änderungen dazwischen:

[1.1.0]: https://github.com/example/project/compare/v1.0.0...v1.1.0

Bei GitLab lautet das Muster https://gitlab.com/example/project/-/compare/v1.0.0...v1.1.0. Die erste Version hat keinen Vorgänger. Sie verweist deshalb direkt auf den Tag, bei GitHub mit /releases/tag/v1.0.0, bei GitLab mit /-/tags/v1.0.0. Der Link für [Unreleased] vergleicht den letzten Tag mit HEAD, also mit dem aktuellen Stand des Hauptzweigs.

Beim Release gibt es eine Besonderheit, denn du schreibst den Changelog-Eintrag, bevor du den Tag setzt. Der Tag soll ja schon das fertige Changelog enthalten. Der Link auf v1.2.0 zeigt in diesem Moment also ins Leere, du rätst ihn gewissermaßen. Das ist in Ordnung: Sobald du den Tag gepusht hast, funktioniert der Link. Vergiss dabei nicht, den [Unreleased]-Link auf v1.2.0...HEAD umzustellen.

Wer wissen will, was genau im Code passiert ist, klickt auf den Link und sieht den vollständigen Diff. Das Changelog liefert die Zusammenfassung, der Vergleich die Details.

Zurückgezogene Versionen

Manchmal geht eine Veröffentlichung schief, etwa wegen eines schwerwiegenden Fehlers oder einer Sicherheitslücke. Version 1.1.0 der Spezifikation hat dafür eine Kennzeichnung ergänzt:

## [1.1.1] - 2026-09-20 [YANKED]

Die Version bleibt in der Historie stehen, ist aber als zurückgezogen markiert. Löschen wäre die schlechtere Wahl, denn dann wüsste niemand, warum die Versionsnummern eine Lücke haben.

Der Partner: Semantic Versioning

Keep a Changelog sagt dir nicht, welche Versionsnummer ein Release bekommt. Das regelt Semantic Versioning, kurz SemVer, mit dem Schema MAJOR.MINOR.PATCH:

• MAJOR erhöhst du bei inkompatiblen Änderungen.
• MINOR erhöhst du bei neuen Funktionen, die abwärtskompatibel sind.
• PATCH erhöhst du bei abwärtskompatiblen Fehlerkorrekturen.

Beide Konventionen ergänzen sich gut, denn die Gruppen im Changelog verraten, welche Nummer fällig ist. Steht unter Removed oder in einem Changed mit Breaking Change etwas, wird es eine neue Hauptversion. Gibt es nur Added, reicht eine neue Nebenversion. Gibt es nur Fixed, bleibt es bei einem Patch-Release.

Schreibtipps

Überleg dir zuerst, wer dein Changelog liest. Ein Endanwender will wissen, was sich in der Bedienung ändert. Ein Ops-Admin interessiert sich für neue Konfigurationsoptionen, Migrationsschritte und geänderte Abhängigkeiten. Ein Security-Spezialist sucht nach behobenen Schwachstellen und deren Schwere. Jeder dieser Leser braucht andere Details, und davon hängt ab, wie ausführlich und wie technisch du schreibst. Manchmal heißt das auch, dass mehrere Zielgruppen in einer Datei bedient werden müssen und dann helfen die Gruppen von oben beim Navigieren.

Ein paar weitere Erfahrungen aus der Praxis:

• Schreib aus Sicht des Lesers: Statt Refactor Parser besser Parser erkennt jetzt verschachtelte Listen.
• Beschreibe die Auswirkung statt der Umsetzung: Ein bis zwei Sätze genügen, bei Bedarf mit Link auf das Issue oder den Merge Request.
• Erwähne Breaking Changes deutlich, denn genau danach suchen die Leser.
• Pflege das Changelog beim Ändern, nicht erst beim Release.

Nicht jede Änderung braucht einen Eintrag

Ein Changelog enthält nur nennenswerte Änderungen, sonst wird es zum git log mit anderem Namen. Refactorings ohne Verhaltensänderung, Tests, CI-Konfiguration oder Tippfehler im Code kannst du getrost weglassen. Frag dich dafür: Würde ein Leser aus meiner Zielgruppe wegen dieser Änderung etwas anders machen oder anders erwarten? Wenn nicht, bleibt der Eintrag weg.

Ein zweiter Blick lohnt sich bei Abhängigkeiten und scheinbar kleinen Korrekturen. Ein Update, das eine Sicherheitslücke schließt, gehört unter Security. Eine neue Mindestversion von Python oder der Datenbank betrifft Ops-Admins. Und ein behobener Fehler bleibt einen Eintrag wert, auch wenn die Korrektur nur eine Zeile umfasst.

Im Team hilft es, das Weglassen bewusst zu machen, zum Beispiel mit einem Hinweis in der Vorlage für Merge Requests („Kein Changelog-Eintrag nötig, weil …“). So sieht ein fehlender Eintrag nicht wie ein Versehen aus.

Gitmoji

Wer mag, ergänzt jede Zeile um ein Gitmoji, also ✨ für Neues und 🐛 für Fehlerkorrekturen. Das ist keine Vorgabe von Keep a Changelog, sondern eine persönliche Vorliebe, die das Überfliegen erleichtert.

Fazit

Keep a Changelog ist keine Technik, sondern eine Vereinbarung. Sie kostet fast nichts, macht Updates planbar und zeigt deinen Anwendern, dass du ihre Zeit respektierst. Fang mit einer CHANGELOG.md und einem leeren Unreleased-Abschnitt an, der Rest ergibt sich mit der Zeit.

Meine Wahl fiel auf Lucide, das ich dir schon in meiner Übersicht freier Icon-Sets vorgestellt habe. Ich liebe dieses Set, weil es die schlichte Handschrift von Feather fortführt, dabei aber deutlich mehr Auswahl bietet. Wie es in die Seiten kommt? Über ein Hugo-Modul und über zehn Zeilen Template-Code, die verhindern, dass Screenreader dekorative Symbole vorlesen.

Was mir wichtig war

Icons lassen sich auf viele Arten einbinden: als Font, als Sprite oder per JavaScript-Bibliothek – jeweils von einem CDN oder aus dem eigenen Projekt. Bevor ich mich entschieden habe, habe ich deshalb aufgeschrieben, was mir dabei überhaupt wichtig ist.

Keine zusätzliche Build-Chain

Für ein paar Symbole ein npm-Projekt, einen Bundler und ein node_modules/ ins Repo zu holen, steht in keinem Verhältnis. Webentwicklung darf und soll unkompliziert bleiben. Dieser (mein persönlicher) Blog kommt bis heute ohne package.json aus und das darf gern auch so bleiben.

Kein JavaScript

Es gibt reichlich Bibliotheken, die ihre Symbole erst im Browser ins HTML setzen. JavaScript als Zugabe ist eine feine Sache, aber um ein Icon neben einen Link zu stellen, brauche ich es nicht. Eine statische Seite baut ihr HTML einmal fertig und liefert es dann aus. Symbole, die erst im Browser in die Seite eingefügt werden, widersprechen genau diesem Ansatz.

Schnelle Ladezeiten

Jede Datei, die eine Seite zusätzlich anfordert, kostet Zeit. Eine Icon-Font zum Beispiel ist ein weiterer Download, und bis er da ist, stehen an den Stellen der Symbole gerne mal leere Kästchen. Kurze Ladezeiten belohnen die Besucher mit einer besseren Erfahrung und die Suchmaschinen mit einer besseren Bewertung.

Datenschutz

Diese Seite lädt keine Ressourcen von fremden Servern – auch die Schriftarten liegen deshalb selbst gehostet im Projekt. Ein CDN würde die IP-Adresse jedes Besuchers an einen Dritten weitergeben, ganz gleich, ob es eine Font, ein Skript oder ein einzelnes SVG ausliefert. Ein hoher Preis für ein paar Kilobyte SVG.

Alle vier Punkte führen zur selben Antwort: Das Icon steht als SVG direkt im HTML, hineingeschrieben von Hugo beim Bauen der Seite. Kein zusätzlicher Request, kein Skript und nichts, was nachlädt. Im ausgelieferten HTML landen wirklich nur die Symbole, die auf der Seite auch vorkommen.

Das Modul

Lucide gibt es glücklicherweise als fertiges Hugo-Modul. Eingebunden wird es in config/_default/hugo.toml:

[module]
  [[module.imports]]
    path = 'github.com/hugomods/icons/vendors/lucide'

Danach muss man einmal das Modul laden:

hugo mod get github.com/hugomods/icons/vendors/lucide

Das legt go.mod und go.sum an. Dafür muss die Go-Toolchain installiert sein, Node braucht es aber nicht. Das Modul bringt die einzelnen SVG-Dateien des Sets mit. Diese werden gemountet nach assets/icons/lucide/.

Ab jetzt stehen dir zwei Wege offen, ein Icon zu setzen. Im Text, also in einer Markdown-Datei, nimmst du den Shortcode ico:

Ein Stern {{< ico lucide star >}}, der deinen Namen trägt…

Der erste Parameter ist das Set, der zweite der Name des Icons, so wie er in der Lucide-Suche steht. Optional kommt als dritter Parameter eine Größe dazu, etwa 2rem. Wer es genauer mag, nutzt die Variante mit benannten Parametern, die zusätzlich color, width, height und className kennt:

{{< icons/icon vendor="lucide" name="star" size="2rem" >}}

In den Templates rufst du stattdessen das Partial des Moduls auf:

{{ partial "icons/icon" (dict "vendor" "lucide" "name" "star") }}

Egal welchen Weg du nimmst – im fertigen HTML landet dasselbe eingebettete SVG:

<svg
  aria-hidden="true"
  class="hi-svg-inline"
  fill="none"
  height="1em"
  width="1em"
  stroke="currentColor"
  stroke-width="2"
  stroke-linecap="round"
  stroke-linejoin="round"
  viewBox="0 0 24 24"
  xmlns="http://www.w3.org/2000/svg"
>
  <path d="M11.525 2.295a.53.53 0 0 1 .95 0l2.31 4.679a2.123 2.123 0 0 0 …" />
</svg>

Drei Details daran sind wichtig. currentColor bedeutet, dass ein Icon automatisch die Farbe des umgebenden Textes annimmt. Im Dark Mode dieser Seite muss dafür also nichts weiter angepasst werden. 1em bedeutet, dass es so hoch wie der Text ist und mit diesem mitwächst, wenn jemand die Schriftgröße hochdreht. Und aria-hidden="true" setzt das Modul immer, was für die meisten Icons genau richtig ist, aber eben nicht für alle. Dazu gleich mehr.

Aktualisiert wird das Set wie jede andere Abhängigkeit (siehe Docs):

hugo mod get -u ./...

Meine Zwischenschicht

Aufgerufen wird das Modul-Partial in meinem Template aber nie direkt. Dazwischen liegt layouts/_partials/icon.html, und das ist der eigentlich interessante Teil:

{{ with .title }}
  <span title="{{ . }}">
{{ end }}
{{- partial "icons/icon" (dict "vendor" "lucide" "name" (.name)) -}}
{{ with .title }}
  </span>
  <span class="sr-only">{{- . -}}:</span>
{{ end }}

Das hat zwei Gründe.

Der erste ist Bequemlichkeit: Der Vendor-Name steht genau einmal im Projekt. Denn ich will ja nicht verschiedene Icon-Sets in meinem Blog benutzen. Ein Aufruf sieht damit so aus:

{{ partial "icon" (dict "name" "rss") }}

Der zweite Grund ist der wichtigere: Barrierefreiheit, der ich bei meinem Blog besondere Aufmerksamkeit gewidmet habe. Icons treten hier nämlich in zwei völlig verschiedenen Rollen auf.

Dekorativ, wenn direkt daneben schon steht, was gemeint ist. In der Fußzeile bekommt jede Kategorie ein Symbol: code für Softwareentwicklung, shield für IT-Sicherheit, wrench für Tooling. Der Linktext nennt die Kategorie jedoch ohnehin beim Namen. Ein Screenreader soll hier gar nichts vorlesen. Genau das passiert, wenn title fehlt: Übrig bleibt ein nacktes SVG mit aria-hidden="true".

Semantisch, wenn das Icon die Beschriftung ersetzt. In der Fußzeile einer Beitragsvorschau steht ein aufgeschlagenes Buch und daneben „5 min“. Wer das Symbol sieht, versteht sofort: Lesezeit. Wer es nicht sieht, weil ein Screenreader vorliest, hört nur „5 min“ und weiß nicht, worum es geht.

Für diesen Fall nimmt das Partial ein title entgegen und macht daraus beides: ein title-Attribut für den Tooltip mit der Maus und einen visuell versteckten Text davor. Die Karte ist eine Definitionsliste, und das Ergebnis liest sich vorgelesen als „Lesezeit: 5 min“, während auf dem Bildschirm nur das Icon steht. Ein alt-Text am SVG würde das nicht leisten, denn das aria-hidden des Moduls bliebe ja bestehen.

Eine Stolperfalle zum Schluss

Das Modul-Partial gibt seinen SVG-String mit einem abschließenden Zeilenumbruch zurück. Steht das Icon direkt vor Text, rendert der Browser diesen Umbruch als Leerzeichen zusätzlich zu dem Abstand, den das Stylesheet ohnehin setzt. Die Trim-Marker von Go-Templates ({{- und -}}) helfen hier nicht, denn sie greifen auf den Template-Text drumherum, jedoch nicht auf den Rückgabewert eines Partials.

Das habe ich neu gelernt: Der Umweg dafür ist chomp.

{{ partial "icon" (dict "name" "arrow-left") | chomp }}

Fazit

Viel ist es am Ende nicht: ein Modul in der Konfiguration, ein Partial mit zehn Zeilen und ein chomp an der richtigen Stelle. Dafür kommt der Blog ohne Node, ohne JavaScript und ohne Ressourcen von fremden Servern aus. Und alle Icons sind da, sobald die Seite geladen hat. Falls du auf den Geschmack gekommen bist: Das Hugo Icons Module bietet übrigens noch weitere Icon-Sets.

Die Daten aller Fahrradzählstellen kann man über die Open-Data-Plattform der Stadt Bonn als CSV abrufen. Allerdings sind das wirklich nur die Daten des Vortags und ich benötige auch die Daten der Vorwoche – und manchmal mache ich auch Analysen über größere Zeiträume hinweg. Daten doppelt zu halten (und das als CSV) ist mir zu umständlich. Daher gehe ich den direkten Weg über die API des Herstellers, doch die alte REST-API ist seit zwei Tagen offline und mein Mastodon-Account liefert keine Daten mehr.

Um herauszufinden, wie ich jetzt noch an die Daten herankomme, öffne ich die Zählstellen-Website des Herstellers für die Stadt Bonn in meinem Browser. Wenn man sich den Datenverkehr der Website in seinem Browser genauer anschaut, fällt einem schnell auf, dass es sich um eine Next.js-Applikation handeln muss. Man kann dies an TURBOPACK in den Daten der übertragenen JavaScript-Dateien erkennen oder aber auch an dem Präfix der CSS-Variablen next-.

Diese Website stellt jedoch keine JSON-API mehr bereit; stattdessen sind die Tageszahlen in den React Server Components (RSC) der Seite eingebettet. Ich zeige euch hier ein Beispiel, wie man diesen Stream abfragt und daraus die aggregierten Tageswerte, die ich für meine Toots benötige, extrahiert. Ich habe den Code extra etwas vereinfacht. Bitte achtet auf die Validierung der Input-Daten.

Die Abfrage der Daten geschieht in drei Schritten:

1. den RSC-Stream abrufen
2. den gewünschten JSON-Wert aus dem Stream extrahieren
3. das extrahierte JSON in eine Liste der täglichen Zahlen umwandeln

Das komplette Skript findet ihr ganz unten. Ich gehe hier nur die wichtigsten Teile durch.

RSC-Stream abrufen

Ich selbst habe noch nie eine Website mit Next.js gebaut. Das ist also auch neu für mich. Schreibt mir gern in die Kommentare, wenn etwas nicht ganz korrekt erklärt ist. Fakt ist, die Next.js-Anwendung verwendet RSCs. Eine URL wie /site/100021143?… kann je nach Art der Anfrage zwei völlig unterschiedliche Ergebnisse liefern:

• Initiale Browseranfrage: Der Server gibt eine vollständige HTML-Seite zurück. React läuft im Browser und die eigentlichen Zähldaten werden nach dem Laden via JavaScript abgerufen und im DOM gerendert.
• Anfrage mit gesetztem HTTP-Header RSC: 1: Next.js gibt stattdessen den RSC-Payload zurück: einen Stream, der den DOM und die Daten beschreibt. Das ist, was der Browser selbst anfordert, wenn du innerhalb der App navigierst – React ruft die neue Seite als RSC-Daten ab, anstatt das vollständige HTML erneut zu laden.

def fetch_rsc_payload(counter_id: int, year: int, month: int) -> str:
    """Return the raw RSC stream text for one site and month."""
    url = f"{SITE_BASE}/site/{counter_id}"
    params = {"year": year, "month": month, "granularity": "P1D"}
    headers = {
        "RSC": "1",
        "Accept": "text/x-component",
        "User-Agent": "Mozilla/5.0",
        "Referer": f"{SITE_BASE}/site/{counter_id}",
    }
    resp = requests.get(url, params=params, headers=headers, timeout=30)
    resp.raise_for_status()
    return resp.text

Was wir von dieser Funktion erhalten, ist etwa folgender Payload (hier deutlich gekürzt):

1:"$Sreact.fragment"
3:I[97367,["/_next/static/chunks/0s2yzmf9j.2c6.js", ...]]
4:"$Sreact.suspense"
...

Wie du schnell erkennst, ist das nicht einfach JSON. Es ist Next.js’ zeilenbasiertes RSC Wire Format (hier ein Blogartikel von Sachin zum Deep Dive). Jede Zeile ist durchnummeriert. Aber – und das ist das Wichtige – die eigentlichen Daten, die uns interessieren, sind als gewöhnliches JSON-Array gespeichert und befinden sich direkt in einer dieser Zeilen:

22:["$","$L25",null,{"granularity":"P1D","site":"$2:2:props:...","chartData":[{"travelMode":"bike","data":[{"timestamp":"2026-07-01T00:00:00+02:00","traffic":{"counts":19014}}, ... ]}], "directionGraphData":[...], ...}]

JSON aus dem Stream extrahieren

In den erhaltenen Daten suchen wir jetzt nach chartData oder graphData (ich hab je nach Monat der Daten diese in dem einen oder in dem anderen Key gefunden, eventuell hat der Betreiber einmal sein Schema geändert?). Wir suchen also nach diesen beiden Schlüsseln und merken uns die Zeile.

SITE_BASE = "https://stadtbonn.eco-counter.com"

def _extract_keyed_value(body: str, key: str) -> object:
    """Find `"key":` in the stream and json.loads the line."""
    needle = f'"{key}":'
    for line in body.split("\n"):
        if needle in line:
            try:
                return json.loads(_extract_json(line))[3][key]
            except (IndexError, KeyError):
                continue

    raise RSCParseError(f'Key "{key}" not found')

Mit dieser Zeile rufen wir dann eine weitere Funktion auf, welche das JSON aus der Zeile herauslöst (es ist ja durch die Zeilennummer gepräfixt, wir trennen daher am ersten Doppelpunkt).

def _extract_json(line: str) -> str:
    """Return the json from a line of the RSCP."""
    try:
        json_data = line.split(":", 1)[1]
        return json_data
    except IndexError:
        raise RSCParseError("Unexpected format of RSC payload.")

Aus dem erhaltenen JSON lassen wir uns jetzt in _extract_keyed_value das vierte Element der Liste ausgeben und aus diesem Objekt dann den Value für unseren gesuchten Key. Warum? Naja, das habe ich halt einfach so aus den erhaltenen Daten abgelesen. Und ob es morgen noch funktioniert, sehen wir dann morgen.

Achtung: Das ist ein sehr fragiler Teil des Codes und überhaupt ist das Parsen von Daten Dritter eine sehr gefährliche Angelegenheit. Dieser Beispielcode ist auch nicht mein Produktivcode! Mit Libraries wie Pydantic könnt ihr euren Code auf wesentlich sichere Beine stellen. Hier aber möchte ich euch den grundsätzlichen Ansatz zeigen.

Liste der täglichen Zahlen

Jetzt bauen wir uns eine Dataclass, welche die täglichen Daten halten soll.

@dataclass(frozen=True)
class DayCount:
    """One day's total count. `count` is None when no data exists for that day."""

    date: dt.date
    count: int | None

Jetzt bauen wir uns eine Funktion, um aus der Liste von Tageswerten eine Liste von DayCount-Objekten zu erhalten.

DATA_KEYS = ("chartData", "graphData")

def parse_daily_counts(body: str) -> list[DayCount]:
    """Extract the aggregate daily counts from an RSC payload."""
    series = None
    for key in DATA_KEYS:
        try:
            series = _extract_keyed_value(body, key)
            break
        except RSCParseError:
            continue
    if series is None:
        raise RSCParseError(
            f"none of {DATA_KEYS} found; the page structure may have changed "
            "or the RSC header is no longer honored"
        )

    # series looks like: [{"travelMode": "bike", "data": [ {timestamp, traffic}, ... ]}]
    rows = series[0].get("data")

    counts = [
        DayCount(
            date=dt.date.fromisoformat(row["timestamp"][:10]),
            count=row["traffic"].get("counts"),
        )
        for row in rows
    ]
    return sorted(counts, key=lambda d: d.date)

Achtung: Auch dieser Beispielcode ist nicht reif für Produktiv!

In dem kompletten Beispielcode, der jetzt folgt, könnt ihr dann auch sehen – und gerne auch ausprobieren – wie alles zusammengestöpselt wird. Dazu erstellt ihr euch am besten ein virtuelles Environment und installiert euch requests mittels pip install requests.

import datetime as dt
import json
from dataclasses import dataclass

import requests

SITE_BASE = "https://stadtbonn.eco-counter.com"
DATA_KEYS = ("chartData", "graphData")


@dataclass(frozen=True)
class DayCount:
    """One day's total count. `count` is None when no data exists for that day."""

    date: dt.date
    count: int | None


class RSCParseError(ValueError):
    """Raised when the expected count data can't be located or parsed."""


# --------------------------------------------------------------------------- #
# Step 1: fetch the RSC stream
# --------------------------------------------------------------------------- #
def fetch_rsc_payload(counter_id: int, year: int, month: int) -> str:
    """Return the raw RSC stream text for one site and month."""
    url = f"{SITE_BASE}/site/{counter_id}"
    params = {"year": year, "month": month, "granularity": "P1D"}
    headers = {
        "RSC": "1",  # <- the key that makes Next.js return the data stream
        "Accept": "text/x-component",
        "User-Agent": "Mozilla/5.0",
        "Referer": f"{SITE_BASE}/site/{counter_id}",
    }
    resp = requests.get(url, params=params, headers=headers, timeout=30)
    resp.raise_for_status()
    return resp.text


# --------------------------------------------------------------------------- #
# Step 2: extract exactly the JSON value we want from the stream
# --------------------------------------------------------------------------- #
def _extract_json(line: str) -> str:
    """Return the json from a line of the RSCP."""
    try:
        json_data = line.split(":", 1)[1]
        return json_data
    except IndexError:
        raise RSCParseError("Unexpected format of RSC payload.")


def _extract_keyed_value(body: str, key: str) -> object:
    """Find `"key":` in the stream and json.loads the line."""
    needle = f'"{key}":'
    for line in body.split("\n"):
        if needle in line:
            try:
                return json.loads(_extract_json(line))[3][key]
            except (IndexError, KeyError):
                continue

    raise RSCParseError(f'Key "{key}" not found')


# --------------------------------------------------------------------------- #
# Step 3: turn the extracted JSON into a clean list of daily counts
# --------------------------------------------------------------------------- #
def parse_daily_counts(body: str) -> list[DayCount]:
    """Extract the aggregate daily counts from an RSC payload."""
    series = None
    for key in DATA_KEYS:
        try:
            series = _extract_keyed_value(body, key)
            break
        except RSCParseError:
            continue
    if series is None:
        raise RSCParseError(
            f"none of {DATA_KEYS} found; the page structure may have changed "
            "or the RSC header is no longer honored"
        )

    # series looks like: [{"travelMode": "bike", "data": [ {timestamp, traffic}, ... ]}]
    rows = series[0].get("data")

    counts = [
        DayCount(
            date=dt.date.fromisoformat(row["timestamp"][:10]),
            count=row["traffic"].get("counts"),
        )
        for row in rows
    ]
    return sorted(counts, key=lambda d: d.date)


# --------------------------------------------------------------------------- #
# Convenience: put the three steps together
# --------------------------------------------------------------------------- #
def get_daily_counts(counter_id: int, year: int, month: int) -> list[DayCount]:
    """Fetch and parse the daily counts for one site and month."""
    return parse_daily_counts(fetch_rsc_payload(counter_id, year, month))


if __name__ == "__main__":
    # Example: the Kennedybrücke counter in Bonn
    # It's an honour to be a Bonner! :)
    KENNEDYBRUECKE = 100021143
    today = dt.date.today()

    counts = get_daily_counts(KENNEDYBRUECKE, today.year, today.month)

    print(f"Daily counts for site {KENNEDYBRUECKE}, {today:%B %Y}:")
    for day in counts:
        value = "—" if day.count is None else f"{day.count:,}"
        print(f"  {day.date:%Y-%m-%d}: {value}")

    # Pick out a single day (e.g. yesterday).
    yesterday = today - dt.timedelta(days=1)
    match = next((d for d in counts if d.date == yesterday), None)
    if match and match.count is not None:
        print(f"\nYesterday ({yesterday}): {match.count:,}")
    else:
        print(f"\nNo data for yesterday ({yesterday}) yet.")

Mit uv gibt es einen neuen, in Rust geschriebenen Paketmanager, der manche Schwächen von Poetry adressiert und neue Vorteile bietet. Ausschlaggebend für meinen Test war, dass uv von den gleichen Entwicklern wie Ruff stammt – ein Tool, das ich bereits intensiv nutze und von dem ich absolut begeistert bin. Da Ruff meine Arbeitsweise in Python bereits deutlich verbessert hat, war ich gespannt, ob uv ähnliche Vorteile bieten kann.

Was mir bei Poetry bislang wirklich gefehlt hat, war die einfache Möglichkeit, zwischen verschiedenen Python-Versionen zu wechseln. uv ersetzt nicht nur pip und Poetry, sondern auch Tools wie pyenv, mit denen sich mehrere Python-Versionen parallel installieren, verwalten und projektbezogen auswählen lassen – ohne Versionskonflikte. Die jeweils benötigte Python-Version wird von uv automatisch installiert und verwaltet, indem du eine .python-version-Datei im Projekt setzt.

Und auch wenn Poetry schon einen enormen Geschwindigkeitsvorteil gegenüber dem klassischen Ansatz mit pip bietet, ist uv noch einmal schneller. 10-100 Mal schneller als pip versprechen die Entwickler. In den meisten Projekten, die ich privat oder auf der Arbeit betreue, hat mich die Geschwindigkeit von Poetry zwar nur selten gestört, wenn du uv aber einmal benutzt, ist die Schwuppdizität spürbar erhöht. Auch für CI-Pipelines ein enormer Gewinn.

Installation

Zur Installation von uv gibt es eine Vielzahl Möglichkeiten. Ich habe uv aus den Paketquellen meiner Linux-Distribution installiert, wenn das für dich nicht möglich ist, empfehle ich die Installation mit dem Standalone installer.

Anschließend trägst du dir die Shell autocompletion in die Konfigurations-Datei deiner Shell ein. Folge dazu einfach den Schritten in der Dokumenation.

Migration

Die Migration deines bestehenden Projekts ist wirklich extrem einfach. uv bringt uvx mit. uvx ist ein Kommandozeilen-Tool und eine Kurzform für uv tool run, das zum schnellen Ausführen von Python-basierten Kommandozeilen-Tools dient. Mit uvx kannst du beliebige Python-Tools ausführen, ohne sie vorher in deiner Projektumgebung installieren zu müssen. Stattdessen wird das gewünschte Tool in einer temporären, von uv verwalteten virtuellen Umgebung ausgeführt, die im Cache liegt. Das hält deine Projektabhängigkeiten sauber und ermöglicht eine sehr schnelle Ausführung.

uvx kannst du auch nutzen, um das Tool migrate-to-uv zu nutzen und damit dein Projekt von Poetry (oder einem anderen Paketmanager) zu uv zu migrieren.

uvx migrate-to-uv

Dieses Tool übernimmt automatisch:

• Die Konvertierung der Projektmetadaten von Poetry zu uv
• Die Übernahme der Abhängigkeitsversionen
• Die Erzeugung einer neuen uv.lock-Datei (und das Entfernen der poetry.lock-Datei)
• Die Beibehaltung von Abhängigkeitsgruppen (Dependency Groups)

Zum Schluss bietet sich noch das Setzen eines Alias zum Aktivieren des virtuellen Environment an. Einen solchen Alias habe ich schon seit langem und erleichtert mir enorm die Aktivierung.

avenv() { source venv/bin/activate 2>/dev/null || source .venv/bin/activate 2>/dev/null || echo "No venv found."; }

Diese Zeile trägst du in deine Shell-Konfiguration ein und kannst ab sofort mit avenv das Environment öffnen.

Fazit

Nach vielen Jahren mit Poetry als treuem Begleiter im Python-Ökosystem hat mich uv wirklich überrascht. Die Kombination aus beeindruckender Geschwindigkeit, einfacher Verwaltung verschiedener Python-Versionen und der wirklich unkomplizierten Migration bestehender Projekte macht uv zu einer spannenden Alternative – gerade auch für Entwickler:innen, die Wert auf moderne und effiziente Workflows legen.

Die Deutsche Bahn ermöglicht die Nutzung von SMS-Codes oder Authentifikator-Apps für die 2FA. Allerdings gibt es während und nach der Einrichtung einige Fallstricke. Eine besonders kritische Situation entsteht, wenn der Zugang über die Authentifikator-App verloren geht. Ich würde mir wünschen, dass die Bahn eine Möglichkeit zur Sicherung und Wiederherstellung anbietet für die man keine Hotline bemühen muss.

Fehlende Backup-Codes

Ein großes Manko scheint mir die fehlende Möglichkeit zu sein, Backup-Codes herunterzuladen. Backup-Codes sind entscheidend, besonders wenn der Zugang über die Hauptmethode verloren geht. Es sind vorab generierte Codes, die du sicher aufbewahren kannst. Im Falle, dass du keinen Zugriff auf deine Haupt-2FA-Methode (z.B., wenn du dein Handy verlierst oder die Authentifikator-App nicht funktioniert) hast, kannst du diese Backup-Codes verwenden, um dich dennoch anzumelden.

Begrenzte Möglichkeiten nach Einrichtung

Nach erfolgreicher Einrichtung einer der beiden Methoden ist es scheinbar nicht möglich, eine zweite Methode hinzuzufügen. Auf Grund der fehlenden Backup-Codes wäre das eine gute Möglichkeit den Zugriff auf sein Konto sicherstellen zu können. Hilft die Bahn dir im Worst-Case wenigstens mit guten Hilfetexten weiter?

Fehlermeldungen und Support

Wenn man dann doch keinen Zugriff auf seinen zweiten Faktor mehr hat, steht man erst einmal alleine da. Die Login-Maske fordert stur die Eingabe des 2-Faktor-Codes. Gibt man einen falschen ein, erscheint lediglich „Ungültiger Authentifizierungscode“. Der Link „Login-Daten vergessen?“ ist nach Eingabe des Passworts bereits verschwunden – und würde auch nicht weiterhelfen. Zum Glück gibt es ein FAQ zur 2-Faktor-Authentifizierung. Die muss man aber erst einmal finden. Zum Glück erscheinen die relevanten Fragen aber auch dann, wenn man „2-Faktor“ in das Suchfeld der allgemeinen „Hilfe & Kontakt“-Seite für Privatkunden eintippt.

FAQ

Die FAQ spricht in der relevanten Hilfe-Seite zwar nur davon, was man bei verlorenem Zugriff auf SMS-Codes tun kann. Ich gehe aber davon aus, dass die Antwort bei Nutzung einer Authentifikator-App die gleiche wäre: „Bitte kontaktieren Sie unser Service-Team unter 030 2970.“ Dauer der Bearbeitungszeit: Bis zu einer Woche!

Insbesondere die Dauer für die Rücksetzung der 2FA könnte für viele Kunden problematisch sein. Hier muss die Deutsche Bahn die Prozesse optimieren, um eine schnellere Unterstützung zu gewährleisten. Ist man auf Reisen unterwegs und hat sein Ticket nur in der App dabei, verliert aber – aus welchen Gründen auch immer – den Zugriff auf sein Bahn-Konto, wird man im Zweifelsfall ein zweites Ticket kaufen müssen.

Mein Fazit

Insgesamt gibt es großen Raum für Verbesserungen bei der 2FA der Deutschen Bahn. Eine erhöhte Flexibilität bei der Einrichtung durch die Möglichkeit der Einrichtung mehrer 2Fa-Methoden, klare Anweisungen bei Problemen und eine schnellere Unterstützung durch den Kundenservice könnten die Nutzererfahrung erheblich verbessern. Und die Deutsche Bahn würde davon auch profitieren: Durch eine Entlastung ihrer Support-Hotline. Aktuell kann ich die Einrichtung der 2-Faktor-Authentifizierung bei der Deutschen Bahn nur bedingt empfehlen.

Ich arbeite seit geraumer Zeit mit Hugo. Für die Erzeugung einer Logowand von Partnern eines Unternehmens habe ich unter content/partners/ für jeden Partner, der angezeigt werden soll, eine Markdown-Datei angelegt. Dort konnte ich dann z.B. das Logo definieren und eine URL als Link hinterlegen. Das hat den großen Vorteil, dass man alle Inhalte sehr strukturiert abgelegt hat.

---
title: "Beispielunternehmen goes brrr"
image: "images/partners/partner-logo.svg"
link: "https://example.com/"
---

Die Logos habe ich dann in das Layout der Startseite integriert:

{{ with .Site.GetPage "/partners" }}
  {{ range .Pages }}
    <a href="{{ .Params.link }}" target="_blank">
      <img
        src="{{ (resources.GetMatch .Params.image).RelPermalink }}"
        alt="{{ .Params.title }}" loading="lazy" />
     </a>
  {{ end }}
{{ end }}

Was mir erst ein paar Tage nach der Veröffentlichung der Website aufgefallen ist, ist, dass ich jetzt zwar alle Logos auf der Startseite angezeigt bekomme, aber jeder Partner jetzt auch eine eigene Seite generiert bekommen hat. So gibt es jetzt für jeden Partner unter https://example.com/partners/beispielunternehmen/ eine Seite, auf der nur das Logo und der Titel angezeigt werden.

Das hätte ich natürlich wissen müssen, aber irgendwie ist es mir entgangen. Die Seiten sind zwar alle nirgendwo auf der Seite verlinkt, können aber trotzdem irgendwann in der Suchmaschine deiner Wahl auftauchen, weil sie in der von Hugo erzeugten sitemap.xml gelistet sind. Und das ist hier nicht erwünscht.

Mein erster Versuch

Ich erstelle zuerst eine index.md. Dadurch werden die Partnerseiten nicht mehr angezeigt. Allerdings habe ich dann immer noch eine Partnerseite, also https://example.com/partners/. Nach einigem Suchen in Hugos Dokumentation habe ich die Build Options gefunden. Das schien genau das zu sein, was ich gesucht hatte. Jetzt musste ich nur noch den folgenden Front Matter in die index.md einfügen:

---
_build:
    list: never
    publishResources: true
    render: never
---

Das funktioniert auch wunderbar. Allerdings habe ich nicht bedacht, dass durch die index.md und die Art und Weise, wie ich derzeit die Logowand im Layout programmiert habe, kein einziges Partnerlogo mehr angezeigt wird. Denn im Layout iteriere ich über alle Unterseiten der /partners-Seite. Und die gibt es nicht mehr.

Mein zweiter Versuch

Aber auch das lässt sich mit wenig Aufwand ändern. Denn die Markdown-Dateien mit den Partnerlogos sind jetzt Ressourcen der Partnerseite. Statt über die Unterseiten iteriere ich jetzt einfach über die Ressourcen der Seite:

{{ with .Site.GetPage "/partners" }}
  {{ range .Pages }}
    <a href="{{ .Params.link }}" target="_blank">
      <img
        src="{{ (resources.GetMatch .Params.image).RelPermalink }}"
        alt="{{ .Params.title }}" loading="lazy" />
     </a>
  {{ end }}
{{ end }}

Fazit

Bei der Suche nach einer Lösung habe ich zunächst versucht, die Partnerseiten durch Erstellung einer index.md zu verbergen. Allerdings führte dies dazu, dass die Partnerlogos nicht mehr angezeigt wurden, da das Layout über die nicht mehr vorhandenen Unterseiten iterierte. Nach etwas Recherche in der Hugo-Dokumentation stieß ich auf die Build Options, die eine Lösung zu bieten schienen. Durch die Nutzung dieser Funktion konnte ich die Datei index.md so konfigurieren, dass sie keine Partnerseiten anzeigt, und die Partnerlogos dennoch auf der Startseite darstellt.

Die Anpassung des Layout-Codes, um über die Ressourcen der Seite zu iterieren, anstatt über die nicht mehr vorhandenen Unterseiten, war der Schlüssel, um die Partnerlogos zurück auf die Startseite zu bringen. Dieser Prozess hat nicht nur das unerwünschte Indexierungsproblem in den Suchmaschinen gelöst, sondern erneut meine Kenntnisse über die Verwendung von Hugo und dessen vielfältigen Funktionen erweitert.

Schritt 1: Lade ImageMagick herunter und installiere es

Zunächst musst du ImageMagick herunterladen und installieren. ImageMagick ist ein Open-Source-Tool, das zum Bearbeiten und Konvertieren von Bildern verwendet wird. Am einfachsten und sichersten installierst du ImageMagick über den Paketmanager deiner Linux-Distribution. Alternativ kannst du es auch von der offiziellen Website herunterladen.

Schritt 2: Öffne einen Texteditor und erstelle das Bash-Skript

Als nächstes öffnest du deinen bevorzugten Texteditor und erstellst ein neues Bash-Skript.

#!/bin/bash

# Überprüfe ob ein Dateiname als Argument übergeben wurde
if [ $# -eq 0 ]; then
  echo "Usage: $0 [input_file]"
  exit 1
fi

# Überprüfe ob die übergebene Datei eine PNG-Datei ist
if ! file "$1" | grep -q "PNG image data"; then
  echo "Error: $1 is not a PNG file"
  exit 1
fi

# Erstellen einer temporären Datei für das Ergebnis
temp_file=$(mktemp)

# Alpha-Kanal entfernen und weißen Hintergrund hinzufügen
convert "$1" -background white -alpha remove "$temp_file"

# Überprüfen, ob die Konvertierung erfolgreich war
if [ $? -eq 0 ]; then
  # Umbenennen der ursprünglichen Datei als Backup und Verschieben der konvertierten Datei an ihre Stelle
  mv "$1" "$1.bak"
  mv "$temp_file" "$1"
  echo "Success: $1 converted"
else
  echo "Error: failed to convert $1"
fi

Dieses Skript überprüft zunächst, ob eine Datei als Argument übergeben wurde und ob es sich um eine PNG-Datei handelt. Dann wird eine temporäre Datei erstellt, der Alpha-Kanal wird entfernt und ein weißer Hintergrund wird hinzugefügt. Schließlich wird die ursprüngliche Datei umbenannt und die konvertierte Datei wird an ihre Stelle verschoben. Wenn du keine Sicherungsdatei des Originals behalten möchtest, kannst du mv "$1" "$1.bak" auch durch rm "$1" ersetzen.

Schritt 3: Speichere das Bash-Skript

Speichere das Bash-Skript unter einem aussagekräftigen Namen, z.B. „remove-alpha“ unter ~/.local/share/nautilus/scripts ab.

Schritt 4: Setze die Ausführungsberechtigung für das Bash-Skript

Um das Bash-Skript ausführen zu können, musst du die Ausführungsberechtigung für das Skript setzen. Öffne dazu ein Terminal-Fenster im Verzeichnis, in dem sich das Bash-Skript befindet, und gebe den folgenden Befehl ein:

chmod +x remove-alpha

Schritt 5: Nautilus öffnen und Bilder konvertieren

Jetzt musst du nur noch deinen Dateibrowser Nautilus öffnen und navigierst zu der Datei, dessen Transparenz du entfernen möchtest. Mittels Rechtsklick → Skripte → remove-alpha kannst du jetzt schnell und einfach die Transparenz aus dem Bild entfernen.

Fazit

Insgesamt ist das Einrichten des Bash-Skripts ein einfacher Prozess, der dir Zeit und Aufwand bei der Konvertierung von PNG-Dateien sparen kann. Mit diesem Skript kannst du schnell und einfach den Alpha-Kanal entfernen und einen weißen Hintergrund hinzufügen. Durch die Integration in Nautilus kannst du super leicht Bilder direkt aus deiner Dateibrowser bearbeiten.

Hast du weitere Tipps für gute Icon-Sets? Schreib’s unten in die Kommentare!

Font Awesome

Den Klassiker vorweg: Font Awesome ist eine der größten Icon-Sammlungen, die es im Netz zu finden gibt. Wahrscheinlich kennt sie fast jeder, der mit Design irgendwie zu tun hat. Kostenlos bekommst du rund 2.100 Icons in den Stilen Solid und Regular – die über 600 Marken-Logos sind darin schon enthalten. Wichtig: Der große Rest kostet extra. Die Pro-Version bringt deutlich mehr Icons mit und schaltet die Familien Duotone und Sharp sowie die Stile Light und Thin frei.

Lizenz: CC BY 4.0 License / SIL OFL 1.1 License

Feather

Ein deutlich kleineres Set an knapp 300 Icons bringt Feather mit. Schau also dringend einmal durch, ob Feather alles mitbringt, was du so brauchst. Wenn du Font Awesome inzwischen einmal leid geworden bist, dann lohnt es sich aber dieses Icon-Set einmal anzuschauen.

Lizenz: MIT License

OpenMoji

Ich bin im letzten Jahr ein echter Fan von einem Icon-Set geworden, das eigentlich ein Set von Emoticons ist: OpenMoji. Rund 4500 Emoticons stellt das Projekt der HfG Schwäbisch Gmünd vollständig als Open Source zur Verfügung.

Lizenz: CC BY-SA 4.0

Remix Icon

Remix Icon ist ein sehr neutrales und schlichtes Icon Set mit Symbolen, die es jeweils ausgefüllt und als Kontur gibt. Über 3200 Symbole sind inzwischen verfügbar.

Lizenz: Apache License 2.0

Material Icons / Material Symbols

Die Material Symbols sind zwei verschiedene offizielle Icon-Sets von Google, die auf dem gleichen Design basieren. Material Icons ist das klassische Set, während Material Symbols im April 2022 eingeführt wurde und auf einer neuen Technologie namens „Variable Font“ basiert. Dadurch hast du noch mehr Möglichkeiten die Symbole an deine Bedürfnisse anzupassen. Die Schriftart als Dateien kannst du im Github-Repository herunterladen.

Lizenz: Apache License 2.0

Lucide

Lucide ist als Community-Fork von Feather entstanden, nachdem dessen Entwicklung ins Stocken geraten war. Die schlichte Handschrift ist geblieben, der Umfang aber deutlich gewachsen: Inzwischen sind es über 1700 Icons. Wer Feather kennt und einfach mehr Auswahl braucht, ist hier genau richtig: der Umstieg fällt kaum auf. Fertige Pakete gibt es für so ziemlich jedes Framework.

Lizenz: ISC License

Heroicons

Heroicons kommt von den Machern von Tailwind CSS. Mit 316 Symbolen ist das Set sehr klein. Jedes Icon gibt es in vier optimierten Varianten: als Kontur und gefüllt in 24 Pixel, dazu Mini mit 20 und Micro mit 16 Pixel.

Lizenz: MIT License

Update

• 1. September 2026: Lucide und Heroicons hinzugefügt, Zahlen aktualisiert
• 10. März 2023: Material Icons / Material Symbols hinzugefügt
• 16. November 2022: Aktualisierte Zahlen

Am einfachsten lässt sich der Unterschied an einem Gedicht erkennen.

Ach, wer bringt die schönen Tage,
Jene Tage der ersten Liebe,
Ach, wer bringt nur eine Stunde
Jener holden Zeit zurück!

Einsam nähr ich meine Wunde,
Und mit stets erneuter Klage
Traur ich ums verlorne Glück.

Ach, wer bringt die schönen Tage,
Jene holde Zeit zurück!

Erster Verlust, Johann Wolfgang von Goethe

Wie du sicher weißt, besteht ein Gedicht aus Versen und Strophen. Einen (harten) Zeilenumbruch nutzt man in einem Gedicht zwischen einzelnen Versen, einen Absatz zwischen einzelnen Strophen. Ein Zeilenumbruch trennt also Verse, lässt aber trotzdem ihre Zugehörigkeit zueinander erkennen. Bei einem Absatz ist die Trennung größer und daher werden Absätze in der Regel auch durch einen deutlichen Abstand zueinander dargestellt. Dieser Abstand erleichtert uns ganz erheblich das Lesen von langen Texten. Manchmal wird zusätzlich auch die erste Zeile des Absatzes etwas eingerückt.

Zur besseren Lesbarkeit und für ein einfacheres Verständnis sollte ein Artikel oder ein sonstiger langer Text in Absätze gegliedert sein. Harte Zeilenumbrüche sollten dagegen die große Ausnahme sein. Doch wie erzeugt man einen Absatz und wie einen harten Zeilenumbruch?

Word / LibreOffice / …

In Word und LibreOffice und vielen weiteren Applikationen erzeugt man in einem Text einen Absatz durch ein einfaches Enter. Einen Zeilenumbruch erzeugt man durch Shift+Enter.

Latex

In Latex erzeugt man einen Absatz, indem man eine Leerzeile anlegt. Einen Zeilenumbruch erzeugt man mit zwei Backslashes \\.

Ach, wer bringt die schönen Tage,\\
Jene Tage der ersten Liebe,\\
Ach, wer bringt nur eine Stunde\\
Jener holden Zeit zurück!

Einsam nähr ich meine Wunde,\\
Und mit stets erneuter Klage\\
Traur ich ums verlorne Glück.

Ach, wer bringt die schönen Tage,\\
Jene holde Zeit zurück!

TL;DR

Benutze harte Zeilenumbrüche nur wenn du dir ganz sicher bist, dass sie da hingehören. Ansonsten benutze Absätze.

Es gibt bestimmt viel zu erzählen über die SSH-Config. Ich möchte heute erklären, wofür sie die meisten Leute nutzen: Um sich Server, die sie regelmäßig besuchen, abzuspeichern und nur noch einen Hostnamen hinter den SSH-Befehl tippen zu müssen. Kein User-Name, kein alternativer Port und auch kein abweichendes Zertifikat. Nur ein:

$ ssh servername

Erreichen kann man dieses Verhalten durch eine Bearbeitung der Datei ~/.ssh/config (eventuell muss diese erst angelegt werden). Dort kann man dann zum Beispiel Folgendes definieren:

Host servername
    HostName servername.uberspace.de
    Port 65022
    User theus
    IdentityFile ~/.ssh/id_work

Die erste Zeile definiert einen Host und gibt direkt dessen Alias servername mit an. Die zweite Zeile gibt nun den Hostnamen an, also die Domain deines Servers. Falls SSH abweichend zum Standard mal nicht auf Port 22 läuft, so kannst du das wie in Zeile 3 definieren. Außerdem kannst du dir die Eingabe eines Benutzernamens durch eine entsprechende Konfiguration sparen und schließlich auch ein abweichendes Zertifikat angeben, wenn du zum Beispiel dienstliche und private Server mit verschiedenen Identities ansprechen möchtest.

Für jeden Server, den du definieren möchtest, erstellst du einen solchen Block in der ~/.ssh/config (oder alternativ systemweit in der /etc/ssh/ssh_config). Wenn du einen Server abweichend von der Config zum Beispiel mit einem anderen Benutzer ansprechen möchtest, kannst du diesen Parameter wie gewohnt in der Kommandozeile überschreiben. So würde

$ ssh root@servername

die gleichen Parameter nutzen, wie oben in der Konfiguration angegeben wurde, aber abweichend davon den Nutzer root statt theus nehmen.

Weitere Parameter findet ihr auf unter anderem auf ssh.com. Und nun viel Spaß beim Ausprobieren.

Wichtig: Die folgende Erklärung über die API funktioniert so nicht mehr.

Allgemein dokumentiert ist aktuell nicht, wie man die Daten der Zählstationen erreichen kann. Ich habe mir dieses Wissen also etwas umständlich aus den Herstellerseiten zusammengefummelt und möchte ich es hier heute für euch dokumentieren. Es sei bedacht, dass die Stadt zwar regelmäßig (aber nur alle paar Jubelmonate) die Daten der Stationen auf opendata.bonn.de veröffentlicht, der Zugriff auf die API des Herstellers selbst bisher jedoch nicht explizit gestattet ist.

Der Zugriff auf die Daten einer Zählstation ist recht einfach. Sie werden im JSON-Format bereitgestellt. Jede Zählstation hat eine ID, die man einfach an die RESTful API übermittelt. So sieht eine Anfrage dann ungefähr aus:

https://www.eco-public.com/api/cw6Xk4jW4X4R/data/periode/{counter_id}?begin={begin_date}&end={end_date}&step={step}

Die Variablen in den geschweiften Klammern müsst ihr nun nur noch wie gewünscht ersetzen und erhaltet dann die Daten:

• {counter_id} mit der ID eines Zählers (s. unten)
• {begin} mit dem Anfangsdatum der gewünschten Daten in der Form YYYYMMDD
• {end} mit dem Enddatum der gewünschten Daten in der Form YYYYMMDD
• {step} mit 2 für ein Interval von 15 Minuten oder 3 für ein Intervall von einer Stunde oder 4 für ein Intervall von einem Tag

Das sieht dann zum Beispiel für die Tagesdaten des Monats Mai 2019 für die Kennedeybrücke so aus:

https://www.eco-public.com/api/cw6Xk4jW4X4R/data/periode/100021143?begin=20190501&end=20190531&step=4

Die IDs der einzelnen Zähler habe ich euch hier zusammengetragen:

[
    {'id': 100021143, 'name': 'Kennedybrücke (gesamt)'},
    {'id': 100019810, 'name': 'Kennedybrücke (Südseite)'},
    {'id': 100019809, 'name': 'Kennedybrücke (Nordseite)'},
    {'id': 100032772, 'name': 'Südbrücke (gesamt)'},
    {'id': 100019722, 'name': 'Südbrücke (Südseite)'},
    {'id': 100019723, 'name': 'Südbrücke (Nordseite)'},
    {'id': 100019720, 'name': 'Nordbrücke (Südseite)'},
    {'id': 100019721, 'name': 'Nordbrücke (Nordseite)'},
    {'id': 100019724, 'name': 'Estermannufer'},
    {'id': 100019726, 'name': 'Brühler Straße'},
    {'id': 100027077, 'name': 'Wilhelm-Spiritus-Ufer'},
    {'id': 100019727, 'name': 'Straßenburger Weg'},
    {'id': 100019728, 'name': 'Von-Sandt-Ufer'},
    {'id': 100027075, 'name': 'John-J.-McCloy-Ufer'},
    {'id': 100019729, 'name': 'Rhenusallee'},
    {'id': 100027076, 'name': 'Hochwasserdamm Beuel'},
    {'id': 100019725, 'name': 'Bröhltalbahnweg'},
]

Die Daten der Kenndeybrücke und der Südbrücke gibt es jeweils getrennt (Südseite / Nordseite) und zusammengerechnet (gesamt = Südseite + Nordseite). Somit hat die Liste insgesamt 17 Einträge für 15 verschiedene Zähler.

Darüber hinaus werden für alle Stationen die Vorbeifahrten auch getrennt der gefahrene Richtung bereitgehalten. Dafür müsste ihr die dritte Ziffer einer ID durch eine 1 bzw. eine 2 ersetzen (fragt bloß nicht warum!?). Für welche Richtung das dann jeweils genau steht, müsst ihr über die offiziellen Websites selbst herausfinden. Da ich das aktuell nicht nutze, habe ich das bisher nicht zusammengetragen.

Und nun: Viel Spaß damit und gebt Bescheid, wenn ihr aus den Daten etwas bastelt.

Update (29. März 2021): Die hier vorgestellte Methode funktioniert nicht mehr bei allen Zählstellen. Zumindest die Zählstelle am John-J.-McCloy-Ufer lässt sich nach einer Reparatur so nicht mehr abfragen. Ich werde beizeiten erklären, welche alternativen Möglichkeiten sich bieten.

Update (26. Juli 2021): Seit einiger Zeit funktioniert dies so auch nicht mehr bei den anderen Zählstellen. Ich werde in Kürze ein Update verfügbar machen.

Interessant wird es jetzt vor allem für Linux-Nutzer. Windows bietet entsprechende Funktionalität leider nicht. Nützlich wird unsere Taste nämlich immer genau dann, wenn deine grafische Oberfläche einfriert und nicht einmal mehr ein Wechsel in die Konsole möglich ist. Vielen Dank an Jonas, der mir eine kluge Tastenfolge gezeigt hat, mir der man seinen PC noch recht geregelt neu starten kann.

Dafür hältst du die ganze Zeit die [Alt]-Taste gedrückt. Um die Magie zu beginnen, drückst du dann die [S-Abf]- bzw. [SysReq]-Taste. Jetzt werden die folgenden Tastatureingaben direkt an den Kernel weitergeleitet (schön weiter die [Alt]-Taste gedrückt halten). Um deinen Rechner nun neu zu starten drückst du nun hintereinander [R]+[E]+[I]+[S]+[U]+[B].

| R | unraw | Nimmt der grafischen Oberfläche den Zugriff auf die Tastatur | | E | term | Sendet ein SIGTERM (abschließen & beenden) an alle Prozesse außer Init | | I | kill | Sendet ein SIGKILL (abbrechen & debuggen) an alle Prozesse außer Init | | S | sync | Schreibt alle noch nicht auf die Festplatte geschriebenen Daten aus dem Kernel-Festplatten-Cache | | U | umount | Alle eingehängten Partitionen werden erst ausgehängt und dann nur-lesbar eingehängt | | B | reboot | Fährt den Rechner sofort herunter und startet den Rechner neu. |

Und wer zum Teufel soll sich das merken? Naja, dafür gibts eine ganze handvoll Merksprüche. Ich merke mir das mit „busier“ rückwärts (der Rechner ist schließlich in solchen Momenten beschäftigter als normal).

Radfunk

Der erste Podcast hat eher weniger mit Computern und Technik zu tun: Radfunk ist ein Podcast von Deutschlandfunk in welchem recht einfach und unkompliziert alle Themen rund um den Drahtesel angesprochen werden. Dabei wird vor nichts halt gemacht: Es geht um fahrradgerechtere Städte, die richtige Kleidung im Winter oder Sicherheit beim Radfahren. Als Gäste laden sich die beiden Moderatoren des Podcasts Paulus Müller und Klaas Reese, Unfallforscher, Stadtplaner, Polizisten, Verkehrswissenschaftler – und natürlich Radfahrer ein.

Die einzelnen Folgen des Podcasts sind ca. 1 Stunde lang. Dabei braucht es für den Zuhörer kein Spezialwissen und man muss auch kein eingefleischter Radfahrer sein. Müller und Reese holen auch in Sachen Radfahren unbedarfte Hörer ab. In den Themen gehen sie trotzdem in die Tiefe, sodass auch ausgefuchste Radaktivisten ihren Spaß darin finden.

Aktuell hat Radfunk acht Folgen. Die erste Folge kam im Mai 2018 heraus. Es folgten bis Mitte Juni 2018 noch weitere fünf Folgen. Im Dezember 2018 und Januar 2019 erschien noch jeweils eine weitere Folge. Anfang April 2019 versprach mir Reese auf Twitter, dass neue Folgen in Vorbereitung seien.

Rechtsbelehrung

Auch wenn sich der Titel dieses Podcasts recht trocken anhört, so sind die Themen immer interessant und, zu meiner Freude, recht häufig sehr internet- und techniklastig. Kein Wunder, denn produziert wird der Podcast Rechtsbelehrung vom Radiojournalisten und Informatiker Marcus Richter und Rechtsanwalt Dr. Thomas Schwenke.

Während Schwenke die juristischen Hintergründe zu den Themen erklärt, holt Richter ihn immer wieder da ob, wo wir juristisch unbedarften Laien stehen: Ganz vorne. In den Folgen thematisieren die zwei zähe Dinge wie die Datenschutzgrundverordnung (in drei langen Folgen) und das Kartellrecht, aber auch viele lockere Themen wie Freifunk oder den verschwundenen Glühweinbecher. Langweilig wird es dabei nie und wenn Schwenke einmal nicht weiter weiß, dann lädt er sich Gäste ein, die weiterhelfen können.

Der Podcast erscheint erfreulich zuverlässig einmal im Monat. Das klappt dank Internet sogar dann, wenn zwischen den beiden Podcastern mal die halbe Weltkugel liegt. Meist nehmen die beiden jedoch gemeinsam auf. Schwenke hegt den Wunsch die Podcasts auf eine Länge von einer Stunde zu begrenzen. Gott sei dank klappt das aber nur selten.

Netzbasteln

Noch ein Podcast von Deutschlandfunk bzw. dem Digitalsender Deutschlandfunk Nova. Netzbasteln ist allerdings kein echter Podcast, sondern bloß ein Zusammenschnitt der gleichnamigen Radioserie. Entsprechend professionell sind die Beiträge gestaltet, in welchen Netzbastler Moritz Metz dem Moderator Sebastian Sonntag seine neusten Life-Hacks und DIY-Basteleien vorstellt. Und das ist immer wieder ziemlich kreativ: eine selbst gebaute Wärmebildkamera, eine Einführung ins Lockpicking oder der Hipsterfahrradwandhalter. Immer gerne mit dabei: WLAN – in Form eines ESP8266.

Netzbasteln erscheint alle zwei Wochen in der Radiosendung Dein Sonntag und danach auch online. Die Beiträge dauern gute 20 Minuten.

Logbuch:Netzpolitik

Im Logbuch:Netzpolitik geht es ganz genau um das: Netzpolitik. Linus Neumann versucht im Team mit Tim Pritlove, Andre Meister und Thomas Lohninger das politische Geschehen rund um das Digitale und Internet einzuordnen.

Das Team selbst erhebt für sich den Anspruch „weitgehend neutral und unaufgeregt“ einen Einblick in Themen wir Vorratsdatenspeicherung, Upload-Filter oder Wahlcomputer zu geben. Jedoch bleiben die Podcasts nicht nur berichtend. Gerade Linus kommentiert das aktuelle Geschehen häufig mit einer guten Portion Zynismus – vielleicht ist das auch die einzige Möglichkeit mit den Wirrungen der Politik umzugehen.

Der Podcast erscheint ungefähr einmal die Woche. Manchmal aber auch nicht und dann aus tagesaktuellen Anlässen widerum gleich mehrmals. Die Länge eines einzelnen Podcast liegt in der Regel bei circa 2 Stunden.

Freak Show

Die Freak Show ist ein Plauderpodcast über „Leben mit Technik im 21. Jahrhundert“. Das sechsköpfige Team um Tim Pritlove, der auch das Logbuch:Netzpolitik herausbringt, spricht im lockeren Ton über eben all das, was es in letzter Zeit beschäftigt hat. Dabei geht es um wirklich alles, was technikbegeisterte Menschen interessieren könnte. Egal ob Streetscooter, DNS, Küchenmaschinen, Elektroautos oder IoT. Außerdem immer wieder Thema: die Produkte von Apple. Das hat auch seinen Grund, denn die Freak Show hieß früher noch mobileMac.

Aufgenommen wird die Show meistens jeden zweiten Mittwoch um 20:00 Uhr (auch wenn die Website von 19:30 Uhr spricht) und kann auch live im Stream verfolgt werden. Wer lange Podcasts genießt, der ist bei der Freak Show genau richtig. Eine einzelne Folge dauert meist circa 4 Stunden.

Methodisch inkorrekt!

Methodisch inkorrekt! ist ein Wissenschaftspodcast von Nicolas Wöhrl und Reinhard Remfort. Die beiden Physiker erklären in lockerer Weise physikalische Effekte und andere vorwiegend, aber nicht ausschließlich naturwissenschaftliche Themen. Daneben küren sie regelmäßig den Schwurbel der Woche aus dem Bereich der Pseudowissenschaften und stellen ein sogenanntes China-Gadget vor. Außerdem ist immer ein Experiment der Woche dabei.

Die einzelnen Folgen erscheinen jeden zweiten Dienstag und sind mit drei bis vier Stunden eher lang. Wer die beiden einmal live erleben möchte, hat dieses Jahr außerdem in einer der Live-Shows der aktuellen Deutschland-Tournee die Möglichkeit dazu.

E-Mail

Mein erstes E-Mail-Postfach habe ich irgendwann als Jugendlicher auf den Tipp meiner Schwestern bei web.de angelegt. Wie viel Speicherplatz es damals gab, kann ich gar nicht mehr sagen. Alte web.de-Nutzer mussten aber lange Zeit mit 12 MB klarkommen und vor über 15 Jahren war es sicherlich noch weniger.

Man kam nicht darumherum alte E-Mails zu löschen. Ansonsten kam es (und dazu kam es öfter) dazu, dass E-Mails an den Absender mit der Meldung „Postfach voll“ zurückgingen. Heute passiert das so schnell nicht mehr. Google bietet bei seinem Postfach bis zu 15 GB Speicherplatz, Posteo hat 2 GB im Angebote und auch web.de hat auf 2 GB aufgestockt.

Vielen Leuten (und so auch mir) ist das Löschen von E-Mails lästig und lassen es dann einfach sein, denn es ist ja Platz genug. Das bleibt aber nicht ohne negative Folgen: Bei einem Einbruch in das Mailpostfach hat der Angreifer Zugriff auch auf private Nachrichten, die schon uralt sind, deren Inhalt aber noch unangenehme Folgen haben kann.

Wenn du alte Nachrichten nicht einfach löschen möchtest und du einen lokalen Mail-Client wie Mozilla Thunderbird nutzt, kannst du mit einem kleinen AddOn automatisiert alte E-Mails aus der Cloud holen. Awesome Auto Archive bietet einem die Möglichkeit E-Mails nach selbst definierbaren Regeln zu archivieren. Gibt man hier einen lokalen Ordner an, dann verschwinden alte Nachrichten automatisch vom Server des Mail-Anbieters, aber bleiben lokal auf dem Rechner vorhanden (Backups nicht vergessen, wenn euch der Inhalt dieser Mails wirklich wichtig ist!).

Messenger-Dienste

Auch Messenger-Dienste häufen über die Zeit viele Daten an. Darüberhinaus werden immer noch viele Android-Smartphones nur über kurze Zeit mit Updates versorgt. Das Risiko sich Schadsoftware einzufangen, ist also durchaus gegeben.

WhatsApp

Leute, ich hab keine Ahnung von WhatsApp. Ich habe die App vor vielen Jahren schon von meinem Smartphone geworfen und auch nicht wieder installiert, als die durchaus gute Ende-zu-Ende-Verschlüsselung eingeführt wurde. Ich habe es nicht bereut, als Facebook schließlich nach dem Messenger griff.

Erstaunlicherweise habe ich bei ein wenig Recherche herausgefunden, dass es bei WhatsApp keine Möglichkeit gibt, alte Nachrichten automatisch löschen zu lassen. Was du tun kannst, ist einzelne Chats oder in den Einstellungen auch alle Chats zu löschen. Wenn du einen Weg weist, wie man auf einfachen Weg nur alte Nachrichten löschen kann, dann schreib mir in die Kommentare.

Signal

Wenn du den freien und datenschutzfreundlichen Messenger Signal nutzt, kannst du mit einer einfachen Angabe in den Einstellungen alte Nachrichten automatisch löschen lassen. Dabei löscht Signal nicht anhand des Alters der Nachrichten, sondern anhand der Menge. Überschreitet eine einzelne Unterhaltung die Höchstgrenze, fliegt die älteste Nachricht raus. Die Funktion scheint damit eher mit dem Blick auf begrenzten Speicherplatz erschaffen worden zu sein.

Dafür gehst du in den Einstellungen auf Unterhaltungen und Medieninhalte → Kürzen von Unterhaltungen und aktivierst die Option Alte Nachrichten löschen. Direkt darunter kannst du die Höchstzahl an Nachrichten je Unterhaltungen frei einstellen.

Threema

Der schweizer Messenger Threema verfolgt ein anderes Konzept als Signal. Aber auch hier scheint der Fokus auf begrenztem Speicher zu liegen. So heißt denn auch die Option, die man in den Einstellungen unter Medien & Speicher aufrufen muss, Speichermanagement. Dort kann man entweder nur Bilder und Dateien, aber auch Nachrichten, die älter als eine gewünschte Zeitspanne sind, löschen lassen. Im Gegensatz zu Signal geht das hier nicht automatisch, sondern immer nur manuell.

Cloud

Was liegt bei dir eigentlich so in der – Achtung: Buzzword! – Cloud herum? Also ganz konkret bei Diensten wie Dropbox, Google Drive oder iCloud. Schau dich doch mal um, was da an Daten so herumliegt und räume auf. Alles, was nicht unbedingt in die Cloud muss, kannst du entweder direkt löschen (auch den Papierkorb der Cloud leeren) oder auf deinem lokalen Gerät speichern. Und in Zukunft willst du deine Daten vielleicht verschlüsselt in die Cloud legen?

Ist da noch mehr?

Bestimmt hast du auch anderswo noch Daten liegen. Es schadet sicher auch nicht, deine lokalen Daten auf PC, Notebook und Smartphone hin und wieder aufzuräumen. Alles, was du nicht mehr brauchst, ab in den Papierkorb! Hast du noch Ideen, wo man hin und wieder sonst so aufräumen sollte, dann schreib mir in die Kommentare.

tar-Archive sind nicht zwingend komprimiert. Die Komprimierung ist optional. Deswegen findet man Dateien mit der Endung .tar.gz genauso wie .tar.bz2 oder .tar.xz. Und so entpackt man die Dinger in der Konsole:

$ tar xvzf archive.tar.gz
$ tar xvjf archive.tar.bz2
$ tar xvJf archive.tar.xz

Ganz ehrlich? Das kann sich wirklich keiner merken. Abhilfe schafft hier das kleine Programm dtrx (Do The Right eXtraction) von Brett Smith. Also schnell installieren:

# Ubuntu
$ sudo apt install dtrx
# Arch Linux
$ yay -S dtrx

Für Arch Linux liegen die Pakete im AUR. Je nach verwendetem Packman Wrapper für das AUR musst du also noch yay durch den von dir installierten Wrapper ersetzen (bspw. pakku, pacaur oder trizen).

dtrx kann übrigens auch zip, 7z, rar, rpm, deb und vieles mehr. Von nun an braucht es also nur noch:

$ dtrx archive.tar.gz

In dem GitHub-Projekt awesome-selfhosted findet sich zu wirklich fast allen Kategorien Software für Netzwerkdienste und Webanwendungen. Bei allen aufgeführten Projekten wird zudem die Lizenz (z. B. GPL, MIT…) und die zugrunde liegende Programmiersprache angegeben.

Durch die Liste der Note-taking and Editors und der Task management/To-do lists muss ich mich auf jeden Fall erst einmal durcharbeiten, denn besonders erwähnenswerte Programme werden in der Liste leider nicht extra hervorgehoben. ¯_(ツ)_/¯

Den MHPG habe ich im Februar 2017 vorgestellt. Er basiert auf einer Idee von Tim Anderson und generiert dir mithilfe eines Master-Passworts dienstespezifische Passwörter, sodass mehrfach genutzte, gleiche Passwörter der Vergangenheit angehören. Das Tool ist komplett in HTML und JavaScript geschrieben, es werden keine Daten an meinen Server gesendet.

Mithilfe der neuen Auto-Copy-Funktion werden erzeugte Passwörter sofort in deine Zwischenablage kopiert. So entfällt lästiges manuelles Kopieren der Passwörter. Zusätzlich ermöglicht dies, dass das Passwort nicht mehr im Klartext ausgegeben werden muss. Stattdessen wird das Ergebnis nur noch mit den klassischen Punkten angezeigt. So kann niemand das Passwort mitlesen, wenn er dir über die Schultern schaut.

Möchtest du das Passwort doch einmal im Klartext sehen, so kannst du es dir mit einem Klick auf das Augen-Symbol ganz einfach anzeigen lassen (und ggf. auch manuell kopieren, falls es mit der Automatik mal nicht klappen sollte).

Ich besitze seit vielen Jahren (es dürften jetzt schon circa sieben sein) ein Network Attached Storage (NAS). Der DS211j von Synology ist inzwischen aber recht betagt und war schon bei der Anschaffung ein eher kleines Modell. Aber es beinhaltet immer noch alle Vorteile, die man von einem NAS mit Einschüben für zwei Festplatten von jeweils maximal 3 TB so erwarten kann. Ansonsten fällt es vor allem durch schwache Leistung auf: 1,2 GHz Single-Core und vor allem 128 MB RAM machen den alten Hasen langsam.

Weg mit dem Strommonster

Was läge also näher als den kleinen weißen Kasten, der so munter in meinem Wohnzimmer flackert endlich auszumisten? Immerhin verbraucht das Ding bis zu 25 W im Betrieb und 10 W im Ruhezustand. Mein (Öko-)Stromanbieter nimmt ca. 24 Cent pro kWh. Das kostet, wenn mich meine Rechenkünste nicht verlassen haben, also irgendwas zwischen 21,02 € (Dauer-Ruhezustand) und 52,56 € (Dauer-Betrieb) im Jahr. Das belastet nicht nur die Umwelt, sondern auch meinen Geldbeutel mehr als ich gedacht habe.

Die Dienste, die auf dem NAS laufen können eigentlich alle ausgelagert werden: Auf meinen Raspberry Pi, der eh Tag und Nacht läuft, um mir Werbetracker vom Hals zu halten oder auf meinem vServer, der dann auch ordentliche Rechenleistung und vor allem Netzanbindung hat.

Welche Dienste laufen auf dem NAS?

Auf dem NAS gibt es eine Vielzahl von möglichen Diensten, die einfach (und per Klick) installiert und administriert werden können. Alles per Weboberfläche, die allerdings sehr langsam und daher mühsam zu bedienen ist. Um herauszufinden, welche Dienste bei mir aktuell laufen, die dann in Zukunft entweder vom Pi oder vom vServer übernommen werden müssen, öffne ich das sogenannte „Paket-Zentrum“. Dort finde ich folgende installierte Pakete/Anwendungen:

• Audio-Station
• File-Station
• WebDAV Server
• CardDAV Server
• Text-Editor
• Note Station
• Python Module
• PHP 7.0
• Universal Search
• USB Copy
• Speicher-Analysator

Dienste, die in der Liste fett markiert sind, muss ich in den nächsten Wochen durch Alternativen ersetzen. Alle anderen sind eher NAS-spezifisch.

Audio-Station

In der Audio-Station liegt meine ganze Musiksammlung. Da ich mich bisher noch erfolgreich von Streaming-Diensten wie Spotify oder Deezer verwehrt habe, ermöglicht mir dieses Stück Software auch von unterwegs mit meinem Smartphone auf all die Musik zuzugreifen, die ich gern höre.

File-Station

Nix Cloud oder so. File-Station ermöglicht den Zugriff auf Dateien über das Netzwerk. Per Samba, NFS oder auch dem Browser. Den ganzen Wust an Dateien, die man eben nicht auf der Platte von seinem Compute haben möchte. Ewig alte Fotos, irgendwelche Backups und Hörbücher.

WebDAV Server

Den WebDAV Server nutze ich, um meine Kalender online zu verwalten.

CardDAV Server

Mit dem CardDAV Server halte ich meine Kontakte über verschiedene Geräte wie Smartphone, Notebook und Co synchronisiert.

Text-Editor & Note Station

Den Text-Editor habe ich wahrscheinlich nur ein handvoll Male benutzt. Die Note Station dagegen nutze ich auf meinem Smartphone dafür wofür man eine Notiz-Anwendung eben nutzt. Schon einmal Weihnachtsgeschenkideen für Eltern, Geschwister und Freundin notieren.

Und nun?

Einige von den Diensten lassen sich wirklich ganz einfach ersetzen. Für Tipps über empfehlenswerte Software freue ich mich trotzdem. Vollständig in Rente wird das NAS übrigens wohl eher nicht gehen. Ich werde es wohl jede Nacht einmal aufwecken, um meine Backups draufzuspielen.

Und ich muss ehrlich sagen, dass ich davon ziemlich begeistert bin. Ich nutze das schon seit ein paar Jahren und es ist an der Zeit das hier einmal festzuhalten. Alles, was man dafür tun muss, ist per cURL die Seite wttr.in aufzurufen. Also schnell ins Terminal getippt:

$ curl wttr.in

Und so sieht das dann aus:

Das Tool versucht den Standort des Nutzers über die IP zu bestimmen. Das funktioniert aus dem Uni-Netz zum Beispiel immer super. Zu Hause hat mich das Tool aber von Bonn circa 20 km weiter nördlich nach Köln verschoben. Das kann man mit der Angabe des Ortes in der URL aber einfach korrigieren:

$ curl wttr.in/Bonn

Statt Städtenamen kann man auch die dreistelligen internationalen Kürzel für Flughäfen angeben. Da komme ich natürlich nicht drumherum, mir einmal das Wetter für den BER anzeigen zu lassen.

wttr.in kannst du natürlich neben cURL auch mit httpie oder ähnlichen Tools nutzen. Außerdem unterstützt wttr.in auch die Ausgabe im Browser oder sogar als Bild:

$ wget wttr.in/Bonn.png

Das heruntergeladene Bild könnt ihr dann mit einem Bildbetrachter eurer Wahl anschauen, auf eure Webseite einbinden oder sogar ausdrucken (#internetausdrucker).