Das Internet ist tot, oder?

Seit einiger Zeit habe ich das Gefühl, dass das Internet ein schlechterer Ort geworden ist. Nicht unbedingt lauter, nicht unbedingt langsamer, aber leer an den Stellen, an denen früher Menschen sichtbar waren. Vor zehn oder fünfzehn Jahren konnte ich mich durch kleine private Blogs klicken, in Foren mitlesen, in Kommentaren widersprechen und dabei nebenbei etwas lernen. Es war ein Netz aus vielen kleinen Stimmen, nicht immer klug, nicht immer schön, aber erkennbar von Menschen gemacht.
Ich erinnere mich an Abende, an denen ich einen Blogeintrag über ein Problem gelesen und über die Kommentare eine bessere Lösung gefunden habe. Ich habe selbst geschrieben, Fragen gestellt, Fehler korrigiert und Links zu anderen Seiten gesetzt. Heute schreibe ich weiterhin über Dinge wie mein GitHub-Backup mit Gickup und Forgejo oder lokale KI im Homelab. Ein Beitrag war früher oft nur der Anfang eines Gesprächs. Heute lande ich viel häufiger bei großen Medien, die längst zu […]

GitHub-Backup mit Gickup und Forgejo

In meinem über Jahre gewachsenen GitHub-Konto codebude steckt ein ziemlich großer Teil meiner Arbeit. Rund 70 Repositories sind es inzwischen, öffentliche und private, darunter auch Forks. Du kennst das: Ein gehostetes Konto ist bequem, aber die Kopie liegt trotzdem bei jemand anderem.
Mein Ziel ist deshalb überschaubar und konkret: Alle Repositories sollen einmal täglich automatisch auf meine eigene, selbst gehostete Forgejo-Instanz gespiegelt werden. Nicht als händischer Export, den ich irgendwann vergesse, sondern als Routine, die auch dann läuft, wenn ich gerade andere Dinge im Kopf habe.
Damit liegt eine vollständige Kopie in meiner Hand, aus der ich jederzeit klonen kann, unabhängig davon, was mit meinem GitHub-Konto oder dem Dienst passiert. Das ist kein Schutz vor jedem denkbaren Datenverlust, aber es entfernt eine wichtige Abhängigkeit.
Im ersten Abschnitt kläre ich, warum ich diesen Umweg überhaupt gehe. Danach bauen wir den Ablauf Schritt für Schritt mit Gickup, Docker und Forgejo auf.
Warum ein eigenes Backup für […]

Wenn Docker schneller als das NAS ist

Am Morgen meldete mein Backup-Tool einen Fehler, und zwar bei allen GitHub-Repositories, die es in meine selbst gehostete Forgejo-Instanz spiegeln sollte. Im Log standen ERR pkt-line 3: EOF git=push und anschließend Exiting with status=1. Mein erster Verdacht fiel auf das Tool-Image, das ich kurz zuvor aktualisiert hatte. Plausibel, schnell gedacht und komplett daneben.
Die eigentliche Ursache lag eine Schicht tiefer. Forgejo speichert seine Repositories auf der NAS, die per NFS in den Container gemountet wird. Mein Docker-Host bootete um 04:06:14, der Forgejo-Container startete um 04:06:45. Die NFS-Mounts waren erst ab 04:07:06 aktiv, der letzte sogar erst um 04:07:16. Docker war also schneller als die NAS.
Das ist eine ungünstige Reihenfolge, weil Docker Bind-Mounts beim Containerstart auflöst und fehlende Quellverzeichnisse selbst anlegt. Existiert der Mountpunkt zu diesem Zeitpunkt nur als lokales Verzeichnis, bindet Docker genau dieses leere Verzeichnis ein. Wenn NFS später erscheint, sieht der Host zwar die echten Daten, der Container bleibt […]

llama.cpp in Docker unter WSL2 mit CUDA

In diesem Guide zeige ich dir, wie ich einen lokalen, OpenAI-kompatiblen llama-server in Docker unter WSL2 mit CUDA-Beschleunigung einrichte, und nehme dich dabei vom grundlegenden Aufbau bis zum ersten funktionierenden Request mit.
Am Ende läuft ein llama-server im Container, der über WSL2 die GPU nutzt, mit genau einem Slot, also -np 1, und mindestens 128k Kontext. Ich brauche diese Größe aus eigener Erfahrung, weil ich einen Coding-Agenten wie OpenCode damit laufen lasse: Bei kleineren Kontexten kommt es zu häufigen Compactions, was das Arbeiten mühsam macht. Ein größerer Kontext wäre schön, passt aber in meinem Setup nicht mehr in den VRAM. Das Setup ist für einen einzelnen lokalen Arbeitsplatz gedacht, nicht für einen Server, an dem mehrere Nutzer gleichzeitig ihre Anfragen stellen.
Den fertigen Endpoint kann jeder Client ansprechen, der die OpenAI-kompatible API versteht, während die Modelle lokal auf deiner eigenen Maschine laufen und keine Cloud benötigen. Der lange Kontext ist dabei kein […]

Wie ich Spotify auf jeder Alexa in Home Assistant starte

Ich höre zu Hause Musik über Spotify Premium und nutze als Abspielgeräte überwiegend Alexa-Geräte von Amazon.
Ich wollte, dass meine Tochter ihre Lieblingslieder selbst starten kann, ohne ein Handy oder einen Bildschirm bedienen zu müssen. Eine NFC-Karte an den Leser halten, und die Musik läuft: eine Art Tonie-Box, nur selbst gebaut. Der Leser basiert auf einem ESP32-Mikrocontroller. Ich habe ihn mit dem ESPHome Builder nach der Vorlage von adonno/tagreader aufgebaut.
Der naheliegende Ansatz in Home Assistant ist die offizielle Spotify-Integration zusammen mit media_player.play_media. Für einen Kaltstart reicht das aber nicht. Mit der Integration lässt sich play_media erst sinnvoll verwenden, wenn auf dem Spotify-Player bereits etwas läuft. Soll ein bestimmter Song, eine Playlist oder ein Podcast aus dem Stand starten, greift dieser Weg zu kurz. Das ist keine Fehlkonfiguration, sondern eine Einschränkung der Integration und ihres aktuellen media_player-Verhaltens.
Die Lösung ist ein kleines Python-Skript. Es fragt die Spotify-Web-API nach den verfügbaren Spotify-Connect-Geräten, sucht die […]

code-bude.net
Datenschutz-Übersicht

Diese Website verwendet Cookies, damit wir dir die bestmögliche Benutzererfahrung bieten können. Cookie-Informationen werden in deinem Browser gespeichert und führen Funktionen aus, wie das Wiedererkennen von dir, wenn du auf unsere Website zurückkehrst, und hilft unserem Team zu verstehen, welche Abschnitte der Website für dich am interessantesten und nützlichsten sind.