Auf Mastodon ansehen
Für ein optimales Hörerlebnis empfehlen wir, eine Podcatcher-App zu verwenden. Zum Beispiel:
- AntennaPod (Android)
- gPodder (Desktop)
- GNOME-Podcast (GNOME-Desktop)
- Kast (KDE-Desktop)
- PodPhoenix (Ubuntu-Touch)
Der RSS-Feed für den Podcast lautet: https://gnulinux.ch/podcast/gnulinux_newscast_rss.xml. Ihr findet uns in den Podcast-Verzeichnissen unter dem Suchbegriff: "GNU/Linux".
Wenn euch der Podcast gefällt, freuen wir uns über eine Unterstützung. Vielen Dank!
Shownotes
CIW - Folge 183 - 17.06.2026 - KIrnel
- Wir begrüssen alle Vibe-Coder zur Folge 183 von "Captain it's Wednesday", dem Podcast über Freie Software und Freie Gesellschaft von GNU/Linux.ch, aufgenommen am 15. Juni von Lioh Möller und Ralf Hersel. In dieser Folge reden wir über die Auswirkungen von KI-generierten Fehlerberichten auf den Linux-Kernel und auf andere Projekte.
Hausmitteilungen
- Vielen Dank für eure zahlreiche Teilnahme an unserem Frühlingswettbewerb über Heimautomatisierung. Wir sind dabei, eure Einreichungen auszuwerten, und werden in Kürze die Gewinner:innen in einem Artikel bekanntgeben.
Thema: KI und der Linux-Kernel
Ausgangslage
- Dirk Hohndel interviewt Linus Torvalds beim Open Source Summit am 18. Mai in Minnesota.
- Seit sechs Monaten werden sehr viel mehr Bug Reports auf der Security Mailing List gemeldet als in den 25 Jahren zuvor. Zwar gab es bei Major-Releases auch früher eine höhere Anzahl, aber nicht in dem Ausmass wie jetzt.
- Der Anstieg lässt sich auf KI-generierte Bug Reports zurückführen. Die Security List ist nicht öffentlich. Jeder kann dort Bugs posten, aber niemand sieht, welche anderen Bugs geposted wurden. Das ist richtig im Sinne der Responsible Disclosure.
- Doch Torvalds bemerkt, dass Bugs, die durch KI gefunden wurden, per Definition öffentlich sind, weil sie theoretisch jeder finden kann. Daraus ergibt sich ein Widerspruch zur geheimen Security List.
- Zudem bemerkt er, dass Security Forscher einen Hang zur Selbstdarstellung haben. Es werden Bugs veröffentlicht, um sich selbst ins Rampenlicht zu rücken. Ohne den Entwicklern genug Zeit zu geben, die Bugs zu beheben.
- Das Auffinden von Fehlern durch KI ist kein Problem von Open Source, sondern genauso von Closed Source. Der KI ist es egal, ob der Quellcode vorliegt oder nicht. Der Konflikt besteht nicht darin, dass KI Fehler finden kann, sondern darin, dass es soziale Schwachstellen gibt, wie damit umgegangen wird.
- Bemängelt wird, dass die Bug-Reports nur in seltenen Fällen Patches enthalten.
- Die Maintainer sind mit der Flut von KI-generierten Bug Reports überlastet. Torvalds sieht weniger ein Kapazitätsproblem von den 1000 Kernel-Entwicklern, die anständig bezahlt werden, sondern bei den kleineren Projekten, die oft nur von Einzelpersonen oder einem kleinen Team gepflegt werden (siehe cURL).
- Das Kernel-Team verwendet selbst KI-Tools, wie z. B. Shashiko, um die Bug-Reports zu beurteilen. Doch die Qualität dieses Tools ist nicht besonders gut.
- Torvalds lehnt KI als Werkzeug für die Code-Generierung nicht ab, stellt sie aber in eine Reihe von Entwicklungen. Während KI die Produktivität um den Faktor 10 steigert, steigern Compiler die Produktivität um den Faktor 1000.
- Vibe-Coding schliesst das Verständnis des Codes aus. Wer Projekte langfristig pflegen möchte, kommt um das Verständnis des Codes nicht herum, egal ob generiert oder selbst geschrieben.
Einordnung
- Diese Entwicklung stellt uns schlagartig vor neue Realitäten. Prozesse, die zuvor geordnet im Hintergrund liefen, in Koordination mit den Distributionen, sind nun vollständig transparent. Es kommt einerseits einer Kapitulation gleich, andererseits ist es möglicherweise einfach eine Anpassung an neue Realitäten.
- Für Distributoren bedeutet dies, dass etablierte Patch-Bereitstellungsprozesse überdacht und beschleunigt werden müssen. Aus Anwender- und Administrator_innen-Perspektive bedeutet es, dass Patching möglichst automatisiert stattfinden sollte. Aus Softwaresicht kann es darauf hinauslaufen, dass wir zeitnah selbstheilende Programme vorfinden werden, die in der Lage sein werden, dynamisch auf Anforderungen und Bedrohungen zu reagieren.
- Es ist eine Frage der Geschwindigkeit. Das Patch-Fenster wird immer kürzer, wenn pressegeile Bug-Reporter den Projekten nicht genug Zeit zum Beheben der Fehler lassen.
- Mit aktuellen LLMs (z. B. Anthropic Mythos oder Fable) erhalten Kriminelle Werkzeuge in die Hand, die Maintainer dazu zwingen, mit denselben Tools ihre Software abzusichern, bevor die Gegenspieler zuschlagen können. Problem: 1 Tag Fable (per Token abgerechnet) kostet ca. 1’000 Dollar pro produktivem Tag.
- Mir gefällt Liohs Idee der selbstheilenden Programme. Doch wenn damit der teure Einsatz von KI zur vorherigen Überprüfung des Codes verstanden wird, ist es falsch gedacht. Damit entspinnt sich ein kostenintensives Katz-und-Maus-Spiel. Ich sehe die Kur eher in einer neuen Generation von Programmiersprachen, Compilern und Distributionsketten, die auf fehlerfreien Code optimiert sind. Mir ist klar, dass es so etwas bisher nicht gibt und vielleicht nie geben wird.
Outro
Euer Feedback zählt! Kommentiert zur Podcast-Folge oder schreibt uns einfach über Matrix, Mastodon oder per E‑Mail. Nehmt aktiv an der Community teil. Ihr könnt Artikel schreiben, Themen diskutieren oder selbst beim Podcast mitmachen. Bei GNU/Linux.ch wird eure Stimme nicht nur gelesen, sondern auch gehört.
Andere Menschen öffentlich als "Arschlöcher" zu bezeichnen, finde ich problematisch. Ihr macht fachlich wirklich hervorragende Arbeit. Dafür vielen Dank! Das sollte sich jedoch auch in der Wortwahl und einen respektvollen Umgang mit anderen Personen ausdrücken. Etwas, das ihr zurecht auch selbst einfordert.
Es ging um Claude oder um die Firma die dahinter steht Namens Anthropic. Aus meiner Erfahrung sind es oftmals die, die sich gerne als "die Guten" darstellen, die letztendlich Daten proaktiv an Ermittlungsbehörden weitergeben.
Stefan, da bin ich ganz bei dir: Aus was für einem Grund das gesagt worden ist, spielt auch keine Rolle, man sagt sowas nicht. Eine Entschuldigung von Lioh würde in diesem Sinne auch positiv im Netz ankommen. Gleiche Rechte für alle.
Da Stefan, soweit mir ist, bei Anoxinon tätig ist, möchte ich gerne auch hierzu noch einige Ergänzungen anführen. Ich habe mich vor längerer Zeit für Anoxinon als Provider für meinen Mastodon Account und das Konto von GNU/Linux.ch entschieden, da ich die Zielsetzungen des Vereins als sinnvoll empfunden habe. Eine gute und solide technische Lösung, betrieben von Menschen, die sich damit auskennen. Mittlerweile ist das GNU/Linux.ch Account wahrscheinlich das grösste Konto auf der Instanz, ohne dies geprüft zu haben.
In den vergangenen Jahren blieb natürlich der ein oder andere technische Schluckauf nicht aus. Ich habe die Kommunikation seitens des Vereins über XMPP dazu jedoch immer als transparent und offen empfunden.
Seit einigen Wochen und Monaten habe ich allerdings den Eindruck, dass sich der Wind im Projekt gedreht hat. Angefangen hat es mit einer unverständlichen Aussage im Rahmen der 2MR Veranstaltung: 'Je mehr Follower, desto mehr Datenverkehr. Ein Problem, dass der Verein Anoxinon lösen will.' https://social.anoxinon.de/@Ruhrnalist@mastodon.social/116517859676290934
Warum und wie will das der Verein Anoxinon da etwas lösen? Dabei handelt es sich um eine grundsätzliche Einschränkung bei verteilten Systemen und in diesem Falle des ActivityPub Protokolls. Sofern hier Anpassungen gewünscht wären, dann wäre es richtig, diese offen im ActivityPub-Gremium zu diskutieren.
Die Ankündigung zum Thema KI, auf die ich mich in der Podcast-Folge bezogen, habe möchte ich auch den Leser_innen welche keinen Account dort haben nicht vorenthalten:
"Moin in die Runde! Das Fediverse ist ein föderiertes Netzwerk von Wesen für Wesen. Daher haben wir folgendes Ergänzung in unsere Moderationsrichtlinien vorgenommen: "KI-Inhalte sind menschenlesbar zu kennzeichnen. KI-Slop ist grundsätzlich unerwünscht."
Wie ist das zu verstehen? Wie lassen sich KI-Inhalte menschenlesbar kennzeichnen? Geht es um Text, dann ist dieser von Menschen lesbar. Geht es um Bilder, wäre eine Bildbeschreibung hilfreich, unabhängig davon, ob es sich um ein KI-Bild handelt oder nicht. KI-Slop hingegen ist ein unklarer Begriff der gerne in Marketingfolien verwendet wird. Slop bezeichnet ursprünglich Tierfutter von niedriger Qualität. Doch wer bewertet dies? Ein KI-generiertes Bild zum Beispiel kann für eine Person minderwertig erscheinen, für eine andere Person jedoch nicht. Mir sind die Beweggründe dieser Regelergänzung nicht klar und für mich klang es so, als ob damit der im Fediverse weit verbreiteten KI-skeptischen Haltung zugesprochen werden soll. Entsprechend sind dann auch die vielen 'positiven' Reaktionen auf die Ankündigung aus der eigenen KI-kritischen Bubble. Hier würde ich mir wieder mehr Offenheit und Toleranz wünschen, so wie ich es bis anhin von Anoxinon gewöhnt bin.
Auch beobachte ich mit Besorgnis, dass die Kommunikationskanäle verstärkt für die Verbreitung einer politischen Agenda genutzt werden und es fallen Aussagen wie „Hackt kaputt, was euch kaputt macht!“ und "Wir finden: Fehlersuche sollte nicht mehr sanktioniert werden und sprechen uns für eine Legalisierung des White Hat Hacking aus."
https://social.anoxinon.de/@Anoxinon/116709421617486615
und
https://mas.to/@informatik/116676852698635586
Ich würde mir wieder mehr Neutralität und einen klaren Focus auf die Erbringung der guten Leistungen im Bereich des Hostings wünschen, so wie es bisher der Fall war.
Im kurzen Rahmen einer Podcast-Folge war es mir nicht möglich diese Aspekte vollumfänglich zu behandeln. Falls ich euch mit meinen Aussagen verletzt habe, möchte ich um Entschuldigung bitten. Das war nicht meine Absicht.
Mit Anoxinon habe ich nichts zu tun. Kannte ich bis überhaupt nicht.
Dann hilft der Kontext hoffentlich anderen. Meine Haltung zu den anderen Themen im Podcast bleibt unverändert.
Win Grosses Problem von selbstheilender Software dürfte sein, dass wenn man einen fehler behebt, die gefahr besteht, dass der fehler zu direkt korrigiert wird.
Es kann durchaus sein, daas ein Fehler eigentlich tiefer im Code korrigiert werden müsste und darum der Selbe Grund für den Fehler an anderer Stelle erscheint.