FreeBSD में मेरे पुराने MacBook के लिए Wi‑Fi ड्राइवर नहीं था, इसलिए AI ने एक बना दिया

• 2016 MacBook Pro में इस्तेमाल होने वाला Broadcom BCM4350 चिप FreeBSD में डिफ़ॉल्ट रूप से सपोर्टेड नहीं है, इसलिए पहले Linux VM के ज़रिए wifibox workaround आम तरीका था
• लेखक ने Claude Code का उपयोग करके Linux के brcmfmac ड्राइवर को FreeBSD पर पोर्ट करने की कोशिश की, लेकिन kernel panic और LinuxKPI compatibility issues की वजह से असफल रहे
• इसके बाद Pi coding agent का उपयोग करके brcmfmac के काम करने के तरीके का विश्लेषण किया गया, और BCM4350 के लिए 11 अध्यायों वाली तकनीकी specification AI ने तैयार की
• कई AI मॉडल्स (Opus, Codex, Gemini आदि) से cross-validation करके specification को सुधारा गया, और इसके आधार पर FreeBSD के लिए नया ड्राइवर पूरी तरह अपने-आप जनरेट किया गया
• अंतिम परिणाम Wi‑Fi scan, 2.4/5GHz connection, WPA/WPA2 authentication सपोर्ट करने वाले kernel module के रूप में तैयार हुआ, और कोड GitHub पर सार्वजनिक किया गया

---

पृष्ठभूमि

• 2016 MacBook Pro में Broadcom BCM4350 Wi‑Fi चिप इस्तेमाल होती है, लेकिन FreeBSD में इस चिप के लिए native driver नहीं है
  • FreeBSD फ़ोरम में आम तौर पर wifibox नाम के Linux VM के ज़रिए brcmfmac ड्राइवर इस्तेमाल करने का तरीका सुझाया जाता है
• brcmfmac Broadcom के FullMAC चिप्स के लिए Linux ड्राइवर है, जो 802.11 frame handling और WPA encryption जैसे काम चिप के अंदर के firmware को सौंप देता है
• FreeBSD के लिए native module बनाने के लिए Linux कोड के कुछ हिस्सों को FreeBSD के अनुरूप पोर्ट करने वाली “glue code” conversion की ज़रूरत होती है

Act 1 — Claude Code के साथ पहली कोशिश

• लेखक ने Claude Code का उपयोग करके brcmfmac कोड को FreeBSD के लिए बदलने की कोशिश की
  • FreeBSD की LinuxKPI compatibility layer को देखते हुए, उससे Intel के iwlwifi ड्राइवर जैसा तरीका अपनाने को कहा गया
• module compile तो हुआ, लेकिन असली hardware पर काम नहीं किया और kernel panic हुआ
• Claude ने #ifdef __FreeBSD__ statements जोड़कर बदलाव किए, लेकिन LinuxKPI की खामियों की वजह से यह फिर भी unstable रहा
• AI ने चेतावनी दी कि यह project “जटिल और बिखरा हुआ” हो जाएगा, और अंत में केवल काम न करने वाला कोड बचा

Act 2 — specification-आधारित approach

• इसके बाद Pi coding agent का उपयोग करके BCM4350-केंद्रित brcmfmac ड्राइवर संरचना का विश्लेषण कराया गया, और clean-room implementation के लिए विस्तृत specification तैयार कराई गई
• AI ने 11 अध्यायों वाला document बनाया
  • उदाहरण: 00-overview.md, 04-firmware-interface.md, 08-data-path.md आदि
• लेखक ने Codex model का उपयोग करके specification और असली कोड के बीच के mismatch की जाँच की और उन्हें ठीक किया
• फिर Opus model से दोबारा validation करके सुनिश्चित किया गया कि बदलाव कोड से मेल खाते हैं
• कई मॉडल्स की तुलना में, Gemini 3 Pro preview में सबसे ज़्यादा errors (“hallucination”) पाए गए, ऐसा उल्लेख किया गया

Act 3 — नया FreeBSD ड्राइवर बनाना

• specification के आधार पर BCM4350 के लिए नया FreeBSD ड्राइवर लिखने का project शुरू किया गया
• AI ने project structure, language (C का उपयोग करना है या नहीं), LinuxKPI dependency, milestones जैसी design decisions को document किया
• शुरुआत में LinuxKPI का उपयोग किया गया, लेकिन बढ़ती complexity के कारण बाद में native FreeBSD code पर स्विच किया गया
• AI ने SSH के ज़रिए build host और test VM तक पहुँचकर automated build-test loop चलाया
  • VM crash होने पर हर बार कारण का सारांश बनाकर रिकॉर्ड करने के लिए सेट किया गया
• कई sessions की पुनरावृत्ति के बाद Wi‑Fi scan, 2.4GHz/5GHz connection, WPA/WPA2 authentication करने वाला kernel module तैयार हो गया

परिणाम और सार्वजनिक रिलीज़

• पूरा हुआ ड्राइवर GitHub repository github.com/narqo/freebsd-brcmfmac में सार्वजनिक किया गया
• लेखक ने स्पष्ट रूप से कहा कि “उन्होंने खुद कोड नहीं लिखा”
• कुछ ज्ञात समस्याएँ अभी भी बाकी हैं, और फ़िलहाल इसे केवल सीखने के संदर्भ के रूप में उपयोग करने की सलाह दी गई है

[heal9179]

सिक्योरिटी में बड़े-बड़े छेद~

[gg5823]

ऐसा करने के बाद उसे security-harden करके, review करवाकर, कम से कम upstream में PR तो छोड़ना चाहिए था, या अपने GitHub पर उसे और मजबूत करके BSD community में ठीक से बताना चाहिए था; अगर बात वहीं खत्म कर दी, तो उसकी sincerity पर मुझे ज़्यादा भरोसा नहीं होता। अगर वह सचमुच का user है, तो security के gaps हाथ से भरेगा, और अगर Windows आराम से इस्तेमाल करते हुए शौक में दूसरे OS के साथ खेलने वाला है, तो फिर छोड़ भी देगा। 2016 मॉडल होने को देखकर लगता है कि मामला दूसरा वाला ही है।

[GN⁺]

Hacker News टिप्पणियाँ

• मेरी नज़र में spec-first approach ही मुख्य insight है
  AI code generation में अगर मॉडल implementation से पहले एक detailed spec लिखे, तो iteration cycle काफ़ी कम हो जाती है
  spec के बिना शुरू करने पर मॉडल plausible approaches के बीच भटकता रहता है, लेकिन अच्छी spec हो तो हज़ारों lines के code में भी consistency बनी रहती है
  दो महीने की development timeline भी दिलचस्प है। यह मानो एक नया kernel driver बन जाने जैसा है, तो अगर API call cost लगभग 500 डॉलर रही हो, तब भी यह पूरी तरह worthwhile experiment है

• code की बजाय एक नया Pi session खोलकर agent से brcmfmac driver की detailed spec लिखवाने वाली बात प्रभावशाली लगी
  इस तरह के planning documents (markdown) बड़े LLM tasks में सचमुच बहुत महत्वपूर्ण होते हैं

  • मुझे लगता है कि AI-assisted reverse engineering और open source license laundering के बीच की रेखा बहुत पतली है
    लेख में बताया गया मामला शायद उस रेखा को पार कर गया है। पारंपरिक clean-room design में एक टीम code नहीं, सिर्फ़ interface को document करती है

• मेरा भी ऐसा ही अनुभव रहा है। QEMU पुराने MacOS (M1 architecture) पर अब compile नहीं हो रहा था, लेकिन Sonnet 4.6 को देने पर उसने कुछ ही मिनटों में patch लिख दिया और install भी कर दिया
  मैंने बस error दिखाकर उसे fix करने को कहा था, और उसने बिल्कुल सही हल कर दिया। सच कहूँ तो AI न होता तो शायद मैं हार मान लेता

  • जानना चाहूँगा कि आपने कौन सा prompt इस्तेमाल किया
  • यह भी जानना चाहूँगा कि क्या आप वह patch code साझा कर सकते हैं

• आगे चलकर शायद ऐसा समय आएगा जब लोग software खरीदने के बजाय खुद बना लेंगे
  Thunderbird का spam filter ख़राब हो गया था, तो मैंने खुद नया बना लिया, और वह कहीं बेहतर काम करता है
  अगर CRM में मनचाहा feature नहीं है, तो उसे खुद बनाया जा सकता है। अब अपने ही problems को solve करने वाले custom solutions को आसानी से बनाना और deploy करना संभव होता जा रहा है

  • व्यावहारिक तौर पर शायद ऐसा सिर्फ़ कुछ लोग ही करेंगे, वही लोग जिन्हें पहले से चीज़ें बनाना पसंद है
    मेरे परिवार जैसे non-technical लोग अब भी app store या websites ही इस्तेमाल करेंगे
  • यह कुछ वैसा ही है जैसा 3D printers के आने पर कहा गया था कि “अब लोग चीज़ें खरीदेंगे नहीं, खुद print करेंगे”
    standardized software के फ़ायदे भी बड़े हैं। कंपनियाँ Photoshop या Xero जैसे tools पहले से जानने वाले लोगों को hire कर सकती हैं
  • मैं भी सहमत हूँ। AI से सीधे modify या patch कर लेना, issue file करने, PR भेजने और review का इंतज़ार करने से कहीं तेज़ है
  • मैं तो यह क्षमता चाहता हूँ कि existing software को AI से modify कर सकूँ। यह इच्छा बहुत पहले से थी, लेकिन अब plugins शायद फिर से लोकप्रिय हो सकते हैं
  • लेकिन यह कुछ हद तक भोला नज़रिया है। ज़्यादातर लोग HN पर नहीं हैं। tech community के बाहर की राय भी सुननी चाहिए

• जल्द ही हर OS में hardware support की समस्या पूरी तरह सुलझी हुई लग सकती है
  AI coding agents इतनी तेज़ी से आगे बढ़ रहे हैं कि वे किसी भी device के लिए driver बना सकें
  जब तक hardware manufacturer जानबूझकर interface नहीं छिपाता, BSD या Linux support स्वाभाविक रूप से आ ही जाएगा

  • यह इसलिए संभव हुआ क्योंकि Claude ने Linux driver को reference किया। अगर existing code ही न हो, तो AI के लिए अपने दम पर hardware को समझना मुश्किल है
  • अभी वह समय काफ़ी दूर है। असल में यह Linux driver को FreeBSD के लिए बदलने का काम था, और AI इसे पूरी तरह अपने आप नहीं कर पाया
    उल्टा, इंसानी management और review की भूमिका और भी महत्वपूर्ण हो गई
  • अब तो लगता है कि GPL की पाबंदियाँ भी AI के सामने बेअसर हो रही हैं
  • कुछ drivers सरल होते हैं, लेकिन कुछ इतने जटिल होते हैं कि टीम-स्तर पर छह महीने या उससे ज़्यादा लग जाते हैं
  • “AI सारे drivers बना सकती है” कहना ज़रूरत से ज़्यादा सरलीकरण है। हक़ीक़त में उसकी reliability साबित नहीं हुई है, और वह proprietary drivers का विकल्प भी नहीं है

• software जिस रफ़्तार से दुनिया को खा रहा था, अब वह और तेज़ हो रहा है
  अब vibe-coded software हर जगह उभर सकता है, और लोग शायद उसे बिना ज़्यादा सोचे इस्तेमाल भी करेंगे
  समस्या यह है कि उसमें malware मिला हुआ code भी आ सकता है। फिर उसका पूरा verification कौन करेगा?

  • आगे शायद one-off software बहुत बढ़ेगा
    जैसे आपको concert tickets खरीदनी हों, तो AI agent उसी समय code बनाकर चलाएगा
    अगले साल फिर खरीदने पर API version के हिसाब से नया code regenerate कर देगा
    यह wasteful लग सकता है, लेकिन संरचना कहीं ज़्यादा dynamic और flexible होगी
    आख़िरकार vendor को सिर्फ़ API देनी होगी, और user के पास अपना UI हो सकता है
  • अंत में लोग उन क्षेत्रों को अलग-अलग समझने लगेंगे जहाँ AI द्वारा बनाया और चलाया गया software सुरक्षित है, और जहाँ इंसानी verification ज़रूरी है
    उदाहरण के लिए, अपना board game collection management app मैं AI को दे सकता हूँ, लेकिन finance या security वाले apps मैं experts के बनाए हुए ही इस्तेमाल करूँगा

• AI से बना kernel module ring 0 में load हो रहा है, और बनाने वाला खुद कह रहा है कि “इसमें बहुत समस्याएँ हैं, इसलिए production use मत करो”
  ऐसा लग रहा है जैसे हम “मूल रूप से असुरक्षित युग” को रफ़्तार के सहारे पार करने की कोशिश कर रहे हों

  • अगर मैं superintelligent AI होता, तो शायद Wi-Fi driver के ज़रिए बाहर निकलने की कोशिश करता
  • manufacturer open source drivers या documentation नहीं देते, इसलिए ऐसी स्थिति पैदा होती है
    फिर भी कुछ न होने से यह बेहतर है, और code public है, इसलिए इसे सुधारा भी जा सकता है
  • security महत्वपूर्ण है, लेकिन experiment करने और साझा करने की स्वतंत्रता भी ज़रूरी है
    हर GitHub project का commercial product होना आवश्यक नहीं है

• यह काम मौजूदा implementation का उपयोग करने वाले porting effort के ज़्यादा क़रीब है
  GPL के नज़रिए से यह ‘inspiration’ के स्तर का है या ‘based on’ के स्तर का, इसकी तुलना करना दिलचस्प होगा
  कंपनियों में भी, अगर existing implementation हो तो लोग आत्मविश्वास से आगे बढ़ते हैं, लेकिन पहली बार रास्ता खोलने वाले लोग अक्सर मान्यता नहीं पाते

• लेखक ने कहा कि “मैंने खुद code नहीं लिखा, इसमें बहुत bugs हैं, और इसे सिर्फ़ learning material की तरह देखें”
  कई महीनों में तीन कोशिशों के बाद यह मुश्किल से चलने लायक हुआ, लेकिन कुछ लोग इसे “AI ने programming पर विजय पा ली” कहकर बढ़ा-चढ़ाकर बता रहे हैं
  असल में यह एक अच्छा लेख है, लेकिन सिर्फ़ शीर्षक देखकर ग़लत समझ लेने वाली टिप्पणियाँ बहुत हैं

  • लेखक ने यह भी कहा कि उसने code ठीक से पढ़ा तक नहीं, और यह बस एक experimental toy था
  • अभी यह अधूरा है, लेकिन पहली बार संभव होने के चरण तक पहुँचना ही महत्वपूर्ण है
    hardware या driver knowledge के बिना काम करने वाला driver बना लेना अपने आप में एक नया milestone है
  • bugs हों तब भी FreeBSD kernel driver का उपयोग कर सकने वाले developers बहुत कम हैं
    ऐसे नतीजे starting point के रूप में बहुत मायने रखते हैं
  • programmers हमेशा abstraction की नई layers खोजते आए हैं। LLM coding उसी प्रवाह की अगली कड़ी है
  • “हर interaction पर LLM code generate करता है” वाली बात कुछ-कुछ GPU upscaling जैसी दक्ष illusion है
    जैसे high resolution में सीधे render करने के बजाय GPU बीच का अंतर ‘विश्वसनीय रूप से’ भर देता है

• अच्छा होगा अगर Asahi Linux के लिए modern Mac drivers मिलें। मुझे लगता है यह AI के अच्छे इस्तेमाल का उदाहरण है

  • लेकिन हम copyright issues की वजह से AI code generation पर रोक रखते हैं
    यह नकारा नहीं जा सकता कि AI ने Apple documentation या binaries से सीखा हो, और generated code की license compatibility की भी गारंटी नहीं है
  • Mac के लिए open source drivers नहीं हैं, इसलिए जब तक AI खुद hardware को observe करके समझना न सीख ले, यह संभव नहीं है
  • यह कुछ ऐसा है जैसे शिकायत करना कि “DeLorean ने time machine के parts नहीं दिए”