FreeBSD डेवलपमेंट के लिए एक साल का प्रायोजन

 (daemonology.net)
2 पॉइंट द्वारा GN⁺ 2025-06-07 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • FreeBSD/EC2 मेंटेनेंस और release engineering ऐसी स्थिति में टकरा रहे थे जहाँ दोनों काम एक ही व्यक्ति के volunteer समय में समा नहीं पा रहे थे, और Amazon के 1 साल के प्रायोजन ने release operations और EC2 platform improvements दोनों को साथ में संभव बनाया
  • यह प्रायोजन GitHub Sponsors के माध्यम से नाममात्र के महीने के 40 घंटे का था, लेकिन वास्तविक काम औसतन महीने के 50 घंटे रहा, जिसमें EC2 issues, release प्रगति, और अन्य release engineering काम लगभग 20/20/10 घंटे में बँटे थे
  • 1 साल में FreeBSD 13.4, 14.2, 13.5, 14.3 releases को मैनेज करते हुए AWS Graviton के power-off signal handling और EC2 device hotplug जैसे priority काम भी साथ में किए गए
  • boot performance regression पकड़ने के लिए 2018 के बाद से साप्ताहिक EC2 AMI builds का benchmark किया गया, और root disk size, EFI entropy seeding, ZFS transaction groups, तथा IMDSv2 IPv6 बदलावों में latency के कारण ढूँढकर ठीक किए गए
  • प्रायोजन खत्म होने के बाद भी यह भूमिका जारी रहेगी, लेकिन release से ठीक पहले आने वाली समस्याओं को सीधे ठीक करना या EC2 feature सूची को लगातार आगे बढ़ाना अब कम उपलब्ध समय के कारण कठिन होगा

प्रायोजन से पहले की bottleneck स्थिति और समय का बँटवारा

  • FreeBSD/EC2 मेंटेनेंस 2010 में Amazon EC2 पर FreeBSD को पहली बार boot कराने के बाद से जारी है, और नवंबर 2023 में इसमें FreeBSD release engineering lead की भूमिका भी जुड़ गई
  • Antithesis और FreeBSD/EC2 Patreon की छोटी sponsorship से इन दोनों भूमिकाओं को निभाना मुश्किल था
    • लागू किए जाने वाले features की सूची ठहर गई थी
    • anomalies दिखने पर भी जाँच का समय न होने से उन्हें टालना बढ़ता गया
    • 2024 की शुरुआत में यह चिंता बढ़ी कि FreeBSD/EC2 platform का “अच्छा मालिक” बने रहना कठिन हो रहा है
  • अप्रैल 2024 में Amazon में budget रखने वाले ज़िम्मेदार व्यक्ति को खोजने के बाद schedule, scope, और प्रक्रिया पर चर्चा हुई, और Amazon ने GitHub Sponsors के माध्यम से 1 साल का प्रायोजन देने का फैसला किया
  • प्रायोजन का दायरा FreeBSD release engineering और FreeBSD/EC2 development को मिलाकर महीने के 40 घंटे का था
    • बताया गया कि दोनों कामों में dependency है, इसलिए सिर्फ एक को sponsor करना व्यावहारिक नहीं होगा
    • वास्तविक समय निवेश औसतन महीने के 50 घंटे तक बढ़ गया
    • औसतन EC2-specific issues पर 20 घंटे, FreeBSD releases पर 20 घंटे, और अन्य release engineering से जुड़े कामों पर 10 घंटे लगते थे, हालांकि महीने-दर-महीने फर्क काफी था

तिमाही release संचालन और build सुधार

  • जुलाई 2024 में घोषित FreeBSD quarterly release schedule के अनुसार 1 साल में 4 releases को मैनेज किया गया
    • FreeBSD 13.4: सितंबर 2024
    • FreeBSD 14.2: दिसंबर 2024
    • FreeBSD 13.5: मार्च 2025
    • FreeBSD 14.3: 10 जून 2025 को release निर्धारित
  • हर release में code merge को बढ़ावा देना, merge requests को approve या reject करना, दूसरी teams के साथ coordination, images build और test करना, announcements लिखना, और release build समस्याओं को ठीक करना शामिल था
    • आम तौर पर 3 Beta, 1 Release Candidate, और अंतिम Release build किया जाता है
    • ज़्यादातर काम release से पहले वाले महीने में, यानी हर quarter के दूसरे महीने “Beta Month” में केंद्रित होता है
    • FreeBSD 13.5 में 33.5 घंटे लगे, जबकि FreeBSD 14.2 में 79 घंटे लगे
    • stable branch के बाद के चरणों में टूटने वाली चीज़ें कम होती जाती हैं, इसलिए release workload भी घटने की प्रवृत्ति रहती है
    • FreeBSD 14.1 को track नहीं किया गया, लेकिन release engineering समय शायद 100 घंटे के करीब रहा होगा, और FreeBSD 15.0 में इससे कहीं ज़्यादा लगने की संभावना है
  • सामान्य release engineering में release build parallelization भी की गई
    • EC2 AMIs की संख्या बढ़ने के साथ वास्तविक build से अधिक समय VM images में FreeBSD install करने में लगने लगा था
    • release code को parallelize किया गया, लेकिन बिखरी हुई build failures आने लगीं, और पूरी release build में लगभग 24 घंटे लगने से root cause अलग करना कठिन था
    • अंतिम कारण Makefile की एक छूटी हुई line थी जिसमें file install करने से पहले directory बनानी थी
    • fix के बाद release build का समय लगभग 22 घंटे से घटकर लगभग 13 घंटे हो गया, और build time की वजह से टाली जा रही EC2 AMI flavour expansion भी संभव हो गई
  • build reproducibility की समस्याएँ EC2 का इस्तेमाल करके नियमित रूप से जाँची जाने लगीं
    • साप्ताहिक snapshot image tests के दौरान EC2 instance चलाकर उस पर अपनी AMI build कराई जाती थी
    • diffoscope से बनी हुई disk image और source image की तुलना की जाती थी
    • नियमित tests से कई issues मिले; कुछ को सीधे ठीक किया गया और कुछ को दूसरे developers को सौंपा गया

FreeBSD/EC2 में Graviton power handling और hotplug

  • Amazon ने FreeBSD/EC2 के लिए priority पर जिन मुख्य features का अनुरोध किया, वे AWS Graviton instances के लिए power driver और device hotplug थे
  • Graviton power driver उस path को handle करता है जिसके माध्यम से EC2 API operating system को shutdown की सूचना देता है
    • इस feature के बिना FreeBSD shutdown signal को ignore करता है, और कुछ मिनट बाद EC2 timeout के बाद virtual power काट देता है
    • Graviton systems का “power button” एक GPIO pin है, और उसका विवरण ACPI _AEI object में होता है
    • ACPI में यह जानकारी खोजकर PL061 GPIO controller driver को configuration देने वाला code जोड़ा गया
    • जब GPIO pin assert होती है, controller interrupt generate करता है, ACPI “power button” event उठता है, और system shutdown तक पहुँचता है
  • EC2 द्वारा दिए गए ACPI tables इस GPIO pin को “Pull Up” के रूप में configure करने को कहते हैं, लेकिन PL061 controller में pullup/pulldown resistors नहीं हैं
    • Linux GPIO configuration failure को चुपचाप ignore कर देता था, इसलिए समस्या सामने नहीं आती थी
    • FreeBSD configuration failure के बाद device को disable कर देता था
    • भविष्य में Graviton systems पर EC2 bug के ठीक होने की संभावना है, लेकिन फिलहाल FreeBSD/EC2 AMI में ACPI_Q_AEI_NOPULL quirk डालकर _AEI object के GPIO PullUp flag को ignore किया गया है
  • hotplug, खासकर hot unplug, में अलग-अलग EC2 instance types पर कई समस्याएँ एक साथ आने के कारण अधिक काम करना पड़ा
    • कुछ Graviton systems में PCI attach के दौरान virtual IRQ reservation leak हो रही थी, और 67 बार EBS volume attach/detach करने के बाद IRQ खत्म हो जाते थे जिससे FreeBSD kernel panic होता था
      • root cause legacy PCI interrupt routing code था, और EC2 पर उस code को बंद करने के लिए boot loader setting जोड़ी गई
    • कुछ Graviton systems PCI device power state का उपयोग इस signal के रूप में कर रहे थे कि OS ने device का उपयोग समाप्त कर दिया है और eject के लिए तैयार है या नहीं
      • इसे EC2 bug माना गया, और अभी ACPI_Q_CLEAR_PME_ON_DETACH quirk के जरिए eject से पहले PCI power management register के कुछ bits बदले जाते हैं
    • नवीनतम पीढ़ी के EC2 instances के x86 और Graviton दोनों में PCIe unplug के बाद FreeBSD nvme driver panic कर जाता था
      • यह समस्या nvme driver maintainer को भेज दी गई
    • कुछ x86 और Graviton EC2 instances में eject के बाद PCI bus पर “ghost” device बच जाता था, जो नए device attach को रोकता था
      • Nitro firmware PCI bus management और PCI device management को asynchronous तरीके से चलाता था, इसलिए एक छोटी window रहती थी जिसमें device unplug हो चुका होता था लेकिन PCI bus अभी भी कुछ milliseconds तक उसके मौजूद होने की report देता था
      • Linux bus को periodically rescan करता है, इसलिए वह अक्सर इस race में हार जाता था, लेकिन FreeBSD detach के तुरंत बाद PCI bus को दोबारा scan करता था, इसलिए उसे ghost ज़्यादा दिखाई देता था
      • फिलहाल ACPI_Q_DELAY_BEFORE_EJECT_RESCAN quirk के जरिए eject signal के बाद PCI bus rescan से पहले 10ms की delay जोड़ी गई है
  • PCIe device eject request के लिए “attention” button दबाने के बाद 5 सेकंड की delay मांगता है, और दूसरी button input आने पर eject request cancel कर देता है
    • EC2 में कोई physical button दबाने वाला व्यक्ति नहीं होता, और virtual button दोबारा दबाने का कोई mechanism भी नहीं है, इसलिए यह delay अनावश्यक थी
    • boot loader tunable जोड़कर EC2 पर timeout को 0 पर सेट किया गया
  • hotplug test scripts के जरिए EC2 instance चलाकर EC2 API से EBS volumes को बार-बार plug/unplug किया जा सकता है, और जाँचा जा सकता है कि FreeBSD लगातार 300 बार attach/detach संभाल पाता है या नहीं
    • भविष्य में अगर EC2 instance types तक pre-access मिल सके, तो इससे hotplug behavior की पुष्टि करने में मदद मिलेगी

boot performance regression tracking और AMI expansion

  • Amazon के शीर्ष दो priority tasks के अलावा EC2-specific समय का लगभग आधा हिस्सा FreeBSD/EC2 की दूसरी समस्याओं पर लगा
  • 2023 के अंत और 2024 की शुरुआत में FreeBSD/EC2 instances कभी-कभी अपेक्षा से अधिक समय लेकर boot हो रहे थे, और साप्ताहिक snapshot tests में instance launch के बाद SSH connection attempt से पहले wait time बढ़ानी पड़ी
  • performance problems को संभालने के लिए 2018 के बाद से साप्ताहिक EC2 AMI builds के boot times का benchmark किया गया
    • इस प्रक्रिया में 10,000 से अधिक EC2 instances चलाए गए
    • FreeBSD boot performance plots बनाना शुरू किया गया
    • नया data collection और plot updates अब साप्ताहिक snapshot tests में शामिल हैं
  • कई boot delay causes खोजे गए और ठीक किए गए
    • 2024 के पहले हफ्ते से FreeBSD boot लगभग 3 गुना धीमा हो गया था, और इसका पता उस commit तक लगा जिसमें root disk size 5GB से 6GB की गई थी
      • Amazon की तरफ से पुष्टि के बाद root disk size को 8GB करने पर पुरानी performance वापस मिली
    • Graviton 2 series में kernel entropy seeding समस्या के कारण boot लंबा हो रहा था
      • FreeBSD kernel अगर secure random number generation के लिए पर्याप्त entropy न पाए, तो और entropy इकट्ठा होने तक boot रोक देता है
      • EFI boot loader के जरिए Nitro firmware से secure seed लेने वाला code था, लेकिन EC2 पर वह चल नहीं रहा था, और Graviton 2 पर 2048-byte request बहुत धीमी थी
      • boot menu Lua code में मौजूद request को boot loader Lua की सही जगह पर ले जाया गया ताकि menu disable हो या न हो, वह हमेशा चले
      • 64-byte EFI entropy लेकर PBKDF2 से उसे 2048-byte API input के अनुरूप expand करने पर FreeBSD arm64/base/UFS boot time लगभग 25 सेकंड से घटकर लगभग 8 सेकंड हो गया
    • ZFS images, UFS की तुलना में, ज़्यादा देर से boot हो रही थीं, और delay disk size पर नहीं बल्कि disk में data की मात्रा पर निर्भर थी
      • makefs सब कुछ एक ही transaction group में डाल रहा था, और ZFS attach के समय recent transaction group को iterate और validate करते हुए disk के सभी file metadata को पढ़ और process कर रहा था
      • Mark Johnston ने filesystem में ऊँचा transaction group लिखने का बदलाव किया ताकि single transaction group को “recent” न माना जाए
      • ZFS image boot time लगभग 22 सेकंड से घटकर लगभग 11 सेकंड हो गया
    • दिसंबर 2024 में net/aws-ec2-imdsv2-get port में IPv6 support जुड़ने के बाद boot समस्या जल्दी पकड़ में आई
      • यह port EC2 Instance MetaData Service के लिए command-line interface देता है
      • यह पहले IPv6 try करता था, लेकिन default IMDS instance configuration IPv4-only थी, और default TCP timeout 75 सेकंड ही बना रहा
      • fix के बाद IPv4 पहले try किया गया और timeout घटाकर 100ms किया गया
  • FreeBSD AMI flavours का विस्तार भी किया गया
    • पहले सिर्फ base और cloud-init मौजूद थे
    • small AMI में debug symbols, LLDB, 32-bit libraries, FreeBSD tests, Amazon SSM Agent, और AWS CLI हटाकर disk usage लगभग 5GB से घटाकर लगभग 1GB कर दी गई
    • builder AMI उपयोगकर्ताओं को custom FreeBSD AMI आसानी से बनाने के लिए FreeBSD AMI Builder AMIs प्रदान करता है
  • 4 AMI flavours, 2 filesystems, 2 architectures, और 3 FreeBSD versions के combination के कारण साप्ताहिक snapshot builds बढ़ गए, इसलिए पुराने images और उनसे जुड़े EBS snapshots को साफ़ किया गया
    • FreeBSD release engineering का AWS account Amazon sponsorship से समर्थित है, लेकिन उसका खर्च किसी न किसी को उठाना पड़ता है
    • shell scripts लिखकर 336TB के EBS snapshots हटाए जा सके

प्रायोजन समाप्त होने के बाद बचा काम और सीमाएँ

  • बड़े projects के अलावा कई छोटे काम भी चलते रहे
    • साप्ताहिक snapshot builds में मिले build breakages को ठीक करना
    • ENA driver patches की review
    • Dave Cottlehuber को OCI Container build करके repository में upload करने की क्षमता जोड़ने में सहायता देना
    • bsdec2-image-upload tool को internal AWS errors को अधिक सहजता से handle करने के लिए बेहतर बनाना
    • संयोग से मिले AWS security issue की report करना
  • प्रायोजन खत्म होने के बाद भी FreeBSD release engineering lead और FreeBSD/EC2 platform maintainer की भूमिकाएँ जारी रहेंगी
    • FreeBSD 15.0 दिसंबर में आने वाला है
    • 2026 में 14.4, 15.1, 14.5, और 15.2 आने की योजना है
  • उपलब्ध समय कम होने से release से ठीक पहले समस्याओं को सीधे ठीक करने वाला तरीका कठिन हो जाएगा
    • देर से आने वाले features के release के लिए ठीक होने के बजाय हटाए जाने की संभावना बढ़ेगी
    • FreeBSD 14.2 से OCI Containers को शामिल किया जा सका, क्योंकि sponsored time के दौरान यह सुनिश्चित किया जा सका कि ज़रूरी हिस्से सही तरीके से शामिल हों
  • EC2 की तरफ boot performance regression tests मौजूद होने से संबंधित समस्याएँ पकड़ी जा सकती हैं, लेकिन अतिरिक्त समय न होने पर feature implementation सूची ठहर सकती है
    • EBS volume expansion के समय filesystem auto-growth
    • multiple network interfaces और network interface hotplug की बेहतर auto-configuration
    • rolling “pre-patched” AMI
    • package installation और daemon execution जैसी चीज़ों के लिए EC2 user-data files बनाने वाली website
    • FreeBSD/Firecracker काम फिर से शुरू करना और उसे supported platform बनाना
  • Amazon का प्रायोजन ज़्यादातर open source developers को मिलने वाले अवसरों से कहीं बड़ा था, और इसके समाप्त होने का अफसोस होने के साथ अब तक किए गए काम के लिए आभार भी है

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

1 टिप्पणियां

 
GN⁺ 2025-06-07
Hacker News टिप्पणियाँ

  • बढ़िया है। आज से ziglang.org डाउनलोड पेज में FreeBSD जोड़ दिया गया है, ताकि FreeBSD यूज़र CI में अपने-आप बने master ब्रांच बिल्ड ले सकें
    अब libc लिंकिंग तक के साथ इसे first-class cross-compile target के रूप में support किया जा रहा है, इसलिए zig cc -o hello hello.c -target riscv64-freebsd जैसी चीज़ें भी संभव हैं
    अगर C/C++ dependencies हैं, तो उन्हें Zig build system में लाकर build किया जा सकता है, इसलिए लगता है कि काफ़ी complex projects को भी FreeBSD के लिए आसानी से cross-compile किया जा सकेगा। उम्मीद है इससे और projects को FreeBSD support और CI testing जोड़ने में मदद मिलेगी

    • Zig का cross-compilation शानदार है, और FreeBSD का supported targets की सूची में आना भी अच्छी बात है
    • Zig का BSD-friendly license है और FreeBSD पहले से base system में LLVM शामिल करता है, तो सोचता हूँ कि क्या किसी दिन Zig भी base system में आ जाएगा
      C का officially मान्यता प्राप्त विकल्प होना अच्छा होगा

  • यहाँ कुछ काफ़ी दिलचस्प बातें हैं
    “2024 के पहले हफ्ते से FreeBSD boot process अचानक लगभग 3 गुना धीमा हो गया। commits को bisect करके देखा तो वजह वह commit निकला जिसने root disk size को 5GB से 6GB किया था। ऐसा क्यों हुआ? Amazon के परिचितों से पूछा तो जवाब ‘जादू’ और ‘आप सच में जानना नहीं चाहेंगे’ के बीच कहीं था, और अहम बात यह थी कि root disk को 8GB करने पर performance पुराने स्तर पर लौट आई”

    • S3 की मूल object size limit 5GB थी, और 2006 में लिखी पोस्ट में भी ऐसा ही लिखा है: https://aws.amazon.com/blogs/aws/amazon_s3/
      पता नहीं इसका देखे गए performance cliff से कोई संबंध है या नहीं
    • फिर भी अब सच में जानने का मन कर रहा है
    • सोचता हूँ ऐसी problem को bisect करने में कितना समय लगा होगा। क्या हर बार image build करके VM reboot किया होगा?

  • laptop side पर भी काफ़ी काम हो रहा है, और मैंने पढ़ा कि BSD Foundation ने इसमें 750,000 डॉलर invest किए हैं
    इसमें S0ix power-saving states जैसी implementations शामिल हैं, और project यहाँ देखा जा सकता है: https://github.com/FreeBSDFoundation/proj-laptop

    • सही है, बहुत काम चल रहा है। मैंने बस उस काम के बारे में लिखा जो मैं कर रहा था ;-)

  • cperciva के लिए सच में बहुत respect है
    वे यह सब और Tarsnap साथ-साथ कैसे कर लेते हैं, समझ नहीं आता

    • एक point के बाद पैसे से समय खरीदा जा सकता है। जैसे टपकते नल को खुद ठीक करना है या plumber बुलाना है, या electricians द्वारा basement drywall हटाने के बाद खुद repair करना है या expert बुलाना है
      fair कहें तो यहाँ लगाया गया कुछ समय Tarsnap से निकला है, लेकिन जितना आप सोचेंगे उससे काफ़ी कम

  • उम्मीद थी कि Amazon ज़्यादा खर्च और contribution करेगा, लेकिन लगता है वे मूल रूप से केवल minimum FreeBSD support के लिए ही पैसे देना चाहते हैं
    Amazon FreeBSD sponsors की सूची में भी नहीं है [1], Google ने पिछले साल सिर्फ़ 9,000 डॉलर sponsor किए, और Apple भी नहीं है। Microsoft कम-से-कम सूची में है, यह मानना पड़ेगा। Meta/Facebook भी गायब है
    ये कंपनियाँ FreeBSD और OpenBSD इस्तेमाल करती हैं और लगातार benefit लेती हैं, इसलिए मुझे उम्मीद थी कि वे basic तौर पर हर साल sponsor करेंगी
    [1] https://freebsdfoundation.org/our-donors/donors/?donationYea...

    • बेशक Amazon और contribute करे तो अच्छा होगा, लेकिन FreeBSD Foundation donor list में न होना यह मतलब नहीं कि वह FreeBSD को support नहीं करता
      उदाहरण के लिए मुझे दिया गया पैसा Foundation के ज़रिए नहीं आया था। मेरा अनुमान है कि corporate funding से होने वाले FreeBSD development में Foundation-supported development शायद करीब 10% होगा
      वह 10% खास तौर पर इसलिए अहम है क्योंकि वह “company X को क्या चाहिए” के बजाय “FreeBSD को क्या चाहिए” पर focus कर सकता है, लेकिन फिर भी यह छोटा हिस्सा है
    • यह बात पूरी तस्वीर नहीं दिखाती
      पहला, यह किसी खास साल के Foundation donations का सिर्फ़ snapshot दिखाती है, इसलिए donation history स्वाभाविक रूप से नहीं दिखती
      दूसरा, development contributions भी नहीं दिखाती। ऐसी चीज़ें आम तौर पर हर release notes में summarized मिल सकती हैं [1]
      [1] https://www.freebsd.org/releases/
    • सोचता हूँ Microsoft sponsor क्यों करता है। Hyper-V extensions Linux जितने complete नहीं हैं, और Microsoft-supported .NET port भी नहीं है
      cloud हो या न हो, Microsoft services का *BSD पर चलना भी याद नहीं आता
    • FAANG में Amazon free और open source software के लिए सबसे कम करने वालों में है

  • मैं home gateway/firewall/DNS/DHCP server के रूप में FreeBSD इस्तेमाल करना चाहता था, लेकिन लगता है मेरे 10GbE NIC के लिए driver नहीं था, इसलिए आखिर में Nix चुना
    बहुत पहले मैंने FreeBSD को workstation के रूप में इस्तेमाल किया था और वह काफ़ी यादगार experience था। अच्छा लगता है कि यह अब भी steady तरीके से चल रहा है

    • मेरी company और personal infrastructure दोनों FreeBSD इस्तेमाल करते हैं। FreeBSD पर Intel NIC 100% reliable हैं, इसलिए मैं वही इस्तेमाल करता हूँ
      Realtek, driver maintain करने वाले FreeBSD engineers की मेहनत के बावजूद, load पड़ने पर टूटता-सा लगता है। शिकायत नहीं कर रहा, उनकी मेहनत की कद्र करता हूँ
      यह छोटी-सी कीमत है, और इससे कम stable operating system install करने से बच जाता हूँ

  • FreeBSD 7 या 8 के आसपास का वह समय याद है जब Atheros Wi-Fi कार्ड जैसी चीज़ों में FreeBSD ड्राइवर Linux से बेहतर हुआ करते थे
    करीब 2021 तक मैं FreeBSD को पसंद करता था, लेकिन अलग-अलग CPU कोर मिले हुए कंप्यूटर आम होते गए तो बात बदल गई। पहले मैंने 2 big कोर और 4 little कोर वाला RockPro64 खरीदा, और बाद में Intel Alder Lake लिया
    मेरी समझ के मुताबिक FreeBSD scheduler अभी भी ऐसी configuration को ठीक से संभाल नहीं पाता, इसलिए system को धीमे कोर के हिसाब से lowest common denominator तक खींच ले जाता है

  • जिज्ञासा है, FreeBSD/EC2 के मुख्य users कौन हैं?

    • बिल्कुल नहीं पता। सच कहूँ तो, मुझसे संपर्क करने वाले users शायद पूरे FreeBSD/EC2 user base के करीब 0.1% ही हैं
      मैं सच में जानना चाहता हूँ कि EC2 पर FreeBSD कौन इस्तेमाल करता है
    • क्या Netflix इसे सिर्फ edge equipment पर ही इस्तेमाल करता है?

  • यह पोस्ट बहुत अच्छे से दिखाती है कि कंपनियों की open source sponsorship कैसे काम करती है

  • क्या FreeBSD इस्तेमाल करने वाला कोई बता सकता है कि Unix space में FreeBSD कौन-सी niche भरता है? ज्यादा सरल और consistent OpenBSD या NetBSD की जगह FreeBSD क्यों?
    अगर जवाब ZFS, Nvidia driver, ELF जैसी support है, तो फिर Linux क्यों नहीं? GNU की समस्याएँ मैं अच्छी तरह जानता हूँ, लेकिन Musl Void जैसी चीज़ों में भी कोई समस्या है क्या?
    सच में जिज्ञासा है। FreeBSD मेरे लिए एक तरह के shadow realm जैसा रहा है; मैं उस core identity को ठीक-ठीक पकड़ नहीं पाया जो इसे लगातार चलाए रखती है, लेकिन जानता हूँ कि वह कहीं न कहीं है

    • मैंने एक financial services company में EC2 और self-managed datacenter के bare metal, दोनों पर FreeBSD इस्तेमाल करने का काम किया है। हम हमेशा जिन दो features का इस्तेमाल करते थे वे थे ZFS और jail
      हर service isolation के लिए अपनी jail में चलती थी, और एक बहुत ज्यादा powerful न होने वाला server भी सारी services चला सकता था, इसलिए cost efficiency जबरदस्त थी
      एक समय hybrid setup के लिए cloud migration किया गया, और Linux(k8s) व FreeBSD को मिलाकर इस्तेमाल करने पर costs तेजी से बढ़ गईं। Datacenter में disks खुद खरीदनी और बदलनी पड़ती हैं, आग जैसी स्थितियों से निपटना पड़ता है, और यह सिर्फ एक देश में होने की कमी है; लेकिन AWS multi-region और कई अच्छे features देता है, और उसी के हिसाब से कीमत भी है
      हमने ZFS का बहुत गहरा इस्तेमाल नहीं किया था, लेकिन production DB में गलती से table delete हो जाने पर पिछले ZFS snapshot पर तुरंत rollback करके एक बार बड़ी बचत हुई। थोड़ा data loss हुआ, लेकिन उस application में uptime ज्यादा महत्वपूर्ण था, इसलिए यह बड़ी समस्या नहीं थी। याद है कि backups के लिए भी ZFS इस्तेमाल किया था
      Production environment की troubleshooting में dtrace को कुछ बार इस्तेमाल किया, और जब FreeBSD servers में Linux लाया गया तो हर team ने स्वाभाविक रूप से अलग distribution चुन लिया और एक तरह का चिड़ियाघर बन गया। Server पर FreeBSD इस्तेमाल करें तो variant सिर्फ एक होता है
      मैं दोनों अब भी इस्तेमाल करता हूँ और पसंद करता हूँ, लेकिन FreeBSD में kernel और operating system का integrated form होना मुझे सच में बहुत पसंद है
    • मेरे अनुभव में FreeBSD, OpenBSD और NetBSD जिन पहलुओं को अलग-अलग महत्व देते हैं, उनके बीच अच्छा संतुलन देता है
      ऐतिहासिक रूप से FreeBSD ने Intel CPU को प्राथमिकता दी, NetBSD portability में ज्यादा मजबूत था, और FreeBSD की security भी ठोस थी, लेकिन OpenBSD security पर ज्यादा केंद्रित था
      FreeBSD का ZFS support सच में game-changing है। Nvidia ने हाल ही में native FreeBSD drivers दिए हैं, ऐसा मुझे पता है; लंबे समय तक FreeBSD की Linux kernel compatibility feature की जरूरत पड़ती थी
      दूसरे शब्दों में, FreeBSD दूसरे BSDs द्वारा दी जाने वाली capabilities को अच्छे से मिलाता है, और साथ ही जिन hardware platforms का मैं मुख्यतः इस्तेमाल करता हूँ उन पर बेहद stable रहा है
    • FreeBSD उस तरह से throughput-oriented है जिस तरह OpenBSD निश्चित रूप से नहीं है, और मेरे हिसाब से NetBSD भी नहीं है
      NetBSD portability पर compete करता है और network throughput को ऊँचा बनाए रखने में बहुत समय लगाता हो, ऐसा महसूस नहीं होता
      सभी BSDs आम तौर पर काफी कम बदलते हैं, और इसके फायदे-नुकसान हैं, लेकिन integration target platform के रूप में मुझे वे बेहतर लगते हैं
    • FreeBSD में license की समस्या नहीं है, इसलिए Linux की तुलना में इसका ZFS support बेहतर है
    • FreeBSD का user base OpenBSD या NetBSD से कहीं बड़ा है। तुलना ही नहीं है
      software list भी कहीं बड़ी है, और इसे modern desktop daily-use operating system के रूप में भी इस्तेमाल किया जा सकता है। बाकी दोनों के बारे में ऐसा कहना मुश्किल है
      Linux क्यों नहीं, तो मैं Linux नहीं चाहता। वह corporate interests के बोझ तले बहुत दबा हुआ है