FreeBSD di Firecracker

 (usenix.org)
3 poin oleh GN⁺ 2023-08-26 | 1 komentar | Bagikan ke WhatsApp
  • Menjalankan kernel FreeBSD 14 di Firecracker VMM, microVM berfokus Linux untuk AWS Lambda, menunjukkan bagaimana lingkungan virtualisasi minimal dapat mengungkap asumsi tersembunyi dan bottleneck pada jalur inisialisasi OS
  • Boot pertama terhambat oleh perbedaan format ELF Note pada PVH boot mode, hypercall khusus Xen, dan perbedaan tata letak memori Firecracker, lalu diselesaikan dengan memodifikasi kode PVH FreeBSD
  • Karena Firecracker tidak menyediakan ACPI, jalur untuk memperoleh informasi CPU dan interupsi menjadi berbeda, dan opsi MPTABLE_LINUX_BUG_COMPAT ditambahkan agar kompatibel dengan bug pemrosesan MPTable di Linux
  • Dalam proses menghubungkan konsol serial dan perangkat Virtio, terungkap perilaku UART, parsing command line kernel, dan batasan I/O disk yang tidak selaras, sehingga FreeBSD menerapkan hw.broken_txfifo, solusi pengosongan FIFO, dan penanganan bounce berbasis busdma
  • Dengan patch yang belum di-commit, kernel FreeBSD dapat boot dalam kurang dari 20 ms pada VM 1 CPU dan RAM 128MB; pekerjaan tersisa mencakup penggabungan dukungan PVH, pemisahan kode Xen, konfigurasi kernel yang lebih kecil, dan peninjauan porting Firecracker ke FreeBSD

Mengapa mencoba menjalankan FreeBSD di Firecracker

  • Firecracker adalah VMM yang membuat dan mengelola microVM ber-overhead rendah di atas Linux KVM untuk lingkungan eksekusi serverless seperti AWS Lambda
  • Pekerjaan porting FreeBSD dimulai pada Juni 2022
  • Motivasi pekerjaan ini adalah untuk sekaligus memeriksa keterbatasan di sisi FreeBSD maupun Firecracker
    • Sambil melanjutkan pekerjaan peningkatan kecepatan boot FreeBSD, tujuannya adalah melihat seberapa cepat sistem bisa berjalan di hypervisor minimal
    • Melakukan porting FreeBSD ke platform baru akan mengungkap bug di FreeBSD maupun platform tersebut
    • AWS Lambda saat ini hanya mendukung Linux, dan terlepas dari apakah Lambda akan diadopsi atau tidak, dukungan Firecracker oleh FreeBSD merupakan prasyarat yang diperlukan
    • Firecracker sendiri adalah platform yang menarik, sehingga ada keinginan untuk memverifikasi apakah ini benar-benar dapat berjalan

Hambatan pertama hingga kernel bisa dieksekusi

  • Firecracker awalnya dirancang untuk menjalankan kernel Linux, tetapi pada 2020 ada patch yang menambahkan dukungan PVH boot mode selain linuxboot
  • Karena FreeBSD mendukung boot PVH di Xen, jalur yang sama dicoba di Firecracker
  • Masalah pertama adalah Firecracker tidak dapat menemukan kernel entry point setelah memuat kernel FreeBSD ke memori
    • Protokol boot PVH menyimpan nilai ini di ELF Note
    • ELF Note memiliki PT_NOTE dan SHT_NOTE, dan FreeBSD tidak menyediakan format yang dicari Firecracker
    • Setelah sedikit memodifikasi linker script kernel FreeBSD, Firecracker dapat mulai mengeksekusi kernel FreeBSD
  • Eksekusi kernel berhenti lagi sekitar 1 mikrodetik kemudian

Debugging awal dan penghapusan ketergantungan Xen

  • Jika kernel mati sebelum debugger kernel dan konsol serial diinisialisasi, fitur debugging FreeBSD hampir tidak membantu
  • Informasi yang diberikan proses Firecracker hanya bahwa guest FreeBSD mengalami triple-fault
  • Dilakukan “kernel bisection” dengan menyisipkan instruksi hlt di tengah kode awal kernel untuk mempersempit lokasi crash
    • Jika mencapai hlt, Firecracker tetap berjalan tetapi penggunaan CPU host menjadi 0%
    • Jika Firecracker keluar, dapat disimpulkan crash terjadi sebelum titik tersebut
  • Penyebab pertama adalah Xen hypercall
    • Entry point PVH FreeBSD sebenarnya adalah kode untuk boot di Xen dan mengasumsikan berjalan di dalam Xen
    • KVM yang digunakan Firecracker tidak menyediakan hypercall Xen, sehingga VM crash saat dipanggil
    • Awalnya hypercall Xen dikomentari, lalu kemudian diubah agar hanya dipanggil setelah memeriksa signature Xen di CPUID
  • Pengambilan peta memori fisik adalah fungsi penting yang sebelumnya ditangani hypercall Xen
    • Sejak PVH version 1, pointer peta memori dikirim melalui halaman start_info
    • FreeBSD diubah agar menggunakan peta memori PVH version 1 alih-alih hypercall Xen
  • Perbedaan tata letak memori antara Firecracker dan Xen juga menimbulkan masalah
    • Xen memuat kernel terlebih dahulu lalu menempatkan halaman start_info di bagian akhir
    • Firecracker menempatkan halaman start_info di alamat rendah tetap lalu memuat kernel setelahnya
    • Kode PVH FreeBSD mengasumsikan ruang tepat setelah start_info sebagai scratch space, dan di Firecracker ini menimpa stack awal kernel
    • Masalah ini diselesaikan dengan mengalokasikan scratch space setelah semua area memori yang telah diinisialisasi hypervisor

Ketiadaan ACPI dan kompatibilitas MPTable

  • Di x86, FreeBSD umumnya memperoleh informasi disk, adaptor jaringan, CPU, dan pengendali interupsi melalui ACPI
  • Firecracker sengaja memilih implementasi minimal dan tidak menyediakan ACPI
  • Sebagai gantinya, FreeBSD dapat menggunakan struktur MPTable dari Intel MultiProcessor Specification lama
    • Ini tidak disertakan secara default dalam konfigurasi kernel GENERIC
    • Dalam konfigurasi kernel ringan untuk Firecracker, ini dapat digunakan dengan menambahkan device mptable
  • MPTable yang disediakan Firecracker bukan standar, melainkan disesuaikan dengan cara yang diterima Linux
    • Linux memiliki bug dalam cara menemukan dan mem-parsing MPTable
    • Firecracker dirancang dengan target boot Linux, sehingga menyediakan tata letak non-standar yang didukung Linux
    • FreeBSD, yang diimplementasikan secara independen sesuai standar, tidak dapat menemukan MPTable yang ditempatkan salah dan bahkan jika ditemukan tidak dapat mem-parsing MPTable yang tidak valid
  • Opsi kernel options MPTABLE_LINUX_BUG_COMPAT ditambahkan ke FreeBSD
    • Ini digunakan saat diperlukan kompatibilitas bug-for-bug dengan pemrosesan MPTable Linux
    • Dengan opsi ini, boot FreeBSD di Firecracker dapat berjalan lebih jauh

Dukungan konsol serial dan perangkat Virtio

  • Salah satu dari sedikit perangkat emulasi yang disediakan Firecracker adalah port serial
    • Dalam konfigurasi umum, input dan output standar proses Firecracker menjadi input dan output port serial VM
  • Kernel FreeBSD berhasil boot dengan disk root disertakan dalam image kernel, dan output konsol kernel pun dapat dibaca
  • Saat beralih ke boot user space, output konsol berhenti pada 16 karakter
    • Gejalanya sama seperti bug UART lama di QEMU
    • Karena tidak ada interupsi saat transmit FIFO UART kosong, FreeBSD tidak dapat menulis lagi setelah 16 byte
    • Masalah ini diselesaikan dengan mengompilasi solusi lama di kernel FreeBSD, yaitu variabel lingkungan kernel hw.broken_txfifo="1"
  • Input konsol juga tidak berfungsi
    • Firecracker menganggap receive FIFO UART emulasi penuh, sehingga tidak membaca konsol
    • Saat inisialisasi UART, FreeBSD mengisi receive FIFO dengan nilai sampah untuk mengukur ukurannya lalu mengosongkannya lewat FIFO Control Register
    • Firecracker tidak mengimplementasikan FIFO Control Register, sehingga FIFO tetap terlihat penuh
    • FreeBSD dimodifikasi agar, jika LSR_RXRDY masih tersisa setelah pengosongan FIFO, karakter dibaca satu per satu untuk benar-benar mengosongkannya
  • Untuk menggunakan disk dan jaringan, dibutuhkan perangkat Virtio block/network
    • Firecracker mengekspos ini sebagai perangkat mmio
    • Konfigurasi kernel FreeBSD untuk Firecracker menambahkan device virtio_mmio
  • FreeBSD awalnya mengharapkan perangkat mmio ditemukan melalui FDT, tetapi Firecracker meneruskan penanda seperti virtio_mmio.device=4K@0x1001e000:5 di command line kernel
    • FreeBSD menambahkan kode untuk mem-parsing penanda ini dan membuat node perangkat virtio_mmio
    • Setelah node perangkat dibuat, proses probe perangkat yang sudah ada di FreeBSD menentukan tipe perangkat Virtio dan memasang driver yang sesuai
  • Saat ada beberapa perangkat Virtio, muncul masalah parsing command line kernel
    • Firecracker meneruskan beberapa pasangan key=value dengan gaya Linux
    • FreeBSD mem-parsing command line kernel sebagai variabel lingkungan, sehingga jika ada dua virtio_mmio.device= dengan nama sama, hanya satu yang tersisa
    • Kode parsing lingkungan kernel awal dimodifikasi agar variabel duplikat dipertahankan dengan suffix angka seperti virtio_mmio.device= dan virtio_mmio.device_1=
  • Setelah shutdown tidak normal, kernel panic terjadi ketika fsck dijalankan pada boot berikutnya
    • fsck adalah salah satu kasus langka di FreeBSD yang menghasilkan I/O disk yang tidak selaras dengan halaman
    • Implementasi Virtio Firecracker hanya menerima satu data buffer dan tidak mendukung cara Virtio umum yang membagi buffer melintasi batas halaman menjadi beberapa segmen
    • Driver blok Virtio FreeBSD dimodifikasi agar menggunakan busdma, dan permintaan yang tidak selaras disesuaikan dengan batasan Firecracker melalui penanganan bounce memakai buffer sementara

Optimisasi boot yang diungkap Firecracker

  • Setelah FreeBSD mulai berjalan di Firecracker, titik-titik untuk mengurangi waktu boot dan penggunaan memori menjadi terlihat jelas
  • Pada VM dengan RAM 128MB, hampir separuh memori sistem berada dalam status wired dan proses sering berhenti
    • Hasil investigasi menunjukkan busdma memesan 32MB untuk bounce page
    • Dengan batasan Firecracker, setiap I/O disk hanya memerlukan satu bounce page maksimal 4KB
    • Sebuah patch yang membatasi reservasi bounce page untuk perangkat yang hanya mendukung sedikit segmen I/O mengurangi penggunaan memori menjadi 512KB
  • Optimisasi generator bilangan acak kernel mengurangi waktu boot
    • Di VM, entropi berbasis perangkat keras mungkin tidak efektif
    • x86 menggunakan RDRAND sebagai sumber entropi cadangan, tetapi jumlah entropi per permintaan kecil dan hanya diminta sekali setiap 100ms
    • Dengan mengubahnya agar meminta cukup untuk sepenuhnya melakukan seed pada generator bilangan acak Fortuna, waktu boot berkurang 2,3 detik
  • Pemrosesan Host ID juga menjadi lebih cepat
    • Biasanya boot loader menetapkan smbios.system.uuid berdasarkan informasi BIOS atau UEFI
    • Firecracker tidak memiliki boot loader, sehingga ID tidak disediakan
    • Perilaku diubah agar jika perangkat keras memberikan ID yang salah muncul peringatan lalu menunggu 2 detik, tetapi jika ID sama sekali tidak ada maka proses berjalan diam-diam dan cepat
  • Kondisi menunggu IPv6 DAD dipersempit
    • FreeBSD sebelumnya menunggu Duplicate Address Detection bila IPv6 diaktifkan pada antarmuka jaringan
    • IPv6 selalu diaktifkan pada antarmuka loopback
    • Diubah agar hanya menunggu DAD bila ada IPv6 pada antarmuka selain loopback, sehingga menghemat 2 detik
  • Waktu tunggu tetap dalam proses reboot dan shutdown dihapus
    • Saat reboot, perilaku menunggu 1 detik setelah pesan Rebooting... demi penyelesaian printf dan waktu baca diubah menjadi sysctl kern.reboot_wait_time, dengan nilai default 0
    • Perilaku BSP yang juga menunggu 1 detik lagi setelah menerima sinyal penghentian CPU lain saat shutdown atau reboot turut dihapus
  • Analisis flame chart boot dilakukan menggunakan TSLOG
    • Lingkungan minimal Firecracker memiliki sedikit noise sehingga bottleneck yang tersisa lebih mudah terlihat
    • Eksekusi VM sangat cepat sehingga membangun kernel baru, menjalankannya, dan membuat flame chart sering kali bisa selesai dalam kurang dari 30 detik
  • Analisis TSLOG mengurangi sejumlah bottleneck pada skala milidetik
    • Mengurangi loop kalibrasi 100000 kali di lapic_init menjadi 1000 kali menghemat 10 ms
    • Mengubah ns8250_drain, yang sebelumnya memanggil DELAY untuk setiap karakter, agar hanya menunda bila perlu setelah memeriksa LSR_RXRDY, menghemat 27 ms
    • Dengan membuat Firecracker mengimplementasikan CPUID leaf yang memberi tahu frekuensi TSC dan local APIC clock, dihemat 20 ms
    • Mengubah kern.nswbuf dari yang selalu 256 menjadi 32 * mp_ncpus menghemat 5 ms pada VM 1 CPU
    • Mengganti bubblesort di mi_startup dengan quicksort dapat menghemat 2 ms, tetapi per 22 Agustus 2023 belum di-commit
    • Mengubah vm_mem dari yang langsung menginisialisasi struktur vm_page untuk seluruh memori fisik menjadi inisialisasi lazy dapat menghemat 2 ms, dan per tanggal yang sama juga belum di-commit
    • Menambahkan MAP_POPULATE ke mmap guest memory Firecracker dapat mengurangi biaya ketika Linux membuat struktur halaman saat akses halaman pertama, sehingga menghemat 2 ms, dan per tanggal yang sama juga belum di-commit

Status saat ini dan pekerjaan yang tersisa

  • FreeBSD dapat boot di Firecracker dan berjalan sangat cepat
  • Dengan patch FreeBSD dan Firecracker yang belum di-commit, kernel FreeBSD dapat boot dalam kurang dari 20 ms pada VM dengan 1 CPU dan RAM 128MB
  • Pekerjaan yang tersisa berfokus pada perapian dukungan PVH dan pengurangan konfigurasi kernel
    • Patch yang disebutkan di atas perlu di-commit
    • Dukungan PVH boot mode perlu digabungkan ke Firecracker mainline
    • Kode PVH booting masih bercampur dengan dukungan Xen dan perlu dipisahkan
    • Kernel FreeBSD arm64 saat ini tidak dapat dibangun tanpa dukungan PCI atau ACPI, dan menghapus ketergantungan yang keliru dapat membuat kernel FreeBSD/Firecracker lebih kecil
    • Pemeriksaan kebutuhan reservasi memori untuk GPU Intel memakan 25µs, sehingga konfigurasi kernel yang lebih kecil masih bisa memangkas beberapa mikrodetik lagi dari waktu boot
  • Dalam jangka lebih panjang, ada juga kemungkinan untuk mem-port Firecracker agar berjalan di FreeBSD
    • Firecracker ditulis dengan asumsi menggunakan Linux KVM
    • Tidak terlihat ada alasan mendasar mengapa ini tidak bisa dibuat untuk menggunakan bagian kernel hypervisor bhyve milik FreeBSD
  • Untuk bereksperimen, kernel FreeBSD 14.0 dapat dibangun untuk amd64 dengan konfigurasi kernel FIRECRACKER, dan dapat menggunakan feature/pvh branch dari proyek Firecracker
    • Jika branch tersebut sudah tidak ada, itu berarti kodenya telah digabungkan ke pohon Firecracker mainline

Bacaan terkait

1 komentar

 
GN⁺ 2023-08-26
Opini Hacker News

  • Saya tidak begitu tahu bahwa Firecracker VM bukan sekadar teknologi container Linux, melainkan mesin virtual penuh.
    Awalnya mungkin terdengar tidak efisien, tetapi jika melihat kasus penggunaan nyata seperti fly.io, mengejutkan bahwa micro VM bisa sangat kecil sekaligus cukup kuat.

    • Jika ingin tahu lebih lanjut, ada baiknya membaca makalah NSDI'20 kami (https://www.usenix.org/conference/nsdi20/presentation/agache) yang membahas mengapa kami memilih arah ini, serta source/dokumentasi Firecracker (https://github.com/firecracker-microvm/firecracker).
      Berkat KVM dan dukungan hardware yang minimal (tanpa PCI, ACPI, dan sebagainya), source Firecracker cukup sederhana dan relatif layak dibaca bahkan oleh non-spesialis.
    • Tidak mungkin vendor cloud kelas enterprise seperti AWS mengizinkan container milik pelanggan berbeda ditempatkan bersama di dalam satu VM pada ECS atau Lambda.
      Itulah persisnya alasan Firecracker ada.
    • Firecracker bukan mesin yang “penuh” sepenuhnya, karena banyak hal yang kebetulan tidak dibutuhkan untuk kasus penggunaan Lambda dan fly.io telah dipangkas.
      ACPI yang disebut dalam artikel adalah salah satu contohnya. Meski begitu, benar bahwa ia memvirtualisasikan hardware, bukan kernel, dan inisialisasinya begitu cepat sehingga kebanyakan pengguna tampaknya tidak akan merasakan perbedaan jika mengganti containerd biasa dengan firecracker-containerd.
    • KVM itu luar biasa.
      Selain Firecracker, banyak micro VM seperti crosvm, cloud-hypervisor, dan Dragonball milik Kata sedang dikembangkan di atas KVM saat ini.
    • Saya heran membuat microkernel yang meniru ruang pengguna Linux atau ruang pengguna *NIX sesuai subset hardware virtual yang disediakan Firecracker dan QEMU bukanlah sesuatu yang standar.
      Saya tidak mendapat kesan bahwa mengimplementasikan target baru untuk bahasa pemrograman itu sesulit itu, jadi jika membuat target mirip sistem operasi seperti WASI/WASM lalu mengirim PR ke bahasa-bahasa yang didukung, sepertinya sebagian besar overhead bisa dikurangi. Bagian tersulit mungkin adalah meniru ruang pengguna Linux dengan cukup akurat, tetapi karena permukaannya sangat luas, jalur membuat target mirip sistem operasi justru tampak paling baik.

  • Jika patch Colin masuk ke FreeBSD dan Firecracker, waktu boot seluruh kernel menjadi kurang dari 20 ms.
    Kita benar-benar hidup di zaman yang sulit dipercaya.

    • Saya penasaran bagaimana ini dibandingkan dengan Linux di atas Firecracker.
      Pencarian singkat memang memunculkan beberapa angka, tetapi datanya dari beberapa tahun lalu, dan tidak jelas apakah cara mengukur waktu boot-nya sama atau apakah definisi “waktu boot”-nya sama, jadi saya tidak yakin apakah bisa dibandingkan.

  • Ini adalah presentasi BSDCan terbaru Colin yang diunggah beberapa hari lalu.
    https://youtu.be/MT3cdeuRTzs?si=l6baNriUjcvy0ZOE

    • Sebagai catatan, isinya hampir sama.
      Setelah presentasi BSDCan, FreeBSD Journal berkata, “itu presentasi yang bagus, bisakah diubah menjadi tulisan?”, lalu setelah artikel FreeBSD Journal terbit, ;login: bertanya apakah boleh memublikasikannya ulang.

  • qemu memiliki microvm yang terinspirasi oleh firecracker.
    https://qemu.readthedocs.io/en/latest/system/i386/microvm.ht...

    • Saya penasaran seberapa banyak workaround seperti ini diperlukan di QEMU.
      Tentu saja, sebagian di antaranya adalah perbaikan bug FreeBSD, jadi memang tetap diperlukan.

  • Menarik bahwa sebagian besar dari jeda 1 detik ternyata sebenarnya tidak benar-benar diperlukan.
    Saya bertanya-tanya berapa banyak administrator sistem yang benar-benar melakukan tindakan bermakna ketika sistem berhenti karena machine UUID yang salah.

    • Mungkin persentase yang cukup besar dari administrator sistem yang mengalami jeda 1 detik itu memang melakukan sesuatu.
      Sebaliknya, bagian “menampilkan pesan kepada pengguna bahwa sistem akan reboot, menunggu 1 detik agar console bisa dibaca, lalu reboot” agak berbeda.

  • Bukan bermaksud terdengar sok tahu, tetapi saya penasaran instance Firecracker semacam ini cocok untuk kasus penggunaan apa.
    Saya memakai FreeBSD untuk semuanya, dari server colocation sampai PC pribadi, dan lebih seperti administrator Unix lama daripada developer. Saya lebih suka bare metal, tetapi menyambut teknologi masa depan yang berkontribusi pada sistem operasi. Hanya saja, meski mendengar buzzword seperti Lambda atau Firecracker, saya tidak begitu paham sebenarnya dipakai untuk apa. Saya memahami Docker dan container, dan sekadar memahami k8s, tetapi saya tidak mengerti mengapa perlu menyalakan VM lalu langsung menghapusnya, padahal bisa saja menyalakan VM dan memakainya saat dibutuhkan. Apakah ini murni untuk pengalaman cloud atau penghematan biaya?

    • Instance aplikasi dibuat sebagai bagian dari siklus hidup request/response.
      Dengan begitu, node mana pun di compute plane dapat menangani trafik aplikasi mana pun. Suatu aplikasi dapat tumbuh untuk mengonsumsi resource komputasi yang tersisa di plane secara dinamis sesuai perubahan pola trafik, dan tidak memakai resource saat tidak menangani trafik. Menambah kapasitas compute plane berarti membawa lebih banyak node online. Selain mengelola banyak deployment skala besar, saya tidak terpikir kasus penggunaan khusus lain; di lingkungan yang bukan “skala besar”, ini akan menjadi teknologi yang tersembunyi di bawah batas vendor.
    • Kasus penggunaan utamanya adalah API yang sesekali dipakai.
      Jika Anda menjalankan layanan dengan API yang tidak sering digunakan tetapi harus merespons cepat saat dipanggil, Lambda atau pendekatan serupa sangat cocok. Pada praktiknya, banyak API untuk aplikasi ponsel masuk kategori ini, dan Anda tentu tidak ingin terus menjalankan mesin yang idle 99% waktunya hanya untuk merespons panggilan API semacam itu.
    • “Tinggal nyalakan VM dan pakai saat dibutuhkan. Selalu menyala dan selalu siap” berarti juga selalu ditagih biayanya.
    • Hampir semua perusahaan bisa mendapat manfaat dari scaling karena trafik tidak konstan 24 jam sehari.
      Kebanyakan tidak melakukannya hanya karena upayanya lebih besar daripada penghematannya, tetapi potensinya ada. Hal-hal seperti Lambda dan Firecracker membuatnya jauh lebih mudah.

  • Sayang sekali AWS maupun macOS di ARM tidak mendukung nested virtualization
    Kalau mendukung, pengembangan dan deployment teknologi berbasis Firecracker akan jauh lebih mudah

    • Sepengetahuan saya, virtualisasi bisa dilakukan di instance .metal
      Sebenarnya virtualisasi bisa dilakukan pada tipe instance apa pun, tetapi setahu saya hanya instance .metal yang bisa memakai akselerasi hardware
    • Sebagai catatan, instance AWS a1.metal cukup kecil, jadi rasional dari sisi biaya untuk mengutak-atik teknologi virtualisasi

  • Firecracker memang mengagumkan, tetapi ada banyak kasus pengecualian yang perlu didokumentasikan
    Saya sangat berterima kasih kepada Colin Percival karena membagikan hal ini. Saya terutama suka kalimat “setelah semua buah yang mudah dipetik sudah diambil”; bagi Colin, itu berarti patch bus_dma kustom. Kini siapa pun bisa menikmati gratis “kernel FreeBSD boot dalam kurang dari 20 ms dengan 1 CPU dan RAM 128 MB”. Ini benar-benar mencengangkan kalau Anda terbiasa dengan DevOps yang memakai cluster k8s atau banyak Docker

  • Saya sempat sedikit mencoba Firecracker; waktu boot memang sesuai janji, tetapi pengalaman penggunaannya cukup terjal
    Misalnya, setelah berhasil boot dan bersorak, semangat saya langsung turun ketika tahu bahwa untuk mengatur networking harus mengikuti tutorial panjang lagi

    • Jelas ada ruang untuk menambah nilai besar dengan membuat alat otomasi di sini
      Akan sangat bagus jika kita bisa mengunduh satu binary lalu menjalankannya, dan web interface serta API langsung muncul, bisa dikonfigurasi dengan cepat, serta otomatis mengunduh hal-hal yang diperlukan

  • “Kernel FreeBSD bisa boot dalam kurang dari 20 ms pada mesin virtual dengan 1 CPU dan RAM 128 MB”
    Astaga, bagaimana cara mencapai hal yang sama di hardware sungguhan tanpa VM ;)

    • Di hardware sungguhan pun boot kernel sudah cukup cepat dan biasanya di bawah 1 detik
      Yang lambat adalah semua sisanya. Misalnya mesin saya: Startup finished in 14.552s (firmware) + 2.885s (loader) + 741ms (kernel) + 23.116s (initrd) + 11.191s (userspace) = 52.488s