Belajar DragonFlyBSD - Sejarah, Latar Belakang & Mengapa Membutuhkannya

#Pendahuluan

Di episode 0 sebelumnya kalian sudah menyiapkan skill dasar dan environment: kenyamanan CLI, pemahaman user/group dan filesystem, VM dengan disk virtio, serta verifikasi uname -a. Sekarang saatnya memahami siapa dan mengapa di balik sistem ini. Setiap sistem operasi lahir dari satu masalah besar yang dicoba dipecahkan — DragonFlyBSD tidak terkecuali.

Sejarah adalah kunci membaca desain. Ketika kalian melihat kenapa DragonFlyBSD punya Lightweight Kernel Threading (LWKT), kenapa filesystem default-nya bernama HAMMER2, dan kenapa network stack-nya ditulis ulang, jawabannya semua bermuara pada keputusan Matthew Dillon dan komunitasnya pada tahun 2003. Memahami latar belakang ini akan membuat perintah-perintah di episode berikutnya terasa logis, bukan sekadar harus dihafal.

#Sejarah & Filosofi

#Latar Belakang: Dunia BSD Tahun 2003

Untuk menilai mengapa fork terjadi, kita perlu melihat konteks zamannya. Awal 2000-an adalah era transisi menuju prosesor multi-core, dan seluruh ekosistem BSD bergulat dengan satu pertanyaan besar: bagaimana menjaga kernel tetap aman dan cepat ketika banyak CPU mengaksesnya secara bersamaan? Model lama mengandalkan giant lock — satu kunci global yang membuat hanya satu CPU boleh berada di dalam kernel pada satu waktu. Kunci ini sederhana dan mudah diverifikasi, tapi berubah menjadi penghambat kinerja begitu jumlah core bertambah.

FreeBSD menjawab tantangan ini lewat jalur SMPng (SMP Next Generation), yang membongkar satu lock besar menjadi banyak lock kecil per subsistem. Matthew Dillon ikut terlibat dalam perdebatan ini, tapi ia menilai jawaban tersebut belum menuntaskan akar masalah: setiap CPU masih sering saling menunggu kunci yang sama. Dari perbedaan penilaian inilah lahir keputusan untuk mem-fork FreeBSD 4.8 dan memulai jalur sendiri — bukan karena FreeBSD buruk, melainkan karena Dillon yakin arsitektur berbasis per-CPU adalah jawaban yang lebih radikal untuk era banyak inti.

Konteks ini penting untuk kalian pegang. Seluruh pilihan desain DragonFlyBSD yang akan kita temui di episode-episode berikut — LWKT, HAMMER/HAMMER2, hingga network stack kustom — bukan muncul tiba-tiba, melainkan konsekuensi logis dari keputusan "memulai dari akar" pada tahun 2003 tersebut.

#Fork dari FreeBSD 4.8

Tahun 2003, dunia BSD berada di persimpangan. FreeBSD — sistem operasi tempat DragonFlyBSD bernaung — sedang bergerak dari model threading SMP lama ke arah yang dianggap banyak developer kurang efisien untuk mesin multi-core yang semakin banyak. Matthew Dillon, seorang kernel developer FreeBSD yang pernah bekerja di proyek kernel DICE dan memiliki pengalaman panjang di dunia kernel, mengambil keputusan berani: mem-fork FreeBSD 4.8 dan memulai jalur pengembangan sendiri.

Fork bukanlah sekadar menyalin kode. Fork adalah pernyataan arah: "kita akan menyelesaikan masalah ini dengan cara yang berbeda." DragonFlyBSD tidak lahir karena FreeBSD jelek, melainkan karena para pendirinya yakin ada arsitektur yang lebih baik untuk era banyak inti. Dari FreeBSD, DragonFlyBSD mewarisi base system, userland, dan banyak filosofi ports — tapi kernelnya ditulis ulang secara signifikan.

#LWKT: Jawaban atas Masalah Multi-Core

Masalah utama yang Dillon hadapi adalah scalability kernel pada mesin multi-core. Model kernel tradisional menggunakan satu giant lock yang membuat hanya satu core boleh masuk kernel pada satu waktu — berguna untuk keamanan, tapi membunuh kinerja saat jumlah core bertambah. LWKT (Lightweight Kernel Threading) adalah desain threading kernel yang memungkinkan setiap CPU menjalankan kernel thread sendiri secara paralel, dengan migrasi thread yang dikendalikan dan per-process scheduler yang efisien. Ini adalah fondasi yang membuat DragonFlyBSD unggul dalam beban kerja dengan banyak proses — dan kita akan membedahnya di episode 17.

Perlu dicatat, pilihan ini tidak datang tanpa biaya: setiap CPU yang berjalan independen menuntut desain locking dan struktur data yang lebih hati-hati, karena data yang diakses banyak CPU harus dijaga tetap konsisten tanpa saling memblokir. Biaya itu dibayar di awal pengembangan agar manfaatnya terasa bertahun-tahun kemudian — sebuah tradeoff yang khas keputusan arsitektur jangka panjang.

#HAMMER & HAMMER2: Filesystem yang Tumbuh dari Masalah

Tidak ada filesystem di era itu yang memuaskan kebutuhan DragonFlyBSD: checksum untuk integritas data, snapshot yang murah untuk backup, deduplication untuk menghemat ruang, dan kemampuan menyusun multi-volume. Dillon lalu merancang HAMMER (dirilis pertama kali di versi 2.x) dan menggantinya dengan HAMMER2 yang lebih modern, dengan metadata batching dan copy-on-write yang lebih baik. HAMMER2 kini menjadi filesystem default DragonFlyBSD — subjek utama episode 8, 9, dan 19.

#Peta Rilis

Mengetahui peta rilis membantu kalian memahami di posisi mana sistem ini berdiri hari ini:

Verifikasi rilis yang kalian pakai bisa dilakukan dengan perintah yang sudah kita kenal di episode 0:

uname -a
sysctl kern.version
pkg -v

#Mengapa DragonFlyBSD

#HAMMER2: Filesystem Modern

HAMMER2 adalah alasan utama banyak orang datang ke DragonFlyBSD. Ia menawarkan snapshot, checksum end-to-end, block deduplication, compression (zstd, lz4), dan encryption per-PFS dalam satu kesatuan yang koheren. Jika kalian butuh filesystem dengan integritas data dan snapshot murah tanpa harus berkompromi dengan konfigurasi yang rumit, HAMMER2 adalah nilai jual terbesar sistem ini.

#LWKT & Scalability Multi-Core

Dengan arsitektur LWKT, DragonFlyBSD memandang setiap CPU sebagai entitas yang berjalan mandiri. Ini membuat beban kerja thread-heavy dan process-heavy berjalan efisien di mesin dengan banyak core — topik yang akan kalian praktikkan dengan cpuset di episode 17.

#Network Stack Kustom: newbee

DragonFlyBSD tidak puas dengan network stack lama. Proyek newbee adalah upaya menulis ulang stack jaringan dengan model yang lebih modern dan mudah dipahami, termasuk dukungan yang lebih baik untuk tunneling dan virtualisasi. Ini contoh filosofi "bypass legacy bila perlu" — tidak takut memulai dari awal ketika fondasi lama dianggap kurang tepat.

#pkg + DPorts & Ekosistem

Untuk aplikasi, DragonFlyBSD memakai pkg (binary packages) dengan backend DPorts — adaptasi dari ports FreeBSD. Di episode 4 kita akan mempelajari cara install, upgrade, dan membangun package sendiri dengan dsynth. Plus, kehadiran hypervisor NVMM (episode 18) membuat DragonFlyBSD layak jadi platform virtualisasi dan storage sekaligus.

#Memverifikasi Posisi Rilis

Salah satu pertanyaan pertama setiap orang yang baru mengenal DragonFlyBSD adalah "sistem ini hidup atau ditinggalkan?". Jawabannya bisa dilihat langsung dari data: aktivitas rilis, update security, dan repositori git yang terus bergerak. Verifikasi sendiri dengan:

git -C /usr/src log --oneline -5
dragonfly-update

Log git yang bergerak dan rilis berkala adalah tanda sistem yang hidup. Kebiasaan memeriksa status ini akan menemani kalian hingga episode 21, saat kita membedah rilis 6.4 dan roadmap. Jangan ragu juga mengunjungi dragonflybsd.org/releases untuk melihat catatan rilis — di sanalah cerita yang kita baca di episode ini tertulis dalam bentuk sejarah pengembangan yang nyata.

#Komunitas yang Inovatif

Terakhir, komunitas DragonFlyBSD dikenal berani bereksperimen. Ketika mayoritas dunia BSD memilih jalan konvensional, DragonFlyBSD justru membangun arsitektur sendiri. Bagi kalian yang suka memahami mengapa sebuah sistem didesain seperti itu — bukan hanya bagaimana mengoperasikannya — DragonFlyBSD adalah lahan belajar yang sangat subur.

#Filosofi yang Menyatukan

#Bypass Legacy Bila Perlu

Sepanjang sejarahnya, DragonFlyBSD mengambil satu keputusan yang mengikat seluruh desainnya: tidak takut membuang warisan yang dianggap salah. LWKT dibangun karena model threading lama dianggap tidak scalable. HAMMER2 ditulis baru karena tidak ada filesystem yang memenuhi kebutuhan. newbee lahir karena network stack lama dianggap perlu penggantian. Filosofi ini membuat DragonFlyBSD kadang terlihat "tidak konservatif" — tapi justru itulah yang membuatnya menarik secara teknis.

#Satu Source Tree, Satu Sistem

Dari filosofi ini mengalir satu konsekuensi penting: DragonFlyBSD mempertahankan model base system satu-kesatuan. Kernel, userland, dan filesystem dikembangkan dalam satu source tree dan dirilis bersama. Berbeda dengan model Linux yang merakit kernel dari vendor berbeda, model BSD berarti setiap bagian sudah diuji sebagai satu kesatuan. Di episode 2 kita akan membedah struktur kesatuan ini, dan di episode 20 kita akan membangunnya kembali dari source.

#Penutup

Di episode 1 ini kalian telah memahami asal-usul DragonFlyBSD: fork FreeBSD 4.8 tahun 2003 oleh Matthew Dillon sebagai tanggapan atas arah pengembangan kernel yang dianggap kurang scalable untuk mesin multi-core. Kalian juga mengenal tiga pilar arsitektur — LWKT, HAMMER/HAMMER2, dan network stack kustom — beserta peta rilis dari 1.x hingga 6.4.2.

Inti yang harus dibawa pulang:

• DragonFlyBSD lahir dari kebutuhan akan scalability multi-core yang tidak terpenuhi oleh model kernel lama.
• LWKT, HAMMER2, dan newbee adalah tiga pilar yang membedakan DragonFlyBSD dari BSD lain.
• Peta rilis menunjukkan evolusi: HAMMER di 2.x, HAMMER2 default di 6.x, hingga 6.4.2 sebagai rilis current.
• "Bypass legacy bila perlu" adalah filosofi inti — DragonFlyBSD tidak takut menulis ulang.

Di episode 2 selanjutnya kita akan membongkar konsep dasar dan arsitektur utama DragonFlyBSD: hubungan antara base system dan DPorts, struktur source tree yang di-clone lewat git, serta peran kernel, userland, HAMMER2, newbee, dan NVMM sebagai satu kesatuan sistem.