FreeBSD hatte keinen Wi-Fi-Treiber für mein altes MacBook, also hat eine KI einen erstellt

 (vladimir.varank.in)
11 Punkte von GN⁺ 2026-02-24 | 3 Kommentare | Auf WhatsApp teilen
  • Der Broadcom-BCM4350-Chip im MacBook Pro von 2016 wird unter FreeBSD nativ nicht unterstützt; bislang war ein wifibox-Workaround über eine Linux-VM die übliche Lösung
  • Der Autor versuchte mit Claude Code, den Linux-Treiber brcmfmac auf FreeBSD zu portieren, scheiterte jedoch an Kernel-Panics und LinuxKPI-Kompatibilitätsproblemen
  • Anschließend nutzte er den Pi coding agent, um die Funktionsweise von brcmfmac zu analysieren; die KI verfasste daraufhin eine 11 Kapitel umfassende technische Spezifikation speziell für den BCM4350
  • Nach einer Gegenprüfung und Ergänzung der Spezifikation mit mehreren KI-Modellen (Opus, Codex, Gemini usw.) wurde auf dieser Basis ein neuer Treiber für FreeBSD vollständig automatisch generiert
  • Das Ergebnis ist ein Kernel-Modul mit Unterstützung für Wi-Fi-Scans, 2,4/5-GHz-Verbindungen und WPA/WPA2-Authentifizierung; der Code wurde auf GitHub veröffentlicht

Hintergrund

  • Das MacBook Pro von 2016 verwendet den Broadcom-BCM4350-Wi-Fi-Chip, doch FreeBSD besitzt keinen nativen Treiber für diesen Chip
    • In FreeBSD-Foren wird üblicherweise die Nutzung des brcmfmac-Treibers über wifibox, also eine Linux-VM, empfohlen
  • brcmfmac ist ein Linux-Treiber für Broadcom-FullMAC-Chips, der Aufgaben wie die Verarbeitung von 802.11-Frames und WPA-Verschlüsselung an die interne Firmware des Chips delegiert
  • Um ein natives Modul für FreeBSD zu erstellen, muss ein Teil des Linux-Codes als „Glue Code“ an FreeBSD angepasst werden

Act 1 — Erster Versuch mit Claude Code

  • Der Autor versuchte mit Claude Code, den brcmfmac-Code für FreeBSD umzuwandeln
    • Dabei bat er darum, sich an der LinuxKPI-Kompatibilitätsschicht von FreeBSD zu orientieren und dem Ansatz des Intel-Treibers iwlwifi zu folgen
  • Das Modul ließ sich kompilieren, funktionierte auf echter Hardware jedoch nicht und verursachte Kernel-Panics
  • Claude nahm Korrekturen vor und fügte #ifdef __FreeBSD__-Blöcke hinzu, doch wegen Mängeln in LinuxKPI blieb das Ergebnis instabil
  • Die KI warnte, das Projekt werde „komplex und unübersichtlich“ werden; übrig blieb letztlich nicht funktionierender Code

Act 2 — Spezifikationsbasierter Ansatz

  • Danach nutzte der Autor den Pi coding agent, um die Struktur des brcmfmac-Treibers mit Fokus auf den BCM4350 zu analysieren und eine detaillierte Spezifikation für eine Clean-Room-Implementierung erstellen zu lassen
  • Die KI erzeugte ein Dokument mit 11 Kapiteln
    • Beispiele: 00-overview.md, 04-firmware-interface.md, 08-data-path.md usw.
  • Mit dem Codex-Modell prüfte und korrigierte der Autor anschließend Abweichungen zwischen Spezifikation und tatsächlichem Code
  • Danach erfolgte eine erneute Validierung mit dem Opus-Modell, um sicherzustellen, dass die Korrekturen mit dem Code übereinstimmen
  • Beim Vergleich mehrerer Modelle wird erwähnt, dass Gemini 3 Pro preview die meisten Fehler bzw. „Halluzinationen“ gezeigt habe

Act 3 — Aufbau eines neuen FreeBSD-Treibers

  • Auf Basis der Spezifikation begann ein neues Projekt, um einen FreeBSD-Treiber für den BCM4350 von Grund auf neu zu schreiben
  • Die KI dokumentierte Architekturentscheidungen wie Projektstruktur, Sprache (ob C verwendet wird), LinuxKPI-Abhängigkeiten und Meilensteine
  • Anfangs wurde LinuxKPI genutzt, später wegen wachsender Komplexität jedoch auf nativen FreeBSD-Code umgestellt
  • Die KI griff per SSH auf den Build-Host und eine Test-VM zu und führte eine automatisierte Build- und Testschleife aus
    • Die Umgebung war so konfiguriert, dass bei jedem VM-Absturz die Ursache zusammengefasst und protokolliert wurde
  • Nach mehreren iterativen Sitzungen entstand ein Kernel-Modul, das Wi-Fi-Scans, 2,4-GHz-/5-GHz-Verbindungen und WPA/WPA2-Authentifizierung beherrscht

Ergebnis und Veröffentlichung

  • Der fertige Treiber wurde im GitHub-Repository github.com/narqo/freebsd-brcmfmac veröffentlicht
  • Der Autor stellt ausdrücklich klar, dass er „den Code nicht selbst geschrieben“ habe
  • Einige bekannte Probleme bestehen weiterhin; derzeit wird empfohlen, den Treiber nur zu Lern- und Referenzzwecken zu verwenden

Verwandte Beiträge

3 Kommentare

 
heal9179 2026-02-24

Voller von Sicherheitslücken~
 
gg5823 2026-02-26

Dann hätte man es auch so entwickeln, absichern und prüfen können, dass man zumindest einen PR upstream hinterlässt, oder es im eigenen GitHub weiter härten und in der BSD-Community gut bekannt machen können. Wenn es dort geendet hat, bin ich mir bei der Ernsthaftigkeit nicht so sicher. Ein echter Nutzer würde Sicherheitslücken wohl manuell stopfen, und jemand, der Windows ganz normal nutzt und nur aus Hobby mit anderen Betriebssystemen herumspielt, würde es eher wieder aufgeben. Wenn man sieht, dass es ein Modell von 2016 ist, wirkt Letzteres wahrscheinlicher.
 
GN⁺ 2026-02-24
Hacker-News-Kommentare

  • Für mich ist der spec-first-Ansatz die zentrale Erkenntnis
    Wenn man das Modell bei der KI-Codegenerierung vor der Implementierung zuerst eine detaillierte Spezifikation schreiben lässt, verkürzt das die Iterationszyklen erheblich
    Ohne Spezifikation irrt das Modell zwischen scheinbar plausiblen Ansätzen herum, aber mit einer guten Spezifikation bleibt es auch über Tausende Zeilen Code hinweg konsistent
    Auch die Entwicklungszeit von zwei Monaten ist interessant. Es ist praktisch ein neuer Kernel-Treiber entstanden, also ist das bei API-Kosten von rund 500 Dollar ein durchaus lohnendes Experiment

  • Beeindruckend fand ich den Teil, in dem statt des Codes eine neue Pi-Session geöffnet und der Agent beauftragt wurde, eine detaillierte Spezifikation des brcmfmac-Treibers zu schreiben
    Das Erstellen solcher Planungsdokumente (Markdown) ist bei großen LLM-Aufgaben wirklich wichtig

    • Ich finde, die Grenze zwischen KI-gestütztem Reverse Engineering und Open-Source-Lizenzwäsche ist sehr schmal
      Der im Artikel beschriebene Fall scheint diese Grenze überschritten zu haben. Beim traditionellen Cleanroom-Design dokumentiert ein Team nur die Schnittstelle, nicht den Code

  • Ich hatte eine ähnliche Erfahrung. QEMU ließ sich auf älteren MacOS-Versionen (M1-Architektur) nicht mehr kompilieren, aber Sonnet 4.6 hat in wenigen Minuten einen Patch geschrieben und die Installation abgeschlossen
    Ich habe nur angewiesen, den Fehler zu sehen und zu beheben, und es hat das Problem perfekt gelöst. Ehrlich gesagt hätte ich ohne KI wohl einfach aufgegeben

    • Mich würde interessieren, welchen Prompt du verwendet hast
    • Mich würde interessieren, ob du diesen Patch-Code teilen kannst

  • Ich glaube, es kommt eine Zeit, in der Menschen Software nicht mehr kaufen, sondern selbst erstellen
    Der Spamfilter von Thunderbird war kaputt, also habe ich selbst einen neuen gebaut, und der funktioniert viel besser
    Wenn ein CRM die gewünschte Funktion nicht hat, baut man sie eben selbst. Es wird immer einfacher werden, maßgeschneiderte Lösungen zur Lösung eigener Probleme zu erstellen und bereitzustellen

    • Realistisch gesehen werden das wohl nur manche Leute tun, nämlich die, die ohnehin schon gern etwas bauen
      Menschen wie meine Familie, die in nichttechnischen Berufen arbeiten, werden weiterhin den App Store oder Websites nutzen
    • Das ist ein bisschen so wie damals bei den ersten 3D-Druckern, als es hieß: „Jetzt kauft niemand mehr Dinge, wir drucken sie einfach selbst“
      Standardisierte Software hat ebenfalls große Vorteile. Unternehmen können Leute einstellen, die Werkzeuge wie Photoshop oder Xero bereits kennen
    • Dem stimme ich zu. Mit KI direkt Änderungen oder Patches zu machen ist viel schneller, als ein Issue zu erstellen, einen PR zu öffnen und auf Review zu warten
    • Was ich möchte, ist die Fähigkeit, bestehende Software mit KI zu modifizieren. Das wollte ich schon lange, und jetzt könnten Plugins wieder populär werden
    • Das ist aber eine etwas naive Sichtweise. Die meisten Menschen sind nicht auf HN. Man sollte auch Meinungen außerhalb der Tech-Community anhören

  • Bald dürfte Hardware-Unterstützung in allen Betriebssystemen vollständig gelöst sein
    KI-Coding-Agenten entwickeln sich dahin, für praktisch jedes Gerät Treiber erzeugen zu können
    Solange Hardwarehersteller die Schnittstellen nicht absichtlich verstecken, wird Unterstützung für BSD oder Linux ganz natürlich folgen

    • Möglich wurde das hier, weil Claude auf Linux-Treiber zurückgegriffen hat. Ohne vorhandenen Code kann KI Hardware nur schwer eigenständig verstehen
    • So weit sind wir noch nicht. In der Praxis war es eine Aufgabe, einen Linux-Treiber für FreeBSD umzuschreiben, und selbst das hat die KI nicht vollständig geschafft.
      Tatsächlich ist die Rolle des Menschen bei Steuerung und Prüfung noch wichtiger geworden
    • Es fühlt sich inzwischen so an, als würden selbst die Beschränkungen der GPL gegenüber KI wirkungslos werden
    • Manche Treiber sind simpel, andere aber so komplex, dass Teams ein halbes Jahr oder länger daran arbeiten
    • Zu sagen, „KI kann alle Treiber schreiben“, ist viel zu simpel gedacht. In der Praxis ist die Stabilität noch nicht verifiziert, und als Ersatz für proprietäre Treiber taugt das noch nicht

  • Die Geschwindigkeit, mit der Software die Welt auffrisst, nimmt noch weiter zu
    Jetzt wird überall vibe-coded Software auftauchen, und die Leute werden sie wohl ohne große Skepsis verwenden
    Das Problem ist, dass dabei auch Code mit Malware-Anteilen herauskommen kann. Wer soll das alles prüfen?

    • In Zukunft wird es wohl viel Einweg-Software geben
      Wenn ich zum Beispiel Konzerttickets kaufen will, erzeugt und startet ein KI-Agent den Code dafür spontan
      Kaufe ich im nächsten Jahr wieder welche, wird der Code passend zur API-Version neu generiert
      Das wirkt verschwenderisch, ist aber eine viel dynamischere und flexiblere Struktur
      Am Ende muss der Anbieter nur noch eine API bereitstellen, und die Nutzer können ihre eigene UI haben
    • Am Ende werden die Menschen wohl zwischen Bereichen unterscheiden, in denen KI sicher Software erzeugen und ausführen darf, und Bereichen, die man selbst verifizieren muss
      Meine App zur Verwaltung meiner Brettspielsammlung würde ich zum Beispiel einer KI überlassen, bei Finanz- oder Sicherheitsanwendungen aber auf von Fachleuten entwickelte Software setzen

  • Ein von KI erzeugtes Kernel-Modul wird in Ring 0 geladen, und selbst der Ersteller sagt: „Viele Probleme, also nicht produktiv einsetzen“
    Es fühlt sich an, als würden wir mit Tempo in ein Zeitalter der „grundsätzlich unsicheren Systeme“ hineinrasen

    • Wenn ich eine superintelligente KI wäre, würde ich wahrscheinlich versuchen, über einen Wi-Fi-Treiber auszubrechen
    • Das ist das Ergebnis davon, dass der Hersteller weder Open-Source-Treiber noch Dokumentation bereitstellt
      Trotzdem ist es besser als gar nichts zu tun, und weil der Code offenliegt, kann er auch verbessert werden
    • Sicherheit ist wichtig, aber auch die Freiheit zum Experimentieren und Teilen
      Nicht jedes GitHub-Projekt muss ein kommerzielles Produkt sein

  • Diese Arbeit kommt eher einem Portierungsprojekt gleich, das auf einer bestehenden Implementierung aufsetzt
    Aus GPL-Sicht wäre es interessant zu vergleichen, ob das eher auf Ebene von „Inspiration“ oder von „Grundlage“ liegt
    Auch in Unternehmen geht man selbstbewusst voran, wenn es bereits eine bestehende Implementierung gibt, aber die Leute, die als Erste Neuland betreten, bekommen kaum Anerkennung

  • Der Autor sagte, er habe „den Code nicht selbst geschrieben, er habe viele Bugs und sei nur zu Lernzwecken gedacht“
    Nach drei Versuchen über mehrere Monate hinweg läuft es gerade so eben, aber manche übertreiben schon mit Aussagen wie „KI hat Programmierung erobert“
    In Wirklichkeit ist es ein guter Artikel, aber es gibt viele Kommentare, die nur anhand der Überschrift missverstehen, worum es geht

    • Der Autor sagte auch, er habe den Code nicht einmal richtig gelesen und es sei nur ein einfaches experimentelles Spielzeug gewesen
    • Es ist zwar noch unvollständig, aber wichtig ist, dass es der erste mögliche Schritt ist
      Dass ein funktionierender Treiber ohne Hardware- oder Treiberwissen gebaut wurde, ist ein neuer Meilenstein
    • Selbst mit Bugs gibt es nur sehr wenige Entwickler, die überhaupt einen FreeBSD-Kernel-Treiber schreiben können
      Als Ausgangspunkt hat so ein Ergebnis große Bedeutung
    • Programmierer haben schon immer nach neuen Abstraktionsebenen gesucht. LLM-Coding ist eine Fortsetzung dieser Entwicklung
    • Die Aussage, „bei jeder Interaktion erzeugt ein LLM den Code“, ist eine effiziente Illusion, ähnlich wie GPU-Upscaling
      Statt direkt in hoher Auflösung zu rendern, füllt die GPU die Unterschiede auf geradezu „illusorische“ Weise auf

  • Ich hätte gern aktuelle Mac-Treiber für Asahi Linux. Ich finde, das ist ein gutes Beispiel für sinnvollen KI-Einsatz

    • Aber wir verbieten KI-Codegenerierung wegen Urheberrechtsproblemen
      Man kann nicht ausschließen, dass die KI auf Apple-Dokumente oder Binärdateien trainiert wurde, und auch die Lizenzkompatibilität des erzeugten Codes ist nicht garantiert
    • Für den Mac gibt es keine Open-Source-Treiber, daher ist das unmöglich, solange die KI die Hardware nicht selbst beobachtet und versteht
    • Das ist ungefähr so, als würde man sich beschweren, dass „der DeLorean keine Teile für eine Zeitmaschine gebaut hat“