Firecracker पर FreeBSD

 (usenix.org)
3 पॉइंट द्वारा GN⁺ 2023-08-26 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • AWS Lambda के लिए Linux-केंद्रित microVM Firecracker VMM पर FreeBSD 14 kernel को boot कराने का काम इस बात का उदाहरण है कि एक न्यूनतम virtualization environment OS initialization path की छिपी assumptions और bottlenecks को कैसे उजागर करता है
  • पहली boot PVH boot mode के ELF Note format में अंतर, Xen-विशेष hypercall, और Firecracker की memory layout में अंतर की वजह से अटकी, जिसे FreeBSD के PVH code में बदलाव करके हल किया गया
  • Firecracker द्वारा ACPI न देने से CPU और interrupt जानकारी पाने का path बदल गया, और Linux के MPTable handling bug से मेल खाने के लिए MPTABLE_LINUX_BUG_COMPAT option जोड़ा गया
  • serial console और Virtio device जोड़ने की प्रक्रिया में UART behavior, kernel command line parsing, और unaligned disk I/O constraints सामने आए; FreeBSD ने hw.broken_txfifo, FIFO drain workaround, और busdma-आधारित bounce handling लागू किया
  • uncommitted patches सहित, 1 CPU और 128MB RAM VM में FreeBSD kernel 20ms से कम में boot होता है; बाकी काम में PVH support merge करना, Xen code अलग करना, छोटा kernel configuration, और Firecracker की FreeBSD porting की समीक्षा शामिल है

Firecracker पर FreeBSD चलाने की वजह

  • Firecracker एक VMM है जो AWS Lambda जैसे serverless execution environments के लिए Linux KVM के ऊपर low-overhead microVM बनाता और manage करता है
  • FreeBSD porting का काम जून 2022 में शुरू हुआ
  • इस काम की प्रेरणा FreeBSD और Firecracker, दोनों की सीमाओं को साथ में समझना था
    • FreeBSD boot speed सुधारने के काम को आगे बढ़ाते हुए देखना था कि minimal hypervisor पर यह कितना तेज हो सकता है
    • FreeBSD को नए platform पर port करने से FreeBSD और उस platform, दोनों के bugs सामने आते हैं
    • AWS Lambda अभी केवल Linux support करता है, और Lambda adoption से अलग, FreeBSD का Firecracker support करना एक जरूरी prerequisite है
    • Firecracker अपने आप में एक रोचक platform है, इसलिए असल में यह चल सकता है या नहीं, यह देखना था

Kernel execution तक पहली बाधा

  • Firecracker मूल रूप से Linux kernel चलाने के लिए design किया गया था, लेकिन 2020 में linuxboot के अलावा PVH boot mode support करने वाला patch था
  • FreeBSD Xen पर PVH booting support करता था, इसलिए वही path Firecracker पर आजमाया गया
  • पहली समस्या यह थी कि Firecracker ने FreeBSD kernel को memory में load करने के बाद kernel entry point नहीं ढूंढ पाया
    • PVH boot protocol यह value ELF Note में store करता है
    • ELF Note में PT_NOTE और SHT_NOTE होते हैं, और FreeBSD वह format नहीं दे रहा था जिसे Firecracker खोज रहा था
    • FreeBSD kernel linker script में छोटा बदलाव करने पर Firecracker FreeBSD kernel execution शुरू कर सका
  • Kernel execution लगभग 1 microsecond बाद फिर रुक गया

शुरुआती debugging और Xen dependency हटाना

  • Kernel debugger और serial console initialize होने से पहले kernel crash होने पर FreeBSD की debugging capabilities लगभग काम नहीं आईं
  • Firecracker process ने सिर्फ यह जानकारी दी कि FreeBSD guest ने triple-fault किया
  • Kernel start code के बीच में hlt instruction डालकर crash की जगह narrow down करने के लिए “kernel bisection” किया गया
    • hlt तक पहुंचने पर Firecracker चलता रहता है, लेकिन host CPU usage 0% हो जाता है
    • Firecracker exit हो जाए, तो माना जा सकता था कि crash उस point से पहले हुआ
  • पहला कारण Xen hypercall था
    • FreeBSD का PVH entry point असल में Xen में boot करने वाला code था और मानकर चलता था कि वह Xen के अंदर चल रहा है
    • Firecracker द्वारा इस्तेमाल किया गया KVM, Xen hypercall नहीं देता, इसलिए call करते ही VM crash हो गया
    • शुरुआत में Xen hypercall comment out किए गए, और बाद में CPUID में Xen signature check करने के बाद ही call करने के लिए बदला गया
  • physical memory map query करना एक जरूरी function था जो Xen hypercall संभाल रहा था
    • PVH version 1 से memory map pointer start_info page के जरिए pass होता है
    • FreeBSD को Xen hypercall के बजाय PVH version 1 memory map इस्तेमाल करने के लिए बदला गया
  • Firecracker और Xen की memory layout में अंतर ने भी समस्या पैदा की
    • Xen पहले kernel load करता है और फिर start_info page को अंत में रखता है
    • Firecracker start_info page को fixed low address पर रखता है और उसके बाद kernel load करता है
    • FreeBSD PVH code start_info के ठीक बाद की जगह को scratch space मानता था, और Firecracker में इससे initial kernel stack overwrite हो रहा था
    • Hypervisor द्वारा initialize किए गए सभी memory regions के बाद scratch space allocate करने के लिए बदलाव करके इसे हल किया गया

ACPI की अनुपस्थिति और MPTable compatibility

  • x86 पर FreeBSD आम तौर पर disk, network adapter, CPU, और interrupt controller की जानकारी ACPI के जरिए पाता है
  • Firecracker जानबूझकर minimal implementation चुनता है और ACPI नहीं देता
  • इसके बजाय FreeBSD पुराने Intel MultiProcessor Specification की MPTable structure इस्तेमाल कर सकता है
    • यह GENERIC kernel configuration में default रूप से शामिल नहीं है
    • Firecracker के लिए lightweight kernel configuration में device mptable जोड़कर इसका इस्तेमाल किया जा सकता था
  • Firecracker द्वारा दिया गया MPTable standard नहीं था, बल्कि Linux जिस तरह स्वीकार करता है उसके हिसाब से था
    • Linux में MPTable खोजने और parse करने के तरीके में bug था
    • Firecracker को Linux boot कराने के लक्ष्य से design किया गया था, इसलिए वह Linux द्वारा support की जाने वाली non-standard layout देता है
    • Standards के अनुसार independently implemented FreeBSD गलत जगह रखे MPTable को नहीं ढूंढ पाया, और मिल भी जाए तो invalid MPTable parse नहीं कर पाया
  • FreeBSD में options MPTABLE_LINUX_BUG_COMPAT kernel option जोड़ा गया
    • जब Linux की MPTable handling के साथ bug-for-bug compatibility चाहिए हो, तब इसका इस्तेमाल होता है
    • इस option से Firecracker पर FreeBSD booting और आगे बढ़ी

Serial console और Virtio device support

  • Firecracker द्वारा दिए जाने वाले कुछ emulated devices में से एक serial port है
    • सामान्य configuration में Firecracker process का standard input/output VM के serial port input/output बन जाता है
  • FreeBSD kernel root disk को kernel image में शामिल करके boot हुआ, और kernel console output तक पढ़ा जा सका
  • User space booting पर जाने के बाद console output 16 characters पर रुक गया
    • यह पुराने QEMU के UART bug जैसा symptom था
    • UART का transmit FIFO खाली होने पर interrupt नहीं आया, इसलिए FreeBSD 16 bytes के बाद और नहीं लिख पाया
    • FreeBSD kernel के मौजूदा workaround hw.broken_txfifo="1" को kernel environment variable के रूप में compile करके हल किया गया
  • Console input भी काम नहीं कर रहा था
    • Firecracker ने माना कि emulated UART का receive FIFO भर गया है, इसलिए उसने console नहीं पढ़ा
    • FreeBSD UART initialization के दौरान FIFO size मापने के लिए receive FIFO को garbage values से भरता है और फिर FIFO Control Register से खाली करता है
    • Firecracker FIFO Control Register implement नहीं करता, इसलिए FIFO भरा ही रहा
    • FreeBSD में बदलाव किया गया कि FIFO clear करने के बाद भी अगर LSR_RXRDY बचा रहे, तो एक-एक character पढ़कर FIFO खाली कर दे
  • Disk और network इस्तेमाल करने के लिए Virtio block/network devices चाहिए थे
    • Firecracker इन्हें mmio devices के रूप में expose करता है
    • FreeBSD Firecracker kernel configuration में device virtio_mmio जोड़ा गया
  • FreeBSD मूल रूप से उम्मीद करता था कि mmio devices FDT से discover होंगे, लेकिन Firecracker kernel command line में virtio_mmio.device=4K@0x1001e000:5 जैसे directives pass करता है
    • FreeBSD ने इन directives को parse करके virtio_mmio device nodes बनाने वाला code जोड़ा
    • Device node बन जाने पर FreeBSD की मौजूदा device probe process Virtio device type पहचानती है और उचित driver attach करती है
  • कई Virtio devices होने पर kernel command line parsing की समस्या आई
    • Firecracker Linux तरीके से कई key=value pairs भेजता है
    • FreeBSD kernel command line को environment variables की तरह parse करता है, इसलिए समान नाम के दो virtio_mmio.device= होने पर सिर्फ एक बचता है
    • Early kernel environment parsing code में बदलाव किया गया कि duplicate variables को numbered suffix देकर virtio_mmio.device= और virtio_mmio.device_1= की तरह preserve करे
  • Abnormal shutdown के बाद अगली boot में fsck चलने पर kernel panic हुआ
    • fsck FreeBSD में page-aligned नहीं होने वाला disk I/O पैदा करने वाले दुर्लभ cases में से एक है
    • Firecracker का Virtio implementation केवल एक data buffer लेता है, और page boundary cross करने वाले buffer को कई segments में बांटने वाली सामान्य Virtio विधि support नहीं करता
    • FreeBSD Virtio block driver को busdma इस्तेमाल करने के लिए बदला गया, और unaligned requests को temporary buffer से गुजरने वाली bounce handling के जरिए Firecracker की limit के अनुरूप किया गया

Firecracker ने जो boot optimizations उजागर किए

  • FreeBSD के Firecracker पर चलने लगने के बाद boot time और memory usage कम करने की जगहें साफ दिखने लगीं
  • 128MB RAM VM में system memory का लगभग आधा हिस्सा wired state में था और processes अक्सर terminate हो रहे थे
    • जांच में पता चला कि busdma bounce pages के लिए 32MB reserve कर रहा था
    • Firecracker की limit के अनुसार हर disk I/O को ज्यादा से ज्यादा एक 4KB bounce page ही चाहिए था
    • कम संख्या में I/O segments support करने वाले devices के लिए bounce page reservation सीमित करने वाले patch से memory usage घटकर 512KB हो गया
  • Kernel random number generator optimization से boot time घटा
    • VM में hardware device-based entropy प्रभावी नहीं हो सकती
    • x86 का RDRAND backup entropy source के रूप में इस्तेमाल होता है, लेकिन हर request में entropy की मात्रा कम थी और request केवल हर 100ms में एक बार की जाती थी
    • Fortuna random number generator को पूरी तरह seed करने लायक request करने के लिए बदलकर 2.3 seconds कम किए गए
  • Host ID handling भी तेज हुई
    • सामान्यतः boot loader BIOS या UEFI जानकारी के आधार पर smbios.system.uuid set करता है
    • Firecracker में boot loader नहीं है, इसलिए ID provide नहीं होती
    • Hardware गलत ID दे तो warning के बाद 2 seconds wait किया जाता था; ID बिल्कुल न हो तो शांत और तेज आगे बढ़ने के लिए बदलाव किया गया
  • IPv6 DAD wait condition संकरी की गई
    • FreeBSD network interface पर IPv6 enabled होने पर Duplicate Address Detection का इंतजार करता था
    • loopback interface पर हमेशा IPv6 enabled था
    • केवल loopback के अलावा किसी interface पर IPv6 हो तभी DAD wait करने के लिए बदलकर 2 seconds कम किए गए
  • Reboot और shutdown process में fixed wait time हटाए गए
    • Reboot के समय Rebooting... message के बाद printf complete होने और पढ़ने के समय के लिए 1 second wait करने वाला behavior kern.reboot_wait_time sysctl में बदला गया, और default value 0 है
    • Shutdown या reboot के समय BSP द्वारा अन्य CPUs को stop signal मिलने के बाद अतिरिक्त 1 second wait भी हटाया गया
  • TSLOG का इस्तेमाल करके boot flame chart analyze किया गया
    • Firecracker का minimal environment कम noise वाला था, इसलिए बचे हुए bottlenecks देखना आसान था
    • VM execution बहुत तेज होने से नया kernel build, run, और flame chart generation अक्सर 30 seconds से कम में संभव था
  • TSLOG analysis से millisecond-level के कई bottlenecks घटे
    • lapic_init के 100000-iteration calibration loop को 1000 iterations तक घटाकर 10ms कम किए गए
    • ns8250_drain में हर character पर DELAY call करने वाले हिस्से को LSR_RXRDY check के बाद केवल जरूरत होने पर delay करने के लिए बदलकर 27ms कम किए गए
    • Firecracker ने TSC और local APIC clock frequency बताने वाला CPUID leaf implement किया, जिससे 20ms कम हुए
    • kern.nswbuf को हमेशा 256 रखने के बजाय 32 * mp_ncpus करने से 1 CPU VM में 5ms कम हुए
    • mi_startup की bubblesort को quicksort में बदलने से 2ms कम हो सकते हैं, और 22 अगस्त 2023 तक यह अभी commit नहीं हुआ था
    • vm_mem द्वारा सारी physical memory के vm_page structures को तुरंत initialize करने के बजाय lazy initialization करने से 2ms कम हो सकते हैं, और उसी तारीख तक यह अभी commit नहीं हुआ था
    • Firecracker की guest memory mmap में MAP_POPULATE जोड़ने से पहली page access पर Linux द्वारा page structure बनाने की cost घटकर 2ms कम हो सकती है, और उसी तारीख तक यह अभी commit नहीं हुआ था

मौजूदा स्थिति और बाकी काम

  • FreeBSD Firecracker पर boot होता है और बहुत तेज चलता है
  • FreeBSD और Firecracker के uncommitted patches सहित, 1 CPU और 128MB RAM VM में FreeBSD kernel 20ms से कम में boot कर सकता है
  • बाकी काम PVH support को व्यवस्थित करने और kernel configuration छोटा करने पर केंद्रित है
    • ऊपर बताए patches commit करने होंगे
    • PVH boot mode support को Firecracker mainline में merge करना होगा
    • PVH booting code Xen support के साथ मिला हुआ है, इसे अलग करना होगा
    • FreeBSD arm64 kernel अभी PCI या ACPI support के बिना build नहीं हो सकता; गलत dependencies हटाने से FreeBSD/Firecracker kernel और छोटा हो सकता है
    • Intel GPU के लिए memory reservation की जरूरत है या नहीं, यह check करने में 25µs लग रहे हैं, इसलिए छोटा kernel configuration boot time को कुछ microseconds और घटा सकता है
  • Longer term में Firecracker को FreeBSD पर चलाने के लिए port करने की संभावना भी है
    • Firecracker को Linux KVM के उपयोग को मानकर लिखा गया है
    • FreeBSD के bhyve hypervisor kernel हिस्से को इस्तेमाल कराने से रोकने वाली कोई बुनियादी वजह नहीं दिखती
  • Experiment करने के लिए FreeBSD 14.0 kernel को amd64 FIRECRACKER kernel configuration से build किया जा सकता है, और Firecracker project की feature/pvh branch इस्तेमाल की जा सकती है
    • अगर वह branch अब नहीं है, तो इसका मतलब है कि code mainline Firecracker tree में merge हो चुका है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-08-26
Hacker News की राय

  • मुझे पता ही नहीं था कि Firecracker VM सिर्फ़ कोई साधारण Linux container तकनीक नहीं, बल्कि एक पूरी virtual machine है
    शुरू में यह अक्षम लग सकता है, लेकिन fly.io जैसे वास्तविक use cases देखें तो हैरानी होती है कि micro VM बहुत छोटे होने के बावजूद काफ़ी शक्तिशाली हैं

    • अगर और जानना हो, तो यह समझाने वाला NSDI'20 paper (https://www.usenix.org/conference/nsdi20/presentation/agache) और Firecracker source/docs (https://github.com/firecracker-microvm/firecracker) देखना अच्छा रहेगा कि हमने यह दिशा क्यों चुनी
      KVM और न्यूनतम hardware support (PCI, ACPI नहीं, आदि) की वजह से Firecracker source काफ़ी सरल है, और non-experts के लिए भी अपेक्षाकृत पढ़ने लायक है
    • AWS जैसा enterprise-grade cloud vendor ECS या Lambda में अलग-अलग customers के containers को एक ही VM के अंदर साथ रखने की अनुमति नहीं देगा
      Firecracker के अस्तित्व की वजह यही है
    • Firecracker “पूरी” machine नहीं है, क्योंकि Lambda और संयोग से fly.io use case के लिए जिन चीज़ों की ज़रूरत नहीं थी, उनमें से बहुत कुछ हटा दिया गया है
      लेख में दिया गया ACPI इसका एक उदाहरण है। फिर भी यह बात सही है कि यह kernel नहीं बल्कि hardware को virtualize करता है, और initialization इतना तेज़ है कि ज़्यादातर users को सामान्य containerd को firecracker-containerd से बदलने पर फ़र्क महसूस नहीं होगा
    • KVM कमाल है
      Firecracker के अलावा crosvm, cloud-hypervisor, Kata के Dragonball जैसे कई micro VM अभी KVM पर develop किए जा रहे हैं
    • यह हैरानी की बात है कि Firecracker और QEMU द्वारा दिए जाने वाले virtual hardware के subset के हिसाब से Linux user space या *NIX user space की नकल करने वाला microkernel बनाना standard नहीं है
      Programming language में नया target implement करना इतना मुश्किल लगता नहीं, इसलिए WASI/WASM जैसे similar OS targets बनाकर supported languages में PR भेजे जाएँ तो overhead का अधिकांश हिस्सा घटाया जा सकता है। सबसे मुश्किल हिस्सा Linux user space की पर्याप्त सटीक नकल करना होगा, लेकिन उसका surface area इतना बड़ा है कि उल्टा similar OS target बनाने वाला रास्ता सबसे अच्छा लगता है

  • Colin के patches FreeBSD और Firecracker में आ जाएँ तो पूरा kernel boot time 20ms से कम हो जाएगा
    सचमुच अविश्वसनीय दौर में जी रहे हैं

    • मुझे जिज्ञासा है कि Firecracker पर Linux की तुलना में यह कैसा है
      जल्दी search करने पर numbers मिल जाते हैं, लेकिन वे कुछ साल पुराने हैं, और boot time मापने का तरीका वही है या “boot time” की परिभाषा वही है, यह भी साफ़ नहीं, इसलिए पता नहीं कि तुलना की जा सकती है या नहीं

  • यह Colin का हाल का BSDCan presentation है, जो कुछ दिन पहले आया था
    https://youtu.be/MT3cdeuRTzs?si=l6baNriUjcvy0ZOE

    • संदर्भ के लिए, यह लगभग वही content है
      BSDCan presentation के बाद FreeBSD Journal ने पूछा कि “presentation अच्छा था, क्या आप इसे article में बदल सकते हैं”, और FreeBSD Journal article आने के बाद ;login: ने पूछा कि क्या वे इसे republish कर सकते हैं

  • qemu में firecracker से प्रेरित microvm है
    https://qemu.readthedocs.io/en/latest/system/i386/microvm.ht...

    • सोच रहा हूँ QEMU में ऐसी कितनी workarounds की ज़रूरत पड़ती है
      बेशक कुछ तो FreeBSD bug fixes हैं, इसलिए उनकी ज़रूरत तो पड़नी ही है

  • यह दिलचस्प है कि 1 second wait का बड़ा हिस्सा असल में अनिवार्य नहीं निकलता
    गलत machine UUID की वजह से system रुकने पर कितने system administrators ने सच में कोई meaningful action लिया होगा, यह सोचता हूँ

    • शायद उस 1 second wait का सामना करने वाले system administrators में काफ़ी बड़ा हिस्सा कुछ न कुछ करता होगा
      दूसरी ओर “user को reboot करने का message दिखाओ, console पढ़ने के लिए 1 second रुको, फिर reboot करो” वाला मामला थोड़ा अलग है

  • दिखावा करने जैसा नहीं लगना चाहता, लेकिन जानना चाहता हूँ कि Firecracker instances किस तरह के use cases के लिए सही हैं
    मैं FreeBSD को colocation servers से लेकर personal PC तक हर जगह इस्तेमाल करता हूँ, और developer से ज़्यादा पुराने Unix admin जैसा हूँ। Bare metal पसंद है, लेकिन operating system में योगदान देने वाली future technologies का स्वागत है। बस Lambda या Firecracker जैसे buzzwords सुनता हूँ तो भी यह ठीक से नहीं समझ आता कि ये असल में कहाँ इस्तेमाल होते हैं। Docker और containers समझता हूँ और k8s बस मुश्किल से समझता हूँ, लेकिन जब ज़रूरत हो तब इस्तेमाल करने के लिए एक VM चला लेना ही काफ़ी है, तो VM को चालू करके तुरंत खत्म क्यों करना है, यह समझ नहीं आता। क्या यह purely cloud experience या cost saving के लिए है?

    • Application instance request/response lifecycle के हिस्से के रूप में बनाया जाता है
      इससे compute plane का कोई भी node किसी भी application traffic को handle कर सकता है। कोई application traffic pattern में बदलाव के हिसाब से plane के बचे हुए compute resources को dynamically consume करते हुए बढ़ सकता है, और जब traffic handle नहीं कर रहा हो तो resources इस्तेमाल नहीं करता। Compute plane की capacity बढ़ाने का मतलब और nodes को online लाना है। बड़े पैमाने पर deployments को बहुत manage करने के अलावा कोई खास use case ध्यान में नहीं आता, और अगर environment “scale” वाला नहीं है तो यह ऐसी technology होगी जो vendor boundary के नीचे छिपी रहती है
    • मुख्य use case कभी-कभार इस्तेमाल होने वाली API है
      अगर आप ऐसी service चला रहे हैं जिसकी API बार-बार इस्तेमाल नहीं होती, लेकिन call होने पर जल्दी response देना होता है, तो Lambda या इसी तरह का तरीका ठीक बैठता है। दरअसल mobile phone apps के लिए APIs का बड़ा हिस्सा इसी category में आता है, और ऐसी API calls का response देने के लिए ऐसी machine हमेशा चालू रखना नहीं चाहेंगे जो 99% समय idle रहे
    • “बस VM चला लो और ज़रूरत पड़ने पर इस्तेमाल कर लो। वह हमेशा चालू और हमेशा ready रहता है” का मतलब है कि billing भी हमेशा होती रहती है
    • लगभग हर company को scaling का फायदा मिल सकता है, क्योंकि traffic 24 घंटे एक जैसा नहीं रहता
      ज़्यादातर ऐसा नहीं करतीं क्योंकि मेहनत बचत से ज़्यादा होती है, लेकिन potential मौजूद है। Lambda और Firecracker जैसी चीज़ें इसे काफ़ी आसान बना देती हैं

  • यह अफसोसजनक है कि AWS और ARM वाला macOS भी nested virtualization को support नहीं करते
    अगर support होता, तो Firecracker-आधारित तकनीक को develop और deploy करना कहीं ज़्यादा आसान होता

    • जहाँ तक मुझे पता है, .metal instances पर virtualization किया जा सकता है
      असल में किसी भी instance type पर virtualization संभव है, लेकिन hardware acceleration इस्तेमाल कर पाने वाले सिर्फ .metal instances हैं, ऐसा मुझे पता है
    • संदर्भ के लिए, AWS a1.metal instance काफी छोटा है, इसलिए virtualization तकनीक से काम करने के लिए cost के लिहाज़ से reasonable है

  • Firecracker कमाल का है, लेकिन ऐसे बहुत सारे edge cases हैं जिन्हें document करने की ज़रूरत है
    Colin Percival ने यह share किया, इसके लिए बहुत धन्यवाद। खासकर “low-hanging fruit चुन लेने के बाद” वाला वाक्य मुझे पसंद है; Colin के लिए इसका मतलब custom bus_dma patches है। अब कोई भी “1 CPU और 128MB RAM पर FreeBSD kernel 20ms से कम में boot होता है” का फायदा मुफ्त में ले सकता है। अगर आप k8s cluster या बहुत सारे Docker इस्तेमाल करने वाले DevOps से परिचित हैं, तो यह वाकई हैरान करने वाली बात है

  • मैंने Firecracker को थोड़ा आज़माया, और boot time वादे के मुताबिक मिलता है, लेकिन user experience काफी कठिन है
    उदाहरण के लिए, boot सफल होने पर खुश होने के बाद पता चलता है कि networking setup करने के लिए फिर एक लंबा tutorial follow करना पड़ेगा, तो उत्साह कम हो गया

    • यहाँ automation tools बनाकर काफी value add करने की गुंजाइश साफ दिखती है
      अगर एक single binary download करके run करने पर web interface और API दोनों start हो जाएँ, जल्दी configure किया जा सके, और वह ज़रूरी चीज़ें खुद download कर दे, तो बहुत अच्छा होगा

  • “1 CPU और 128MB RAM वाली virtual machine में FreeBSD kernel 20ms से कम में boot हो सकता है”
    अरे वाह, VM के बिना real hardware पर वही चीज़ कैसे हासिल की जा सकती है ;)

    • real hardware पर भी kernel boot पर्याप्त तेज़ होता है और आम तौर पर 1 second से कम रहता है
      धीमा तो बाकी सब कुछ है। उदाहरण के लिए मेरी machine पर Startup finished in 14.552s (firmware) + 2.885s (loader) + 741ms (kernel) + 23.116s (initrd) + 11.191s (userspace) = 52.488s है