Kernel.org: 98 Prozent des Linux-Kernel-Archiv-Traffics sind wohl keine Menschen

Was geschehen ist: Ein massiver Ansturm auf das Herz des Linux-Kernels

Das Team hinter Kernel.org, der zentralen Anlaufstelle für den Quellcode des Linux-Kernels, sieht sich mit einer beispiellosen Herausforderung konfrontiert. Wie aktuelle Berichte des Entwicklers Konstantin Ryabitsev von der Linux Foundation verdeutlichen, ist der Datenverkehr auf den Servern des Archivs in eine Schieflage geraten, die das Ausmaß des menschlichen Interesses bei weitem übersteigt. Der Großteil der Anfragen, die täglich auf git.kernel.org einlaufen, stammt nicht von Entwicklern oder Anwendern, die aktiv am Code arbeiten oder diesen für ihre Projekte beziehen. Stattdessen sind es automatisierte Systeme, sogenannte Scraper und Bots, die die gesamte Sammlung an Commits und Forks systematisch durchforsten. Die Zahlen sind alarmierend: Lediglich zwei Prozent des gesamten Traffics lassen sich auf legitime menschliche Nutzer oder nicht-scrapiende Systeme zurückführen. Der Rest wird von einer Flut an automatisierten Abfragen dominiert, die das Ziel verfolgen, die wertvollen Datenbestände für das Training von Künstlichen Intelligenzen abzugreifen. Diese Entwicklung stellt die Betreiber vor die Aufgabe, die Integrität und Erreichbarkeit ihrer Infrastruktur angesichts einer fast erdrückenden Last durch Maschinen zu schützen.

Die Einzelheiten: Zahlen, Fakten und die Last der Scraper

Die Dimensionen, in denen sich Kernel.org bewegt, sind beeindruckend und gleichzeitig der Grund für die hohe Attraktivität für Datensammler. Insgesamt hostet das Portal rund 1,48 Millionen Commits sowie etwa 922 verschiedene Forks des Linux-Kernels. Diese Datenmenge stellt eine der umfangreichsten Sammlungen menschlicher Programmierarbeit im gesamten Internet dar. Laut Konstantin Ryabitsev, der für die Verwaltung der Server verantwortlich ist, machen Anfragen durch Bots mittlerweile etwa 22 Prozent der gesamten Servergrundlast aus – und das, obwohl bereits zwei Drittel aller eingehenden Anfragen durch Sicherheitsmechanismen im Vorfeld blockiert werden. Das Problem verschärft sich dadurch, dass Scraper anders agieren als menschliche Entwickler. Während ein Mensch oder ein legitimes System die benötigten Daten einmalig klont und anschließend lokal auf dem eigenen Rechner verarbeitet, durchsuchen Bots die Seiten mittels CGit immer und immer wieder. Da dies für sämtliche 922 Forks wiederholt wird, entstehen enorme Lastspitzen. Ryabitsev beziffert den potenziellen Aufwand im schlimmsten Fall auf eine CPU-Zeit, die um den Faktor 4,6 Millionen höher liegt als bei einer effizienten Abfrage. Trotz dieser massiven Belastung sind die Systeme derzeit noch stabil, doch der Druck wächst stetig.

Hintergrund: Der Hunger der KI-Modelle nach menschlichem Code

Die Ursache für diesen massiven Anstieg des automatisierten Traffics liegt in der aktuellen Entwicklung der Künstlichen Intelligenz. KI-Modelle benötigen für ihr Training kontinuierlich neue, qualitativ hochwertige Datenmengen. Da der Linux-Kernel als ein exzellentes Beispiel für menschliche Programmierarbeit gilt, ist er zu einem bevorzugten Ziel für Entwickler von KI-Systemen geworden. Die Bestrebungen, diese Daten in großem Stil abzugreifen, haben dazu geführt, dass Kernel.org unfreiwillig zu einer Hauptquelle für das Training von Sprachmodellen und anderen KI-Anwendungen geworden ist. Die Historie des Portals, das über Jahre hinweg eine verlässliche und offene Quelle für den Kernel-Code darstellte, macht es nun zu einem Ziel für automatisierte Datensammler. Was als offenes Archiv für die Community begann, wird nun von der schieren Masse an KI-orientierten Anfragen überrollt. Die Betreiber müssen nun Wege finden, den legitimen Zugriff für Entwickler zu gewährleisten, während sie gleichzeitig die Ressourcen vor einer Überlastung durch die unersättlichen Algorithmen schützen, die den Code als Rohstoff für ihre Lernprozesse betrachten.

Die Beteiligten: Wer verwaltet und wer sich äußert

Im Zentrum dieser technologischen Auseinandersetzung steht das Team von Kernel.org, das für die Bereitstellung und Wartung des Linux-Kernel-Archivs zuständig ist. Eine zentrale Figur in diesem Kontext ist Konstantin Ryabitsev, ein Entwickler bei der Linux Foundation. Er ist maßgeblich an der Verwaltung der Server beteiligt und fungiert als Sprachrohr für die Probleme, mit denen sich das Team konfrontiert sieht. Ryabitsev ist es auch, der die alarmierenden Statistiken über den Traffic und die Auswirkungen der Scraper öffentlich gemacht hat. Auf der anderen Seite stehen die Betreiber der Bots und Scraper, deren Identität und genaue Herkunft in den Berichten nicht im Detail spezifiziert werden, die jedoch kollektiv als Akteure agieren, die den Kernel-Code für KI-Modelle extrahieren wollen. Die Linux Foundation als übergeordnete Institution trägt die Verantwortung für die Infrastruktur und muss entscheiden, welche Maßnahmen zum Schutz der Server ergriffen werden, um den Betrieb für die weltweite Entwicklergemeinschaft aufrechtzuerhalten.

Einordnung: Was der Ansturm für die Zukunft bedeutet

Den Berichten zufolge ist die aktuelle Situation ein deutliches Warnsignal für die Belastbarkeit offener digitaler Archive. Einzuordnen ist das so: Die schiere Masse an Bots, die nur noch zwei Prozent menschlichen Traffic zulässt, zeigt, wie sehr die automatisierte Datengewinnung die ursprüngliche Nutzung von Web-Ressourcen in den Schatten stellt. Dass die Systeme von Kernel.org derzeit noch nicht unter der Last zusammenbrechen, ist einerseits ein Erfolg der bisherigen Abwehrmaßnahmen, andererseits aber auch ein Zeichen dafür, dass die Kapazitäten noch ausreichen. Dennoch ist die Entwicklung kritisch zu betrachten. Wenn eine Infrastruktur, die für den Austausch von Wissen und Code zwischen Menschen geschaffen wurde, fast ausschließlich von Maschinen belegt wird, stellt sich die Frage nach der Nachhaltigkeit. Die Notwendigkeit, den Zugang durch mathematische Hürden zu erschweren, ist ein Eingriff in die Offenheit des Projekts, der jedoch notwendig erscheint, um die Funktionalität für die eigentliche Zielgruppe – die Softwareentwickler – zu bewahren. Es ist ein Wettlauf zwischen der Rechenleistung der Server und dem Hunger der KI-Modelle.

Offene Fragen: Was wir noch nicht wissen

Obwohl die Berichte von Konstantin Ryabitsev ein sehr detailliertes Bild der aktuellen Serverlast zeichnen, bleiben einige Punkte unklar. So geht aus dem Quelltext nicht hervor, welche spezifischen KI-Projekte oder Unternehmen hinter den aggressivsten Scraper-Clustern stecken. Es wird nicht benannt, ob es sich primär um große Tech-Konzerne oder um kleinere, spezialisierte KI-Startups handelt, die den Code abgreifen. Zudem bleibt offen, wie viele der blockierten Anfragen tatsächlich bösartige Absichten verfolgen und wie viele lediglich schlecht konfigurierte Bots von legitimen Nutzern sind, die ungewollt das System belasten. Auch die Frage, ob die bisherigen Maßnahmen wie das Anubis-System langfristig ausreichen werden, wenn die KI-Entwickler ihre Scraper weiter optimieren, wird im Text nicht beantwortet. Es fehlen konkrete Angaben darüber, ob eine weitergehende Einschränkung des Zugangs, etwa durch eine Registrierungspflicht, innerhalb der Linux Foundation bereits ernsthaft diskutiert wird oder ob man weiterhin auf technische Hürden wie mathematische Aufgaben setzt.

Wie es weitergeht: Maßnahmen und Abwehrstrategien

Um der drohenden Überlastung entgegenzuwirken, hat das Team von Kernel.org bereits das sogenannte Anubis-System implementiert. Dieses System zwingt Clients dazu, mathematische Gleichungen zu lösen, bevor sie Zugriff auf die Daten erhalten. Diese zusätzliche Rechenlast dient als Abschreckung für automatisierte Bots, die bei derartigen Hürden oft scheitern oder deren Betrieb durch die erschwerte Abfrage ineffizient wird. Die Strategie der Betreiber besteht derzeit darin, den Aufwand für die Scraper so weit in die Höhe zu treiben, dass sich das automatisierte Durchsuchen der 922 Forks nicht mehr lohnt. Da die Systeme aktuell noch stabil laufen, ist kurzfristig keine massive Änderung der Infrastruktur geplant, doch die Beobachtung des Traffics bleibt eine Daueraufgabe. Das Team wird weiterhin darauf angewiesen sein, die Abwehrmechanismen anzupassen, um auf neue Methoden der Scraper reagieren zu können. Die Entscheidung, ob weitere, drastischere Schritte zur Zugangsbeschränkung notwendig werden, hängt maßgeblich davon ab, wie sich das Verhältnis zwischen menschlichem Traffic und Bot-Anfragen in den kommenden Monaten entwickelt.