Meta में custom XR OS बनाने के खिलाफ John Carmack का तर्क

• John Carmack ने Meta के custom XR OS development के खिलाफ अपना रुख व्यक्त किया
• उन्होंने ज़ोर दिया कि अपना operating system विकसित करने से complexity और risk बढ़ते हैं
• उनका तर्क है कि मौजूदा platforms का उपयोग development efficiency और resources के बेहतर उपयोग के लिए अधिक प्रभावी है
• Carmack ने बाज़ार में तेज़ innovation और त्वरित प्रतिक्रिया के लिए standard OS-आधारित strategy की सिफारिश की
• उन्होंने अनावश्यक technical division और fragmentation से बचने की ज़रूरत पर ज़ोर दिया

---

John Carmack के Meta custom XR OS के विरोध के तर्क

पृष्ठभूमि

• यह जाना जाता है कि John Carmack, Meta द्वारा अपना custom XR (extended reality) OS विकसित करने के विचार पर नकारात्मक दृष्टिकोण रखते हैं
• XR OS से आशय उस operating system से है जो AR/VR जैसे extended reality devices पर चलता है

मुख्य तर्कों का सार

• Carmack ने कहा कि यदि development पहले से बाज़ार में मौजूद platforms (Android, Windows आदि) पर किया जाए, तो development speed और innovation और तेज़ हो सकते हैं
• custom OS development के साथ complexity में वृद्धि, bugs का जोखिम, और long-term maintenance burden जैसी कई समस्याएँ आती हैं
• यदि resources को अपने platform बनाने में लगाया जाता है, तो मौजूदा ecosystem के standardized tools और technologies का लाभ खो जाता है
• नई technologies और user demands में बदलाव के प्रति ज़्यादा तेज़ी से प्रतिक्रिया देने के लिए मौजूदा OS का सक्रिय उपयोग करने वाली strategy प्रभावी है
• custom OS, developers और consumers दोनों के लिए compatibility issues और learning cost पैदा कर सकता है

निष्कर्ष

• Carmack, लंबे समय में technology और services के fragmentation को रोकने और scalability तथा usability को अधिकतम करने के लिए custom XR OS development की बजाय मौजूदा platforms के उपयोग की strategy को प्राथमिकता देते हैं

[GN⁺]

Hacker News राय

• Meta में काम करने की समस्या यह है कि अगर मैं अच्छा काम करूँ, तो मैं दुनिया को और खराब बनाने में मदद कर रहा होता हूँ… सच कहूँ तो असली हीरो वे लोग हैं जो पैसे और efficiency बर्बाद करते हैं<br>अगर आप सक्षम हैं, तो कहीं और करियर बनाने की सलाह दूँगा
  • software engineer के तौर पर मानवता की सेवा करने के सबसे अच्छे तरीकों में से एक यह है कि Meta या TikTok जैसी कंपनियों में जॉइन करके जितना हो सके उतना लंबे समय तक काम न कर पाने का नाटक किया जाए
  • मैं Facebook और उससे जुड़ी services को block करूँगा और zstd का इस्तेमाल करूँगा<br>दुनिया काला-सफेद तर्क पर नहीं चलती
  • यह नज़रिया बहुत ज़्यादा सरल है<br>Meta के core business के बारे में आपकी जो भी राय हो, कंपनी social media से बहुत कम जुड़ी R&D, जैसे कई open source projects, VR, और data center technologies पर भी बहुत सारे engineers को काम पर रखती है<br>जिस चीज़ में आपकी दिलचस्पी हो, उस research के लिए salary मिलना उससे भी बुरा रास्ता हो सकता है
  • यह थोड़ा निराशावादी विचार है, लेकिन अब तक के data को देखें तो इसका खंडन करना आसान नहीं है
  • लेकिन सच में यह बात हर बड़ी कंपनी, यहाँ तक कि हर listed company पर लागू नहीं होती क्या?<br>शुरुआत में founder के कुछ और लक्ष्य रहे हों, लेकिन समय बीतने के साथ अंत में सिर्फ profit ही लक्ष्य बन जाता है, और आमतौर पर profit बुरे कामों पर ध्यान देने से कहीं ज़्यादा आता है<br>यह एक systemic समस्या है
• मैंने तरह-तरह के low-level software, BSP, और लगभग पूरा operating system तक बनाया है, और आजकल OS सीधे न बनाने की असली वजह silicon vendors हैं<br>पहले वे detailed specs देते थे ताकि आप खुद driver लिख सकें, लेकिन अब वे सिर्फ अस्पष्ट explanations और घटिया Linux drivers फेंक देते हैं<br>इसमें आलस भी है, लेकिन complexity बढ़ना भी वजह है<br>आधुनिक hardware इतना जटिल है कि उसे पूरी तरह document करने में ही बहुत समय लग जाता है, और अगर आप खुद driver लिखें तो उससे भी ज़्यादा समय लगता है
  • Intel अभी भी ठीक-ठाक documentation देता है<br>high-speed NICs के लिए बहुत detailed docs सार्वजनिक हैं, और e810 100Gb ethernet card जैसे मामले में तो सिर्फ आधिकारिक 2750-पेज datasheet के आधार पर शुरू से driver लिखा जा सकता है<br>बाकी vendors या तो (1) नज़रअंदाज़ करते हैं, या (2) NDA माँगते हैं, या (3) सिर्फ बेकार Linux/FreeBSD driver docs दिखाते हैं<br>NVMe SSD जैसे दूसरे hardware में स्थिति कैसी है, यह मुझे ठीक से नहीं पता
  • मैंने भी हाल ही में अपने hobby OS में "soft reboot" button support जोड़ने की कोशिश की, लेकिन इतनी मुश्किल हुई कि छोड़ना पड़ा (GCP में reboot speed तेज़ करने के लिए)<br>OS Dev Wiki की guidelines, Linux और FreeBSD source तक सब पढ़ लिया, लेकिन कोई प्रगति नहीं हुई<br>यह वही feature है जो Windows हो या Linux, restart के समय इस्तेमाल होता है<br>कई दिन बर्बाद करने के बाद आखिरकार छोड़ दिया<br>OS developers सच में अलग तरह के लोग होते हैं, और लगता है कि उन पर आमतौर पर आर्थिक दबाव नहीं होता
  • लोग अक्सर कहते हैं, “आधुनिक hardware इतना जटिल है कि documentation मुश्किल है”, लेकिन मुझे यह बहाना लगता है<br>टीम में नए लोगों को training भी देनी होती है, testing भी manage करनी होती है, इसलिए अगर चीज़ जटिल है तो उसे और ज़्यादा detail में document करना चाहिए<br>इसलिए silicon vendors की यह सफाई मुझे जँचती नहीं
  • अगर आजकल आप सच में अपना OS बनाना चाहते हैं, तो या तो hardware पर बहुत मज़बूत control होना चाहिए, या फिर OS में एक servant Linux instance शामिल करना होगा<br>Windows में drivers होते हैं, भले ही वे bug जैसे लगें, और Linux में मुफ्त के buggy drivers हैं<br>अगर आपका OS Linux hypervisor के ऊपर client की तरह लगातार चल सकता है, तो वह रास्ता भी ठीक है, नहीं तो hardware support features को धीरे-धीरे अपने OS में लाना ही विकल्प है. बस इसकी रफ़्तार Linux की नई dependencies बनने से तेज़ होनी चाहिए…
  • कुछ खास तरह के OS के लिए मुझे लगता है कि Linux hardware support का बड़ा हिस्सा port किए गए LKL(https://github.com/lkl/linux) से आसानी से लिया जा सकता है, और बस hardware access के hooks जोड़ने होंगे<br>बेशक core platform/chipset code अलग से लिखना पड़ेगा, लेकिन बाकी I/O devices लगभग cover हो जाएँगे<br>सामान्य monolithic kernel की तुलना में, user-mode drivers support करने वाली शैली में यह और बेहतर काम करेगा
• John की बात बिल्कुल उसी system का वर्णन करती है जिसे मैं सच में चाहता हूँ कि कोई बनाए<br>“अगर आप कुछ पूरी तरह अलग तरह का computer बनाना चाहते हैं, तो मौजूदा solutions के gravity well से बाहर निकलने के लिए लगभग संन्यासी-मठ जैसे engineers के समूह की ज़रूरत होती है”<br>एक thought experiment के तौर पर:<br>- ऐसी जगह चुनो जहाँ मासिक जीवन-यापन खर्च 200 डॉलर हो<br>- रहने लायक अच्छा कस्बा बनाओ (साफ़ हवा, स्वस्थ खाना, अच्छे स्कूल वगैरह) — इतना सस्ता कि कोई अमीर प्रायोजक भी आसानी से चला सके<br>- ऐसे बहुत सारे computers दो जिनमें software और internet लगभग न के बराबर हो<br>- शुरुआत से बिल्कुल नई computing बनाकर देखो<br>धैर्य सबसे अहम है. इसमें दशकों लगेंगे
  • यह idea सच में दिलचस्प है<br>मैं सोच रहा हूँ कि इतनी कम living cost वाली जगहें कहाँ हो सकती हैं
  • लेकिन सच में मेरा सवाल यह है कि अभी ऐसी समस्या हल करने की कोशिश क्यों की जाए जिसे अभी लागू ही नहीं किया जा सकता? क्या CPU जैसे hardware से शुरुआत करनी होगी?<br>मुझे Intel के एक पूर्व engineer की बात याद है — आधुनिक ISA, CPU uArch, GPU जैसी चीज़ों को पूरी तरह सीखकर फिर उन्हें नए सिरे से बनाना, और वह भी खुद अनुभव और trial-and-error से, शायद retirement के आसपास ही संभव हो
  • मैं 10 साल से ज़्यादा समय से अपना OS बना रहा हूँ, और अगर आप सच में कुछ करना चाहते हैं तो यह काम वैसा नहीं है<br>हाँ, मज़ेदार ज़रूर है, और कभी-कभी मैं सोचता हूँ कि अगर कभी बहुत बड़ी developers की फ़ौज मिल जाए तो यह कितनी दूर जा सकता है. (हालाँकि इससे पैसा नहीं बनेगा)
  • ईमानदारी से कहूँ तो यह एक बहुत बढ़िया sci-fi concept लगता है
• Meta में operating system से जुड़े बहुत से लोग Microsoft से आए थे, और उन्हें मूल रूप से OS बनाने में दिलचस्पी थी<br>लेकिन Meta में उन्हें XR काम में लगा दिया गया, और स्वाभाविक रूप से वे custom OS बनाना चाहते थे
• Meta में John Carmack ने जो किया, उसके बाद अब उन्हें गंभीरता से लेना मुश्किल लगता है<br>सिर्फ SerenityOS को देख लें, तो Windows या Linux से ज़्यादा उपयोगी और consistent system बनाना पूरी तरह संभव साबित हुआ है<br>स्पष्ट vision, execution power, और commitment, “top engineers” को hire करने या “high-quality code” से भी ज़्यादा महत्वपूर्ण हैं — अगर ये हों, तो अच्छा code और अच्छे लोग अपने-आप आ जाते हैं<br>यही वजह है कि Meta में यह असंभव है, और Linux की हालत भी ऐसी ही है<br>असल बाधा आखिरकार driver ही है. संदर्भ: Thirty-Million line समस्या — caseymuratori.com ब्लॉग
• Oculus merger के बाद वहाँ काम करते हुए, XROS core technology teams के लिए सच में बहुत झंझट और distraction था<br>पहले से ही कई tech stacks में हल करने के लिए समस्याओं का पहाड़ था, और XROS का idea तब आया जब Oculus पूरी तरह FB में integrate हो चुका था<br>मेरी नज़र में FB की कुछ teams (या कुछ लोग) सिर्फ ARVR trend में शामिल होना चाहते थे<br>Carmack पूरी तरह सही थे, और reorg के बाद उनका प्रभाव लगातार कम होता गया, जिसका बुरा असर मैंने खुद महसूस किया
  • XROS team का ज़्यादातर हिस्सा FB headquarters से नहीं आया था, बल्कि industry से lateral hiring के ज़रिए लाया गया था (ज़्यादातर E5/E6 level)<br>FB SWE की technical क्षमता मेल नहीं खाती थी, कुछ bootcamp background वाले लोग भी थे, लेकिन वे सफल नहीं हुए और जल्दी दूसरी जगह चले गए
  • Oculus open source community को बर्बाद करने, और community द्वारा fund किए गए project को Meta की एक और chain में बदलकर privacy डेटा ले जाने पर मुझे गुस्सा है<br>फिर भी उम्मीद है paycheck अच्छा रहा होगा
• मैंने 2002~2004 के आसपास Microsoft में एक internal paper पढ़ा था, जिसे कुछ OS developers ने Bill Gates की Think Week के लिए hackathon की तरह लिखा था<br>वह .NET के ऊपर बना एक पूरी तरह नया operating system था, जिसमें GC और memory management भी खुद implement किए गए थे, कई तरह के hardware पर boot हो जाता था, और उसमें काफ़ी दिलचस्प features भी थे<br>डिज़ाइन साफ़ तौर पर Windows से zero compatibility वाला था, और शायद वही उसकी विफलता की वजह रही होगी<br>कुछ OS experts ने लगभग एक महीने के केंद्रित काम से यह बनाया था, और यह सच में दिलचस्प था
  • क्या वह Singularity था?<br>Wikipedia पर विवरण<br>Microsoft Research का आधिकारिक पेज
  • शायद वह Midori project था<br>असल में वह Microsoft Research का बड़ा project था, जिसमें कई साल तक 100 से ज़्यादा लोग लगे थे<br>ZDNet का Midori project लेख
• ऐसी बात सामने आई कि John Carmack को XROS team manager ने HR में रिपोर्ट किया था कि वे “team members की भावनाएँ आहत करते हैं”<br>असल में मुझे Carmack की public communication हमेशा professional और विनम्र लगी है<br>मुझे भी HR के weaponization जैसा अनुभव हुआ है, और ऐसी चीज़ें कंपनी के माहौल को ठंडा कर देती हैं — एक बार अगर लगे कि कोई आपके शब्दों से नाराज़ होकर HR में शिकायत कर सकता है, तो उसके बाद सब लोग बोलने में बहुत सावधान हो जाते हैं
  • मैंने Carmack के resign करने से पहले उनकी internal posts फॉलो की थीं, और वे resource waste पर बहुत सख़्त थे; अगर hand tracking feature बार-बार खराब होता, तो वे numbers के आधार पर उसकी आलोचना करते थे<br>उनका संदेश हमेशा यही था कि “Apple ने hardware पर पकड़ बना ली है, इसलिए अब efficient software ही भविष्य की कुंजी है”, और Meta की फिजूलखर्ची आखिरकार संगठन के भीतर की power struggle की वजह से थी
  • Lucovsky इस बात पर अड़े रहे कि OS सीधे scratch से बनाया जाए, और वे इस वास्तविकता को नहीं देख पाए कि product teams को ग्राहकों तक कोई असली चीज़ पहुँचानी होती है, इसलिए उन्हें किनारे कर दिया गया<br>उनके पीछे छोड़ी गई toxicity (जिसकी गंभीरता शायद उन्हें खुद समझ नहीं थी) का भी असर रहा<br>ऐसा ही व्यवहार Google में भी दोहराया गया, जहाँ अंत में उन्हें वहाँ से भी हटा दिया गया, और आधिकारिक तौर पर इसे उनका स्वैच्छिक इस्तीफ़ा बताया गया<br>Twitter संदर्भ 1 Twitter संदर्भ 2
  • John आमने-सामने मिलने पर काफ़ी सीधा और तीखा हो सकता है<br>जिन चीज़ों पर उसका विश्वास नहीं होता, उन पर वह ज़रूरत से ज़्यादा आलोचनात्मक हो सकता है, और ऐसे में power balance की वजह से उसका जवाब देना भी मुश्किल हो जाता है
  • Meta में उस समय internal माहौल थोड़ा अजीब था<br>PSC (performance review) बहुत महत्वपूर्ण था, इसलिए अगर Carmack जैसे दिग्गज आपके project को “resource waste” कह दें, तो उसका असर आपकी review पर सीधे पड़ता था<br>“impact” Facebook में यह मापने का एक अहम पैमाना था कि आपका काम कंपनी के लिए कितना उपयोगी है
  • Google में भी मैंने ऐसा ही दृश्य देखा है<br>एक Distinguished engineer ने एक junior engineer से पहले नरमी से, फिर साफ़ तौर पर कहा कि “यह अच्छा idea नहीं है, इसे छोड़ दो”, और उसके बाद HR शामिल हो गया<br>ऐसे माहौल में कई बार मैंने भी सिर्फ इसलिए मुद्दा छोड़ दिया क्योंकि मैं उस पर और समय या मेहनत खर्च नहीं करना चाहता था
• मैं Google में उस समय था जब Flutter team Fuchsia बना रही थी<br>वहाँ सच में असाधारण प्रतिभा थी (मेरे देखे सबसे बेहतरीन engineers), और लोगों की संख्या भी सैकड़ों में थी<br>तकनीकी रूप से वह बहुत प्रभावशाली था, लेकिन शुरू से ही कोई यह साफ़ नहीं बता पा रहा था कि इसे आखिर इस्तेमाल कौन करेगा<br>अगर लक्ष्य सिर्फ kernel नया बनाकर मौजूदा Linux को replace करना होता, तो ठीक था, लेकिन इसके उलट वे kernel, UI, window manager तक operating system की हर layer को शुरू से बनाना चाहते थे<br>आखिर में उन्होंने सिर्फ Home Hub जैसे UI-only special devices को target किया, और वहाँ भी यह नहीं समझा पाए कि मौजूदा products की तुलना में OS को इतना जटिल तरीके से बदलने की ज़रूरत क्यों है<br>आज तक Fuchsia चलता जा रहा है, यह बात मुझे हैरान करने लायक हद तक समझ नहीं आती<br>Google restructuring के दौरान जहाँ essential teams के resources काटे गए, वहीं ऐसे project पर लोग बने रहे — यह बात और भी उदास करती है<br>सच कहूँ तो यह project अब तक क्यों बचा हुआ है, मैं समझ नहीं पाता
  • अगर short-term नतीजों से देखें, तो इसका बचाव करना मुश्किल है, लेकिन long-term नज़रिए से नया OS बनाना उचित हो सकता है<br>Google वास्तव में long-term investments में रुचि रखता है, और project को बाहरी दुनिया के सामने कोई justification देने की ज़रूरत भी नहीं होती<br>इसे लेकर आलोचना करना ही शायद अजीब है. ज़रूरत हो तो शामिल हों, नहीं तो बस नज़रअंदाज़ कर दें<br>नई application ecosystem बनाना तो मूल लक्ष्य था ही नहीं; सबसे कठिन बात यह है कि रोज़मर्रा में जिन countless technologies को हम obvious मानते हैं, उन सबको फिर से implement करना पड़ता है. कठिन है, पर असंभव नहीं
  • विकल्प बढ़ना बुरा नहीं है — अगर browser market में diversity महत्वपूर्ण मानी जाती है, तो OS market में monopoly को ठीक मानना विरोधाभासी तर्क है; ज़्यादा विविध OS होना अच्छी बात है
  • शायद कुछ devices (Home Hub) को शुरुआती बिंदु बनाकर वहाँ से experience और revenue जमा करते हुए धीरे-धीरे विस्तार करने की योजना थी<br>मुझे नहीं लगता कि वे शुरुआत से ही सब कुछ एक साथ replace करने निकले थे
  • मेरी समझ में Fuchsia असल में एक नया paradigm था, जहाँ कई OS और app packages पूरी तरह containers में चलते हैं<br>मेरी कल्पना में यह भविष्य का OS था जो web पर भी चल सकता है, और कई machines पर साथ में भी चल सकता है<br>मैं यह भी सोचता था कि एक ही machine पर कई instances चलाकर उन्हें अलग-अलग users के हिसाब से ढाला जा सकता है
  • मुझे Fuchsia कुछ हद तक Google का ऐसा war-of-attrition project लगता था, जिसका मकसद बेहतरीन kernel engineers को competitors के पास जाने से रोकना हो
  • Home Hub पर Fuchsia को ज़बरदस्ती push किया गया, जिससे पुराना stack तुरंत legacy बन गया, और उसके बाद लगातार delays होते रहे, फिर भी कोई नतीजा नहीं निकला<br>अपना OS बनाना सुनने में cool लगता था, लेकिन पूरे project का बाकी teams के काम पर बस बुरा असर पड़ा
• आजकल Linux kernel को bypass करके सीधे hardware access करना आसान हो गया है, और ज़्यादा cores वाले CPU भी आम हो गए हैं<br>मुख्य बात यह है कि cores को isolate करके threads assign किए जाएँ, फिर kernel bypass techniques से hardware को सीधे control किया जाए. cores के बीच communication ring buffer से हो, तो hardware-optimized performance के करीब पहुँचते हुए management/monitoring/debugging में Linux kernel के फायदे भी साथ मिल जाते हैं
  • /dev/mem को mmap करके physical memory तक सीधे पहुँचने की तरह, kernel bypass तो हमेशा संभव है