News Linux-Kernel: KI-generierte Bugreports plötzlich brauchbar - Maintainer überrascht

[PCGH_Jacky]

KI-generierte Bugreports galten bisher als unbrauchbar. Im Linux-Umfeld hat sich das offenbar zuletzt geändert. Maintainer berichten von einer auffälligen Verschiebung hin zu verwertbaren Hinweisen.

Was sagt die PCGH-X-Community zu Linux-Kernel: KI-generierte Bugreports plötzlich brauchbar - Maintainer überrascht

Bitte beachten: Thema dieses Kommentar-Threads ist der Inhalt der Meldung. Kritik und allgemeine Fragen zu Online-Artikeln von PC Games Hardware werden hier gemäß der Forenregeln ohne Nachfrage entfernt, sie sind im Feedback-Thread besser aufgehoben.

 

[Andreas1975]

Da sieht man wieder wie altruistisch Nutzer von offenen OS, wie die Ki Anwendungen, sind. Da wird nicht auf den Server geschaut in dem man selber sitzt sondern zuerst bei den armen Seelen welche noch kein GNU System Nutzen. Da scheinen die Ergebnisse zu passen und kümmert sich um das eigenen System. Das die Nutzer dieser Systeme bisher keine große Hilfe von der Ki erhalten haben ist nicht so drmataisch da es sich bei den Nutzern eh um ganz eingefleischte Terminal Nutzer handelt. Das wird sich künftig sicher schnell ändern.

Das die Reporte nun offensichtlich brauchbar sind ist der erste Schritt wo man sieht das die KI nicht nur auf Linux Servern läuft sondern auch über Linux lernt. Künftig keine lange Suche in Linux Foren wenn es doch das seltende Erlebnis eines Problems auf einem Linux System gibt. Künftig kann die KI befragt werden. Jetzt profitieren noch die Programmierer bald jeder Nutzer.

 

[joecnstr]

Da sieht man wieder wie altruistisch Nutzer von offenen OS, wie die Ki Anwendungen, sind. Da wird nicht auf den Server geschaut in dem man selber sitzt sondern zuerst bei den armen Seelen welche noch kein GNU System Nutzen. Da scheinen die Ergebnisse zu passen und kümmert sich um das eigenen System. Das die Nutzer dieser Systeme bisher keine große Hilfe von der Ki erhalten haben ist nicht so drmataisch da es sich bei den Nutzern eh um ganz eingefleischte Terminal Nutzer handelt. Das wird sich künftig sicher schnell ändern.

Das die Reporte nun offensichtlich brauchbar sind ist der erste Schritt wo man sieht das die KI nicht nur auf Linux Servern läuft sondern auch über Linux lernt. Künftig keine lange Suche in Linux Foren wenn es doch das seltende Erlebnis eines Problems auf einem Linux System gibt. Künftig kann die KI befragt werden. Jetzt profitieren noch die Programmierer bald jeder Nutzer.

Hab es schon öfter in ähnlicher Art gepostet:

• Linux Probleme kann man mit KI oft sehr schnell lösen: Es gibt viel hervorragendes Trainingsmaterial einer starken und kompetenten Community. Daher sehr oft sehr gute KI Antworten
• Coding mit KI (ich sehe es immer noch kritisch aber ich sehe auch das Potential) wäre ohne Open Source gar nicht möglich - wieder eine Frage des Trainingsmaterials

Ich hoffe nur, dass KI diese zwei Punkte in Zukunft nicht "enshittificaten" wird

 

[x2K]

Hab es schon öfter in ähnlicher Art gepostet:

• Linux Probleme kann man mit KI oft sehr schnell lösen: Es gibt viel hervorragendes Trainingsmaterial einer starken und kompetenten Community. Daher sehr oft sehr gute KI Antworten
• Coding mit KI (ich sehe es immer noch kritisch aber ich sehe auch das Potential) wäre ohne Open Source gar nicht möglich - wieder eine Frage des Trainingsmaterials

Ich hoffe nur, dass KI diese zwei Punkte in Zukunft nicht "enshittificaten" wird

Die KI jat aber kein Zeitgefühl und vermischt manchmal neue und alte Pakete.
Ich hab das mal getestet als bei mir der sound plötzlich nicht mehr ging. Die ki hat dann Alsa und Pipe Wire miteinander vermischt . Da muss man dann schon etwas aufpassen.

 

[joecnstr]

Die KI jat aber kein Zeitgefühl und vermischt manchmal neue und alte Pakete.
Ich hab das mal getestet als bei mir der sound plötzlich nicht mehr ging. Die ki hat dann Alsa und Pipe Wire miteinander vermischt . Da muss man dann schon etwas aufpassen.

Auf jeden Fall - man muss IMMER prüfen, was die KI sagt. Aber mir hat es schon oft stundenlanges googeln erspart. Gerade bei einem Audioproblem kürzlich (kein Sound in Flatpak). Wenn ich mich zurück erinnere, wie ich Anfang 2000er tagelang gekämpft hab eine ISA Bridge Soundkarte zum laufen zu bekommen

Was bei den KI fragen auch sehr hilft: Präzise beschreiben was der Hintergrund ist (also welche Linux Distro, welche Teile betroffen sind, was Symptome sind und was man schon probiert hat)

Was ich cool fände: Ein lokales Modell, speziell auf deine Distro trainiert, genau für solche Fragen. Sollte gut in 16B oder so passen

 

[Andreas1975]

Was ich cool fände: Ein lokales Modell, speziell auf deine Distro trainiert, genau für solche Fragen. Sollte gut in 16B oder so passen

Ich schau gerade mal was die LLM bei mir Lokal da so ausgibt.

 

[G4mest3r]

Unklar bleibe allerdings, wodurch dieser Umschwung ausgelöst worden sei. Weder innerhalb der Kernel-Community noch in anderen Projekten gebe es bisher eine eindeutige Erklärung. Möglich sei, dass sich die zugrunde liegenden KI-Modelle verbessert hätten oder deren Nutzung stärker professionalisiert worden sei. Ebenso könne eine Kombination aus mehreren Faktoren verantwortlich sein.

Parallel dazu verändere sich aber auch die Rolle von KI innerhalb der Entwicklung, denn während automatisierte Systeme zuvor eher als zusätzliche Belastung wahrgenommen worden seien, würden sie zunehmend als unterstützendes Werkzeug eingesetzt. Vor allem im Bereich der Code-Reviews kämen KI-gestützte Analysen zum Einsatz, um offensichtliche Fehler frühzeitig und beschleunigt zu erkennen.

Gleichzeitig steige jedoch auch der Prüfaufwand. Mehr automatisierte Meldungen bedeuteten zwangsläufig mehr Inhalte, die bewertet und eingeordnet werden müssten.

Also, zunächst ist es noch nicht klar, ob jetzt die KI besser wurde oder die Menschen sie sinnvoller nutzen und nicht mehr so viel Slop ungesichtet weiterreichen.
(wurde nicht auch kürzlich wegen der qualitativ unbrauchbaren Flut an AI-slop-Reports stark eingeschränkt, von welchen vertrauenswürdigen und erfahrenen Quellen solche Reports noch akzeptiert würden, um nicht massenhaft Murks von Hunz&Kunz - die gar keine Ahnung haben, was da ausgespuckt wurde - sichten zu müssen?)

Masse erzeugt mehr Aufwand bei Qualitätssicherung.

Wichtig sind Prüfprozesse, die brauchbare Hinweise an Entscheider liefern.
Bei KI generierten Inhalten (z.B Code) ist 4-Augen-Prinzip und generell Qualitätssicherung sehr wichtig.

The Register gibt am Ende sehr treffend wieder: "The trick for Kroah-Hartman and his peers will be to keep AI as a force multiplier, without drowning the open source maintainers"

-> Gewinnbringenden Nutzen ohne in masseproduziertem Mist (Slop) zu ertrinken - das ist tatsächlich der Trick bei "sinnvollem" Einsatz.

Nicht überall den spezial-Hammer von jedem Laien (auf alles sinnfrei angewandt), sondern gezielt und mit bedacht durch den erfahrenen Fachmann

 

[Andreas1975]

So schlecht sieht das gar nicht aus.

 

[G4mest3r]

So schlecht sieht das gar nicht aus.

Was hast Du genau vor?
Überprüfen, ob LLM's besser in ihren Antworten geworden sind zu früher?

Ich bin mir jetzt nicht ganz sicher, ob rein

sudo dnf install kernel

ausreicht, um die neueste Kernel-Version innerhalb des Repositories - oder gar irgendeine neue Kernel-Version außerhalb der Repositories - zu installieren

Das Fedora-Handbuch steht zum manuellen Kernel-upgrade weit mehr Code-Schritte und konkretere Angaben bei den Kernel-Versionen

 

[Andreas1975]

ausreicht, um die neueste Kernel-Version innerhalb des Repositories

Doch schon


Btw ich habe natürlich auch die Frage gestellt wenn der Kernel noch nicht bestandteil ist.
Siehe:


Du hattest doch davon gesproche Lokal die Ki zu befragen. Nun ist das kein extra auf Linux trainiertes Model aber schaut doch so schlecht nicht aus. Ich hätte da mit wesentlich mehr Ungereimtheiten gerechnet. Ich werde das künftig mal nebenbei nutzen wenn ich am System rumfrickel.


Edit

Gerade das 11B Model befragt. Das ging jetzt richtig schnell.

 

[G4mest3r]

@Andreas1975 ich hätte ja zwischendurch wenigstens noch

dnf list installed "kernel*"

eingeschoben.

@Andreas1975 die Frage ist auch, welches Modell zu verwendest. Claude liefert hier sehr viel brauchbarere Ergebnisse, als beispielsweise GPT.

 

[Andreas1975]

Ich hatte Llama3.2 Vision 11B (oben angepasst dachte es wäre ein 7B Model) und 90B befragt. Habe aber auch andere Modele, bin da noch am probieren. Claude schau ich mir mal an. Nein sehe ich gerade ist für Alpaka nicht verfügbar. Na eventuell gibt es eins welches auf Claude basiert. Oder ich nutze doch noch ein anderes Tool.

 

[Hoagy]

Also, zunächst ist es noch nicht klar, ob jetzt die KI besser wurde oder die Menschen sie sinnvoller nutzen und nicht mehr so viel Slop ungesichtet weiterreichen.

Beides. Und dazu kommt noch der Tool-Stack, der sich in der letzten Zeit durch die (Open Source) Community stark weiterentwickelt hat.

Vor ungefähr zwei Monaten haben wir auf der Arbeit erstmals KI Reviews als gut genug erachtet, um sie in unsere CI-Automation zu integrieren. Zu der Zeit waren immer mal wieder recht brauchbare Kommentare dabei, aber auch viel Unnötiges (vor Allem zu viele Lobhudeleien).
Vor zwei Wochen sind wir dann auf eine neue Version des Review-Bots umgestiegen, die jetzt 8 verschiedene KI-Personas (basierend auf dem selben KI-Modell) verwendet, die mit jeweils eigenem Schewerpunkt reviewen (Security, Architektur, etc.). Eine davon dient wiederum als Orchestrator, der die Resultate der anderen gewichtet und filtert. Das Ergebnis ist eine enorme Verbesserung und eine extrem wertvolle Ergänzung zum menschlichen Review.

Diese Personas mussten natürlich erstmal ausgetüftelt und getunt werden, was eine gewisse Zeit und Kompetenz benötigt. So ein Tool-Stack entsteht nicht von heute auf morgen. Genau das macht den Bereich Prompt Engineering so wichtig in der Softwareentwicklung.

 

[joecnstr]

Ich hatte Llama3.2 Vision 11B (oben angepasst dachte es wäre ein 7B Model) und 90B befragt. Habe aber auch andere Modele, bin da noch am probieren. Claude schau ich mir mal an. Nein sehe ich gerade ist für Alpaka nicht verfügbar. Na eventuell gibt es eins welches auf Claude basiert. Oder ich nutze doch noch ein anderes Tool.

Ich meinte allerdings nicht mal ein "Stock Modell" einer lokalen KI, sondern eines, das speziell mit Linux-Wissen (oder sogar Distro-spezifischem Wissen) trainiert bzw augmentiert wurde. Ich hab mal mit einem Llamafile gespielt und ihm die Anteilung "Repair Bootloader" von popOS gefüttert (die Anleitung ist meiner Meinung nach sehr gut für Debian-basierte Distros, siehe https://support.system76.com/articles/bootloader/).

Das lokale Modell konnte einen dann recht gut durch den Reparaturprozess führen

 

[Andreas1975]

Ich meinte allerdings nicht mal ein "Stock Modell" einer lokalen KI, sondern eines, das speziell mit Linux-Wissen (oder sogar Distro-spezifischem Wissen) trainiert bzw augmentiert wurde. Ich hab mal mit einem Llamafile gespielt und ihm die Anteilung "Repair Bootloader" von popOS gefüttert (die Anleitung ist meiner Meinung nach sehr gut für Debian-basierte Distros, siehe https://support.system76.com/articles/bootloader/).

Das lokale Modell konnte einen dann recht gut durch den Reparaturprozess führen

Die Ki merkt sich ja die Dialoge. Ich füttere sie derzeit auch mit entsprechenden Texten. Zum Bespiel mit
The GNU C Library Reference Manual. Das sind 1200 Seiten welche ich künftig mit der Ki nachschlage.
Aber ja eine eigene Ki nur für Linux wäre natürlich richtig geil. Aber ich bin derzeit schon recht zufrieden was diese lokal so kann. Nur bin ich mir noch nicht sicher welches Model ich verwende. Das gute ist das ich mehrere verwenden kann. Da kann man die Übersetzung auch mal zum nächsten Model schieben.

 

[G4mest3r]

Beides. Und dazu kommt noch der Tool-Stack, der sich in der letzten Zeit durch die (Open Source) Community stark weiterentwickelt hat.

Dann weisst Du mehr, als die zitierte Studie.
Vielleicht solltest Du Deine Erkenntnisse und stichhaltigen Belege denen mitteilen

 

[Hoagy]

Dann weisst Du mehr, als die zitierte Studie.
Vielleicht solltest Du Deine Erkenntnisse und stichhaltigen Belege denen mitteilen

Das ist nunmal mein Arbeitsalltag. Wir evaluieren ständig, was möglich ist. Und das hat sich in den letzten Monaten stark weiterentwickelt, was KI-Fähigkeiten und Tooling angeht. Unsere dazugewonnene Erfahrung hilft uns natürlich auch dabei, diese Fähigkeiten immer besser zu nutzen. Das sind also Erfahrungen aus erster Hand. Ich gehe davon aus, dass es in anderen Softwarefirmen genauso ist. Belegen kann ich dir das natürlich nicht.

 

[G4mest3r]

Belegen kann ich dir das natürlich nicht.

Es gibt Verbesserungen, die man nicht belegen kann?
Spannend.
Das muss sich doch irgendwie manifestieren: weniger Code-Fehler, weniger nachgelagerter Korrektur- und Review-Aufwand, weniger Schwachstellen, Bugs und erfolgreiche Angriffe, performanterer, effizienterer Code ...
Kein Wunder, dass die Studie zu dem Schluss kam, wenn es nicht messbar ist

Dagegen dann solche Meldungn (shoutout @Poulton):

Absturz oder Kernschmelze: Cisco Source Code gestohlen; Anthropic Claude Code geleakt; ChatGPT-Schwachstelle etc.

Angeblich soll der Source Code von Cisco gestohlen worden sein. Anthropic ist ein Fehler unterlaufen, wodurch der Code von Claude Code geleakt wurde. In OpenAIs ChatGPT wurde wieder eine…

borncity.com

Das Erstellen von Code ist kein Engpass mehr. Aber Vibe-Coding verursache mittlerweile in der Hälfte der Zeit genauso viel technische Schulden wie 10 reguläre Entwickler, schreibt der Autor des Tweets. Das Testen dieses Codes, das Debuggen, die Überwachung in der Produktion und das Beheben von Fehlern stellen den wahren Flaschenhals dar. Vibe-Coding eigne sich hervorragend für einen ersten Entwurf.

Eigentlich sollte mit den neuen AI-Tools doch alles besser werden. Stattdessen wird Software immer schneller, mit mehr Fehlern und mehr Sicherheitslücken über die Anwender gekippt.

Das gilt für alles AI: Geschwindigkeit, Masse.
Aufwand wird nur verlagert. Flaschenhals ist dann bei der Qualität und im sicheren Einsatz.

 

[Hoagy]

Es gibt Verbesserungen, die man nicht belegen kann?
Spannend.
Das muss sich doch irgendwie manifestieren: weniger Code-Fehler, weniger nachgelagerter Korrektur- und Review-Aufwand, weniger Schwachstellen, Bugs und erfolgreiche Angriffe, performanterer, effizienterer Code ...
Kein Wunder, dass die Studie zu dem Schluss kam, wenn es nicht messbar ist

Natürlich, alles davon. Und selbstverständlich lässt sich das sowohl messen als auch belegen, sonst würden wir es ja nicht machen.
Dennoch kann ich dir hier keine Beweise liefern, weil ich natürlich nicht die Details unserer Arbeit hier öffentlich ausbreiten kann. Das meinte ich mit dem Satz.

Dagegen dann solche Meldungn (shoutout @Poulton):

Absturz oder Kernschmelze: Cisco Source Code gestohlen; Anthropic Claude Code geleakt; ChatGPT-Schwachstelle etc.

Angeblich soll der Source Code von Cisco gestohlen worden sein. Anthropic ist ein Fehler unterlaufen, wodurch der Code von Claude Code geleakt wurde. In OpenAIs ChatGPT wurde wieder eine…

borncity.com

Das gilt für alles AI: Geschwindigkeit, Masse.
Aufwand wird nur verlagert. Flaschenhals ist dann bei der Qualität und im sicheren Einsatz.

Das kann ich so hingegen absolut nicht bestätigen. Bei uns hat KI zu etwas mehr Produktivität geführt und sehr viel mehr Qualität.
Man darf nur nicht den Fehler machen, Menschen durch KI ersetzen zu wollen, sondern man sollte sie ergänzend einsetzen. Dann bekommt man in jeder Hinsicht bessere Resultate.

Aber in deinem Artikel ist ja auch von Vibe-Coding die Rede. Vibe-Coding ist grundsätzlich ein schlechter Ansatz. Das ist in der Software-Industrie schon lange Konsens.

 

[x2K]

Was ich cool fände: Ein lokales Modell, speziell auf deine Distro trainiert, genau für solche Fragen. Sollte gut in 16B oder so passen

Da würde mir ein Diagnostik tool mehr helfen das den fehler analysiert die konfig liest und ggf Paket varianzen erkennt. Das ganze dann in eine verständliche aussage verpackt und ggf selbstständig fehler beseitigen kann. Anfänge davon gibt es unter Windows mit der Problembehebung.

Der Vorteil unter Linux wäre der das man sich nicht in jedes Paket einlesen muss oder von hand zig Abhängigkeiten prüfen muss. Jedes paket könnte so eine art error file mitbringen das die Diagnostik als Referenz nutzen könnte. Eine ki in dem sinne brauchts dann nicht, das wäre absoluter Overkill.