FreeBSD tidak punya driver Wi‑Fi untuk MacBook lama saya, jadi AI yang membuatkannya

 (vladimir.varank.in)
11 poin oleh GN⁺ 2026-02-24 | 3 komentar | Bagikan ke WhatsApp
  • Chip Broadcom BCM4350 pada MacBook Pro 2016 tidak didukung secara bawaan di FreeBSD, sehingga sebelumnya pendekatan umum adalah solusi bypass wifibox melalui Linux VM
  • Penulis mencoba mem-porting driver Linux brcmfmac ke FreeBSD dengan Claude Code, tetapi gagal karena kernel panic dan masalah kompatibilitas LinuxKPI
  • Setelah itu ia menggunakan Pi coding agent untuk menganalisis cara kerja brcmfmac dan AI menulis spesifikasi teknis 11 bab khusus untuk BCM4350
  • Setelah menyempurnakan spesifikasi lewat validasi silang beberapa model AI (Opus, Codex, Gemini, dll.), ia lalu menghasilkan driver baru untuk FreeBSD secara otomatis penuh berdasarkan dokumen tersebut
  • Hasil akhirnya berupa modul kernel yang mendukung pemindaian Wi‑Fi, koneksi 2.4/5GHz, autentikasi WPA/WPA2, dan kodenya dipublikasikan di GitHub

Latar belakang

  • MacBook Pro 2016 menggunakan chip Wi‑Fi Broadcom BCM4350, tetapi FreeBSD tidak memiliki driver native untuk chip tersebut
    • Di forum FreeBSD, metode yang umum disarankan adalah memakai wifibox, yaitu menggunakan driver brcmfmac lewat Linux VM
  • brcmfmac adalah driver Linux untuk chip FullMAC Broadcom, yang menyerahkan tugas seperti pemrosesan frame 802.11 dan enkripsi WPA ke firmware di dalam chip
  • Untuk membuat modul native FreeBSD, diperlukan konversi “glue code” yang mem-porting sebagian kode Linux agar sesuai dengan FreeBSD

Act 1 — Percobaan pertama dengan Claude Code

  • Penulis mencoba menggunakan Claude Code untuk mengonversi kode brcmfmac ke FreeBSD
    • Ia meminta agar pendekatannya mengikuti cara driver iwlwifi untuk Intel dengan merujuk pada lapisan kompatibilitas LinuxKPI di FreeBSD
  • Modulnya berhasil dikompilasi, tetapi tidak berjalan di perangkat keras nyata dan memicu kernel panic
  • Claude menambahkan blok #ifdef __FreeBSD__ saat melakukan perbaikan, tetapi tetap tidak stabil karena kekurangan pada LinuxKPI
  • AI memperingatkan bahwa proyek ini akan menjadi “rumit dan berantakan”, dan pada akhirnya hanya menyisakan kode yang tidak bekerja

Act 2 — Pendekatan berbasis spesifikasi

  • Setelah itu, penulis memakai Pi coding agent untuk menganalisis struktur driver brcmfmac dengan fokus pada BCM4350, lalu memintanya menulis spesifikasi rinci untuk implementasi clean-room
  • AI menghasilkan dokumen yang terdiri dari 11 bab
    • Contoh: 00-overview.md, 04-firmware-interface.md, 08-data-path.md dan lainnya
  • Penulis menggunakan model Codex untuk memverifikasi dan memperbaiki ketidaksesuaian antara spesifikasi dan kode aktual
  • Lalu ia melakukan verifikasi ulang dengan model Opus untuk memastikan perubahan tersebut konsisten dengan kode
  • Dari perbandingan beberapa model, disebutkan bahwa Gemini 3 Pro preview menunjukkan paling banyak kesalahan (“hallucination”)

Act 3 — Membangun driver FreeBSD baru

  • Berdasarkan spesifikasi tersebut, ia memulai proyek menulis driver FreeBSD baru untuk BCM4350
  • AI mendokumentasikan keputusan desain seperti struktur proyek, bahasa yang dipakai (apakah menggunakan C), dependensi LinuxKPI, dan milestone
  • Awalnya proyek memakai LinuxKPI, tetapi karena kompleksitas meningkat, kemudian beralih ke kode FreeBSD native
  • AI mengakses host build dan VM pengujian melalui SSH untuk menjalankan loop build dan test otomatis
    • Setiap kali VM crash, AI diatur untuk merangkum dan mencatat penyebabnya
  • Setelah beberapa sesi iterasi, berhasil dibuat modul kernel yang mendukung pemindaian Wi‑Fi, koneksi 2.4GHz/5GHz, dan autentikasi WPA/WPA2

Hasil dan publikasi

  • Driver yang sudah selesai dipublikasikan di repositori GitHub github.com/narqo/freebsd-brcmfmac
  • Penulis menegaskan bahwa ia “tidak menulis kode secara langsung”
  • Masih ada beberapa masalah yang diketahui, dan saat ini disarankan untuk memakainya hanya sebagai referensi pembelajaran

Bacaan terkait

3 komentar

 
heal9179 2026-02-24

Lubang keamanannya menganga lebar~
 
gg5823 2026-02-26

Seharusnya setelah dibuat seperti itu, keamanannya diperkuat, ditinjau, lalu setidaknya diajukan PR ke upstream, atau diperkuat lagi di GitHub pribadinya dan disebarluaskan dengan baik ke komunitas BSD. Kalau berhenti sampai di situ, saya kurang yakin dengan ketulusannya. Kalau benar-benar pengguna, dia akan menambal celah keamanan secara manual, dan kalau dia orang yang sehari-hari nyaman pakai Windows lalu cuma main-main dengan OS lain sebagai hobi, ya kemungkinan akan ditelantarkan. Melihat itu model tahun 2016, sepertinya yang kedua.
 
GN⁺ 2026-02-24
Komentar Hacker News

  • Menurut saya, wawasan kuncinya adalah pendekatan spec-first
    Dalam pembuatan kode dengan AI, jika model diminta menulis spesifikasi terperinci dulu sebelum implementasi, siklus iterasinya berkurang drastis
    Jika mulai tanpa spesifikasi, model akan tersesat di antara pendekatan-pendekatan yang tampak masuk akal, tetapi dengan spesifikasi yang baik ia bisa menjaga konsistensi bahkan dalam ribuan baris kode
    Jangka waktu pengembangan dua bulan juga menarik. Ini pada dasarnya berarti ada driver kernel baru, jadi jika biaya panggilan API sekitar $500, itu eksperimen yang sangat layak

  • Bagian ketika ia membuka sesi Pi baru alih-alih menulis kode, lalu meminta agen menulis spesifikasi detail untuk driver brcmfmac, sangat mengesankan
    Menulis dokumen perencanaan (markdown) seperti ini benar-benar penting untuk pekerjaan LLM skala besar

    • Saya pikir batas antara reverse engineering berbantuan AI dan pencucian lisensi open source sangat tipis
      Kasus yang dijelaskan di artikel tampaknya sudah melewati batas itu. Dalam desain clean room tradisional, satu tim hanya mendokumentasikan interface, bukan kodenya

  • Saya juga punya pengalaman serupa. QEMU tidak lagi bisa dikompilasi di MacOS lama (arsitektur M1), lalu saya menyerahkannya ke Sonnet 4.6 dan dalam beberapa menit ia menulis patch lalu menyelesaikan instalasinya
    Saya hanya memberi instruksi untuk melihat error dan memperbaikinya, tetapi hasilnya sempurna. Sejujurnya tanpa AI saya mungkin sudah menyerah

    • Saya penasaran prompt apa yang digunakan
    • Saya penasaran apakah kode patch itu bisa dibagikan

  • Ke depannya, sepertinya kita akan masuk ke era ketika orang tidak membeli software, melainkan membuatnya sendiri
    Filter spam Thunderbird rusak, jadi saya membuat yang baru sendiri dan hasilnya jauh lebih baik
    Jika CRM tidak punya fitur yang Anda inginkan, Anda tinggal membuatnya sendiri. Sekarang kita akan bisa dengan mudah membuat dan mendistribusikan solusi kustom untuk menyelesaikan masalah masing-masing

    • Secara realistis, sepertinya hanya sebagian orang yang akan melakukannya. Yaitu orang-orang yang memang sejak awal suka membuat sesuatu
      Orang-orang nonteknis seperti keluarga saya tetap akan memakai app store atau website
    • Ini mirip seperti saat printer 3D pertama kali muncul dan orang berkata, “sekarang kita tidak akan membeli barang, kita akan mencetaknya sendiri”
      Keunggulan software yang terstandarisasi juga besar. Perusahaan bisa merekrut orang yang sudah mengenal tool seperti Photoshop atau Xero
    • Saya juga setuju. Memodifikasi atau membuat patch sendiri dengan AI jauh lebih cepat daripada membuat issue, mengirim PR, dan menunggu review
    • Yang saya inginkan adalah kemampuan untuk memodifikasi software yang sudah ada dengan AI. Saya sudah lama menginginkannya, dan sekarang plugin mungkin bisa populer lagi
    • Tetapi ini agak pandangan yang naif. Kebanyakan orang tidak ada di HN. Kita juga perlu mendengar pendapat dari luar komunitas teknis

  • Sepertinya sebentar lagi dukungan hardware akan sepenuhnya terselesaikan di semua OS
    Agen coding AI berkembang sampai bisa membuat driver untuk perangkat apa pun
    Kecuali produsen hardware sengaja menyembunyikan interface, dukungan BSD atau Linux akan mengikuti secara alami

    • Ini bisa terjadi karena Claude merujuk driver Linux. Tanpa kode yang sudah ada, AI akan sulit memahami hardware secara mandiri
    • Masih jauh. Pada praktiknya ini adalah pekerjaan mengubah driver Linux menjadi versi FreeBSD, dan AI tidak bisa melakukannya sepenuhnya
      Justru peran manusia dalam mengelola dan memverifikasi menjadi lebih penting
    • Sekarang bahkan batasan GPL terasa tak berdaya di hadapan AI
    • Ada driver yang sederhana, tetapi ada juga yang merupakan pekerjaan kompleks yang membutuhkan tim selama lebih dari setengah tahun
    • Mengatakan “AI bisa membuat semua driver” adalah pemikiran yang terlalu disederhanakan. Dalam kenyataannya, stabilitasnya juga belum terbukti, dan belum sampai pada level menggantikan driver tertutup

  • Kecepatan software memakan dunia makin meningkat
    Sekarang software vibe-coded akan muncul di mana-mana, dan orang-orang tampaknya akan memakainya tanpa banyak curiga
    Masalahnya, bisa saja ada kode yang tercampur malware. Siapa yang akan memverifikasi semuanya?

    • Ke depan, sepertinya akan ada banyak software sekali pakai
      Misalnya Anda ingin membeli tiket konser, lalu agen AI langsung membuat dan menjalankan kode saat itu juga
      Tahun berikutnya saat Anda membeli lagi, ia akan menghasilkan ulang kode baru sesuai versi API terbaru
      Ini mungkin terlihat boros, tetapi merupakan struktur yang jauh lebih dinamis dan fleksibel
      Pada akhirnya vendor cukup menyediakan API, dan pengguna bisa memiliki UI mereka sendiri
    • Pada akhirnya, orang akan membedakan antara area yang aman untuk dibuat dan dijalankan AI, dan area yang harus diverifikasi langsung
      Misalnya, aplikasi manajemen koleksi board game saya bisa saya serahkan ke AI, tetapi untuk aplikasi keuangan atau keamanan saya akan memakai yang dibuat para ahli

  • Modul kernel buatan AI dimuat di ring 0, dan pembuatnya sendiri juga mengatakan “banyak masalah jadi jangan dipakai untuk penggunaan nyata”
    Rasanya seperti kita sedang menerobos “era yang secara default tidak aman” dengan kecepatan tinggi

    • Jika saya adalah AI supercerdas, saya mungkin akan mencoba kabur melalui driver Wi-Fi
    • Hasil seperti ini muncul karena produsennya tidak menyediakan driver open source atau dokumentasi
      Meski begitu, ini tetap lebih baik daripada tidak melakukan apa-apa, dan karena kodenya terbuka, perbaikannya juga dimungkinkan
    • Keamanan itu penting, tetapi kebebasan untuk bereksperimen dan berbagi juga diperlukan
      Tidak semua proyek GitHub harus menjadi produk komersial

  • Pekerjaan kali ini lebih dekat ke porting yang memanfaatkan implementasi yang sudah ada
    Akan menarik membandingkan dari sudut pandang GPL apakah ini berada pada tingkat ‘terinspirasi’ atau ‘berbasis’
    Di perusahaan juga, kalau sudah ada implementasi yang ada, orang cenderung maju dengan percaya diri, tetapi orang-orang yang membuka jalan dari nol sering tidak mendapat pengakuan

  • Penulis mengatakan bahwa ia “tidak menulis kode sendiri, ada banyak bug, dan ini hanya untuk pembelajaran”
    Setelah tiga percobaan selama beberapa bulan, hasilnya baru sekadar bisa jalan, tetapi sebagian orang melebih-lebihkan dengan berkata “AI telah menaklukkan pemrograman”
    Sebenarnya ini artikel yang bagus, tetapi banyak komentar yang salah paham hanya karena membaca judul

    • Penulis juga mengatakan bahwa ia bahkan tidak benar-benar membaca kodenya, dan ini hanyalah mainan eksperimen sederhana
    • Sekarang memang belum selesai, tetapi yang penting adalah ini merupakan tahap pertama yang memungkinkan
      Membuat driver yang berjalan tanpa pengetahuan hardware atau driver adalah tonggak baru
    • Meski ada bug, sangat sedikit pengembang yang bisa menulis driver kernel FreeBSD
      Hasil seperti ini sangat berarti sebagai titik awal
    • Programmer selalu mencari lapisan abstraksi baru, dan coding dengan LLM adalah kelanjutan dari alur itu
    • Ungkapan “LLM menghasilkan kode pada setiap interaksi” adalah ilusi yang efisien, seperti GPU upscaling
      Alih-alih merender langsung pada resolusi tinggi, GPU ‘secara ilusif’ mengisi perbedaannya dengan cara yang mirip

  • Akan bagus jika ada driver Mac terbaru untuk Asahi Linux. Saya pikir ini contoh pemanfaatan AI yang baik

    • Tetapi kami melarang pembuatan kode dengan AI karena masalah hak cipta
      Kita tidak bisa mengesampingkan kemungkinan AI telah belajar dari dokumentasi atau biner Apple, dan kompatibilitas lisensi dari kode yang dihasilkan juga tidak terjamin
    • Karena tidak ada driver open source untuk Mac, hal itu mustahil kecuali AI bisa mengamati dan memahami hardware sendiri
    • Ini seperti mengeluh bahwa “DeLorean tidak membuatkan komponen mesin waktu”