Moin! Das hier ist meine Werkbank im Netz – privat, nerdig, ehrlich.
Hier landet alles, was mir vor die Lötspitze, den Paketmitschnitt oder die Shell kommt. Kein Showroom, sondern Notizen, Skizzen und Lösungen, die bei mir reproduzierbar funktionieren.
Was dich hier erwartet
- Elektronik & Reparieren: messen, löten, wiederbeleben – knapp dokumentiert zum Nachbauen (Arduino/ESP32, RasPi, Kleinzeug).
- Systeme & Netze: FreeBSD/Linux, ZFS & Backups, HA/Load‑Balancing, Virtualisierung, Container/Kubernetes.
- Mail & Security: SPF/DKIM/DMARC, Postfix/Dovecot, Rspamd; Checks, PoCs, pragmatische Fixes.
- Security‑Notizen: defensiv, verantwortungsvoll, reproduzierbar – ohne Zirkus.
- Blog & Bilder: kleine Gedanken, schnelle Notizen und eine Galerie für Kram, der nicht in die Shell passt.
Hausordnung
Werkbank, nicht Helpdesk. Ich helfe gern beim Selbermachen und gebe Hinweise – aber ich bin kein „Admin auf Zuruf“ und keine günstige Unternehmens‑Alternative.
Doku lieber knapp als geschwätzig: ein funktionierendes diff schlägt fünf Absätze Marketingdeutsch.
Warum das Ganze – Selbst‑Hosting
Ich hoste und betreibe das meiste selbst: aufwändig, aber lehrreich. Privat gut machbar und ideal, um Dinge wirklich zu verstehen – auch mal Draft‑RFCs auszuprobieren – und die Datenhoheit zu behalten. Große Managed‑Systeme sind im Business oft sinnvoll; hier geht’s bewusst um Verstehen & Experimentieren.
Cloud, Automatisierung & AI
Cloud ist Gegenwart; Handarbeit ersetze ich durch Automatisierung – deklarativ, versioniert, beobachtbar.
AI nutze ich als zusätzlichen Sensor und Beschleuniger (Prototypen, Tests, Review, z. B. Signale im Mail‑Stack). AI entscheidet nie allein – Mensch schaut noch drüber, bevor’s live geht.
Security ist der rote Faden
Risiken sichtbar machen, sauber nachstellen, fair kommunizieren – Responsible Disclosure statt Drama.
Security‑Kontakt & PGP‑Key stehen in der security.txt und auf der Kontakt‑Seite.
Nerd‑Fu
Hier kannst du seltene Techniken in freier Wildbahn sehen – je nach Client u. a.:
- HTTP/3 / QUIC (UDP) neben HTTP/2/1.1 (TCP),
- post‑quantum‑fähige, hybride TLS‑Handshakes (z. B. X25519 + ML‑KEM/Kyber),
- DNSSEC mit Spezial‑RRs wie SSHFP, SRV und TXT,
- DANE/TLSA sowie MTA‑STS/TLS‑RPT,
- eine .onion‑Variante dieser Seite.
- Viel Spaß beim Suchen & Finden, da ist noch etwas versteckt. 🙂
Warum eigentlich „Kernel-Error“?
Wie ist „Kernel-Error“ eigentlich entstanden? Das war Ende der 90er, etwa ’97, als ich mit Debian 1.3 „Bo“ herumhantierte. Ich hatte damals einen CD-Brenner bekommen, und unter Linux war das Brennen damals noch eine kleine Bastelei. IDE-Brenner wurden nicht direkt unterstützt, der Kernel brauchte eine Art SCSI-Brücke. Man musste den Kernel patchen, ein bisschen fummeln, und das Ganze irgendwie ans Laufen kriegen. Für mich, jung und grün hinter den Ohren, war das damals alles andere als trivial.
Google, wie wir es kennen, gab’s noch nicht – das Ding hieß damals BackRub, und Wikipedia oder YouTube waren ferne Zukunftsmusik. Es gab keine Übersetzungstools, kein ChatGPT, nichts. Also lief alles über 56k-Modem, PS-Telefonnetz und Handarbeit: Man rief Bekannte an, las jede manpage, übersetzte mit Krüppel-Englisch. Und genau so kam’s dann, dass ich meinen Bekannten ständig anrief, sobald der Kernel mal wieder gestolpert war.
Irgendwann hob er ab und meinte nur: „Ach, da ist bestimmt wieder der Kernel-Error.“ Der Spitzname blieb hängen, wurde im Freundeskreis zum Running Gag, und so bin ich eben „Kernel-Error“ geworden. Am Ende war ich schnell genug, mir die Domain zu holen.
Kontakt
Am liebsten per E‑Mail (PGP willkommen). Mehr Wege und der Schlüssel stehen auf der Kontakt‑Seite.
Kaffee holen, scrollen – und bitte nicht übers Kabel stolpern