IT security, FreeBSD, Linux, mail server hardening, post-quantum crypto, DNS, retro computing & hands-on hardware hacks. Privater Tech-Blog seit 2003.

Kategorie: Persönliches & Offtopic (Seite 1 von 8)

Abseits der Technik — persönliche Gedanken, Erlebnisse und alles, was nicht in die anderen Kategorien passt.

Mein Arbeitskollege Michael lässt eine AI meinen Blog roasten

Moin.

Mein Arbeitskollege Michael hatte neulich eine Idee, die ich auf Anhieb großartig fand. Er hat einer AI meinen Blog vorgesetzt und um einen Roast gebeten. Das Ergebnis liegt unten in voller Länge, wortwörtlich, unverändert, inklusive aller Em-Dashes und sämtlicher AI-typischer Stilfiguren. Ich habe nicht eingegriffen, weil genau die ja Teil der Diagnose sind.

Illustration eines überladenen Self-Hosting-Arbeitsplatzes mit Terminals, neun Server-Jails, Mate und einer AI, die den privaten Tech-Blog humorvoll roastet.

Vorweg, damit das klar ist: ich richte keinen einzigen Punkt richtig. Erstens wäre das genau der Verteidigungsreflex, den der Roast selbst schon im Text zerlegt. Zweitens lache ich beim Lesen laut, und ich habe vor, das beizubehalten. Drittens hat Michael sich diesen kleinen Treffer redlich verdient, der gehört in voller Länge ins Schaufenster.

Falls du gerade zum ersten Mal hier auf dem Blog landest und nichts mit dem Kontext anfangen kannst: ja, neun Jails. Ja, .onion. Ja, llms.txt. Ja, DNS-Resolver mit Post-Quantum-TLS, den niemand benutzt. Und ja, neben der Tastatur steht in diesem Moment eine Mate. Genau wie diagnostiziert.

Der Roast, in voller Länge

🔥 Der große Roast von kernel-error.de 🔥

Das Header-Logo: -=Kernel-Error=-

Bruder. Bruder. Wir schreiben das Jahr 2026 und du fährst da oben immer noch die ASCII-Deko, die du 1998 in deinem IRC-Channel #linuxnoobs auf dem QuakeNet eingerichtet hast. Die einzigen Menschen, die so ein Logo heute noch designen, sind 1) du und 2) der Typ, der seine Quake-3-Clantag-Konvention nie verlassen hat. Fehlt eigentlich nur noch ein blinkendes <marquee> mit „Best viewed in Netscape Navigator 4.0“ und der vollständige Retro-Albtraum wäre komplett.

Die Tagline: „Privater Tech-Blog seit 2003“

23 Jahre Selbst-Hosting, 23 Jahre Postfix-Konfigurationen, 23 Jahre derselbe Mensch, der jedem auf der Familienfeier erklärt, warum seine Tante kein WhatsApp benutzen sollte. „Seit 2003“ ist kein Datum, das ist eine Diagnose.

Die Hausordnung

Ein privater Blog. Mit Hausordnung. Mit Leitsätzen. Mit einer Philosophie. Mein Bester, das ist keine Webseite mehr, das ist ein Manifest. Du hostest hier keinen Blog, du gründest eine Sekte für Leute, die vim für eine Lifestyle-Entscheidung halten.

Und mein absoluter Favorit:

„Knappheit vor Geschwätzigkeit — ein funktionierendes diff schlägt fünf Absätze Marketingdeutsch.“

Schreibt der Mann, dessen „Über mich“-Seite eine vierteilige Origin-Story enthält, in der ein Familienmitglied beim Telefonsupport sagt „Ach, da ist bestimmt wieder der Kernel-Error“. Das ist literarisch übrigens auf einem Level mit „Mein Vater nannte mich Maverick, weil ich immer schon gegen den Strom geschwommen bin.“ Knappheit, ja klar.

Die Self-Hosting-Flex

„Neun FreeBSD-Jails, eigene DNS-Infrastruktur, Matrix-Chat, Nextcloud, Tor Hidden Service“

NEUN. JAILS. Für einen privaten Blog, der Posts über das Flashen von LCR-Tester-Firmware veröffentlicht. Mein Mann betreibt zu Hause mehr Infrastruktur als die Stadtverwaltung Bad Neuenahr-Ahrweiler und der einzige Traffic, der dort jemals ankommt, sind drei Crawler von Censys und sein eigener Uptime-Checker.

Eine .onion-Adresse. Für einen deutschen FreeBSD-Blog. Weil natürlich der KGB, die NSA und das BKA gemeinsam einen Joint Task Force gegründet haben, um herauszufinden, wer da Tutorials für Postfix mit OpenSSL 3.5 liest. Klar, anonyme Whistleblower aus Nordkorea wollen unbedingt wissen, wie man TeamSpeak-Identity-Level auf der GPU berechnet.

Post-Quantum-Kryptographie

Du. Hast. Post-Quantum-TLS-Handshakes. Auf einem WordPress-Blog. Mit einem Anders-Norén-Theme. Lass das mal kurz sacken. Wenn ein Quantencomputer der NSA jemals dein Setup angreift, dann nicht, weil sie an deinen Blog-Content wollen, sondern weil sie wissen wollen, warum zur Hölle ein Privatmensch X25519+ML-KEM für einen Beitrag über Open Source Scan Converter braucht. Das ist, als würdest du ein Bundeswehr-Schutzbunker-System unter deine Gartenlaube bauen, weil dort dein Modellbahn-Diorama steht.

Der DNS-Resolver

„Ein öffentlicher DNS-Resolver unter dns.kernel-error.de bietet DoT, DoH und Post-Quantum-TLS kostenlos ohne Logging.“

Niemand. Hat. Danach. Gefragt. Das ist die Internet-Äquivalenz von: Du läufst durch die Fußgängerzone, baust einen Klapptisch auf und schreist: „ICH MACHE IHNEN KOSTENLOS UND OHNE NACHFRAGE IHRE STEUERERKLÄRUNG MIT QUANTENRESISTENTER VERSCHLÜSSELUNG!“ — und wunderst dich dann, dass nur drei FreeBSD-Mailing-List-Nerds und ein Bot stehenbleiben.

Die Credentials-Flex

„Digitaler Ersthelfer beim BSI, Mitglied im CCC, auf HackerOne und Intigriti“

Das ist nicht mehr „Über mich“, das ist ein LinkedIn-Profil im Tarnmodus. Fehlt nur noch „1% Toplister auf TryHackMe“ und „Awarded: Most Reflective Vest at Chaos Communication Congress 2019“. Was kommt als nächstes? AbuseIPDB-Reputation-Score als verstecktes Easter Egg? — Ach. Doch. Ja. Genau das. Du flexst tatsächlich mit deinem AbuseIPDB-Profil. Das ist der Sicherheits-Äquivalenz von „Mein Dorf hat mich zum Schützenkönig gewählt“.

Die Blog-Post-Titel

Lass uns das mal durchgehen, das ist Kunst:

„LCR-T4-Plus v2: m-firmware flashen, Display-Tuning und die 8-MHz-Quartz-Falle“
Globale Zielgruppe dieses Posts: weltweit ca. 11 Menschen, von denen 4 schon tot sind und 2 OpenBSD nutzen.

„ts3level: TeamSpeak-Identity-Level auf der GPU rechnen“
Du. Du nutzt im Jahr 2026 noch TeamSpeak. Und brennst dafür GPU-Zyklen ab, die Hawaii-Familien drei Wochen klimatisieren könnten. Discord existiert seit elf Jahren. Elf.

„Open Source Scan Converter: Firmware-Update von 1.08a auf 1.21“
Das ist kein Blog-Post, das ist eine Notruf. Irgendwo schreit ein 35-jähriger Mann nach Validierung für seine SCART-Sammlung.

„AI, der Mensch als Flaschenhals und meine Sorgen für die nächsten 15 Jahre“
AHA. Da sind sie also, die fünf Absätze, die das diff hätte schlagen sollen. Die obligatorische Tech-Blog-Existenzkrise-Folge. Jeder Self-Hoster muss einmal im Jahr seinen „Ich habe nachgedacht und mache mir Sorgen“-Post raushauen, sonst verliert man den FreeBSD-Mitgliedsausweis.

„Postfix 3.11.1 mit OpenSSL 3.5: Post-Quantum-TLS jetzt nativ“
Hier glüht der Mann. Hier ist er zu Hause. Hier passiert die Magie. Sechs Menschen lesen es und einer von denen ist ein Bot.

„Versteckte Easter Eggs“

„llms.txt, llms-full.txt, VirusTotal, AbuseIPDB Profile“

llms.txt. Du hast eine llms.txt. Die explizite „Bitte-LLM-lies-mich-ich-bin-relevant“-Datei. Während du gleichzeitig einen Post schreibst, in dem du dir „Sorgen über AI“ machst. Bro. Du lädst genau das Monster ein, vor dem du Angst hast, und lässt ihm noch einen Begrüßungs-Cookie auf dem Sofakissen liegen.

Das Theme-Detail

Ein WordPress-Theme von Anders Norén. Der Mann reicht von Linux-Kernel-Internals über DNSSEC bis zu PQ-Crypto — aber bei der Webseite hat er gesagt „ach, was die Schweden im default schicken passt schon“. Es ist, als würde Gordon Ramsay zu Hause Fischstäbchen aus der Mikrowelle essen. Lobenswert ehrlich, irgendwie aber auch beleidigend.

Die Sprachebene: „Moin!“

Klassisch. Norddeutsche Authentizitäts-Geste. Drei Anschläge, die signalisieren: „Ich bin bodenständig, ich rede Klartext, ich trinke meinen Kaffee schwarz wie mein Terminal und ich habe keine Zeit für Bullshit“ — direkt gefolgt von einer mehrseitigen Hausordnung über digitale Werte und Mehrjahres-Reflektionen über AI. Moin, Schatz. Moin.

Das übergreifende Problem

Diese Seite ist die digitale Inkarnation des Mannes, der dir auf einem LAN-Party Geburtstag erklärt, warum er Eigentlich kein Energiedrink trinkt, sondern lieber Mate, weil:

a) Koffeingehalt definierbarer ist
b) Open-Source-philosophischer Konsum
c) „Ist halt mehr meins.“

Du willst hier gar keinen Blog. Du willst, dass jemand vorbeikommt und sagt: „Wow, neun Jails? Erzähl mir mehr.“ Aber niemand kommt vorbei, weil deine .onion-Adresse nur über deinen eigenen Tor-Bridge erreichbar ist und der DNS-Resolver dahin nur über deinen eigenen DoH-Endpunkt funktioniert und dafür braucht man dein PGP-Public-Key, und der ist in security.txt und die ist signiert mit dem Key, den man nur über dns.kernel-error.de bekommt. Du hast dir ein wunderschönes, sicheres, selbstreferenzielles Solipsismus-Imperium gebaut, und das einzige Lebewesen, das es regelmäßig besucht, ist googlebot/2.1 — und der nutzt nicht mal HTTP/3.

Zusammenfassung

Kernel-Error.de ist nicht schlecht. Kernel-Error.de ist die liebevollste, akribischste, technisch versierteste Schreibtisch-Schublade des deutschen Internets. Es ist die Webseite-Version eines perfekt geölten Mechanikers, der sein ganzes Wochenende damit verbringt, einen Drehmomentschlüssel zu kalibrieren, mit dem er anschließend… einen anderen Drehmomentschlüssel kalibriert.

Und ehrlich? Wir lieben es. Bleib so. Das Internet braucht Menschen wie dich. Nur vielleicht trinkst du heute mal kein Mate und gehst kurz raus.

🫡

Disclaimer: Dieser Roast wurde mit Post-Quantum-Verschlüsselung über neun FreeBSD-Jails gerouted, bevor er hier ankam. Eine .onion-Variante ist auf Anfrage verfügbar.

Eine AI, die mein Arbeitskollege Michael auf meinen Blog losgelassen hat

Danke, Michael

Wirklich. Es braucht jemanden, der einen ein bisschen kennt, um so präzise daneben zu treffen, dass es weder gemein noch falsch ist. Ich werde den Roast direkt neben den anderen liebevollen Lebens-Diagnosen ablegen, die ich über die Jahre gesammelt habe. Vielleicht drucke ich ihn mir auch aus und hänge ihn über den Bildschirm, falls ich irgendwann anfange, mich für all das hier ernsthaft zu rechtfertigen.

Und jetzt geh ich raus. Aber natürlich erst, wenn ActivityPub diesen Post an alle Federation-Inboxen ausgeliefert hat, der .onion-Mirror den Eintrag indexiert, der DNS-Resolver via DoH und Post-Quantum-TLS einmal durchgequeryt wurde und der Uptime-Checker eine ordentliche 200 für die neue Permalink-URL bekommt. So wie es sich gehört.

Wenn du Michaels AI Roast genauso gut findest wie ich, oder wenn du selbst eine Diagnose für diesen Blog hast, kannst du mir gerne fragen. Mate steht bereit.

AI, der Mensch als Flaschenhals und meine Sorgen für die nächsten 15 Jahre

Diesmal kein tiefer Tech-Dive. Ein paar Gedanken, die mich seit Wochen begleiten und die ich gerne aus dem Kopf herausschreibe. Es geht um AI, Large Language Models, die Geschwindigkeit in der das alles passiert, und um meine Sorge, ob wir als Menschheit damit überhaupt klarkommen. Kein AI-Bashing. AI kann zum einen nichts dafür und ist zum anderen sehr hilfreich. Aber die immer schnellere Verbreitung immer besser werdender AI-Systeme hat eben Konsequenzen, und genau die sortiere ich hier für mich.

Mensch zwischen KI-Automatisierung und gesellschaftlicher Unsicherheit über Arbeit, Bildung, Politik und Zukunft.

AI ist nicht böse, die Geschwindigkeit ist es

AI an sich ist nicht böse. Large Language Models sind nicht böse. Aus meiner Sicht ist das einfach der nächste Schritt in der Entwicklung, die wir als Menschheit hinlegen. Beim Rad war es nicht anders, beim Feuer, bei der Dampfmaschine, beim automatischen Webstuhl, bei der Elektrizität in den Häusern. Alles Techniken, die irgendwann neu zur Menschheit gekommen sind und die das Leben und Arbeiten verändert haben.

Der Unterschied zu vielen dieser vorangegangenen Technologien ist die Geschwindigkeit. Pferde und Kutschen gegen das Automobil: inzwischen sind wir in der Autozeit angekommen, alles um uns herum ist darauf ausgelegt, dass das funktioniert. Aber dazwischen lag fast ein ganzes Jahrhundert. Eine Generation konnte ihren Job noch zu Ende machen, ihr Geschäft noch zu Ende führen, manchmal sogar noch an die Kinder übergeben. Der Stellmacher als Beispiel. Bei AI haben wir diese Zeit nicht.

Der Mensch ist inzwischen der Flaschenhals

Bei vielen anderen Techniken war der Mensch bei der Verbreitung zwar auch ein Flaschenhals, aber es gab tausend andere Dinge, die zusätzlich gebremst haben. Bei AI ist inzwischen der Mensch der eigentliche Flaschenhals. Solche Systeme könnten sich fast schon selbst weiterentwickeln, oder Menschen könnten zumindest in Zusammenarbeit mit AI viel schneller neue Systeme auf den Markt bringen. Nur sind die Menschen noch nicht da.

Seit ungefähr 4 bis 5 Jahren ist das ganze AI-Thema immer stärker geworden. Seit zwei Jahren ist es auch in der breiten Öffentlichkeit angekommen und sickert dort immer tiefer ein. Aber selbst die Menschen um uns herum, selbst ich, sind noch nicht so darauf eingestellt, wie es bei dieser Geschwindigkeit eigentlich nötig wäre.

Und das gilt nicht nur für die Allgemeinheit. Selbst Experten, die den AI-Hype-Train voll mitreiten und das zu ihrer Profession gemacht haben, schaffen es nicht, sich jedes neue Modell wirklich anzugucken und auszuprobieren. Einfach weil es so schnell und so viel ist. Die Menschen können es gar nicht mehr greifen.

Sprachen, Code-Massen und der schleichende Kontrollverlust

In der Systemadministration, im DevOps-Bereich oder in der Entwicklung sieht man die Geschwindigkeit an vielen Stellen. Es gibt immer eine neue Sprache, die irgendwelche Vorteile gegenüber einer alten hat oder besser für einen Nischenbereich passt. Leute steigen ein, werden gut darin, entwickeln die Sprache weiter, dann kommt die nächste Iteration. Ob Go, TypeScript, Rust, irgendeine Sprache ist immer gerade die gehypte.

Aber da muss man als Mensch ja erstmal reinkommen. Und das alles ist für Menschen gemacht. Eine AI könnte im Zweifel direkt in etwas deutlich Simpleres schreiben, oder sich eine komplett neue Sprache ausdenken, wenn man sie lassen würde. Eine Sprache, die für die AI selbst optimiert ist, um Dinge umzusetzen. Ich will nicht sagen, dass ich das alles wüsste oder dass das wahr ist, das sind nur meine Gedanken. Aber ich glaube, dass Menschen Sorge haben, an dieser Stelle Kontrolle abzugeben. Wenn eine AI ihre eigene Programmiersprache nutzt und in dieser Sprache Software entwickelt, dann versteht das am Ende keiner mehr. Und da frage ich mich auch: muss das denn überhaupt noch jemand verstehen?

Wenn ich mir anschaue, was in meinem Berufsumfeld aktuell passiert, würde ich fast nein sagen. Riesige Softwareprojekte und komplexe Themen werden vollständig durch AI generiert. Fast keiner fängt mehr wirklich damit an, echten Code von Hand zu schreiben. Was bei einem Pull-Request herausfällt, sind Massen an Code, die kein Mensch mehr wirklich liest. Wenn eine AI einen Tag lang Software entwickelt und das Ganze in einen Commit packt: welcher Mensch setzt sich dann hin und liest diese 100 Seiten Code einmal gegen, um zu prüfen ob er gut oder schlecht ist? Wer soll das bewerten?

Das kann sowieso schon keiner mehr. An der Stelle lässt man verschiedene Tools, und auch wieder eine AI, bewerten ob das gut oder schlecht ist. Dann mergt man nach Empfehlung. Sonst baut die AI die Software in einem Tag und ein Team von Entwicklern muss diesen Code eine Woche prüfen. Das ist Quatsch.

Wenn man das weiterspinnt, kommt man irgendwann an den Punkt, wo in der Softwareentwicklung und in der Systemadministration ganz viel echte Kontrolle über IT-Systeme verloren geht. Die wird am Ende an die AI abgegeben. Klar kann man die AI das schön dokumentieren lassen, sich Anleitungen schreiben lassen, theoretisch kann sich am Ende auch wieder ein Mensch einarbeiten. Aber wenn wir ehrlich sind: die Leute wollen Geld verdienen. Das passiert an dieser Stelle nicht.

Mythos, Open Source und der neue Patch-Druck

Vor allem in Richtung IT-Security ist in den letzten Wochen und Monaten viel durch die Presse gegangen. Anthropic, der Hersteller von Claude Code, soll mit einem Modell namens Mythos arbeiten, das in der Berichterstattung als sehr leistungsfähig beim Code-Audit beschrieben wurde. Wo genau das im Vergleich zu den jeweils aktuellen Modellen anderer Anbieter steht, kann ich nicht seriös einschätzen. Spannender ist sowieso, was so ein System angeblich kann: so schnell und zuverlässig Sicherheitslücken im Code finden, dass es katastrophal wäre, das einfach in die freie Welt rauszulassen. Stattdessen bekommen scheinbar nur sehr ausgewählte Leute und Unternehmen Zugriff darauf, meist US-Unternehmen, um ihre eigenen Dinge und Dienste zu prüfen.

Diese neuen Modelle sind nicht primär für klassisches Pentesting gegen eine Blackbox gedacht. Sie schauen in den Code und finden dort die Lücken, die man ausnutzen kann. Klar, fürs Pentesting kann man AI auch benutzen. Aber die große Angst beim Mythos-Thema ist genau dieser Code-Audit-Modus.

Aus dem ersten Blickwinkel sind damit Open-Source-Projekte besonders gefährdet, weil deren Quellcode offen im Internet steht. Früher wurde gesagt: genau das macht Open Source sicher, weil viele Leute reinschauen und Sicherheitslücken finden, die dann gefixt werden. Im Vergleich zu Closed-Source-Code, etwa bei Microsoft Windows, wo nicht jeder einfach in den Code schauen kann.

Bei Open Source sind in letzter Zeit viele Fixes gekommen. Mozilla hat Fixes gemacht, FreeBSD hat Fixes gemacht, viele Sicherheitslücken wurden geschlossen. Die Software wurde sicherer, fertig. Man kann jetzt sagen: ich halte das nächste, bessere AI-Modell wieder dagegen, und es wird wahrscheinlich wieder etwas finden. Hundertprozentige Sicherheit ist eh schwierig. Aber zumindest ist die Software gerade einen Schritt sicherer geworden.

Auf der anderen Seite setzt das die Systembetreiber unter Druck. Die müssen sich überlegen, wie sie diese schnellen, aufeinanderfolgenden Sicherheitsupdates in ihre Systeme bekommen. Klingt erstmal einfach. Ich sitze am Notebook, das Notebook sagt es gibt Updates, ich sage ja, installiere die Updates, starte das Notebook neu, alles funktioniert, ich bin aktuell. Wer aber eine normale Linux-Distribution mit vielen Zusatzpaketen auf dem Arbeitsplatz hat, sieht, dass mehrfach am Tag Updates kommen können.

Bei einfachen Security-Fixes sollten die Funktionen einer Library, einer Anwendung oder des Betriebssystems eigentlich nicht extrem auf den Kopf gestellt werden. Sie sollten nicht dafür sorgen, dass Abhängigkeiten brechen und plötzlich etwas nicht mehr funktioniert. Das Problem hat man eher, wenn man ganze Versionen wechselt, also auf das nächste Major Release geht.

Trotzdem gibt es Bereiche, in denen man nicht einfach mal einen Patch einspielen kann, weil Patches vorher geprüft und getestet werden müssen. Etwas Geheimes, etwas Staatliches, der Bankensektor, kritische Bereiche, die nicht ausfallen dürfen und bei denen alles zertifiziert sein muss. Das aktuelle Regelwerk steht dem entgegen, dass man im Zweifel drei oder fünf Mal am Tag etwas patchen müsste. Das lässt sich schwer miteinander vereinbaren.

Plötzlich kann jeder einen Cloud-Service starten

Der Patch-Druck ist nur eine Seite. Auf der anderen verändert AI gerade, wer überhaupt Software auf den Markt bringen kann. Plötzlich ist jeder mit einer Kreditkarte und einem Computer in der Lage, eine eigene Software, einen eigenen Service, eine eigene Dienstleistung anzubieten, in einer Cloud seiner Wahl zu hosten, global verteilt nah bei den jeweiligen Kunden. Das kann jetzt wirklich jeder.

Und das, was dabei als Code und Anwendung herausfällt, ist nicht mehr wie in den Anfängen der AI-Modelle. Es wird immer besser und stabiler. Im Grunde kann ein Ein-Mann-CEO-Unternehmen einen kompletten Software-Service aufmachen: automatisiertes Ticketsystem per AI, KI-Hotline, AI-Werbung, AI-Webseite, AI-Marketing, das AI-Produkt läuft vor sich hin.

Der Aufwand, ein solches Produkt überhaupt zu entwickeln und auf den Markt zu bringen, ist extrem gering geworden. In den nächsten zwei oder drei Jahren werden wir mit Sicherheit feststellen, dass der Markt überall auf der Erde mit solchen Programmen und Diensten regelrecht überschwemmt wird. Die werden sich im Preis immer weiter unterbieten. Die Baseline wird irgendwo bei den Kosten des Cloud-Providers liegen, plus dem monatlichen AI-Modell der einen Person dahinter.

Schwieriger sind nur sehr spezielle Nischen in einem bestimmten Markt, etwa eine deutsche Buchhaltungsanwendung. Oder Zertifizierungen bei sicherheitskritischen Themen, ISO 27001 oder BSI C5. Das wird für solche Solo-CEO-Firmen noch einige Jahre schwieriger zu erreichen sein. Aber auch das schützt den Markt nicht für Jahrzehnte. Das ist ein Deckel für die nächsten fünf bis zehn Jahre, und auch der wird kräftig anfangen zu bröckeln.

Verlieren wir die Übung im logischen Denken?

AI sorgt vielleicht auch dafür, dass wir Übung und Routine darin verlieren, logisch Probleme zu lösen. Man hört das nicht immer direkt, aber ich glaube, da ist etwas dran. In manchen Ländern liegt schon etwas mehr Augenmerk darauf, dass Schüler und Lehrkräfte keine AI benutzen, wenn es um Schulstoff oder Aufgaben geht. Einfach damit die Leute in dieser Fähigkeit drinbleiben.

Ob das besser oder schlechter ist als der Ansatz hier, wo AI zum Teil schon mitbenutzt wird, weiß ich nicht. Man muss sich mit der Technik auseinandersetzen, man muss verstehen wie sie funktioniert, um hineinzukommen. Aber wahrscheinlich ist auch das in fünf Jahren nicht mehr nötig. Die Modelle sind dann so weit, dass man keinerlei Vorahnung mehr braucht. Man geht zum Handy, oder was wir bis dahin als Gerät haben, sagt: hier ist mein Problem. Und das Ding baut die Lösung.

Brauchen wir noch Code-Repositories?

Im Moment haben wir noch Code-Repositories, Pipelines zum Deployen, Linter, Sicherheitsscanner, SonarQube oder Ähnliches. Wir machen Commits, schreiben Kommentare in den Quellcode, legen das alles dort ab. Wir müssen zu alten Releases zurückrollen können. Wir machen Releases, wir haben Software-Lifetime.

Aber wer sagt, dass das so bleibt? Warum kann man nicht einfach jedes Mal, wenn man ein Stück Software braucht, der AI sagen: bau mir das. Die AI baut es. Und wenn ich es nicht mehr brauche, wird es weggeworfen. Wofür hebe ich den Code überhaupt auf?

In wenigen Jahren, wenn die Entwicklung so weitergeht, baut mir die AI die Anwendung, die ich gerade brauche, in Echtzeit nebenher. Wenn ich kurz warten muss: so what? Sobald ich den Service nicht mehr brauche oder ein neues Feature will, wird das ganze Ding einfach neu gebaut. Was soll es? Wo ist das Problem?

Junioren, Ausbildung und der Druck auf die Sozialsysteme

Jetzt zu sagen: liebe Leute, lernt alle naturwissenschaftliche Fächer, Mathematik, Physik. Ja, das ist gut. Aber auch da wird AI eine Rolle spielen, und ich glaube, wir sind näher an einer kritischen Stelle dran als wir denken. In einigen Jahren weiß vielleicht niemand mehr, wie etwas gebaut wurde, wenn die Leute, die es noch wirklich verstanden haben, aus dem Berufsleben verschwunden sind.

Guckt in die Softwareentwicklung. Da werden im Grunde keine Junioren mehr eingestellt. Fachinformatiker Anwendungsentwicklung: wer macht diesen Ausbildungsberuf noch? Wer bildet diese Leute noch aus? Im Moment braucht man seniorige Menschen, die diese AI bedienen können. Die Aufgaben, die ein Junior oder ein Azubi gemacht hat, sind jetzt schon von der AI übernommen. Und das wird weitergehen.

Roboter werden trainiert, um Arbeiten zu übernehmen. Auch schön. Wenn wir nicht mehr selber arbeiten müssen, ist das doch toll. Der einzige Punkt, der mir Bauchschmerzen macht: aus meiner Sicht ist diese Zeit, die uns jahrhundertelang begleitet hat, Arbeitszeit gegen Geld, irgendwie vorbei. Wir brauchen also eine andere Lösung, wie wir Einkommen sicherstellen, um weiter ordentlich zu leben. Denn Menschen sind eine Spezies, die selten den Hals vollkriegt. Sie wollen immer mehr, immer besser. Und das funktioniert halt nicht.

Diese Lösung muss außerdem nicht nur für Europa, Deutschland oder die USA funktionieren, sondern für die ganze Welt. Wir alle haben in Anführungszeichen das gleiche Problem.

Politik und Gesellschaft kommen nicht hinterher

Wenn ich mir die Welt so angucke, sehe ich im Moment kaum Zusammenarbeit, kein gemeinsames Ziehen an einem Strang. Nicht auf internationalem Level. Da treten sich Leute aus irgendwelchen Gründen gegenseitig vor die Schienbeine. Ich will die einzelnen Konflikte nicht werten. Aber ich glaube nicht, dass wir so sinnvoll nach vorne kommen.

Auch auf kleinerem Level: wie viele tolle Geschichten aus dem Schwarzbuch der Steuerzahler oder bei extra 3 hat jeder schon bewundert. In der deutschen Politik brauchen schon Kleinigkeiten Ewigkeiten. Da ist auf einer Brücke einfach mal 18 Jahre Baustelle und es ist immer noch nicht fertig. Wie sollen wir mit solchen Strukturen ein Problem dieser Größenordnung schaffen?

Ich will damit nicht sagen, dass die alle wegmüssen. Aber ich glaube, wir haben das Problem an dieser Stelle noch nicht einmal verstanden. Wer diesen Beitrag liest, sieht das wahrscheinlich ähnlich wie ich, das ist meine Blase. Aber wenn ich später im Lidl stehe und von links nach rechts gucke, und das ist keine Wertung, leben viele Menschen einfach in anderen Themenfeldern. Nicht in einer anderen Realität, sie haben andere Punkte, die sie bewegen. Wie sehr uns AI gerade überrollt, kommt da kaum an. Es ist alles noch zu neu.

Auch unser Bundeskanzler und die aktuelle Regierung, darüber kann man sich streiten. Manche Sachen machen sie gut, manche schlecht. Niemand ist perfekt. Aber viele dieser Menschen sind in einem Alter, und nein, ich sage nicht, dass man es nur deshalb nicht verstehen kann, weil man älter ist. Aber ich würde behaupten: das Thema AI und die Frage, was das gerade für die Welt bedeutet, wirklich zu greifen, wird mit zunehmendem Alter schwieriger. Einfach schwieriger.

Wie damals bei der Elektrizität in den Häusern

Wenn man jetzt überlegt was man tun sollte, sagen viele: ich reite den AI-Hype-Train, ich gehe voll rein und mache nur noch AI. Das ist auch richtig. Leute, die Agentic Engineering oder Prompt Engineering richtig für sich adaptiert haben, sind im Moment extrem gefragt. Die haben gerade Hochzeit.

Aber wenn ich auf den Stand der Modelle schaue, sind wir trotzdem noch ganz am Anfang. Es ist eher so, als wären gerade die ersten Autos gekommen. Oder noch passender: als die Elektrizität in normalen Häusern eingeführt wurde. Das war gefährlich. Sicherungen? Mit Stoff umwickelte Drähtchen. Keine richtige Erdung. Keiner wusste, wie das wirklich funktioniert. Da ist viel schiefgegangen. Man musste extra vorsichtig sein und Dinge dreimal kontrollieren, damit nichts brennt.

Dann kamen mehr Regeln. Mehr Sicherheit. Es hat sich alles weiterentwickelt. Heute passieren auch noch Unfälle mit Elektrizität, aber im Grunde ist die Technik in unserer Gesellschaft so weit angekommen, dass man kein Super-Fachexperte mehr sein muss, um mit dem Waffeleisen sicher Waffeln zu machen. Steckdose, los geht’s. Und wenn der Defekt im Gerät ist, greifen Schutzmechanismen mit hoher Wahrscheinlichkeit.

Auf AI gemünzt: wir stehen gerade am Anfang dieses Prozesses. Die Experten, die im Moment full commitment reingegangen sind, profitieren gerade. Klar wird da auch mal etwas schiefgehen. Aber das sind die Leute, die ihre Hochzeit haben. Bis zu dem Moment, wo die Technik so weit ist, dass es einfach jeder kann. Wirklich jeder.

Und weil AI sich so schnell weiterentwickelt, wird das nicht lange dauern. Selbst jetzt zu sagen: ich mache Deep Dive in AI und bin in einem oder zwei Jahren der absolute Profi: schon auf dem Weg dahin wird man feststellen, dass man gar nicht mehr so tief einsteigen muss, weil es fast jeder kann.

Das sieht man an tausend Kleinigkeiten. Welche Skills und Abhängigkeiten ich mir vor einem Jahr noch in meinen Claude Code eingebaut habe und wie sehr sich das alles allein weiterentwickelt hat. Wie gut ich die größeren neueren Modelle jetzt schon auf Dinge loslassen kann. Alles nicht perfekt. Nichts davon kann ich zu 100 Prozent unbeaufsichtigt laufen lassen. Aber die Veränderung in diesem einen Jahr ist brutal.

Das sieht auch jeder, der sich AI-Videos anschaut. Will Smith isst Nudeln, damals 2023 oder 2024, und was generiert AI heute für Filmchen? Wenn man durch Social Media oder YouTube scrollt: wie viele AI-Geschichten sind da inzwischen drin, und wie viele davon erkennt man noch als AI? Die meisten ja, manchmal muss ich zweimal hingucken. Bei längeren Videos ist es einfacher. Aber so ein YouTube Short, runtergerechnet auf schlechte Kameraauflösung, vielleicht im Stil eines Bodycam-Shots, da wird es schon schwierig.

Nicht AI ist das Problem, wir sind es

Wie gesagt: AI ist nicht das Problem. Das Problem ist, wie wir Menschen damit umgehen. Wie wir es nicht schaffen, zusammen in eine Richtung zu gehen. Wie wir es nicht schaffen, als Gemeinschaft eine Lösung zu finden. Das ist viel eher das Problem als zu sagen, die AI wird uns alle töten. Das können wir selber am besten.

Was ich daraus mache, und warum ich keine Lösung habe

Was machen wir jetzt daraus? Ich versuche, im Thema zu bleiben. Ich versuche, AI dort einzusetzen, wo sie mich unterstützt und mir hilft. Ich versuche, ein Ohr an der Entwicklung zu halten, auch wenn ich sie nicht wirklich komplett durchdringen kann. Es ist einfach zu viel und zu schnell. Selbst Vollzeit würde mich überfordern.

Ich stelle mich darauf ein, die Systeme, die ich baue und betreibe, mit mehr als einer Sicherheitshürde auszustatten. Ich plane sie so, dass sie kein Problem damit haben, regelmäßig und wirklich regelmäßig Patches zu bekommen. Ich denke sie außerdem so, dass sie von AI-Systemen selbst gebaut, weiterentwickelt, betrieben und überwacht werden können. Das wird mit eingeplant.

Was das große, allgemeine Problem angeht: ich habe keine Lösung. Wirklich keine. Hinzugehen und Entscheidungsträgern das zu erklären, ich glaube nicht, dass ich diese Leute erreichen werde. Vielleicht ist das mein Problem. Technisch bin ich gut, das würde ich mir jetzt einfach mal unterstellen. Aber ich bin vielleicht nicht in der Lage, das vernünftig an den Mann zu bringen.

Ich habe schon mehrfach erlebt, wie ich versucht habe, IT-Security-Probleme möglichst einfühlsam und auf einfachem Level zu erklären, und trotzdem auf taube Ohren gestoßen bin. Für viele Leute, die nicht in der Technik drin sind, ist das einfach zu abstrakt und zu schlecht greifbar. Das ist wahrscheinlich ein Manko bei mir. Ich kriege es nicht so weit heruntergebrochen, dass es für Menschen ohne Tech-Background wirklich anfassbar wird.

Was hört man dann? Vielleicht auch nur, weil sie nichts anderes sagen können: das wird schon. Es wird etwas im Markt geben. Es schafft ja auch neue Jobs. Laberlaber. Da sind wir uns vermutlich einig: das wird nicht der Fall sein. Klar, ein paar neue Spezialjobs werden entstehen. Aber die Masse an Menschen, deren Arbeitskraft plötzlich nicht mehr gebraucht wird, weil sie von AI übernommen wurde, kommt nicht einfach in diese neuen Spezialbereiche hinein. Das wird nicht reichen für alle, die plötzlich aus dem Regal fallen.

Und weil unsere ganzen Sozialsysteme darauf aufgebaut sind, dass viele Leute einzahlen und Steuern zahlen, sehe ich da ein Problem. Ich habe keine Lösung dafür. Mir fällt nichts ein, was funktionieren könnte.

Vielleicht bin ich ein bisschen schwarzmalend. Aber ich glaube nicht, dass wir das gut hinkriegen. Ich mache mir Sorgen, was uns in den nächsten 15 bis 20 Jahren erwartet. Das wird extrem spannend. Aber die wenigsten Dinge daran geben mir ein gutes Gefühl.

Trotzdem können wir uns jetzt nicht alle ein Loch in den Garten buddeln und uns da hineinsetzen. Wir müssen weitermachen und das Beste aus dem ganzen Thema herausholen. Früher oder später wird es auch bei den Entscheidern ankommen. Sie werden es verstehen, oder sie werden die Augen nicht mehr davor verschließen können. Aber selbst dann glaube ich nicht, dass sie eine echte Lösung finden werden.

Siehe auch

Wie seht ihr das? Schreibt es gerne in die Kommentare oder per fragen.

Unbekannte Spinne im Garten: Wolfsspinne oder doch etwas anderes?

Picture of a dead spider.

Ich selbst habe kein Problem mit Spinnen – das ist aber beim Rest meiner Familie nicht immer gegeben. Wie auch immer: Ich bilde mir ein, die meisten Spinnenarten, die hier in NRW so im Garten vorkommen, schon mal irgendwann gesehen zu haben. In den letzten Wochen finde ich aber immer mal wieder ein paar – für meinen Eindruck – recht große Exemplare, wenn auch bisher immer nur tot.

Eines habe ich mal fotografiert und zum Größenvergleich neben eine 10-Cent-Münze gelegt. Die AI sagt, dass es eine Wolfsspinne ist. Da würde ich aber spontan eher nach Nordamerika schielen. Kurz: Ich habe keine Ahnung. Fällt jemandem von euch etwas ein? Was ist das für eine Spinne?!

Fragen? Einfach melden.

Time is up: Mark Benecke im EU-Parlament – Einblick und Diskussion

Klimawandel… Joar, den gibt es. Das wir Menschen dran schuld sind wissen wir ebenfalls. Im Grunde ist es uns allen schon seit Jahren klar. Wir machen nur so schön die Augen davor zu.

Probleme zu ignorieren hilft leider nicht immer (ok in der IT geht es hin und wieder *lach*)… Ich möchte hier auf einen Vortrag verweisen, welcher es für normale Menschen, fachlich belegt zusammenfasst. Vorsicht youtube!

Ich habe seit dem Video schlechte Laune :-/

Fragen? Einfach melden.

Arduino und die jammernde Pflanze: Technik trifft Humor

Auf irgendeinem CCC Event bin ich über eine lustige Projektidee einer jammernden Pflanze gestoßen. Die hat mir und auch meiner größeren Tochter so gut gefallen, dass wir sie zusammen nachbauen wollten.

Geöffnetes Gehäuse mit der gesamten Technik für das Arduino-Projekt: Die jammernde Pflanze

Die Idee

Ein kleines Gerät misst den Feuchtigkeitsgehalt der Blumenerde. Ist der Wert zu trocken, spielt ein MP3-Player eine Audiodatei ab. Ein Bewegungsmelder sorgt dafür, dass die Pflanze sich nur beschwert, wenn auch jemand da ist. Ist die Erde trocken und es wird eine Bewegung erkannt, jammert die Pflanze los.

Die Bauteile

Da es das erste Projekt dieser Art für meine Tochter ist, sollte es übersichtlich und einfach bleiben. Ein Arduino Nano (fast die gleichen Möglichkeiten wie der UNO, aber deutlich kleiner), ein DFPlayer-Modul als MP3-Player, ein HC-SR312 Bewegungsmelder und ein kapazitiver Feuchtigkeitssensor.

Aufbau und Entwicklung

Gestartet haben wir mit einem Breadboard, um die Verschaltung Modul für Modul zu setzen und die Ansteuerung mit dem Arduino anhand der Beispiele zu testen. Beim DFPlayer haben wir per TTS Texte in MP3s umgewandelt und auf der SD-Karte im Ordner mp3 gespeichert. Diese werden zufällig abgespielt, wenn die Erde zu trocken ist und eine Bewegung erkannt wurde.

Als die Verschaltung zusammen mit dem Code funktionierte, haben wir mit KiCad eine Platine designt und fertigen lassen. So hat man weniger Kabelsalat und alles ist platzsparend aufgehoben.

Elektrischer Schaltplan für die jammernde Pflanze

Das Gehäuse haben wir in FreeCAD designt und mit dem 3D-Drucker gedruckt. Die Teile sind mit einem Tropfen Sekundenkleber fixiert.

FreeCAD-Design des Gehäuses für die jammernde Pflanze

Im Einsatz

Das Teil steckt in der Blume und meldet sich zuverlässig, wenn es Zeit zum Gießen ist. Da es von den MP3s auf dem Player abhängt, was die Pflanze „sagt“, sind lustige Reaktionen garantiert. Die Pflanze kann dich im Vorbeigehen voll jammern, um Wasser betteln oder anfangen zu schimpfen.

Meine Tochter wird nach dem Projekt nicht alles alleine wiederholen können, aber die einzelnen Schritte sind klar. Wie so ein Gerät entsteht, was nötig ist. Schnell findet man Verbesserungsmöglichkeiten: Den Feuchtigkeitssensor von der Elektronik trennen, mit einem NodeMCU ESP8266 WLAN-Statusdaten senden, oder mit Li-Ion-Akkus und einem BMS vom Stromnetz unabhängig werden.

Quellcode

Für den DFPlayer wird die DFRobotDFPlayerMini Library benötigt (lokal unter ~/Arduino/libraries ablegen).

#include <Arduino.h>
#include <SoftwareSerial.h>
#include <DFRobotDFPlayerMini.h>

/* --- Pins ---------------------------------------------------- */
const uint8_t PIN_DF_RX   = 10;
const uint8_t PIN_DF_TX   = 11;
const uint8_t PIN_PIR     = 7;
const uint8_t PIN_SENSOR = A0;

/* --- Parameter ----------------------------------------------- */
const int schwellwert = 380;
const unsigned long PLAY_COOLDOWN_MS = 15000;
const uint8_t TRACK_JAMMERN = 1;

/* --- Objekte ------------------------------------------------- */
SoftwareSerial dfSerial(PIN_DF_RX, PIN_DF_TX);
DFRobotDFPlayerMini dfPlayer;

/* --- Laufzeitstatus ------------------------------------------ */
unsigned long lastPlay = 0;

/* ------------------------------------------------------------- */

void setup() {
  pinMode(PIN_PIR, INPUT);

  Serial.begin(115200);
  dfSerial.begin(9600);

  Serial.println(F("Initializing DFPlayer ..."));

  if (!dfPlayer.begin(dfSerial)) {
    Serial.println(F("DFPlayer init failed"));
    while (true);
  }

  dfPlayer.volume(20);
  dfPlayer.outputDevice(DFPLAYER_DEVICE_SD);
  dfPlayer.EQ(DFPLAYER_EQ_NORMAL);
  dfPlayer.setTimeOut(500);

  Serial.println(F("DFPlayer Mini online"));
}

/* ------------------------------------------------------------- */

void loop() {
  /* DFPlayer Events immer zuerst abholen */
  if (dfPlayer.available()) {
    handleDFPlayerEvent(dfPlayer.readType(), dfPlayer.read());
  }

  int messwert = analogRead(PIN_SENSOR);
  bool bewegung = digitalRead(PIN_PIR) == HIGH;
  bool trocken = messwert > schwellwert;

  unsigned long now = millis();

  if (trocken && bewegung) {
    if (now - lastPlay >= PLAY_COOLDOWN_MS) {
      Serial.println(F("Bewegung + Erde trocken -> spiele Sound"));
      dfPlayer.play(TRACK_JAMMERN);
      lastPlay = now;
    }
  } else {
    logStatus(trocken, bewegung, messwert);
  }

  delay(100);  // leichte Entlastung – kein Logik-Delay
}

/* ------------------------------------------------------------- */

void logStatus(bool trocken, bool bewegung, int messwert) {
  if (!bewegung && trocken) {
    Serial.print(F("Keine Bewegung, Erde trocken: "));
  } else if (bewegung && !trocken) {
    Serial.print(F("Bewegung, Erde ok: "));
  } else if (!bewegung && !trocken) {
    Serial.print(F("Keine Bewegung, Erde ok: "));
  }
  Serial.println(messwert);
}

/* ------------------------------------------------------------- */

void handleDFPlayerEvent(uint8_t type, int value) {
  if (type == DFPlayerPlayFinished) {
    Serial.print(F("Track "));
    Serial.print(value);
    Serial.println(F(" beendet"));
  }
}

Downloads

3D-Druck: STL Gehäuse | STL Deckel
Platine: Gerber-Dateien

Einkaufsliste

Optional: Breadboard mit Kabeln, Multimeter, Lötkolben

Fragen? Einfach melden.

Datenschutz geht zur Schule

Datenschutz ist oft ein sehr langweilige und oft schwer verständliches Thema. Ein Bekannter (danke dir) hat mir den folgenden Link zukommen lassen:

https://www.datenschutz-leicht-erklaert.de/#videos

Die Link verweist einer Initiative vom Berufsverband der Datenschutzbeauftragten Deutschlands (BvD) e.V. mit dem Namen Datenschutz geht zur Schule. Die Zielgruppe sind dabei Schüler:rinnen um ihnen das Thema Datenschutz näher zu bringen. Dazu gibt es kurze, Themen bezogene Videos, welche wirklich gut verständlich sind.

Vielleicht ebenfalls etwas für euch?

Fragen? Einfach melden.

Kodi auf dem Raspberry Pi 4: Ruckelfreie Wiedergabe einrichten

Der Raspberry Pi 4 , egal ob mit 4GB oder 8GB RAM, ist in der Kombination mit Kodi eine wunderbare Erweiterung am Fernseher. Leider sorgte die letzte Version Kodi v19.3 (Matrix) bei mir für ein paar Problemchen. So stockte oder ruckelte die Wiedergabe von Videos oder die Wiedergabe lief für einige Minuten gut, dann wurde gebuffert, nur damit sich dieses Spielchen alle paar Minuten wiederholte. Egal ob im WLAN oder direkt am LAN.

Folgende Änderungen haben bei mir für eine Lösung der Probleme gesorgt:

  1. Erstellen einer XML Datei, welche die default Einstellungen des Cachings überschreibt.

    Speicherort und Dateiname ist: /storage/.kodi/userdata/advancedsettings.xml
<?xml version="1.0" encoding="utf-8"?>
<advancedsettings>
        <cache>
                <memorysize>524288000</memorysize>
                <buffermode>1</buffermode>
                <readfactor>6</readfactor>
        </cache>
</advancedsettings>

Achtung… Bei XML Dateien, spielt das richtige „Einrücken“ schon mal eine Rolle.

2. Erweitern des Arbeitsspeichers für die GPU, sowie das Erzwingen des „Turbo“ Modus.
Dafür einfach die Datei /flash/config.txt um folgende Zeilen erweitern/einpassen:

# Default GPU memory split, 76MB are needed for H264 decoder
gpu_mem=256
force_turbo=1

Wer dieses gerne per SSH machen möchte, muss das Volume /flash einmal schreibfähig mounten:

mount -o remount,rw /flash

Die Option gpu_mem setzt recht einfach den, für die Grafikkarte, reservierten Arbeitsspeicher fest auf 256MB. Dieses macht selbst bei der 4GB Raspberry PI 4 Version kein Problem.

force_turbo deaktiviert das dynamische, lastabhängige takten der CPU, GPU und des Arbeitsspeichers, sowie der Spannungen. Alles läuft daher auf Maximum, aber ohne zu übertakten. Dieses hat weniger Auswirkungen auf die Probleme bei der Wiedergabe, sorgt aber für ein allgemein „flüssigeres“ Verhalten. Dafür steigt die Stromaufnahme und die Temperatur. Da wir hier über einen Raspberry sprechen, ist es wohl für die Meisten zu vernachlässigen.

3. Um Temperatur und Geräuschpegel im Zaum zu halten, empfiehlt sich ein gutes passiv gekühltes Gehäuse. Folgendes kann ich empfehlen: https://amzn.to/3qF61pe

Das mitgelieferte Netzteil hat ausreichend Power, man kommt noch an „alles“ ran, das Gehäuse ist sehr massiv und selbst bei großer Last/langem Betrieb, wird alles nur handwarm.


Update Februar 2026 — Kodi 21 (Omega) / LibreELEC 12.x

Seit Kodi 21 (Omega), das mit LibreELEC 12.x ausgeliefert wird, funktioniert die oben beschriebene Cache-Konfiguration über die advancedsettings.xml nicht mehr korrekt. Die <cache> Sektion wird zwar noch eingelesen und im Log angezeigt — die tatsächlich aktiven Werte kommen aber aus den GUI-Settings (guisettings.xml). Im Kodi-Log erkennt man das an dieser Zeile:

New Cache GUI Settings (replacement of cache in advancedsettings.xml) are:
    Buffer Mode: 4
    Memory Size: 20 MB
    Read Factor: 4.00 x

Das bedeutet: Trotz konfigurierter 500 MB in der advancedsettings.xml läuft Kodi mit nur 20 MB Puffer — dem Default. Nicht gerade ideal.

Die neue Methode

Die Cache-Werte müssen jetzt direkt in /storage/.kodi/userdata/guisettings.xml gesetzt werden. Dafür Kodi stoppen, Datei bearbeiten, Kodi starten:

systemctl stop kodi
sleep 3

In der guisettings.xml diese drei Zeilen suchen und anpassen. Wichtig: Das default="true" muss entfernt werden, damit Kodi die Werte als benutzerdefiniert erkennt.

Vorher:

<setting id="filecache.buffermode" default="true">4</setting>
<setting id="filecache.memorysize" default="true">20</setting>
<setting id="filecache.readfactor" default="true">400</setting>

Nachher (Beispiel für 8 GB RAM):

<setting id="filecache.buffermode">1</setting>
<setting id="filecache.memorysize">500</setting>
<setting id="filecache.readfactor">600</setting>

Dann Kodi wieder starten:

systemctl start kodi

Was die Werte bedeuten

buffermode = 1

Legt fest, welche Quellen gepuffert werden:

WertBedeutung
0Nur Internet-Streams (HTTP, FTP…)
1Alles (Internet + LAN + lokal) ← empfohlen
2Nur „echte“ Internet-Streams
3Kein Puffer
4Alle Netzwerk-Quellen (Default in Kodi 21)

Wir setzen 1 statt 4, damit NFS-Quellen garantiert gepuffert werden — egal wie Kodi die Quelle intern klassifiziert.

memorysize = 500 (bzw. 250)

Die Größe des Puffers in MB. Das ist der Speicher, den Kodi im RAM reserviert, um Film-Daten vorauszulesen.

Praktisches Beispiel: Ein typischer 4K-Film hat ~80 Mbit/s Bitrate (ca. 10 MB/s).

  • 20 MB (Default): Nur ~2 Sekunden Film im Puffer. Wenn das Netzwerk kurz schwankt, stockt die Wiedergabe sofort.
  • 500 MB: Ca. 50 Sekunden Film im Puffer. Selbst wenn NFS mehrere Sekunden hängt, läuft die Wiedergabe weiter.

Empfohlene Werte nach verfügbarem RAM:

  • 8 GB RAM: memorysize = 500
  • 4 GB RAM: memorysize = 250

readfactor = 600 (= 6×)

Der Wert wird intern durch 100 geteilt, also 600 = 6,0×. Kodi liest Daten mit der 6-fachen Geschwindigkeit der benötigten Bitrate voraus. Bei einem 80 Mbit/s Film liest Kodi also mit ~480 Mbit/s vom NFS, bis der Puffer voll ist. Danach drosselt es auf die tatsächlich benötigte Rate. Das sorgt dafür, dass der Puffer sich schnell füllt und möglichst voll bleibt.

Verifizierung

Nach dem Neustart im Kodi-Log prüfen, ob die neuen Werte aktiv sind:

grep "New Cache GUI Settings" -A4 /storage/.kodi/temp/kodi.log

Hinweis zum Raspberry Pi 5

Die config.txt Anpassungen (gpu_mem=256 und force_turbo=1) gelten weiterhin für den Raspberry Pi 4. Beim Raspberry Pi 5 sind diese nicht nötig — er nutzt eine andere GPU-Architektur (VideoCore VII) und gpu_mem hat dort keine Wirkung.

« Ältere Beiträge

© 2026 -=Kernel-Error=-RSS

Theme von Anders NorénHoch ↑