Linux-Kernel: Fehlerbehebungen pro Release seit April 2026 mehr als verdoppelt
Linux bugs fixed per release over time: >2× rise since 2026-04
Der 7.2-Kernel ist mit 16.418 Nicht-Merge-Commits von 2.652 Entwicklern der zweitgrößte Release der Kernel-Geschichte. Auffällig: 613 Erstbeitragende – ein neuer Rekord – und 1.111 Changes mit Assisted-by-Tags, mehr als dreimal so viele wie in 7.1. Zugleich steigt die Zahl der Fixes-Tags deutlich an, und das Sashiko-Review-System taucht in 568 Commit-Logs auf. Der Anteil an Reviews sinkt leicht.
Die tatsächliche Zahl der LLM-unterstützten Patches in 7.2 dürfte sicherlich weit höher liegen.
- ogoffart
Ich habe dasselbe in meinem Projekt bemerkt.
Der Agent hilft sehr beim Beheben von Fehlern. Man muss die Agents nur auf die Fehlerberichte ansetzen. Sie übernehmen die Reproduktion, das Debugging und die Korrekturen. Wir müssen „nur“ noch reviewen. (Manchmal nach mehr Details fragen und sagen, dass wir einen anderen Ansatz bevorzugen würden.) Das macht die Fehlerbehebung viel schneller und automatisierter.
Und gleichzeitig scheint es, dass wir weniger Fehlerberichte für unsere Bibliothek bekommen.
Ich denke, die Nutzer verwenden einfach ihre Agents zum Programmieren, und Agents melden keine Fehler, sie umgehen sie einfach irgendwie.
Insgesamt sinkt also die Zahl der offenen Fehler. Was sich irgendwie gut anfühlt.
Andererseits bekommen wir viele PRs von den Agents anderer Leute, was etwas überwältigend sein kann, wenn es nur ein riesiger Code-Dump ist. Das können wir nicht einfach reviewen.
- zdw
Greg KH hat ein Video über die Flut von LLM-erzeugtem Zeug gemacht: https://www.youtube.com/watch?v=NnV_cWeoo5Q , HN-Thread: https://news.ycombinator.com/item?id=49929391
Darin wird behandelt, wie er darauf reagiert und vielem davon entgegentritt, sowie die Bitte um einen Patch (nicht nur Fehlerberichte).
- 05kqhg
Die Überschrift lautet „Development statistics for the 7.2 kernel“, und der letzte Absatz ist stark LLM-kritisch, im Kontrast zur redaktionell bearbeiteten Überschrift „Linux bugs fixed per release over time: >2× rise since 2026-04“, die so etwas wie eine Art Mythos-Fehlerfindung zu implizieren scheint.
Aus dem letzten Absatz:
„Der Linux-Kernel ist auf den Produktiveinsatz ausgerichtet, nicht auf Forschung oder Experimente. Aber derzeit läuft ein massives Experiment mit den Entwicklungsprozessen und der Community des Kernels.“
- jayd16
Das große Problem bei dieser Art von Kurztexten ist, dass es keine Kontrollgruppe gibt.
Historische Zahlen sind nicht gültig, weil sich die Anreize einer gut finanzierten Einheit geändert haben. Es bräuchte einen ebenso gut finanzierten Vorstoß, um die Patch-Zahlen ohne LLMs zu erhöhen, um die Auswirkungen wirklich quantifizierbar zu messen.
- AmazingEveryDay
Wie massiv können die maschinengenerierten amdgpu-Header-Dateien eigentlich werden, es könnte Zeit sein, einige Grenzen zu setzen.
- dash2
Es scheint also sinnvoll, eine Survival-Analyse für eingeführte Fehler zu vibecoden. Aber nicht ganz eine Survival-Analyse, weil wir nicht einmal wissen, dass die Fehler existieren, bis das Ereignis ihrer Entdeckung eintritt ... Gibt es dafür einen öffentlich verfügbaren Datensatz mit einer URL?
- tosti
Achtung für alle, die auf 7.3 aktualisieren: Ich habe gerade meine Slackware-Kiste von 7.3-rc7 auf 7.2.10 heruntergestuft, weil /dev/input/events fehlte. Tastatur und Maus funktionierten infolgedessen nur in der Konsole.
YMMV
- cwillu
Bitte keine redaktionellen Titel.
(Bearbeitung: Titel wurde korrigiert)