Pendanaan selama 1 tahun untuk pengembangan FreeBSD

 (daemonology.net)
2 poin oleh GN⁺ 2025-06-07 | 1 komentar | Bagikan ke WhatsApp
  • Dalam situasi ketika pemeliharaan FreeBSD/EC2 dan release engineering saling berbenturan dalam waktu sukarela satu orang, pendanaan 1 tahun dari Amazon memungkinkan operasi rilis dan peningkatan platform EC2 berjalan bersamaan
  • Pendanaan tersebut secara nominal bernilai 40 jam per bulan melalui GitHub Sponsors, tetapi pekerjaan aktual rata-rata 50 jam per bulan, dengan isu EC2, proses rilis, dan release engineering lainnya terbagi kira-kira 20/20/10 jam
  • Selama setahun, pengelolaan rilis FreeBSD 13.4, 14.2, 13.5, dan 14.3 dilakukan sambil menjalankan pekerjaan prioritas seperti penanganan sinyal power off pada AWS Graviton dan hotplug perangkat EC2
  • Untuk menangkap regresi performa boot, build EC2 AMI mingguan sejak 2018 dibenchmark, dan penyebab keterlambatan ditemukan serta diperbaiki pada ukuran root disk, EFI entropy seeding, transaction group ZFS, dan perubahan IPv6 IMDSv2
  • Setelah pendanaan berakhir, peran-peran tersebut tetap berlanjut, tetapi waktu yang tersedia untuk memperbaiki langsung masalah menjelang rilis atau terus mendorong daftar fitur EC2 menjadi berkurang

Bottleneck sebelum pendanaan dan pembagian waktu

  • Pemeliharaan FreeBSD/EC2 telah berlangsung sejak FreeBSD pertama kali di-boot di Amazon EC2 pada 2010, dan pada November 2023 peran lead FreeBSD release engineering juga ditambahkan
  • Pendanaan kecil dari Antithesis dan FreeBSD/EC2 Patreon tidak cukup untuk menangani kedua peran tersebut
    • Daftar fitur yang perlu diimplementasikan mandek
    • Semakin banyak anomali yang ditemukan tetapi ditunda karena tidak ada waktu untuk menyelidikinya
    • Pada awal 2024, kekhawatiran meningkat bahwa peran sebagai “owner yang baik” untuk platform FreeBSD/EC2 akan sulit dijalankan
  • Pada April 2024, setelah Amazon menemukan penanggung jawab yang memiliki anggaran, diskusi mengenai jadwal, cakupan, dan prosedur berlanjut, dan Amazon memutuskan memberi pendanaan selama 1 tahun melalui GitHub Sponsors
  • Sasaran pendanaan adalah gabungan FreeBSD release engineering dan pengembangan FreeBSD/EC2 sebesar 40 jam per bulan
    • Disampaikan bahwa mendanai hanya salah satunya tidak realistis karena kedua pekerjaan saling bergantung
    • Waktu aktual yang dicurahkan meningkat menjadi rata-rata sekitar 50 jam per bulan
    • Rata-rata, pembagiannya adalah 20 jam untuk isu khusus EC2, 20 jam untuk proses rilis FreeBSD, dan 10 jam untuk pekerjaan terkait release engineering lainnya, meski variasi per bulan cukup besar

Operasi rilis kuartalan dan peningkatan build

  • Sesuai jadwal rilis kuartalan FreeBSD yang diumumkan pada Juli 2024, 4 rilis dikelola selama 1 tahun
    • FreeBSD 13.4: September 2024
    • FreeBSD 14.2: Desember 2024
    • FreeBSD 13.5: Maret 2025
    • FreeBSD 14.3: dijadwalkan rilis pada 10 Juni 2025
  • Setiap rilis mencakup mendorong merge kode, menyetujui atau menolak permintaan merge, koordinasi dengan tim lain, build dan pengujian image, penulisan pengumuman, serta perbaikan masalah build rilis
    • Umumnya, 3 Beta, 1 Release Candidate, dan Release final di-build
    • Sebagian besar pekerjaan terkonsentrasi pada bulan sebelum rilis, yaitu “Beta Month”, bulan kedua di setiap kuartal
    • FreeBSD 13.5 membutuhkan 33,5 jam, sedangkan FreeBSD 14.2 membutuhkan 79 jam
    • Semakin mendekati akhir stable branch, item yang rusak cenderung berkurang sehingga beban kerja rilis juga menurun
    • FreeBSD 14.1 tidak dilacak, tetapi waktu release engineering diperkirakan mendekati 100 jam, dan FreeBSD 15.0 kemungkinan jauh lebih besar dari itu
  • Dalam release engineering umum, paralelisasi build rilis juga dilakukan
    • Seiring bertambahnya jumlah EC2 AMI, waktu untuk menginstal FreeBSD ke VM image menjadi porsi yang lebih besar dibanding build sebenarnya
    • Kode rilis diparalelkan, tetapi muncul kegagalan build sporadis, dan karena build rilis penuh memakan waktu sekitar 24 jam, penyebabnya sulit dipisahkan
    • Penyebab akhirnya adalah satu baris Makefile yang hilang, yang seharusnya membuat direktori sebelum memasang file
    • Setelah diperbaiki, build rilis turun dari sekitar 22 jam menjadi sekitar 13 jam, dan ekspansi flavour EC2 AMI yang sebelumnya ditunda karena waktu build menjadi memungkinkan
  • Masalah reproduksibilitas build mulai diperiksa secara berkala dengan memanfaatkan EC2
    • Dalam proses pengujian image snapshot mingguan, instance EC2 dijalankan dan diminta membuild AMI-nya sendiri
    • Image disk yang dihasilkan dibandingkan dengan image asli menggunakan diffoscope
    • Melalui pengujian rutin, beberapa isu ditemukan; sebagian diperbaiki langsung dan sebagian diteruskan ke pengembang lain

Penanganan power Graviton dan hotplug di FreeBSD/EC2

  • Fitur utama yang diminta Amazon sebagai prioritas di FreeBSD/EC2 adalah power driver untuk instance AWS Graviton dan hotplug perangkat
  • Driver power Graviton menangani jalur ketika EC2 API memberi tahu sistem operasi untuk shutdown
    • Tanpa fitur ini, FreeBSD mengabaikan sinyal shutdown, lalu beberapa menit kemudian EC2 timeout dan memutus daya virtual
    • “Tombol daya” pada sistem Graviton adalah pin GPIO, dan detailnya ada di objek ACPI _AEI
    • Kode ditambahkan untuk menemukan informasi tersebut di ACPI dan meneruskan konfigurasi ke driver controller GPIO PL061
    • Ketika pin GPIO di-assert, controller membuat interrupt, event “power button” ACPI terjadi, dan sistem berujung shutdown
  • Tabel ACPI yang disediakan EC2 menentukan bahwa pin GPIO tersebut harus disetel sebagai “Pull Up”, tetapi controller PL061 tidak memiliki resistor pullup/pulldown
    • Linux mengabaikan kegagalan konfigurasi GPIO secara diam-diam sehingga masalah tidak terlihat
    • FreeBSD menonaktifkan perangkat setelah konfigurasi gagal
    • Bug EC2 ini diperkirakan akan diperbaiki pada sistem Graviton mendatang, tetapi saat ini AMI FreeBSD/EC2 memasukkan quirk ACPI_Q_AEI_NOPULL untuk mengabaikan flag GPIO PullUp pada objek _AEI
  • Hotplug, khususnya hot unplug, membutuhkan lebih banyak pekerjaan karena beberapa tipe instance EC2 memiliki masalah berbeda yang saling bertumpuk
    • Sebagian sistem Graviton membocorkan reservasi IRQ virtual saat PCI attach, dan setelah EBS volume di-attach/detach 67 kali, IRQ habis lalu kernel FreeBSD panic
      • Penyebabnya adalah kode routing interrupt PCI legacy, dan pengaturan boot loader ditambahkan untuk menonaktifkan kode tersebut di EC2
    • Sebagian sistem Graviton menggunakan status daya perangkat PCI sebagai sinyal untuk menentukan apakah OS sudah selesai menggunakan perangkat dan siap dieject
      • Ini dianggap sebagai bug EC2, dan saat ini quirk ACPI_Q_CLEAR_PME_ON_DETACH mengubah sebagian bit pada register manajemen daya PCI sebelum eject
    • Pada x86 dan Graviton di instance EC2 generasi terbaru, driver FreeBSD nvme mengalami panic setelah PCIe unplug
      • Masalah ini diteruskan ke maintainer driver nvme
    • Pada sebagian instance EC2 x86 dan Graviton, perangkat “ghost” tersisa di bus PCI setelah eject dan menghalangi attach perangkat baru
      • Firmware Nitro mengelola bus PCI dan perangkat PCI secara asinkron, sehingga ada jendela ketika perangkat sudah di-unplug tetapi bus PCI selama beberapa ms masih dilaporkan ada
      • Linux memindai bus secara berkala sehingga biasanya kalah dalam race ini, tetapi FreeBSD segera memindai ulang bus PCI tepat setelah detach sehingga lebih sering melihat ghost
      • Saat ini quirk ACPI_Q_DELAY_BEFORE_EJECT_RESCAN menambahkan jeda 10 ms setelah sinyal eject sebelum rescan bus PCI
  • PCIe mewajibkan jeda 5 detik setelah menekan tombol “attention” untuk permintaan eject perangkat, dan jika ada input tombol kedua, permintaan eject dibatalkan
    • Di EC2 tidak ada orang yang menekan tombol fisik dan tidak ada mekanisme untuk menekan ulang tombol virtual, sehingga jeda ini tidak diperlukan
    • Boot loader tunable ditambahkan untuk menyetel timeout menjadi 0 di EC2
  • Dengan skrip pengujian hotplug, instance EC2 dapat dijalankan lalu EBS volume di-plug/unplug berulang kali melalui EC2 API, dan dapat diverifikasi apakah FreeBSD berhasil attach/detach 300 kali berturut-turut
    • Jika akses awal ke tipe instance EC2 mendatang tersedia, ini dapat digunakan untuk memeriksa apakah perilaku hotplug berfungsi

Pelacakan regresi performa boot dan ekspansi AMI

  • Selain dua pekerjaan prioritas tertinggi dari Amazon, sekitar separuh waktu khusus EC2 digunakan untuk masalah FreeBSD/EC2 lainnya
  • Pada akhir 2023 dan awal 2024, instance FreeBSD/EC2 kadang-kadang boot lebih lama dari perkiraan, dan dalam pengujian snapshot mingguan waktu tunggu setelah menjalankan instance sebelum mencoba koneksi SSH harus diperpanjang
  • Untuk menangani masalah performa, waktu boot build EC2 AMI mingguan sejak 2018 dibenchmark
    • Dalam proses ini, lebih dari 10.000 instance EC2 dijalankan
    • Pembuatan plot performa boot FreeBSD mulai dilakukan
    • Pengumpulan data baru dan pembaruan plot dimasukkan ke dalam proses pengujian snapshot mingguan
  • Beberapa penyebab keterlambatan boot ditemukan dan diperbaiki
    • Sejak minggu pertama 2024, boot FreeBSD menjadi sekitar 3 kali lebih lambat, dan penyebabnya ditelusuri ke commit yang meningkatkan ukuran root disk dari 5 GB menjadi 6 GB
      • Hasil konfirmasi dari pihak Amazon menunjukkan bahwa menaikkan ukuran root disk menjadi 8 GB memulihkan performa ke tingkat sebelumnya
    • Pada keluarga Graviton 2, masalah kernel entropy seeding membuat boot menjadi lama
      • Kernel FreeBSD menghentikan boot sampai mengumpulkan lebih banyak entropy jika entropy untuk pembuatan bilangan acak aman tidak mencukupi
      • Ada kode untuk menerima seed aman dari firmware Nitro melalui EFI boot loader, tetapi tidak berjalan di EC2, dan pada Graviton 2 permintaan 2048 byte sangat lambat
      • Permintaan yang berada di kode Lua menu boot dipindahkan ke lokasi Lua boot loader yang tepat agar berjalan terlepas dari apakah menu dinonaktifkan atau tidak
      • Dengan menerima 64 byte entropy EFI lalu memperluasnya dengan PBKDF2 agar sesuai dengan input API 2048 byte, waktu boot FreeBSD arm64/base/UFS turun dari sekitar 25 detik menjadi sekitar 8 detik
    • Image ZFS boot lebih lama daripada UFS, dan besar keterlambatannya bergantung pada jumlah data di disk, bukan ukuran disk
      • makefs memasukkan semuanya ke dalam satu transaction group, lalu saat ZFS attach, transaction group terbaru dilalui dan diverifikasi, sehingga semua metadata file di disk dibaca dan diproses
      • Mark Johnston menyelesaikannya dengan membuat filesystem mencatat transaction group yang lebih tinggi agar satu transaction group tersebut tidak dianggap sebagai “terbaru”
      • Waktu boot image ZFS turun dari sekitar 22 detik menjadi sekitar 11 detik
    • Setelah penambahan dukungan IPv6 pada port net/aws-ec2-imdsv2-get pada Desember 2024, masalah boot cepat terdeteksi
      • Port ini menyediakan command-line interface untuk EC2 Instance MetaData Service
      • IPv6 dicoba terlebih dahulu, tetapi konfigurasi instance IMDS default adalah IPv4-only, dan timeout TCP default 75 detik juga tetap digunakan
      • Setelah diperbaiki, IPv4 dicoba terlebih dahulu dan timeout dikurangi menjadi 100 ms
  • Flavour FreeBSD AMI juga diperluas
    • Sebelumnya hanya ada base dan cloud-init
    • AMI small menghapus debug symbol, LLDB, library 32-bit, pengujian FreeBSD, Amazon SSM Agent, dan AWS CLI, sehingga penggunaan disk turun dari sekitar 5 GB menjadi sekitar 1 GB
    • AMI builder menyediakan FreeBSD AMI Builder AMIs agar pengguna dapat dengan mudah membuat FreeBSD AMI kustom
  • Dengan bertambahnya build snapshot mingguan menjadi kombinasi 4 flavour AMI, 2 filesystem, 2 arsitektur, dan 3 versi FreeBSD, image lama dan snapshot EBS terkait dibersihkan
    • Akun AWS FreeBSD release engineering mendapat pendanaan Amazon, tetapi biayanya tetap ditanggung seseorang
    • Skrip shell ditulis sehingga 336 TB snapshot EBS dapat dihapus

Pekerjaan yang tersisa dan keterbatasan setelah pendanaan berakhir

  • Selain proyek besar, berbagai pekerjaan kecil juga berlanjut
    • Memperbaiki build yang rusak yang ditemukan dalam build snapshot mingguan
    • Review patch driver ENA
    • Membantu Dave Cottlehuber menambahkan kemampuan untuk membuild OCI Container dan mengunggahnya ke repositori
    • Meningkatkan tool bsdec2-image-upload agar menangani error internal AWS dengan lebih halus
    • Melaporkan isu keamanan AWS yang ditemukan secara kebetulan
  • Setelah pendanaan berakhir, peran sebagai lead FreeBSD release engineering dan maintainer platform FreeBSD/EC2 tetap berlanjut
    • FreeBSD 15.0 dijadwalkan tiba pada Desember
    • Pada 2026, 14.4, 15.1, 14.5, dan 15.2 dijadwalkan menyusul
  • Karena waktu yang tersedia berkurang, cara memperbaiki langsung masalah menjelang rilis menjadi sulit
    • Fitur yang masuk terlambat lebih mungkin dihapus daripada diperbaiki agar sesuai jadwal rilis
    • FreeBSD 14.2 dapat menyertakan OCI Containers karena waktu yang didanai memungkinkan memastikan semua bagian yang dibutuhkan masuk secara utuh
  • Di sisi EC2, pengujian regresi performa boot sudah tersedia sehingga kemungkinan menangkap masalah terkait lebih besar, tetapi daftar implementasi fitur dapat mandek tanpa waktu tambahan
    • Perluasan filesystem otomatis saat EBS volume diperbesar
    • Peningkatan konfigurasi otomatis untuk beberapa network interface dan hotplug network interface
    • AMI rolling “pre-patched”
    • Situs web pembuat file EC2 user-data untuk instalasi paket, menjalankan daemon, dan sebagainya
    • Melanjutkan pekerjaan FreeBSD/Firecracker dan menjadikannya platform yang didukung
  • Pendanaan Amazon adalah kesempatan yang jauh lebih besar daripada yang diterima kebanyakan pengembang open source, dan meski ada rasa kecewa karena pendanaan berakhir, ada pula rasa terima kasih atas hasil kerja selama periode tersebut

Bacaan terkait

1 komentar

 
GN⁺ 2025-06-07
Komentar Hacker News

  • Bagus. Mulai hari ini, halaman unduhan ziglang.org menambahkan FreeBSD, sehingga pengguna FreeBSD bisa mendapatkan build branch master yang dibangun otomatis dari CI
    Sekarang FreeBSD didukung sebagai target cross-compilation kelas satu, termasuk hingga linking libc, jadi hal seperti zig cc -o hello hello.c -target riscv64-freebsd juga bisa dilakukan
    Kalau ada dependensi C/C++, itu bisa dibawa ke sistem build Zig dan dibangun, jadi rasanya proyek yang cukup kompleks pun bisa dengan mudah di-cross-compile untuk FreeBSD. Semoga ini membantu lebih banyak proyek menambahkan dukungan FreeBSD dan pengujian CI

    • Cross-compilation Zig memang hebat, dan menyenangkan melihat FreeBSD masuk ke daftar target yang didukung
    • Zig memakai lisensi yang ramah BSD, dan FreeBSD sudah menyertakan LLVM di sistem dasar, jadi saya penasaran apakah suatu hari Zig juga akan masuk ke sistem dasar
      Akan bagus kalau ada pengganti C yang diakui secara resmi

  • Ada cukup banyak bagian menarik di sini
    “Sejak minggu pertama 2024, proses boot FreeBSD tiba-tiba menjadi sekitar 3 kali lebih lambat. Setelah melakukan bisect pada commit, penyebabnya adalah commit yang menaikkan ukuran disk root dari 5GB menjadi 6GB. Kenapa begitu? Saat bertanya kepada kenalan di Amazon, jawabannya berada di antara ‘sihir’ dan ‘kamu benar-benar tidak ingin tahu’; yang penting, ketika disk root dinaikkan menjadi 8GB, performanya kembali ke level sebelumnya”

    • Batas ukuran objek asli S3 adalah 5GB, dan tulisan tahun 2006 juga menyebut demikian: https://aws.amazon.com/blogs/aws/amazon_s3/
      Saya tidak tahu apakah ini terkait dengan tebing performa yang diamati
    • Tapi sekarang saya jadi benar-benar ingin tahu
    • Saya penasaran berapa lama waktu yang dibutuhkan untuk melakukan bisect pada masalah seperti itu. Apakah setiap kali harus membangun image lalu me-reboot VM?

  • Di sisi laptop juga banyak pekerjaan, dan saya membaca bahwa BSD Foundation menginvestasikan 750 ribu dolar untuk ini
    Termasuk implementasi seperti status hemat daya S0ix, dan proyeknya bisa dilihat di sini: https://github.com/FreeBSDFoundation/proj-laptop

    • Betul, banyak pekerjaan sedang berjalan. Saya hanya menulis tentang pekerjaan yang saya lakukan ;-)

  • Saya benar-benar menaruh hormat pada cperciva
    Entah bagaimana ia bisa mengerjakan semua ini sekaligus Tarsnap

    • Pada titik tertentu, uang bisa membeli waktu. Ini seperti memilih apakah memperbaiki keran bocor sendiri atau memanggil tukang ledeng, atau apakah memulihkan sendiri drywall ruang bawah tanah setelah tukang listrik membongkarnya atau memanggil ahli
      Agar adil, sebagian waktu yang dipakai untuk ini memang diambil dari Tarsnap, tetapi jauh lebih sedikit daripada yang mungkin dikira

  • Saya berharap Amazon mengeluarkan lebih banyak biaya dan kontribusi, tetapi pada dasarnya mereka terlihat hanya ingin membayar untuk dukungan FreeBSD seminimal mungkin
    Amazon bahkan tidak ada di daftar sponsor FreeBSD [1], Google tahun lalu hanya mensponsori 9 ribu dolar, dan Apple juga tidak ada. Microsoft setidaknya ada di daftar, jadi patut diakui. Meta/Facebook juga absen
    Perusahaan-perusahaan ini menggunakan FreeBSD dan OpenBSD serta terus mendapat manfaat darinya, jadi pada dasarnya saya mengira mereka akan menjadi sponsor setiap tahun
    [1] https://freebsdfoundation.org/our-donors/donors/?donationYea...

    • Tentu akan bagus kalau Amazon berkontribusi lebih banyak, tetapi tidak ada di daftar donatur FreeBSD Foundation bukan berarti mereka tidak mendukung FreeBSD
      Misalnya, uang yang dibayarkan kepada saya tidak melalui Foundation. Kalau menebak, dari pengembangan FreeBSD yang didanai perusahaan, pengembangan yang didukung Foundation mungkin sekitar 10%
      10% itu penting karena bisa berfokus bukan pada “yang dibutuhkan perusahaan X”, melainkan “yang dibutuhkan FreeBSD”, tetapi porsinya tetap kecil
    • Cerita ini tidak menunjukkan gambaran keseluruhan
      Pertama, ini hanya menampilkan snapshot donasi Foundation untuk tahun tertentu, jadi tentu saja riwayat donasi tidak terlihat
      Kedua, ini juga tidak menunjukkan kontribusi pengembangan. Hal seperti ini biasanya bisa dilihat dalam ringkasan di tiap catatan rilis [1]
      [1] https://www.freebsd.org/releases/
    • Saya penasaran mengapa Microsoft mensponsori. Ekstensi Hyper-V tidak selengkap di Linux, dan tidak ada port .NET yang didukung Microsoft
      Saya juga tidak terpikir ada layanan Microsoft, baik cloud maupun bukan, yang berjalan di *BSD
    • Di antara FAANG, Amazon termasuk yang paling sedikit berkontribusi pada perangkat lunak bebas dan open source

  • Saya ingin memakai FreeBSD sebagai gateway/firewall/DNS/server DHCP di rumah, tetapi sepertinya tidak ada driver untuk NIC 10GbE saya, jadi akhirnya saya memilih Nix
    Dulu sekali saya memakai FreeBSD sebagai workstation, dan itu pengalaman yang cukup berkesan. Senang melihatnya masih terus berjalan stabil

    • Infrastruktur perusahaan dan pribadi saya semuanya menggunakan FreeBSD. Di FreeBSD, Intel NIC 100% dapat diandalkan, jadi saya hanya memakai itu
      Realtek tampaknya rusak saat mendapat beban, meski para engineer FreeBSD yang memelihara drivernya sudah berusaha keras. Saya tidak sedang mengeluh; saya menghargai usaha mereka
      Itu harga kecil yang harus dibayar, dan membuat saya tidak perlu memasang sistem operasi yang kurang stabil

  • Saya ingat sekitar era FreeBSD 7 atau 8, ada masa ketika driver FreeBSD untuk hal-hal seperti kartu Wi‑Fi Atheros lebih baik daripada Linux
    Saya masih lebih menyukai FreeBSD sampai sekitar 2021, tetapi itu berubah ketika komputer dengan campuran core CPU yang berbeda mulai umum. Awalnya saya membeli RockPro64 dengan 2 core big dan 4 core little, lalu kemudian membeli Intel Alder Lake
    Sejauh pemahaman saya, scheduler FreeBSD masih belum menangani konfigurasi seperti ini dengan baik, sehingga sistem seperti ditarik ke penyebut umum terendah berdasarkan core yang lambat

  • Sekadar penasaran, siapa pengguna utama FreeBSD/EC2?

    • Sama sekali tidak tahu. Serius, pengguna yang menghubungi saya mungkin sekitar 0,1% dari seluruh basis pengguna FreeBSD/EC2
      Saya benar-benar ingin tahu siapa yang memakai FreeBSD di EC2
    • Apakah Netflix memakainya hanya di perangkat edge?

  • Tulisan ini sangat bagus menunjukkan bagaimana sponsorship open source oleh perusahaan bekerja

  • Bisakah seseorang yang memakai FreeBSD menjelaskan ceruk apa yang diisi FreeBSD di ruang Unix? Mengapa FreeBSD, bukan OpenBSD atau NetBSD yang lebih sederhana dan konsisten?
    Jika jawabannya adalah dukungan seperti ZFS, driver Nvidia, ELF, lalu mengapa bukan Linux? Saya paham masalah GNU, tetapi apakah ada masalah juga pada sesuatu seperti Musl Void?
    Saya benar-benar penasaran. Bagi saya FreeBSD seperti semacam wilayah bayangan; saya belum bisa menangkap dengan tepat identitas inti yang membuatnya terus berjalan, tetapi saya tahu itu ada di suatu tempat

    • Saya pernah bekerja di perusahaan layanan keuangan yang memakai FreeBSD baik di EC2 maupun di bare metal di data center yang dikelola sendiri. Dua fitur yang selalu dipakai adalah ZFS dan jail
      Setiap layanan berjalan di jail-nya sendiri untuk isolasi, dan satu server yang bahkan tidak terlalu kuat bisa menjalankan semua layanan, sehingga efisiensi biayanya luar biasa
      Pada suatu titik kami melakukan migrasi cloud untuk konfigurasi hybrid, dan ketika memakai campuran Linux (k8s) dan FreeBSD, biaya melonjak tajam. Di data center, kekurangannya adalah harus membeli dan mengganti disk sendiri, menangani situasi seperti kebakaran, dan hanya berada di satu negara; tetapi AWS menyediakan multi-region dan berbagai fitur bagus, dan harganya pun sepadan
      Kami tidak memanfaatkan ZFS secara sangat mendalam, tetapi ketika sebuah tabel di DB produksi terhapus tidak sengaja, snapshot ZFS tepat sebelumnya memungkinkan rollback instan dan menyelamatkan kami besar-besaran sekali. Ada sedikit kehilangan data, tetapi untuk aplikasi tersebut uptime lebih penting, jadi itu bukan masalah besar. Seingat saya, kami juga memakai ZFS untuk backup
      Saya beberapa kali menggunakan dtrace untuk troubleshooting masalah lingkungan produksi, dan ketika Linux diperkenalkan ke armada server FreeBSD, tiap tim secara alami memilih distro yang berbeda, sehingga menjadi semacam kebun binatang. Jika memakai FreeBSD di server, variannya hanya satu
      Saya masih memakai dan menyukai keduanya, tetapi saya benar-benar menyukai fakta bahwa FreeBSD adalah kernel dan sistem operasi yang terintegrasi
    • Dari pengalaman saya, FreeBSD menawarkan keseimbangan yang baik di antara hal-hal yang masing-masing ditekankan OpenBSD dan NetBSD
      Secara historis FreeBSD memprioritaskan CPU Intel, NetBSD lebih kuat dalam portabilitas, dan meski FreeBSD juga solid dalam keamanan, OpenBSD lebih berfokus pada keamanan
      Dukungan ZFS FreeBSD benar-benar bisa mengubah permainan. Setahu saya Nvidia baru belakangan ini menyediakan driver native FreeBSD, dan untuk waktu lama diperlukan fitur kompatibilitas kernel Linux milik FreeBSD
      Dengan kata lain, FreeBSD memadukan dengan baik fitur-fitur yang disediakan BSD lain, sekaligus sangat stabil pada platform hardware yang terutama saya pakai
    • FreeBSD berorientasi throughput dengan cara yang jelas tidak berlaku pada OpenBSD, dan menurut saya juga tidak pada NetBSD
      NetBSD bersaing lewat portabilitas, dan saya merasa mereka tidak menghabiskan banyak waktu untuk menjaga throughput jaringan tetap tinggi
      Semua BSD pada umumnya jauh lebih sedikit berubah, dan meski ada plus minusnya, menurut saya itu lebih baik sebagai platform target integrasi
    • FreeBSD memiliki dukungan ZFS yang lebih baik daripada Linux karena tidak ada masalah lisensi
    • Basis pengguna FreeBSD jauh lebih besar daripada OpenBSD atau NetBSD. Tidak sebanding
      Daftar perangkat lunaknya juga jauh lebih besar, dan bisa digunakan sebagai sistem operasi desktop modern untuk penggunaan sehari-hari. Sulit mengatakan hal yang sama tentang dua lainnya
      Jika ditanya mengapa bukan Linux, saya tidak menginginkan Linux. Terlalu terbebani oleh kepentingan korporat