Willkommen zu allesnurgecloud.com – Ausgabe #243

Das EU-Parlament hat am 9. Juli die „Chatkontrolle 1.0″ passieren lassen: Das anlasslose Scannen privater Nachrichten auf US-Plattformen ist damit bis 2028 wieder erlaubt — obwohl eine Mehrheit der abstimmenden Abgeordneten (314 zu 276) dagegen stimmte, verfehlte die Ablehnung die nötige absolute Mehrheit von 361 Stimmen – das hat dank eines Tricks im Verfahren und mit dem beginnenden Urlaub vieler Abgeordneter nun leider funktioniert.

Nvidia führt für seine KI-Beschleuniger ein „Credit-Support“-Modell ein: Kleinere Rechenzentrumsbetreiber (Neoclouds) bekommen die Hardware, und Nvidia verspricht, ungenutzte Kapazität selbst zurückzumieten — im Gegenzug für eine Umsatzbeteiligung – fängt hier nun die Blase an zu platzen? (Quelle heise).

Woher beziehen Piraten die Streams, die sie zur WM 2026 in 4K weiterverbreiten? Aus derselben Infrastruktur wie die legitimen Anbieter — dem CDN. Ein auf LinkedIn dokumentierter Fall zeigt eine Piratenseite, die ihren Restream ausgerechnet über TikToks CDN ausliefert: Die Millionen-Dollar-Infrastruktur eines globalen Konzerns transportiert den gestohlenen Stream gleich mit – clever und günstig, in dem Fall.

Und wie du schon weißt, baue ich aktuell mit Statuswerk eine komplett in Deutschland betriebene Statuspage – alle Daten, E-Mail und SMS bleiben hierzulande. Fokus nur darauf, dafür richtig und fair bepreist. Auf die Warteliste eintragen – Launch Ende Juli mit Early-Bird.

So, und nun viel Spaß mit der neuen Ausgabe!

Happy Bootstrapping Podcast

In der aktuellen Podcast Folge 180 habe ich mit Michael und Stephan Wirth von EAS360 gesprochen. Der Aufzugsprofi und sein Schwiegersohn haben aus einer abgestürzten Excel-Tabelle eine Software gebaut, die Wartung, Prüffristen und Kosten von Aufzügen bündelt und überteuerte Angebote per Marktpreisvergleich entlarvt. Wir reden über ihr Geschäftsmodell, einen Kunden, der 40 % sparte, und die App EAS-Y 360 für Störungen und Inaugenscheinnahmen. Gerne kannst du die Folge auf YouTube schauen oder wie immer bei Spotify, Apple und allen anderen Playern anhören.

Wenn dir die Podcastfolgen zu lang sind, kannst du gerne auch den Newsletter dazu abonnieren – erscheint jeden Montag (in der Regel).

allesnurgecloud.com ist ein kuratierter Newsletter mit Inhalten aus der Open-Source, Cloud und IT-Welt.
Für weiteren Content folge mir gerne auf Twitter, Mastodon oder LinkedIn.

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren:

Nextcloud-Leck und die Grenzen der Souveränität

Ausgerechnet Nextcloud: Der deutsche Anbieter, der gern als souveräne Alternative zu US-Diensten firmiert, hat laut einem Bericht bei Golem über 367.000 interne Datensätze offen im Netz stehen lassen. Ursache war ein fehlkonfigurierter Elasticsearch-Cluster — der Klassiker unter den Datenlecks.

In der Datenbank lagen Mitarbeiterdaten, Verträge und unverschlüsselte Rechnungen. Heikel sind vor allem die kundenspezifischen Skripte, mit denen Nextcloud-Infrastruktur in fremde Systeme eingebunden wird — wer sie liest, findet Angriffspunkte bei den Kunden. Dazu E-Mail-Adressen von Angestellten bei Strato und Ionos sowie des NRW-Schulministeriums: quer durch das eigene Souveränitäts-Ökosystem und in die Verwaltung hinein.

Nextcloud schloss die Lücke zwei Tage nach Entdeckung und betont, kein Kundenserver sei direkt betroffen, Missbrauch nicht bekannt. Beruhigend ist das nur bedingt — aus offenen Rechnungen und Adressen baut man täuschend echte Phishing-Mails, und die Setup-Skripte sind eine Vorlage für gezielte Angriffe.

Der Fall passt ins Muster: Das Souveränitäts-Argument — raus aus der US-Cloud, rein zu Nextcloud (siehe Ausgabe 192) — steht und fällt mit dem Betrieb. Ein offener Elasticsearch-Cluster ist kein US-Problem, sondern ein Konfigurationsproblem. Die operative Fragilität von Nextcloud war schon in Ausgabe 228 Thema. Souveränität heißt eben auch: selbst sicher betreiben können. Das fängt dann natürlich beim Anbieter selbst an….

Wo stehen deine Datenbanken — und weißt du, welche nach außen offen sind?

Kundenskripte und Rechnungen standen offen im Netz

---

Januscape: 16 Jahre alte KVM-Lücke, VM-Ausbruch

Diesmal trifft es nicht den Container, sondern die VM-Grenze selbst. Sicherheitsforscher Hyunwoo Kim (alias V4bel) hat mit Januscape (CVE-2026-53359) einen Use-after-free in der Shadow-MMU von KVM/x86 offengelegt — dem Teil, der Speicheradressen übersetzt. Betroffen sind Intel- und AMD-Systeme, nicht aber Arm64. Der Bug steckte seit einem Commit von 2010 im Kernel — rund 16 Jahre.

Heikel ist das Angreifermodell: Es genügt Root im Gastsystem — also eine einzige gemietete Instanz in einer Public Cloud. Damit lässt sich die Shadow-Page des Host-Kernels beschädigen und die Gast-Host-Isolation aushebeln. Im schlimmsten Fall führt ein Angreifer Code mit Root-Rechten auf dem Host aus und übernimmt alle Gäste auf derselben Maschine. Genau das Szenario, das Multi-Tenancy auf geteilter Hardware so heikel macht — die Konsequenz „Namespace- oder gar VM-Grenzen reichen nicht automatisch“ zog sich schon durch Copy Fail in Ausgabe 234.

Zur Mitigation: Der Patch ist seit dem 16. Juni 2026 im Mainline-Kernel, aber für Debian, Ubuntu, SUSE und Red Hat war er zum Meldezeitpunkt teils noch nicht ausgerollt — teilweise ist nicht mal klar, welche Versionen anfällig sind. Ein Reboot auf den gepatchten Kernel ist nötig. Kim hält einen vollständigen VM-Ausbruch-Exploit vorerst zurück — bei KI-gestützter Schwachstellenforschung aber keine Garantie, dass ihm niemand zuvorkommt. Laut einem Kommentar könnte aktivierte nested Virtualization Voraussetzung sein — bitte für deine Umgebung prüfen.

Läuft bei dir KVM auf Intel/AMD mit fremden Gästen auf derselben Hardware?

16 Jahre alte KVM-Lücke ermöglicht VM-Ausbruch

---

---

Warum ClickHouse mit dem Datenvolumen skaliert

Seit rund zehn Jahren beschäftigt sich Mat Duggan mit Observability, und in seinem lesenswerten Rant bringt er ein Argument, das jenseits des Titels sitzt: Logs seien der undankbarste Teil des Jobs — geprägt von jenem ersten grep auf einer kleinen Box, das einen für alles danach verdirbt. Aus vierzig Services werden vierhundert, und die Erwartungen von Entwicklern, Support und Data-Team kollidieren.

Sein eigentlicher Punkt ist die Skalierung. Bei 1 TB/Tag funktioniert jeder Stack — nimm, was dein Team kennt. Bei 5 TB wird Kafka zur Pflicht und die Shard-Mathematik zum Problem. Bei 10 TB/Tag kapitulieren Elasticsearch und die LGTM-Combo, während Datadog finanziell mutiert: zu einer Rechnung, für deren Drückung du ein eigenes Pipeline-Team brauchst. Du baust dir also ein System, um das System zu meiden, für das du zahlst — und über 1 Million Dollar pro Monat sind da drin. Dass eine unbeobachtete Datadog-Rechnung schnell explodiert, kennen wir schon von Coinbases 65-Millionen-Jahresrechnung aus Ausgabe 103.

Nur ClickHouse ändere seine Form nicht — dieselbe Architektur bei 10 TB wie bei 1 TB, nur mehr Shards. Columnar Storage liest ausschließlich die abgefragten Spalten und komprimiert 10–14x statt 2–3x bei Elasticsearch. Der Preis dafür: Schema-Design und ORDER-BY-Keys vorab, während andere Systeme anfangs bequemer sind.

Prompt kontert Charity Majors, CTO bei Honeycomb: Es gehe gar nicht um ClickHouse, sondern um columnar storage als solches — also Observability 2.0, über das sie seit Jahren schreibt. Ihre These zur Betriebsblindheit: Ein einzelner Vendor wird als Marketing abgetan, erst mehrere Stimmen verschieben die Wahrnehmung. Ihr Vorwurf an die Post-2019-Anbieter, die allesamt auf Spaltenspeichern bauen: Sie verkaufen „Datadog, nur billiger“ und verschleiern den eigentlichen Unterschied. „The weakness I sense in Datadog is all product.“ Für sie zählt der Trace, nicht der Preis — die Beziehungen im Datensatz seien der eigentliche Wert, den die Aufteilung in drei Säulen zerstört.

Dass ClickHouse bei diesen Volumen zur Standardwahl wird, zeigte zuletzt die Skalierung auf über 100 PB in Ausgabe 194. Nutzt du ClickHouse schon produktiv — oder zahlst du noch Datadog-Tribut?

Clickhouse is winning the Observability Wars

---

Glue Work, KI und die Beförderungsfrage

Der Hauptaufhänger diese Woche kommt ausgerechnet von XING — ein Satz, den ich nie zu schreiben glaubte, ich bin da nicht mal mehr angemeldet. Christian Thiele argumentiert dort in einem lesenswerten Beitrag, dass Glue Work durch KI vom unsichtbaren Kostenfaktor zur sichtbaren Wertschöpfungsquelle wird.

Der Begriff stammt von Tanya Reilly, die ihn 2019 in ihrem Vortrag prägte: die Koordinations-, Kontext- und Beziehungsarbeit, die ein Team zusammenhält — Onboarding, Design-Reviews, Doku, Stakeholder-Alignment. Reillys bittere Diagnose: Wer sich zu früh darauf einlässt, schreibt zu wenig sichtbaren Code und wird nicht befördert. Und die Last verteilt sich ungleich — Frauen übernehmen solche Aufgaben nachweislich häufiger, ohne dafür belohnt zu werden.

Thieles Wendung: Übernimmt KI den codierbaren Teil, bleibt genau die Arbeit übrig, die Maschinen nicht können — Kontext dokumentieren, Agenten managen, eskalieren, Vertrauen herstellen. Er bündelt die Forschung dazu (Deming, Acemoglu/Restrepo, Felten) und zitiert eine GitHub-Engineerin in der FT: Diese Hintergrundarbeit werde zur wichtigsten Fähigkeit. Seine optimistische Pointe — KI zwinge Organisationen, ehrlich zu werden und Glue Work endlich zu benennen.

Die Praxis ist skeptischer. In einem Reddit-Thread zur Frage, wie man Glue Work fürs Performance-Review dokumentiert, ist der Tenor ernüchternd: „Glue work has barely counted for promotions at any of them.“ Der brauchbarste Rat dreht sich um Leverage — hat die Arbeit Hebelwirkung erzeugt, und lässt sich das belegen?

Ich hatte das Thema vor zwei Jahren schon einmal. Die Grunddynamik ist gleich geblieben, der Einsatz steigt. Bist du der „Klebstoff“ deines Teams — und zählt es bei euch?

„Glue Work“ oder das stille Heldentum: Organisationen müssen sich mehr um ihren Klebstoff kümmern

---

400 GB ohne Downtime: Supabase zu PlanetScale

Migrations-Postmortems sind oft verkappte Werbung — dieses von Vitalize (Infrastruktur für Klinik-Personalplanung) hat aber echten Praxiswert. Beschrieben wird der Umzug von Supabase zu PlanetScale Postgres: 400 GB, 150 Millionen Zeilen, ohne Downtime.

Auslöser war Supabases Connection-Handling. Trotz 15.000 Usern blieben effektiv unter 150 nutzbare Verbindungen übrig, 10–30 reserviert die Plattform selbst für Auth und Storage. Transaction- und Session-Pooler hielten nicht, was sie versprachen. Dazu ging über 60 % der CPU-Zeit für IOWait drauf — die Queries warteten auf die Platte, das klassische Symptom von Shared Storage. Genau hier setzt PlanetScale Metal mit lokalen NVMe an, wie schon bei Intercoms Migration in Ausgabe 184.

Lesenswert sind vor allem die Pannen: nicht-deterministische Duplicate-Key-Fehler beim pgcopydb-Sync, eine vom supa_audit-Extension angelegte Tabelle, deren 130 Millionen Altdatensätze nicht mitkopiert wurden, und am Ende ein volllaufendes Ziel-Volume trotz doppelt geprüfter Rechnung — WAL und System-Overhead fraßen den Puffer. Auch das Dedup ohne sauberen Cutoff (bigserial-IDs taugen bei paralleler Replikation nicht als Grenze) ist lehrreich.

Das Ergebnis: P95 bei 2 ms, Reads auf der JSONB-Tabelle statt 50 s nun 1,2 s — auf kleinerer Instanz. Die PlanetScale-Benchmarks gegen Supabase aus Ausgabe 195 passen ins Bild. Und für mehr Performance gibt es ja Planetscale Metal.

Bist du bei Supabase schon an Connection-Limits gestoßen?

From Supabase to PlanetScale: Zero Downtime, 400GB, 150 Million Rows

---

Zehn Jahre Traefik: 3,5 Milliarden Pulls

Zehn Jahre Traefik, und Gründer Emile Vauge nutzt den Anlass für eine Bilanz: 1.000 Contributoren auf GitHub und 3,5 Milliarden Pulls des offiziellen Docker-Images. Klingt nach Jubiläums-PR — an einer Stelle ist es aber tatsächlich interessant. Denn 2026 ist laut Vauge das aktivste Jahr der Projektgeschichte: 470 gemergte Pull Requests im ersten Halbjahr, hochgerechnet rund 940 — fast doppelt so viele wie 2025.

Der Treiber ist weniger Marketing als Timing. Mit der Abkündigung von Ingress NGINX standen Millionen Cluster vor einer Migration, und Traefik hat dafür einen nativen NGINX-Ingress-Provider gebaut, der bestehende Ingress-Ressourcen samt der über 80 nginx.ingress-Annotationen direkt liest — ohne YAML-Umschreiben. Die daraus folgende Adopter-Welle treibt die Aktivität. Passend dazu hatte ich in Ausgabe 236 den per KI gefundenen nginx-Bug NGINX Rift — Vauge bedankt sich in seinem Post süffisant bei „Claude“ fürs Rekordjahr an CVE-Reports.

Als Default-Ingress ist Traefik ohnehin breit gesetzt: K3s, MicroK8s, Nutanix, ab v1.36 auch RKE2. „That is not a trend; it is a standard“, so Vauge. Der Rest — Traefik Hub, AI Gateway, MCP Gateway, die Vision vom „unified gateway“ für VMs, Container und AI — ist die übliche Plattform-Erzählung.

Läuft bei dir noch Ingress NGINX — und wenn ja, wann oder wohin migrierst du? Ich mache selbst mittlerweile viel mit Caddy ehrlicherweise.

Ten Years In, Traefik is Having Its Biggest Year Ever

---

Ein Friends-GIF, 377 GB und das ext4-Hardlink-Limit

Ein einziges Reaction-GIF, 246.173-mal dupliziert, 377 GB Backup-Ballast — und ein Filesystem-Limit, von dem der Autor nichts wusste. Jake Goldsborough beschreibt hier, wie Discourse-Backups auf großen Foren den Speicher sprengten.

Ursache ist ein Design-Detail: Discourse‘ „secure uploads“ legt bei jedem Wechsel des Security-Kontexts — etwa von der PM in einen öffentlichen Post — eine neue Kopie mit frischer SHA1 an. Gleicher Inhalt, neue Datei. Ein Kunde hatte 432 GB Uploads, nur 26 GB davon einzigartig — Faktor 16.

Der Fix: nach original_sha1 gruppieren, einmal herunterladen, den Rest per Hardlink verknüpfen; tar speichert die Daten dann nur einmal. Funktionierte — bis bei rund 65.000 Hardlinks Schluss war, dem ext4-Limit pro Inode. Der Schuldige: jenes GIF von Rachel aus Friends, 1,6 MB, eine Viertelmillion Kopien.

Lehrreich ist die Reparatur der Reparatur. Statt eine magische Zahl zu raten — ext4, XFS und ZFS haben verschiedene Limits —, fängt man Errno::EMLINK ab und nutzt die lokal vorhandene Kopie als neuen Primary. Der eingebaute Fallback rettete das Feature: „a 99.998% improvement with graceful degradation beats a 100% improvement that crashes.“

Welches obskure Limit hat dich zuletzt kalt erwischt?

How Jennifer Aniston and Friends Cost Us 377GB and Broke ext4 Hardlinks

---

Warum der Incident Commander zum Debuggen abdriftet

Neunzig Minuten in den Ausfall hinein hängt ausgerechnet die Person, die den Incident leiten soll, selbst im Terminal und debuggt mit. Niemand verschickt Status-Updates, niemand koordiniert. Brent Chapman beschreibt dieses Muster und widerspricht der üblichen Deutung: Das sei kein Disziplinproblem, das man mit Willenskraft löst, sondern ein kognitives.

Troubleshooting und Koordination verlangen unvereinbare Aufmerksamkeit. Debugging ist heads-down: eine Hypothese verfolgen, testen, nachjustieren — Unterbrechungen sind teuer. Koordination ist das Gegenteil, heads-up und ständig springend zwischen Team-Check-ins, Status-Updates und ETA-Fragen aus dem Management. Beide Rhythmen bekämpfen sich, und das Debugging gewinnt fast immer, weil es greifbarer wirkt als das „Papierkram“-Gefühl eines Status-Updates.

Chapmans Bild dafür ist der Dirigent: „The moment the conductor picks up a violin, nobody’s conducting.“ Der Incident Commander entstört nicht den Ausfall, sondern die Incident-Response. Bei größeren Vorfällen empfiehlt er zusätzlich einen Tech Lead nach innen (das Problem), während der IC nach außen zeigt (Stakeholder). Gerade in größeren Organisationen oder Umgebungen sind beide Rollen wichtig.

Das deckt sich mit dem, was ich hier in Ausgabe 86 und Ausgabe 138 schon vertreten habe: Der eigentliche Wert der Rolle ist, den Engineers den Rücken freizuhalten. Neu für mich — und überzeugend — ist die kognitive Begründung dahinter.

Hast du einen dedizierten Incident Commander — oder debuggt der bei euch auch mit?

Why you keep losing your incident commander to debugging

---

Open Source vor und nach GitHub

Bevor es GitHub gab, war Armin Ronachers Open Source zu Hause auf eigener Infrastruktur: Trac, Subversion, Tarballs, ein selbst betriebenes Kollektiv namens Pocoo. In seinem Essay nutzt der Flask- und Jinja-Erfinder GitHubs sichtbaren Niedergang, um an diese kleinere Welt zu erinnern — und an das, was beim Abschied verloren gehen könnte.

Sein Punkt ist nicht die übliche Klage über Copilot-Lärm und fehlende Führung; die hatten wir hier schon beim Zig-Exodus in Ausgabe 215 und der Forgejo-Migration in Ausgabe 236. Ronacher interessiert die tiefere Ironie: Das verteilte Versionskontrollsystem hat gewonnen — und trotzdem einigte sich alles auf einen zentralen Dienst.

Damit sei GitHub versehentlich zum Archiv geworden. Der Code ist dank Git verteilt, der soziale Kontext aber nicht: Issues, Reviews, Design-Diskussionen, Release-Artefakte, Security-Advisories. Genau das verschwindet schneller, als man denkt — siehe Google Code und Bitbucket. Wandern Projekte jetzt auf viele kleine, selbst gehostete Forges zurück, gewinnt man Autonomie, riskiert aber wieder kaputte Tarball-Links.

Sein Vorschlag: ein langweiliges, öffentlich oder per Stiftung finanziertes Archiv, dessen einziger Job es ist, dass das Wichtige nicht verschwindet — unabhängig von der Laune eines einzelnen Konzerns. „keep the memory and lose the dependence.“

Wo liegt dein Code — noch bei GitHub, oder schon woanders gespiegelt?

Before GitHub

---

Schmunzelecke

Bei Instagram gibt es einen neuen Corporate / Remote Work „Star“ aus Deutschland Cristiano Ozair – siehe hier und da.

Command & Conquer Generals wurde von Claude Code mit Fable Model auf iOS portiert – crazy, was hier mittlerweile geht.

---

💡 Link Tipps aus der Open Source Welt

PureMac – Open Source Mac Cleaner ohne Telemetrie

PureMac ist ein kostenloser, quelloffener Uninstaller und System Cleaner für macOS – die CleanMyMac-Alternative ohne Abo, ohne Telemetrie, ohne Fake-Urgency. Alles landet im Papierkorb, nichts wird unwiderruflich gelöscht.

Key Features:

• App Uninstaller: 10-stufige Matching Engine (Bundle ID, Team Identifier, Entitlements, Spotlight, Container Discovery) findet alle Dateien, die eine App über das System verteilt hat. Drei Empfindlichkeitsstufen, Apple System-Apps automatisch ausgeschlossen
• Orphan Finder: Durchsucht ~/Library nach Überbleibseln bereits gelöschter Apps
• System Cleaner: Parallel-Scan über System Junk, User Cache, AI Apps (Ollama/LM Studio), Mail Attachments, Xcode DerivedData, Homebrew Cache, Node Cache, Docker Cache, Large & Old Files
• Honest by Design: Kein „47 GB Junk detected!“-Alarm, kein Purgeable-Space-Betrug, keine Auto-Deletion. Jeder Fund zeigt den echten Pfad mit Reveal-in-Finder
• Scheduled Cleaning: Optionale automatische Bereinigung mit konfigurierbarem Intervall und Schwellwert
• Security: Symlink-Attack-Prevention, Allow-List-basiertes Cleaning, Admin Escalation nur für definierte Roots

Native SwiftUI App, signed und notarisiert von Apple. macOS 13.0+. Installation via brew install --cask puremac.

Das „Promise“ des Projekts liest sich wie ein Manifest gegen die gesamte Mac-Cleaner-Kategorie – und der Code hält es ein. Wer CleanMyMac-Abos satt hat und einen transparenten Cleaner will, bei dem man im Source nachschauen kann was gelöscht wird, ist hier richtig.

https://github.com/momenbasel/PureMac

Hunk – Review-First Terminal Diff Viewer für AI-generierte Changesets

Hunk ist ein interaktiver Diff Viewer im Terminal, gebaut für das Review von Changesets, die AI Agents oder Coworker produziert haben. Multi-File-Navigation, inline AI-Annotations und responsive Layouts – statt Diffs im Pager durchscrollen, Changesets wie in einem Code Review durcharbeiten.

Key Features:

• Multi-File Review Stream: Sidebar mit allen geänderten Dateien, durchnavigierbar mit Keyboard und Maus
• Inline AI/Agent Annotations: Notizen und Kommentare direkt neben dem Code – ideal zum Review von Agent-generierten Änderungen
• Split, Stack, Auto-Layout: Responsive Layouts, zur Laufzeit umschaltbar
• Watch Mode: hunk diff --watch reloaded automatisch bei Dateiänderungen
• VCS-agnostisch: Git, Jujutsu und Sapling nativ unterstützt mit automatischer Erkennung
• Agent Workflow: Live-Session öffnen, Agent den Skill-Pfad geben, Agent reviewt gegen die laufende Hunk Session
• Git Integration: Als core.pager setzbar, dann öffnet git diff/git show direkt in Hunk
• Themes: Built-in Themes (GitHub Dark/Light, Catppuccin, Graphite), Custom Themes via TOML
• OpenTUI Component: Diff-Renderer als wiederverwendbare Komponente für eigene TUI-Apps publisht

Installation via npm i -g hunkdiff oder brew install hunk. Node.js 18+, macOS/Linux/Windows.

Trifft den Zeitgeist perfekt: je mehr Code von Agents geschrieben wird, desto wichtiger wird ein guter Review-Workflow. Hunk füllt genau die Lücke zwischen git diff im Terminal und einem vollen PR-Review auf GitHub – schnell, keyboard-driven, mit dem entscheidenden Extra der inline Agent-Annotations.

https://github.com/modem-dev/hunk

❓ Feedback & Newsletter Abo

Vielen Dank, dass du es bis hierhin geschafft hast!
Kommentiere gerne oder schicke mir Inhalte, die du passend findest.

Falls dir die Inhalte gefallen haben, kannst du mir gerne auf Twitter folgen.
Gerne kannst du mir ein Bier ausgeben oder mal auf meiner Wunschliste vorbeischauen – Danke!

Möchtest du den Newsletter wöchentlich per E-Mail erhalten?
Einfach hier abonnieren: