Helios: Oxide Rack को चलाने वाला illumos distribution

 (github.com/oxidecomputer)
1 पॉइंट द्वारा GN⁺ 2024-01-30 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Helios एक illumos distribution है जो Oxide Rack को चलाता है, और इस top-level repository के tools और documents कई software consolidations को जोड़कर पूरे distribution build को manage करते हैं
  • यह distribution core OS के रूप में illumos-gate stlouis branch का उपयोग करता है, और मुख्य रूप से stock illumos packages देता है जिनमें Oxide hardware के लिए अतिरिक्त components और कुछ packaging conversions जोड़े गए हैं
  • सभी component repositories public नहीं हैं, और private consolidations को OXIDE_STAFF=no gmake setup के साथ clone और build target से बाहर रखा जा सकता है
  • अपनी package build प्रक्रिया में latest Helios environment में rustup, gmake setup, और Rust-आधारित helios-build का उपयोग होता है, और development के दौरान shadow compiler व कुछ checks बंद करके quick build किया जा सकता है
  • build output को local boot environment में install किया जा सकता है, pkg.depotd के जरिए दूसरे test systems पर deploy किया जा सकता है, या install किए बिना केवल converted package repository बनाकर inspect किया जा सकता है

Helios की भूमिका और संरचना

  • Helios एक illumos distribution है जो Oxide Rack को चलाता है
  • पूरा distribution कई software consolidations से बना है, और इस top-level repository के tools और documents build को lead करते हैं
  • Public consolidations में ये शामिल हैं
  • कुछ consolidations अभी public नहीं हैं
    • amd-firmware: AMD CPU firmware binary blobs, भविष्य में public होने की योजना
    • chelsio-t6-roms: Chelsio T6 NIC firmware blobs, भविष्य में public होने की योजना
    • pilot: Oxide system low-level control utility, भविष्य में public होने की योजना
    • dmar-report: DRAM margining report generator, भविष्य में public होने की योजना
  • अगर आपके पास private repositories की access permission नहीं है, तो OXIDE_STAFF=no gmake setup से अभी public न हुए software की clone और build प्रक्रिया को skip किया जा सकता है

शुरुआती environment और initial setup

  • यह प्रक्रिया उन मामलों के लिए है जहाँ आप अपने OS packages को build और install करना चाहते हैं; अगर आपका उद्देश्य सिर्फ Helios का उपयोग करना है, तो helios-engvm में उपलब्ध prebuilt Helios software जानकारी वाला flow देखें
  • अनुशंसित शुरुआती बिंदु latest Helios installed physical या virtual build machine है
    • virtual machine install details helios-engvm में हैं
    • physical x86 systems के install media की जानकारी भी उसी repository में है
  • अगर आपने helios-engvm प्रक्रिया से VM बनाया है, तो ज़रूरी packages पहले से install होने चाहिए
  • अगर आपने ISO installer या किसी और तरीके से Helios environment बनाया है, तो pkg:/developer/illumos-tools package की ज़रूरत पड़ सकती है
    • install है या नहीं, यह pkg list developer/illumos-tools से जांचें
    • अगर missing हो, तो pkg install से install करें
  • latest Helios packages का उपयोग करना बेहतर है, और pkg update के बाद आने वाले instructions को ध्यान से देखना चाहिए
    • अगर update बताता है कि नया boot environment बना है, तो reboot के बाद उसे activate करके आगे बढ़ें
  • Rust और Cargo को Rust project के official binaries से rustup के जरिए install करें
    • official install procedure में sh की जगह bash का उपयोग करें
    • example command: curl --proto '=https' --tlsv1.2 -sSf https://sh.rustup.rs | bash

Repository clone और helios-build

  • Helios machine पर repository clone करने के बाद gmake setup चलाएँ
    • tools/helios-build में Rust-आधारित helios-build tool build होता है
    • कई repositories projects/ के नीचे clone की जाती हैं
  • अगर आपके पास oxidecomputer GitHub organization की private repositories की access नहीं है, तो आप सिर्फ public repositories का उपयोग इस तरह कर सकते हैं
    • OXIDE_STAFF=no gmake setup
  • helios-build tool का पहला build समय ले सकता है
  • initial setup step expected project repositories को clone करता है, लेकिन बाद के operations जैसे updates या branch switching कुछ repositories पर ही किए जाते हैं
    • कौन-सी repositories auto update के target हैं, यह config/projects.toml के auto_update में देखा जा सकता है
    • बाकी local clones को सामान्य Git repository की तरह manually branch switching और pull के साथ manage करना होगा

illumos build का तरीका

  • Helios के core OS components illumos-gate की stlouis branch से आते हैं
  • Helios system में शामिल अधिकांश packages stock illumos पर आधारित हैं, जिनमें Oxide hardware के लिए अतिरिक्त components और कुछ मामूली packaging conversions जोड़े गए हैं
  • helios-build illumos build को आसान बनाने के लिए build settings manage करता है और illumos build tools को call करने वाले कई wrappers देता है
  • upstream illumos documentation का Building illumos भाग उन अधिकांश कामों को cover करता है जो Helios tools आपके लिए करते हैं
  • development के दौरान आप इस command से quick build कर सकते हैं
    • ./helios-build build-illumos -q
    • quick build final integration में आवश्यक shadow compiler और कुछ checks को disable करता है
  • build time build machine के CPU count और local storage performance पर निर्भर करता है
  • पूरा build log बड़ा होता है; उदाहरण के लिए tail -F projects/illumos/log/nightly.log से इसे देखा जा सकता है
  • build सफल होने पर projects/illumos/packages/i386 में package repository बनती है, जिसे बाद में कई तरीकों से convert और install किया जा सकता है

Built packages की installation और deployment

  • Local build machine पर install

    • नए built packages को ./helios-build onu -t my-be-name से build machine पर install किया जा सकता है
    • यह command illumos packages को convert और install करती है, और -t से दिए गए नाम के साथ नया Boot Environment बनाती है
    • नया boot environment onu द्वारा activate किया जाता है, और उपयोगकर्ता reboot करके उस environment में जाता है
    • boot environment की जानकारी के लिए beadm(8) देखें
    • reboot करते समय console पर रहना बेहतर है ताकि boot messages देख सकें और boot loader से interact कर सकें
    • install के बाद pkg list -Hv system/kernel में आप देख सकते हैं कि system/kernel package local file-based on-nightly publisher और quick build version 3.0.999999 से आया है

  • दूसरी machine पर package repository server के रूप में install

    • अगर आपके पास build machine से अलग test machine है, तो आप build machine के pkg.depotd package repository server का उपयोग कर सकते हैं
    • ./helios-build onu -D recent build के packages को convert करता है और package server शुरू करता है
    • उदाहरण में यह 0.0.0.0:7891 पर service देता है
    • server Control-C या किसी अन्य termination तक चलता रहता है
    • target machine पर pkgrepo info -s http://genesis:7891 से build machine connectivity जांचें
    • stock Helios system में default रूप से central repository https://pkg.oxide.computer/helios/3/dev/ का उपयोग करने वाला एक helios publisher होता है
    • test machine पर on-nightly publisher जोड़ें, उसे search priority में पहले रखें, और existing helios publisher के sticky rule को ढीला करें
    • pkg set-publisher -r -O http://genesis:7891 --search-first on-nightly
    • pkg set-publisher -r --non-sticky helios
    • कुछ स्थितियों में update से पहले entire meta package हटाना पड़ सकता है
    • खासकर तब, जब lipkg brand-आधारित zones मौजूद हों
    • stock illumos का onu tool यह काम अपने-आप करता है
    • pkg update -nv से dry-run करें और verify करें कि update quick build packages की ओर जा रहा है
    • उदाहरण में 325 packages update होते हैं, और नया boot environment creation, activation, तथा boot archive rebuild की ज़रूरत होती है
    • version stock Helios के stlouis branch commit number-आधारित version से बदलकर 3.0.999999 quick build version हो जाता है
    • वास्तविक update pkg update -v से करें, और सफल होने पर नए boot environment में reboot करें
    • reboot के बाद publisher configuration बनी रहती है
    • इसके बाद नया build, package server restart, और test machine पर pkg update -v वाला flow बार-बार दोहराया जा सकता है

  • Install किए बिना केवल packages बनाना

    • ./helios-build onu -P quick build output packages को install किए बिना सिर्फ convert करता है
    • converted package repository tmp/onu/repo.redist में बनती है
    • यह तरीका build repository की contents inspect करने में उपयोगी है
    • pkgrepo info -s tmp/onu/repo.redist
    • pkgrepo list -s tmp/onu/repo.redist
    • pkg contents -t file -s tmp/onu/repo.redist '*microcode*'
    • package files को preserve करके अलग-अलग build outputs की तुलना, remote systems पर transfer, या बाद में install के लिए उपयोग किया जा सकता है

Changes पर काम और iterative builds

  • system changes पर काम आमतौर पर quick build के बाद clean build workspace से शुरू करना बेहतर होता है
  • किसी specific source file को बदलकर component को फिर से build करना हो, तो पहले bldenv से build environment में जाएँ
    • ./helios-build bldenv -q
    • एक नया interactive shell शुरू होता है और PATH व अन्य variables सही तरह सेट हो जाते हैं
  • component directory में जाकर dmake -S -m serial install जैसी commands से build और install किया जा सकता है
    • उदाहरण में cmd/id के अंदर id command build करके proto area में install की जाती है
  • इस तरह का targeted incremental edit-and-recompile तरीका छोटे cycle में यह जांचने के लिए उपयुक्त है कि changes compile हो रहे हैं या नहीं

  • सबसे सही लेकिन धीमा विकल्प

    • पूरे OS को दोबारा build किया जा सकता है
    • यह प्रक्रिया जहाँ तक संभव हो, सही result सुनिश्चित करने का एकमात्र तरीका है
    • अगर incremental approach में कोई ऐसी समस्या आए जिसे समझाना मुश्किल हो, तो पहले full build आज़माना बेहतर है
    • command है ./helios-build build-illumos -q

  • गारंटी नहीं, लेकिन तेज़ विकल्प

    • अगर आपने dmake install से proto area में binaries अपडेट की हैं, तो full build के बिना सिर्फ packages दोबारा बनाकर install किया जा सकता है
    • bldenv के अंदर $SRC/pkg में जाएँ और dmake install चलाएँ
    • इसके बाद updated packages के साथ package repository server शुरू करें या local install करें

  • File system को सीधे handle करने वाला विकल्प

    • operating system अंततः file system के अंदर files का समूह ही है, इसलिए packaging tools के अलावा अन्य तरीके भी संभव हैं
    • modified binaries को build system पर सीधे चलाया जा सकता है, या scp, rsync से test system पर copy करके चलाया जा सकता है
    • अगर binary को library या kernel changes चाहिए, तो यह काम न करे
    • आप नया boot environment बनाकर उसके अंदर files बदल सकते हैं
    • boot environment एक अलग ZFS file system होता है जिसे modify, snapshot, clone और boot किया जा सकता है
    • beadm create, beadm mount, beadm activate का उपयोग किया जा सकता है
    • पूरी तरह नई disk image या ramdisk बनाकर VM या PXE से boot किया जा सकता है
    • Helios-specific image generation tools helios-engvm image tools में हैं
    • ये tools quick build packages या मनचाही अतिरिक्त files को image template modifications के जरिए शामिल कर सकते हैं
    • इनका आधार upstream illumos/image-builder है

OS image archive

  • Oxide compute sled के लिए OS image build करने की प्रक्रिया में image archive बनता है
  • इस archive में boot ROM और root file system ramdisk images शामिल होते हैं
  • इसमें JSON file metadata भी शामिल होता है, और यह omicron1 brand जैसा format उपयोग करता है
  • file contents Helios और Omicron के उन हिस्सों के बीच committed interface हैं जिन्हें Oxide Rack के physical systems पर OS images download और install करने होते हैं
  • Omicron उपयोग के लिए आवश्यक files में कम-से-कम ये शामिल हैं
    • oxide.json: metadata header file, जिसमें कम-से-कम v=1 key और OS image identification के लिए t=os key होती है
    • image/rom: 32MiB host boot ROM image
    • image/zfs.img: मनचाहे आकार की host root file system ramdisk image
  • engineering या diagnostic उद्देश्यों के लिए अतिरिक्त files हो सकती हैं
    • उदाहरण: bldb या nanobl-rs के लिए unix.z compressed kernel, cpio.z compressed boot archive
    • अलग diagnostic features को दर्शाने वाले suffix के साथ अतिरिक्त ROM files की array
  • अतिरिक्त files committed interface का हिस्सा नहीं हैं और भविष्य में कभी भी बदल सकती हैं
  • image archive को parse करने वाला software ऐसी files को ignore करे जिन्हें वह पहचानता नहीं है

लाइसेंस

  • copyright 2026 Oxide Computer Company के पास है
  • अलग से उल्लेख न होने पर सभी components Mozilla Public License Version 2.0 के तहत licensed हैं

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

1 टिप्पणियां

 
GN⁺ 2024-01-30
Hacker News की राय

  • अच्छा लगा कि यह सार्वजनिक हुआ, और इसे लोकल में deploy करके जितना हो सके सीखने का सोच रहा हूँ
    Oxide tech stack और वहाँ काम करने वाले लोगों—दोनों लिहाज़ से लगभग dream company जैसी है

    • homepage को करीब 20 सेकंड देखने के बाद लगा, “on-premises server खरीदने के लिए vertical integration? custom operating system तक? आखिर premium क्यों दूँ?”
      लेकिन फिर तुरंत खयाल आगे बढ़ा: “server operating system करता ही क्या है? बस virtual machine चलानी होती है, है न? Linux ज़रूरी नहीं, Linux virtual machine चला सकना ज़रूरी है, है न”
    • SmartOS से इसकी तुलना कैसी होगी, यह देखने की उत्सुकता है
      personal infrastructure में SmartOS पर काफी investment किया है, लेकिन Joyent acquisition के बाद उसके भविष्य को लेकर चिंता थी
      काश मैं इतनी बड़ी organization में काम करता जो Oxide equipment इस्तेमाल कर सके। नकली IBM PC AT-style compatibility ढाँचे, खराब BMC और iDRAC, hardware RAID controllers जैसी चीज़ों से जूझना न पड़े, तो यह बेहद शानदार होगा
    • Oxide सच में उन गिनी-चुनी companies में से है जहाँ मैं काम करना चाहूँगा
      बाहर से देखने पर इसका vibe Sun जैसा लगता है, और मैं हमेशा ऐसी ही company का सपना देखता रहा हूँ
      हालांकि परिवार का खर्च उठाने की स्थिति में salary structure मेरे लिए संभव नहीं है। जब बच्चा college से graduate हो जाए और बड़ी income की ज़रूरत न रहे, तब शायद यह सपना पूरा कर सकूँ

  • कोई Oxide क्या provide करता है, यह 5 साल के बच्चे को समझाने जैसा समझा सकता है? website देखकर भी समझ नहीं आया
    क्या यह खरीदकर on-premises में इस्तेमाल होने वाला hardware+software है, PaaS है, या कोई और cloud provider है?

    • लगता है downvote इसलिए मिल रहे हैं क्योंकि इससे जुड़ा एक बड़ा thread पहले से है, लेकिन यह थोड़ा unfair लगता है
      सीधे निष्कर्ष पर आएँ तो हाँ। यह खरीदकर on-premises में इस्तेमाल होने वाला hardware+software है
      ज़्यादातर existing on-premises cloud products से फर्क यह है कि यह एक single vendor है जिसने hardware और software को साथ में अच्छे से काम करने के लिए design किया है। software को जितना संभव हो open source बनाया जा रहा है, इसलिए इस तरह की announcements आती हैं
      अधिकांश products कई vendors के products को जोड़ते हैं और असल में integration बेचते हैं। Oxide का मानना है कि वह तरीका कई समस्याएँ पैदा करता है, और उनका product उन समस्याओं को हल करता है
      एक और बात यह है कि SKU सिर्फ दो हैं। केवल half rack और full rack हैं; 1U unit में नहीं, rack unit में खरीदते हैं
      पूरे rack को एक cohesive unit के रूप में design करने पर ऐसे काम किए जा सकते हैं जो 1U form factor में संभव नहीं होते। वे fan की बात हमेशा करते हैं—इस पर मज़ाक होता है, लेकिन यह सच है। traditional 1U से बड़े sleds इस्तेमाल करने के कारण बड़े fans लगाए जा सकते हैं, और उन्हें कम RPM पर चलाया जा सकता है, जिससे power बचती है
      यह जानबूझकर किया गया design choice है, लेकिन इसके side effects भी हैं। कम RPM की वजह से servers काफी शांत होते हैं। शुरुआती potential customers में से कुछ ने demo के दौरान पूछा भी था, “क्या यह सच में चालू है?”
      server खरीदने की वजह सिर्फ शांत होना तो नहीं होगी, लेकिन यह एक दिलचस्प example है कि product को सिर्फ integration work मानने के बजाय पूरे तौर पर दोबारा सोचने से क्या हो सकता है
    • on-premises के लिए पूरी तरह integrated compute और storage solution है, cloud-style API से resources provision करता है, और open source के प्रति commitment भी साथ देता है

  • मुझे पता है कि Oxide के लोग Sun से आए हैं, लेकिन Linux के बजाय कुछ और चुनने में business value proposition के लिहाज़ से असल तकनीकी फायदा है क्या?
    मुझे पता है कि illumos, Linux से तकनीकी रूप से कुछ मामलों में बेहतर है, लेकिन क्या इसे खरीदने वाले ग्राहक के लिए यह सच में मायने रखता है, समझ नहीं आता
    कहीं ऐसा तो नहीं कि विचारधारा या परंपरा की वजह से वे ऐसी जटिल समस्या खोल रहे हैं जो ज़्यादा कंप्यूटर बेचने में बाधा बनेगी
    Linux container workloads चलाने वाले के नज़रिए से, इसका मूल रूप से non-Linux होना खरीदने की वजह नहीं बल्कि खरीद पर हिचकने की वजह बनता है। मुझे पता है कि यह Linux binaries को बिना बदलाव के चला सकता है

    • product में ऐसा नहीं कहा जाता कि “वैसे, अंदर illumos है, इसलिए आपको यह rack खरीदना चाहिए”
      यह customer-facing product detail नहीं है, और ज़्यादातर को शायद इस बात का पता भी न हो
      ग्राहक को इस बात से मतलब है कि rack efficient, stable और उसकी जरूरत के हिसाब से है या नहीं। यहाँ Linux के बजाय illumos चुनना उस value को प्रभावी ढंग से देने के लिए किया गया चुनाव है
      बेशक इसका मतलब यह नहीं कि ऐसा ही product Linux पर बनाया नहीं जा सकता, बल्कि हमने माना कि illumos उद्देश्य के लिए ज़्यादा उपयुक्त है
      यह फैसला हमने team के साथ RFD[1] के रूप में लिया था, और उसका number #26 है, लेकिन फिलहाल public नहीं है। गंभीरता से देखे गए विकल्प Linux का KVM और illumos का bhyve थे, और वह काफ़ी लंबा document है
      आखिरकार एक रास्ता चुनना था, और हमने यह रास्ता चुना। मैं इस हिस्से को सीधे develop नहीं करता, लेकिन अब तक इसे बाधा मानने की कोई वजह नहीं दिखी; उल्टा यह सही चुनाव होने की संभावना ज़्यादा लगती है
      मुझे जानना है कि non-Linux होना खरीद के खिलाफ वजह क्यों बनता है। अगर आप और समझा सकें तो अच्छा होगा। आह, नीचे वाला comment देखा: https://news.ycombinator.com/item?id=39180814
      1: https://rfd.shared.oxide.computer/
    • Helios rack का सिर्फ implementation detail है, और Hubris[0] की तरह user या application को दिखने वाला element नहीं है। rack users virtual machines provision करते हैं
      illumos derivative को किसी और चीज़ के बजाय क्यों इस्तेमाल किया गया, इसे हमने पहला rack ship करते समय Q&A[1] में थोड़ा cover किया था, और आज बाद में होने वाली recorded discussion[2] में फिर समझाएँगे
      [0] https://hubris.oxide.computer/
      [1] https://www.youtube.com/watch?v=5P5Mk_IggE0&t=2556s
      [2] https://mastodon.social/@bcantrill/111840269356297809
    • embedded या appliance क्षेत्र में Linux आसानी से nightmare बन सकता है
      platform engineers अपना दिन latest kernel, drivers और core libraries की समस्याएँ ठीक करने में बिता देते हैं, और असली application उसी के ऊपर depend करने लगती है
      या फिर 99% IoT vendors की तरह base operating system को कभी update न करने और यह दुआ करने वाला रास्ता अपनाते हैं कि उसे target करने वाले active exploits न हों
      इसी वजह से mid-sized companies ने CentOS issue पर बहुत सिर पीटा। क्योंकि वे paid full RHEL installation चलाए बिना भी एक अपेक्षाकृत stable platform पर रहते हुए security updates पा सकती थीं
      करीब हर 10 साल में सारी dependencies को फिर से देखना पड़ता था, लेकिन 1–2 साल के update cycle के साथ चलने से यह कहीं आसान था। कुछ systems में validation period ही 6 महीने से ज़्यादा होता है, इसलिए वह cycle बहुत छोटा है
      यह लगभग सिर्फ Linux की समस्या जैसी है, और *BSD जैसे alternatives, Linux जो कुछ देता है उसका ज़्यादातर हिस्सा देते हुए भी इस तरह की लगातार टूट-फूट को बहुत कम रखते हैं
    • विकल्पों का होना healthy बात है, और Oracle के Sun खरीदने के बाद universe थोड़ा recover होता हुआ भी लगता है
      Oxide systems को एक साथ जोड़कर deliver करने वाली team के लिए इनसे बेहतर लोगों की कल्पना करना मुश्किल है
      अभी मैं सिर्फ Linux पर काम करने वाला engineer हूँ, लेकिन वह समय याद आता है जब high-value workloads चलाने के लिए एक और मजबूत Unix मौजूद था
      Linux के openvswitch और Solaris की Crossbow SDN capabilities की तुलना करें तो मैं कभी भी Crossbow चुनूँगा
      इसका मतलब यह नहीं कि Linux गलत है, लेकिन tools अपने-अपने रास्ते चलते हुए complexity बनाते हैं, और उसके ऊपर फिर और complex tools से abstract करना पड़ता है; यानी “master plan” जैसी cohesion की बहुत कमी है
    • ग्राहक इसके ऊपर virtualized operating systems चलाते हैं
      यह Azure Host OS, Bottlerocket, Flatcar जैसी चीज़ों से बहुत अलग नहीं है
      अहम बात यह है कि वे पूरा stack जानते हैं, kernel code का कुछ हिस्सा Sun के दिनों से उनके पास है, और security evaluation के लिए source access चाहने वाले ग्राहकों को उसे दिखाया जा सकता है

  • illumos के बारे में ठीक से नहीं जानता था, इसलिए वेबपेज देखा तो सबसे पहले “illumos is a Unix operating system” लिखा था
    क्या illumos, macOS की तरह सचमुच Unix है, या GNU/Linux की तरह Unix-जैसा operating system है?

    • सचमुच Unix है। Wikipedia की व्याख्या काफी अच्छी है: https://en.wikipedia.org/wiki/Illumos
      यह OpenSolaris पर आधारित है, और OpenSolaris, System V Release 4(SVR4) और Berkeley Software Distribution(BSD) पर आधारित है। Illumos में kernel, device drivers, system libraries, और system administration के लिए utility software शामिल हैं। यह core, कई open source Illumos distributions का आधार बनता है, ठीक वैसे ही जैसे Linux kernel कई Linux distributions का आधार बनता है
    • Open Group के Unix Branding certification tests पास करवाने के लिए किसी ने पैसे नहीं दिए
      https://www.opengroup.org/openbrand/register/
      इसलिए UNIX™ trademark इस्तेमाल नहीं किया जा सकता
      लेकिन अंदर AT&T Unix kernel और user space source मौजूद है
      PDP-11 Unix System III: https://www.tuhs.org/cgi-bin/utree.pl?file=SysIII/usr/src/ut...
      IllumOS: https://github.com/illumos/illumos-gate/blob/b8169dedfa435c0...
    • कानूनी रूप से NetBSD भी असली Unix नहीं है। उस brand का वह मतलब नहीं है जो लोग समझते हैं
    • यह Solaris की open source शाखा थी, जिस पर Sun में Ian Murdock ने Project Indiana नाम से काम किया था, और यह UNIX SVR4 से निकला है
    • असली Unix है। मेरी जानकारी में यह Solaris परिवार का है

  • ऐसा नहीं कि मैं Oxide का समर्थन नहीं करता, लेकिन product अभी बहुत ज्यादा niche और शुरुआती stage में है, इसलिए कल्पना करना मुश्किल है कि वास्तविक कंपनियां कुछ समय तक इसे खरीदेंगी
    पिछले summer के आखिर में ही पहला rack पहले customer को ship किया गया था, और वह customer भी Idaho National Laboratory है
    अभी इस तरह का दांव लगा सकने वाली जगहें असल में लगभग राष्ट्रीय research institutions ही लगती हैं

    • पिछले साल October की announcement में दो customers का जिक्र था: https://oxide.computer/blog/oxide-unveils-the-worlds-first-c...
      Oxide के customers में Idaho National Laboratory और एक global financial services organization शामिल हैं। Fortune 1000 company में अतिरिक्त installation भी आने वाले कुछ महीनों में पूरी होने वाली है
    • अपने शुरुआती अस्तित्व में हर product ऐसा ही दिखता है
      अगर आप किसी और तरीके से launch करने की planning कर रहे हैं, तो आपने launch से पहले ही company को डुबो दिया है। कुछ lucky survivors होते हैं, लेकिन वही startup की 10 में से 9 failures वाली statistic में योगदान देता है
      शुरुआती customer segment पर बेहद focus करके chasm पार करना होता है, उसके बाद mass market आता है
    • उम्मीद है कि कभी वे छोटा और सस्ता homelab product भी निकालेंगे
      लोग सीख सकेंगे या startups इसे आजमा सकेंगे, और इससे आगे चलकर rack sales या hiring हो सकती है
    • हाल में public हुई एक tech company में काम करता हूं, और on-premises evaluate करते समय हमने Oxide को गंभीरता से consider किया था
      अब भी “on-premises... उफ” सोचने वाले लोगों पर भी यह proposal काम करता है
      ऐसा लगता है कि यह आपके अपने hardware पर cloud-like experience देता है
      काश यह Dell जितना सस्ता होता
    • हमारी company ने भी इसे evaluate किया और product से बहुत गहरा impression पड़ा
      अकेली समस्या यह थी कि यह general-purpose compute के लिए बनाया गया है, जबकि हमें सच में ज्यादा तेज processor options चाहिए थे

  • मुझे सच में अच्छा लगा कि documentation साफ और सहज दिखती है। व्यक्तिगत रूप से मुझे लगता है कि illumos community ने historically जिस क्षेत्र में struggle किया है, वह documentation ही था
    नए source release में consolidations की बात देखकर अच्छा लगा। हालांकि अगर मैंने repository structure को बहुत गलत नहीं समझा है, तो यह traditional gate paradigm से अलग दिशा में जाता दिखता है
    कुछ सवाल हैं, मुख्यतः tools से जुड़े। gmake क्यों? बाद में dmake की भी वैसे जरूरत लगती है
    guide में rustup को bash से explicitly चलाने को कहा गया है—क्या यह upstream defect है, या local sh पूरी तरह POSIX-compatible नहीं है?
    internal development कैसे करते हैं? क्या Oxide के लोग illumos workstations इस्तेमाल करते हैं, या सब virtual machines में develop करते हैं या servers में SSH करते हैं?
    MPL क्यों? क्या GPL compatibility की वजह से?

    • मैं सीधे helios पर काम नहीं करता, इसलिए सबका जवाब नहीं दे सकता, लेकिन कुछ का दे सकता हूं
      Oxide के लोग illumos workstations इस्तेमाल करते हैं या virtual machines/server SSH से develop करते हैं, इस पर मैंने यहां लिखा है: https://news.ycombinator.com/item?id=39181727
      हालांकि सच में कुछ लोग workstation पर illumos इस्तेमाल करते हैं
      MPL के बारे में यहां है: https://news.ycombinator.com/item?id=39181844
      उस comment में “क्यों” पर गहराई से बात नहीं की, लेकिन मुझे यह possibilities के दायरे में अच्छा compromise लगता है। यह BSD से ज्यादा copyleft है, लेकिन GPL से कम restrictive है
    • मेरी जानकारी में वह upstream issue है
      ज्यादातर open source projects की तरह वहां भी Linuxism/Bashism है
    • ऐतिहासिक कारणों से core operating system build करते समय dmake इस्तेमाल होता है, लेकिन दूसरे consolidation में नया Makefile बनाते समय आम तौर पर GNU make(gmake) recommend किया जाता है
      यह व्यापक रूप से उपलब्ध है, दूसरे platforms पर भी चल सकता है, और इसमें ज्यादा modern features हैं

  • सॉफ्टवेयर का open source होना शानदार है, लेकिन क्या इसे दूसरे hardware पर deploy करके इस्तेमाल किया जा सकता है?
    अगर किसी भी वजह से कंपनी आगे Oxide rack नहीं खरीद पाए, तो क्या उसे infrastructure को शुरू से फिर बनाना पड़ेगा, या वह Oxide hardware के इर्द-गिर्द ही विस्तार जारी रख सकती है?

    • हमारे hardware के बाहर इसका तुरंत उपयोगी होने की संभावना ज़्यादा नहीं है, लेकिन मुख्य काम virtual machines deploy करना है
      अगर आप खरीदे हुए Oxide rack का इस्तेमाल बंद करने का फैसला करते हैं, तो virtual machines को बाद में चुने गए infrastructure पर ले जा सकते हैं

  • सच में उत्सुकता है कि कंपनियाँ Linux/Mac/BSD नहीं, बल्कि किसी custom Unix पर कौन-से workloads चलाना चाहेंगी
    ज़्यादा परिपक्व operating system diversity बनना अच्छा है और मैं इसका समर्थन करता हूँ, लेकिन अंतिम users कौन होंगे और उनकी ज़रूरतें क्या होंगी, इसका अंदाज़ा नहीं लग रहा

    • Oxide rack में provision की जाने वाली compute virtual machines हैं। FreeBSD से bhyve को port किया गया है और live migration भी जोड़ा गया है
      अगर ज़रूरत पड़ी तो Windows Server भी boot किया जा सकेगा, ऐसा लगता है
      Illumos इस्तेमाल करने की वजह यह भी है कि Sun, Joyent आदि से आए बहुत लोग हैं, इसलिए एक स्वाभाविक झुकाव है
      लेकिन इसका एक काफ़ी ठोस कारण भी है कि यह IBM-compatible x86 personal computer नहीं है। न BIOS है, न UEFI, न पारंपरिक BMC; और modern x86 इस्तेमाल करते हुए भी proprietary firmware और binary blobs को जितना हो सके हटाया गया लगता है
      हर sled में service processor और hardware root of trust है, जो CPU को सीधे boot करता है, AMD training blob load करता है और फिर operating system boot करता है
      फिलहाल सिर्फ़ उनके पास मौजूद कंप्यूटर के लिए ऐसे बदलावों को Linux या BSD में upstream करना मुश्किल होगा। आखिरकार उन्हें अपना downstream fork maintain करना पड़ेगा, और operating system की मजबूती की ज़िम्मेदारी लेने वाला कोई और भी नहीं होगा; इसलिए वे वही operating system इस्तेमाल करना बेहतर समझते हैं जिसे वे कई सालों से support और develop करते आए हैं
    • यह product में user को दिखने वाली detail नहीं है
      customer rack पर virtual machines चलाते हैं, applications को illumos के लिए build नहीं करते
      अपने लक्ष्य पूरे करने के लिए जिस भी operating system की ज़रूरत हो, वह उन virtual machines के अंदर चलाते हैं
    • ZFS illumos में native है, और containerization के बराबर की capabilities वगैरह भी काफ़ी अच्छी हैं
      अगर पर्याप्त लोगों को hire किया जा सके, तो यह तर्क भी वाजिब है कि cloud के servers पर अनिवार्य रूप से वही operating system होना ज़रूरी नहीं
    • शायद आपको यह पता भी नहीं चलेगा कि यह Linux नहीं है
      आप अपना code इस operating system के ऊपर नहीं चलाते, बल्कि इस operating system द्वारा उपलब्ध कराई गई virtual machines के ऊपर चलाते हैं

  • उत्सुकता है कि लोगों को पहली बार Oxide के बारे में कैसे पता चला
    मैं किसी तरह उनके podcast तक पहुँचा, और मेरे लिए यह ज़बरदस्त marketing जैसा लगता है। product को सीधे बेचने के अलावा वे सब कुछ करते हैं
    हर episode के अंत में छोटा-सा pitch जोड़ना भी अच्छा हो सकता है
    वे “compiler से कुछ करवाना सच में बहुत मुश्किल था” जैसी बातें करते-करते पुरानी यादों में चले जाते हैं
    फिर भी उम्मीद है कि वे बातें करते रहें, और उनकी सफलता की कामना है

    • मूल podcast On The Metal पहले से record किए गए self-promotion के 2–3 हिस्सों को हद से ज़्यादा दोहराने के लिए बदनाम था, यहाँ तक कि fans खुद ads record करके चलाने को कहने लगे थे
      इसके उलट Oxide and Friends पारंपरिक podcast से ज़्यादा, Twitter पर शुरू हुए और अब Discord पर चलने वाले live “space” या group call recording जैसा है
      मुझे लगता है कि इसे सिर्फ़ podcast की तरह सुनने के बजाय live participate करते समय सबसे बेहतर तरीके से consume किया जाता है। live सुनने पर recording का माहौल कहीं बेहतर समझ आता है
      https://oxide.computer/podcasts/oxide-and-friends
    • मैं पहले Twitter पर @jessfraz को follow करता था, इसलिए जब Oxide पहली बार announce हुआ तो वहीं से पता चला
    • Oxide पहली बार announce होने पर Pentagram द्वारा branding reveal किए जाने को देखकर पता चला

  • server rack announce होने के समय से ही मैं इसका इंतज़ार कर रहा था
    अगर Oxide बंद हो जाए, तो कोई भी paperweight बन चुके equipment को नहीं चाहेगा

    • स्पष्ट कर दूँ, वह “paperweight problem” हमारे लिए भी बहुत महत्वपूर्ण है
      यह याद रखना ज़रूरी है कि MPL इस बात पर निर्भर नहीं करता कि copy GitHub पर public रूप से उपलब्ध है या नहीं
      मैं lawyer नहीं हूँ, लेकिन non-customers code देख सकते हैं या नहीं, इससे अलग customers के प्रति MPL के तहत obligations हैं