Memodernisasi driver kernel berusia 25 tahun dengan Claude Code
(dmitrybrant.com)- Driver ftape adalah satu-satunya driver kernel open source Linux yang dapat memulihkan data dari pita cadangan (QIC-80) era 1990-an
- Namun, driver tersebut tidak lagi dipelihara sejak setelah tahun 2000, sehingga hanya bisa digunakan di lingkungan Linux lama
- Dengan memanfaatkan Claude Code, kode sumber lama direfaktor agar sesuai dengan kernel Linux modern, lalu berhasil diubah menjadi modul kernel mandiri
- Dalam prosesnya, Claude secara otomatis mengonversi fungsi dan struct lawas ke API modern, sementara pengguna menganalisis hasil output secara manual untuk memperbaiki beberapa kesalahan konfigurasi
- Melalui pengalaman menggunakan agen coding AI, penulis memperoleh wawasan tentang penguatan kemampuan programmer dan cara onboarding cepat ke teknologi serta framework baru
Latar belakang: pemulihan pita cadangan lama dan driver ftape
- Memulihkan data dari kartrid pita seperti QIC-80 adalah salah satu hobi penulis
- Pita semacam ini umumnya memerlukan drive pita khusus yang terhubung ke floppy controller
- Drive tersebut terutama digunakan oleh usaha kecil atau pengguna perorangan pada 1990-an untuk keperluan backup
- Pendekatan memakai floppy controller bisa diimplementasikan dengan murah tanpa adaptor SCSI terpisah, tetapi memiliki berbagai kelemahan seperti batas kecepatan (500Kbps) dan protokol nonstandar
- Untuk berkomunikasi dengan perangkat pita ini, di Linux driver kernel ftape wajib digunakan
- Hanya ftape yang bisa membaca data biner mentah murni, sehingga mutlak diperlukan untuk pemulihan
- Namun, driver ftape tidak dipelihara lagi sejak sekitar tahun 2000, sehingga tidak bisa dipakai di kernel Linux modern
- Akibatnya, setiap kali ingin memulihkan data, penulis harus mem-boot Linux lawas (seperti CentOS 3.5) secara langsung
Mulai memodernisasi driver kernel dengan Claude Code
- Penulis meminta Claude Code, bersama penjelasan repositori, untuk "memodernisasi driver agar bisa dibangun di kernel terbaru"
- Claude menemukan lalu mengganti fungsi dan struct lawas agar sesuai dengan API dan struktur kernel saat ini
- Setelah beberapa kali umpan balik dan koreksi manual, akhirnya dihasilkan kode driver yang bisa dikompilasi tanpa error
- Kode awalnya hanya bisa dibangun di dalam keseluruhan source tree kernel, tetapi lewat permintaan tambahan Claude juga otomatis membuat sistem build modul eksternal mandiri
- Dengan ini, modul kernel dapat dibuat terpisah sebagai file .ko dan pengujian koneksi ke perangkat keras nyata pun dimulai
Proses pemecahan masalah
- Modul kernel berhasil dimuat, tetapi muncul masalah deteksi drive dan komunikasi
- Karena pekerjaan ini memerlukan hak akses sudo, Claude tidak bisa langsung menjalankan iterasi berulang, sehingga penulis secara manual mengirimkan log dmesg untuk melacak masalah
- Dengan membandingkan log dan contoh keberhasilan sebelumnya, Claude menemukan bug terkait alamat port I/O default yang tidak disetel serta inisialisasi parameter
- Nilai default berubah dari -1 menjadi 0xffff sehingga deteksi gagal; masalah teratasi setelah diatur ulang ke alamat yang benar
- Pada akhirnya, modul termuat dengan normal dan berhasil melakukan dump data dari pita uji
Implikasi dari pengalaman berkolaborasi dengan agen coding AI
- Interaksi dengan Claude Code terasa seperti "berkolaborasi dengan developer junior" dan bekerja dengan engineer sungguhan
- Pengguna tetap harus memimpin keputusan arsitektur, menemukan masalah, dan menentukan arah pengerjaan
- Semakin spesifik kata kunci yang berfokus pada domain dan permintaan yang diberikan, semakin efektif hasilnya
- Produktivitas agen AI meningkat tajam bila diberi jenis tugas yang tepat, sehingga perlu kepekaan untuk memahami batasan dan kekuatannya
- AI menggandakan kemampuan penulis. Pekerjaan yang secara manual akan memakan waktu berminggu-minggu dapat diselesaikan hanya dalam beberapa hari lewat percakapan dan umpan balik sehari-hari
- Dalam proses ini, penulis juga mempelajari keterampilan yang benar-benar berguna seperti praktik pengembangan kernel modern, arsitektur x86, dan tool baris perintah baru
- Ditekankan pula bahwa AI sangat mempercepat onboarding dan proses adaptasi awal terhadap framework baru (Rust, Flutter, dan lain-lain)
Kesimpulan: ftape hidup kembali
- Setelah 25 tahun, ftape kembali bisa dibangun dan digunakan di Linux modern
- Penulis sedang melanjutkan peningkatan fitur dan pengujian tambahan, serta telah memastikan dukungan tidak hanya untuk drive berbasis floppy tetapi juga perangkat berbasis port paralel
- Perangkat fisiknya hampir sama seperti dulu, tetapi sistem operasinya kini berubah dari CentOS 3.5 menjadi Xubuntu 24.04
Referensi
- Kode sumber proyek ftape tersedia di GitHub
- Daftar perangkat koleksi penulis dan lainnya dapat dilihat di blog pribadinya
1 komentar
Komentar Hacker News
Saya memuat modulnya sendiri lalu berulang kali menyalin-tempel output
dmesgke Claude secara manualSalah satu alasan utama saya memakai Claude adalah karena ia bisa memulai proses yang berjalan lama, membaca output-nya, lalu membantu debugging
Ada berbagai cara hack untuk melewati langkah manual ini—misalnya dengan mem-pipe
dmesgke port UDP lokal dan membuat Claude menjalankan listenerMenurut saya ini contoh yang bagus
Saat memakai alat seperti ini, saya melihat ada dua efek utama
Pertama, pada framework yang sudah saya kuasai, Claude bisa cepat melakukan pattern matching pada bagian-bagian repetitif dan sangat meningkatkan produktivitas
Kedua, saat mempelajari framework baru pun proses onboarding jadi jauh lebih cepat—ini sangat membantu terutama di perusahaan besar yang memakai banyak stack berbeda
Untuk benar-benar memahami kapabilitas AI, kita perlu meluangkan cukup banyak waktu pada teknologi dan framework yang berubah cepat
Kalau belum memakai Claude Code atau Claude 4.0 lebih dari 100 jam, kemungkinan besar orang belum benar-benar paham potensinya
Skenario “orang yang bukan programmer ngoding pakai insting lalu terjebak masalah” mungkin memang umum di X (dulu Twitter), tetapi pengembang berpengalaman yang konsisten meluangkan waktu akan mendapatkan pengalaman yang sama sekali berbeda
Ini poin utamanya
Saya memakai Claude Code setiap hari tanpa absen sebagai alat utama untuk mengubah codebase yang sudah ada
Setelah banyak trial and error, saya membuat proses versi saya sendiri, dan hasilnya produktivitas serta keberanian untuk mencoba eksperimen besar meningkat drastis
Saya terutama suka bahwa setelah saya lebih dulu merancang struktur data, skema, dan API internal, Claude Code hampir selalu bisa membuat UI untuk tool internal dengan sangat baik dalam satu kali jalan
Karena saya jadi bisa berpikir lebih abstrak tanpa terjebak pekerjaan repetitif atau kerumitan framework, ini menjadi titik balik besar dalam 16 tahun karier saya
Betul
Pada dasarnya penulis menyuruh Claude mem-port driver Linux 2.4 ke 6.8
Karena materi terkait sudah cukup banyak tersedia online, sebagian besar pekerjaan bisa ditangani Claude, dan keahlian penulis benar-benar hanya dibutuhkan pada bagian inti yang rumit
Ungkapan “memakai AI sebagai alat untuk melipatgandakan kemampuan sendiri secara eksplosif” benar-benar terasa pas
Kalau kemampuan dasar seseorang di sini adalah 0, maka dikalikan AI pun hasilnya akan tetap mendekati 0, atau bahkan menjadi produktivitas negatif
Di tim kami juga ada orang yang berani mencoba area baru lewat LLM, tetapi bahkan ketika Claude 4 thinking agent diberikan ke semua orang, tetap sering keluar banyak kode yang ngawur
Kalau selama sebagian besar karier coding seseorang ia terbiasa dengan pattern matching, maka agent LLM pada dasarnya menambahkan pattern matching lagi di atas itu; bagi anggota tim yang tidak punya pengalaman semacam itu, ini justru jadi merepotkan
Agent LLM memang melakukan pattern matching yang bisa dilakukan manusia dengan jauh lebih cepat, tetapi secara umum rasanya tidak benar-benar lebih unggul daripada manusia
Bukan hanya berguna untuk menjelajahi framework baru, tapi juga bahasa baru
Tim kami memakai Ruby, dan karena Ruby mudah dibaca, saya bahkan tidak perlu benar-benar mempelajari sintaksnya; saya cukup menyuruh LLM menulis kode dan saya sendiri mengambil keputusan
Bahkan tanpa tahu Ruby, saya bisa langsung menulis kode yang masih berada dalam standar yang diterima tim, sehingga tetap produktif meski di lingkungan yang asing
(Catatan: Pull Request tetap direview anggota tim)
Ungkapan “alat yang melipatgandakan kemampuan sendiri secara eksplosif” benar-benar terasa minggu ini ketika saya membuat proyek kecil yang sama sampai 10 kali berulang
Nilai AI paling terasa ketika saya memberi arahan lalu merapikan dan menggabungkan markup, style, JS, dan hal-hal lain yang awalnya dibuat secara berantakan oleh AI
Di lingkungan seperti startup yang konvensi coding-nya lemah, permintaan pattern matching sulit diterapkan, tetapi saya bisa membayangkan hasilnya akan sangat berbeda pada codebase yang kuat dan matang
Saya rasa prompt harus disusun dengan kata kunci yang sangat spesifik dan sesuai domain
Kalau pemahaman teknis terhadap bahasa atau framework tertentu kurang, prompt akan jadi ambigu, lalu bagian ambigu itu diisi sendiri oleh LLM sehingga hasilnya mudah melenceng dari niat awal
Ambiguitas seperti inilah sumber bug
Ini sisi lain dari “pelipatgandaan eksplosif” itu
Saat membaca tulisan seperti ini, saya jadi berpikir bahwa sebelum adopsi LLM, jumlah pekerjaan yang benar-benar terselesaikan sebenarnya jauh lebih sedikit dibanding permintaannya
Saya masih merasa bottleneck-nya bukan pada ‘eksekusi’, melainkan pada ‘ide yang punya pasar’
Tidak banyak hal yang benar-benar ingin dibayar orang
Masalahnya bukan selalu karena kekurangan pekerjaan, melainkan karena kurangnya orang yang punya keterampilan dan pengalaman pendahuluan untuk mengerjakannya
Tanpa pengalaman pengembangan kernel, sebaik apa pun prompt yang dibuat, akan sulit mendapatkan hasil seperti penulis
Secara teori, mungkin saja dengan kekuatan LLM semua driver lama bisa “dimodernisasi” ke kernel terbaru, tetapi dalam praktiknya tetap harus ada pengawasan manusia (orang berpengalaman), dan jumlah ahli seperti ini jauh terlalu sedikit dibanding jumlah driver yang perlu dipelihara
Ada diskusi dan wawancara yang bagus dengan Alan Kay dan Joe Armstrong yang menyinggung masalah bahwa kebanyakan kode tidak dikembangkan dengan cara mengganti target lalu mengompilasi ulang berdasarkan spesifikasi yang jelas
Jika spesifikasi formal memang ada di luar kode, memindahkan driver ke target kernel baru akan jauh lebih mudah, semacam “mengompilasi ulang spesifikasi”
Tetapi sekarang yang menjadi dasar bukan spesifikasi, melainkan kode lama, sehingga dalam proses memindahkan kode lama ke kode modern, LLM hanya melakukan pattern matching pada kode yang mirip dan tidak benar-benar memahami atau menjamin maknanya—karena itu keterampilan manusia tetap mutlak dibutuhkan
Saya memang sempat merasa bahwa AI akan menurunkan hambatan masuk ke kernel hacking
Dan saya terus melihat bahwa ini memang benar
Tak lama lagi dukungan hardware embedded/ARM bisa menjadi jauh lebih luas, dan mungkin juga akan muncul OS baru untuk perangkat pintar ringan
Hanya saja kebanyakan orang meminta AI untuk ‘membangunkan seluruh rumah’, padahal jauh lebih efektif jika dipakai untuk ‘membantu memaku dengan palu’
Menurut saya ini contoh yang bagus tentang pengembang yang memahami dengan tepat peran dan batasan AI lalu memakainya secara sesuai
Saya terutama terkesan dengan sikap skeptisnya yang membuat driver itu dijadikan modul terpisah
Saya ingin menyoroti ‘petunjuk penting’ yang belum disebut orang lain
Penulis secara jelas mengatakan, “Saya punya sedikit pengalaman dengan kernel module dan cukup mahir bahasa C, jadi hasil Claude ini jangan terlalu dibesar-besarkan”
Artinya, ini benar-benar bukan kasus tiga kali tanya lalu kernel module langsung selesai, melainkan ada banyak percakapan bolak-balik dan banyak perbaikan manual pada kode
Ia juga mengatakan bahwa tanpa memahami struktur internal dasar kernel module, modernisasi seperti ini sama sekali tidak mungkin—ini konteks yang wajib diingat saat memakai alat pembuat kode apa pun
Selain itu, ia menulis bahwa bekerja bersama Claude Code terasa “mirip seperti bekerja dengan engineer junior”; kalau disuruh, ia akan mengerjakan apa saja, dan saat kesalahannya ditunjukkan ia langsung minta maaf atau memuji, sehingga lebih terasa seperti gaya yang menjilat daripada engineer sungguhan
Terakhir, penulis mengatakan bahwa “kalau benar-benar mau, saya sebenarnya bisa mengerjakan ini sendiri, hanya saja saya harus belajar lagi cara pengembangan kernel 25 tahun lalu”
Ini mengingatkan lagi bahwa pada akhirnya inti modernisasi adalah “memahami solusi legacy secara akurat dan mengetahui apa yang sebenarnya dibutuhkan”
Menarik juga bahwa salah satu manfaat yang disebut justru adalah bisa melewati proses belajar itu
Saya merasa sangat terbantu ketika agent menjelaskan proyek yang tidak saya kenal
Baru-baru ini saya meng-clone source Firefox lalu memakai qwen-code untuk bertanya tentang fitur AI di Firefox dan bagaimana implementasinya, dan saya benar-benar belajar banyak dengan cara yang keren
Cara belajar sekarang jadi jauh lebih bagus
Saya rasa ini perubahan yang memberi lebih banyak daya kepada orang
Penulis sudah lama mengerjakan side project dengan penuh semangat, dan upgrade alat seperti ini benar-benar hal yang bagus
Tetapi kalau bidangnya terlalu sempit, dukungan komunitas bisa kurang, dan di situlah LLM bisa membantu menyelesaikan masalah yang sangat kustom
Hambatan masuk terus menurun, dan akan datang masa ketika orang dengan latar belakang teknis yang lebih minim pun bisa langsung menyelesaikan masalah khusus yang lebih sederhana sendiri
Ini perubahan positif yang membuat lebih banyak orang bisa mencoba
Saya penasaran bagaimana perubahan kecepatannya setelah upgrade