Den interessantesten Aspekt kommentiert hier überraschend keiner....

3.000 Kernel-Bugs (und hier wirklich nur der Kernel), die alle sicherheitsrelevant sind, in einem solchen Zeitraum. Das sind übrigens mehr Kernelbugs, als der Windows NT Kernel über seine ganze Existenz aufzuweisen hat (d.h. von NT 3.51 bis heute), kann gern jeder prüfen.
Der Linux-Kernel ist zu einem Blob verkommen, der kaum noch vernünftig wartbar ist und dem die ganzen Kreuz- und Querverbindungen zunehmend um die Ohren fliegen. Es ist ja nicht so, dass die Anzahl der Fehler abnimmt, im Gegenteil. Was allerdings auch logisch ist, Stichwort: Komplexitätstheorie.
Nun werden natürlich Argumente kommen, dass da ja gut ist (war ja auch schon Bestandteil der Diskussion, auf die sich der Artikel bezieht. Ja und nein. Natürlich ist es gut, wenn Fehler beseitigt werden. Hier ist aber schon länger ein stetes Wachstum von gemeldeten Fehlern zu sehen, was eben mit den zunehmenden Querverbindungen zu tun hat und auch nicht verhinderbar ist. Frage ist, wie das enden soll/wird. Irgendwann muss man sich offensichtlich Gedanken darüber machen, ob die Architektur, alles und jedes in den Kernel zu verlagern, noch vernünftig ist. Warum muss ein sekundärer Treiber in den Kernel? Man erinnere sich an den Streit mit Tannenbaum und der Architektur von Minix, die anfangs ja nachgebaut wurde, dann aber als schlecht verdammt und aufgeblasen worden ist (wobei vielleicht schlicht das Verständnis für die Architektur nicht vorhanden war). Inzwischen ist die Kernelentwicklung eher ein getriebener vom Erfolg und anstatt sich Zeit zu nehmen, kommt man mit Release Zyklen, die nicht mehr sinnvoll erscheinen. Release early - release often funktioniert eben nur bedingt. Und wenn man dann liest, dass 50K Codezeilen Changes in einem Zeitraum von 2 Wochen zu testen sind.... Sicher sind die einzelnen Funktionen hinreichend getestet, das Problem ist aber die Interaktion mit allen möglichen anderen Sachen. Und interessant wird es besonders dann, wenn sich zwei Funktionen "begegnen", die geändert wurden - hier gab es eben keinen Test vorab, da der Entwickler seine Umgebung nutzt und den anderen Code gar nicht hat.
Sicher haben das Problem auch andere, keine Frage. Aber die lassen sich halt auch deutlich mehr Zeit mit Releases. So dauert es z.B. bei Microsoft für eine neue Windows Version vom RC0 bis zum Release mind. 4 Monate. Das ist dann schon eine Hausnummer.