Nix से Railpack पर स्विच करने की वजह

• Railway ने मौजूदा Nixpacks के बजाय नया build system Railpack लॉन्च किया है
• Railpack, version management की granular control, छोटे image size, और बेहतर caching जैसे मामलों में मौजूदा Nixpacks से बेहतर capabilities देता है
• Nixpacks की commit-based versioning पद्धति ने अलग-अलग user needs और scalability के संदर्भ में सीमाएँ दिखाईं
• Railpack, BuildKit integration, secret environment variables की सुरक्षा, और कई languages व frameworks के support के जरिए build environment की stability और flexibility को बेहतर बनाता है
• फिलहाल यह Node, Python, Go, PHP, static HTML को support करता है, और framework व language support लगातार बढ़ाया जा रहा है

---

अवलोकन और पृष्ठभूमि

• Railway ने Railpack नाम का अगली पीढ़ी का build system पेश किया है
• Railpack एक नया tool है, जिसे Railway platform पर Nixpacks के साथ 1.4 करोड़ से अधिक apps build करने के अनुभव के आधार पर विकसित किया गया है
• मौजूदा Nixpacks कुल users के 80% के लिए उपयुक्त था, लेकिन 2 लाख से अधिक users को सीमाओं की वजह से असुविधा हुई
• user base के विस्तार और टिकाऊ build environment के लिए एक बड़ा upgrade ज़रूरी माना गया

Railpack के प्रमुख सुधार

• version management की granular control: हर package के लिए major.minor.patch स्तर पर बारीक version specification का support, जिससे Nix की अस्पष्ट versioning पद्धति की सीमाएँ दूर होती हैं
• छोटा image size: Node में 38% और Python में 77% तक default build image size घटाकर, तेज़ deployment experience प्रदान किया गया
• बेहतर caching: BuildKit के साथ सीधे integration के जरिए layers और file system पर नियंत्रण, cache hit rate में सुधार और environments के बीच cache sharing संभव
• railway.com और केंद्रीय services पर Railpack builds पहले से लागू हैं

Nixpacks इस्तेमाल करते समय समस्याएँ

• Nix की package versioning पद्धति commit-based संरचना पर आधारित है, जिसमें केवल latest major version मिलता है, और हर version nixpkgs repository के किसी specific commit से जुड़ा होता है
• छोटे patch versions तक सब कुछ manually manage करना पड़ता है, और contributors के लिए भी version management intuitive नहीं है, जिससे accessibility घटती है
• Node या Python जैसी languages के मामले में भी अंततः केवल latest major version ही support होता है
• version update के समय commit hash बदलने से दूसरे package versions भी एक साथ प्रभावित हो सकते हैं, जिससे reliability पर भरोसा घटता है और अनपेक्षित build failures हो सकते हैं
• Nixpacks में /nix/store की एक ही layer में सभी dependencies शामिल होती हैं, इसलिए image को प्रभावी ढंग से विभाजित करना या उसका size कम करना कठिन है
• caching भी environment variable inject होने पर हर बार layer invalidate हो जाने के कारण ठीक से उपयोग नहीं हो पाती

समस्या Nix में नहीं, उसके उपयोग के तरीके की सीमा में थी

• यह Nix के अपने design की समस्या नहीं थी, बल्कि Railway के उपयोग और abstraction के तरीके से सीमाएँ पैदा हुईं
• Railway ने ऐसा design करने की कोशिश की थी कि users को Nix की derivation concept या internal version structure समझने की ज़रूरत न पड़े, लेकिन व्यावहारिक रूप से इसे असंभव माना गया
• इन्हीं समस्याओं को हल करने के लिए Railpack विकसित किया गया

Railpack की तकनीकी architecture

• Rust → Go codebase बदलाव: BuildKit के उपयोग और ecosystem compatibility को मजबूत करने के लिए Go language अपनाई गई
• BuildKit LLB और frontend: custom BuildKit LLB और frontend को सीधे generate करके build image की संरचना पर सटीक नियंत्रण किया गया → Node और Python की default images, Nixpacks की तुलना में काफ़ी हल्की हो गईं
• Mise से version management: package installation और version resolution के लिए Mise का उपयोग, जिससे आगे चलकर अन्य executable sources को support करना भी आसान होगा
• build सफल होने पर, उसी समय की dependency lock-in लागू होती है → Node का default version 22 से 24 होने पर भी मौजूदा build नहीं टूटेगी
• BuildKit के secret feature का उपयोग करके environment variables की security और management बेहतर की गई

Railpack के build चरण

• Analyze: code analysis के जरिए ज़रूरी packages, run commands, और startup command निकाले जाते हैं
• Plan: JSON-serializable रूप में build plan तैयार किया जाता है (जिसमें कई stages शामिल होती हैं, और हर stage पिछले stage के परिणाम या पूरी image पर निर्भर करती है)
• Generates: BuildKit का build graph generate किया जाता है (input/output के आधार पर)

BuildKit का उपयोग करने वाली रणनीतिक build प्रक्रिया

• जहाँ Dockerfile serial तरीके से काम करता है, वहीं BuildKit कई commands को parallel में process कर सकता है और हर stage के input/output पर बारीक नियंत्रण देता है
• Railpack, code analysis के आधार पर सभी build stages को define करता है और हर stage की dependencies को low-level पर विस्तार से specify करता है
• इस plan को BuildKit LLB graph में बदलकर resolve किया जाता है
• environment variables आदि बदलने पर, उस value के hash के रूप में file mount की जाती है; code और variables में बदलाव न हो तो cache hit सुनिश्चित रहता है
• नतीजतन image generation के तरीके पर Railpack का पूर्ण नियंत्रण संभव हो जाता है

Railpack अपनाने से संभव नए features

• Vite, Astro, CRA, Angular static site build/deploy को बिना configuration के support
• Railway UI के साथ build process का करीबी integration
• language के latest versions का support, Railpack की अलग release के बिना भी संभव
• project-स्तर पर environments के बीच caching optimization
• फिलहाल Node, Python, Go, PHP, static HTML को support करता है, और framework व language support लगातार बढ़ रहा है

open source और भविष्य की योजना

• Railpack फिलहाल Beta स्थिति में सार्वजनिक है, और activate करते ही तुरंत इस्तेमाल किया जा सकता है
• official documentation, actual code, और public support channels railpack.com पर उपलब्ध हैं
• आगे व्यापक रूप से इस्तेमाल होने वाली languages के लिए गहरा support प्राथमिकता होगी, और core API व abstraction level स्थापित होने के बाद दायरा बढ़ाने की योजना है

[GN⁺]

Hacker News की राय

• मैं Nix का प्रशंसक हूँ, लेकिन कृपया यह मानें कि Nix का उपयोग न करने के फैसले से मैं भावनात्मक रूप से चिपका हुआ नहीं हूँ। फिर भी, इस लेख में की गई कुछ शिकायतें मुझे ठीक से समझ नहीं आतीं और लगता है कि उन पर और स्पष्टीकरण चाहिए। उदाहरण के लिए, यह बात कि “Nix की सबसे बड़ी समस्या commit-आधारित package version management है।” Nixpkgs एक शानदार resource है, लेकिन Nix और Nixpkgs एक ही चीज़ नहीं हैं। अगर किसी toolchain का मनचाहा version लाना हो, तो Nixpkgs उसके लिए बहुत उपयुक्त नहीं है, लेकिन Nix में दूसरे तरीके भी हैं। जैसे Rust के मनचाहे versions लाने के लिए Nix tools काफ़ी अच्छे हैं। इसी तरह, यह कहना कि “Nix dependencies को अलग layer में विभाजित नहीं किया जा सकता”, मुझे बिल्कुल समझ में नहीं आता। आप इसे अपनी इच्छानुसार किसी भी तरीके से विभाजित कर सकते हैं। Nixpkgs के Docker tools भी इसे support करते हैं। codebase को Rust से Go में ले जाना Nix से सीधे जुड़ा नहीं है, लेकिन दिलचस्प लगा। आम तौर पर लोग language change हल्के में तय नहीं करते; ज़्यादातर तब करते हैं जब शुरू से फिर से बनाने की योजना हो। मुझे शक है कि Railpacks और Nixpacks पर अलग-अलग लोगों ने काम किया होगा। मैंने यह भी देखा है कि Nix को ठीक से न जानने वाले लोगों को organization में अधूरी Nix solution संभालनी पड़े तो क्या होता है। वह अच्छा दृश्य नहीं होता, और ज़्यादातर लोग Nix सीखने की कोशिश भी नहीं करते। इसलिए मेरी पिछली नौकरी में ऐसी स्थिति से बचने के लिए Nix का लगभग उपयोग ही नहीं होता था

  • मुझे Nix का उपयोग करना पसंद है, लेकिन जब भी Nix की बुनियादी usability समस्याओं पर चर्चा होती है, तो हर बार यही जवाब मिलता है कि “इसके workaround हैं” — लेकिन उनके लिए खराब documentation, एक अजीब language, खराब error messages, और ऐसी अधूरी जानकारी के बीच दर्जनों या सैकड़ों lines का code जोड़ना पड़ता है, जो सिर्फ़ अनुभवी लोग जानते हैं। यह बहुत थका देने वाला है। Nix से जुड़ी ज़्यादातर समस्याएँ इसकी Turing-completeness से नहीं, बल्कि intuitive API जैसे बुनियादी built-in features की कमी से आती हैं। अगर हर project में Nix का इस्तेमाल धीरे-धीरे Nix की अपनी समस्याएँ सुलझाने में डूबने लगे, तो फिर अच्छी तरह documented mainstream tools होते हुए Nix इस्तेमाल करने का कारण नहीं बचता। व्यवहार में भी लोग अक्सर Docker ही चुनते हैं। यह बहुत निराशाजनक है कि Nix developer experience की वास्तविक समस्याओं को व्यावहारिक समयसीमा में हल करने के बजाय आदर्श शुद्धता पर अड़ा रहता है। निश्चित रूप से सब लोग स्वेच्छा से योगदान करते हैं, लेकिन यह देखना दुखद है कि इतनी technical मेहनत खराब UX के कारण व्यवहारिक रूप से उपयोग न किए जा सकने वाली स्थिति में रह जाती है

  • मैं Nix का उपयोग नहीं करता, लेकिन “Nix ≠ Nixpkgs” वाला दावा मुझे वास्तविकता से कटा हुआ लगता है। अगर विकल्प के लिए अतिरिक्त research और effort चाहिए, तो ज़्यादातर users के लिए Nixpkgs ही अंततः Nix बन जाता है। “इसे अलग layers में बाँटा जा सकता है” — यह भी जानना चाहूँगा कि क्या यह सच में intuitive, simple, और default behavior है

  • यहाँ महत्वपूर्ण बात यह है कि Railway के users ऐसे developers हैं जो अपने मनचाहे packages के versions निर्दिष्ट करना चाहते हैं। Nix और Nixpkgs की संरचना में किसी package का version pin करना, practically पूरे nixpkgs tree के commit को pin करने जैसा है। node/python/ruby packages के builds अक्सर tree के बाहर की चीज़ों पर निर्भर होते हैं, इसलिए version और commit mapping की ज़रूरत पड़ती है। यह abstraction पूरी तरह परिपूर्ण नहीं है, इसलिए user अगर सिर्फ़ “yarn add package” भी करना चाहे, तो उसे tree state मिलानी पड़ सकती है। Nixpkgs के बिना सिर्फ़ Nix का उपयोग सीमित use cases में ठीक हो सकता है, लेकिन Railway जैसी platform के लिए यह कठिन चुनाव है

  • मुझे version management को लेकर विवाद ठीक से समझ नहीं आता। मैं Nix अभी नया-नया इस्तेमाल कर रहा हूँ, लेकिन मेरे पास साफ़ तौर पर ऐसे packages हैं जिन्हें किसी specific commit से लिया गया है

  • मुझे लगता है कि बात सही ढंग से पकड़ी गई है। Nixpkgs और Nix अलग हैं, लेकिन असल में Nixpkgs ही इसकी असली ताकत है। NixOS इस्तेमाल करते हुए पहली बार मैंने Linux kernel का सबसे नया version release वाले दिन ही इस्तेमाल किया। Debian Stable भी ठीक है, लेकिन उसमें हमेशा कुछ साल पीछे लौट जाने जैसा लगता है। हालाँकि, Nix language पर आलोचना की बहुत गुंजाइश है। यह पुरानी language है, और जितना best effort हो सकता था उतना किया गया है, लेकिन मुझे नहीं लगता कि इसे बदलने की ज़रूरत है। Nix build system काफ़ी पारंपरिक है, इसलिए अनावश्यक rebuilds बहुत होते हैं। उदाहरण के लिए, NixOS install ISO में kernel को दिए जाने वाले command line options में सिर्फ़ एक चीज़ बदलें — जैसे console port speed — तब भी लगभग 3 मिनट लगने वाला अजीब build behavior होता है। यह मज़ेदार तो है, लेकिन मैं Nix छोड़ नहीं रहा। बस, अपने build system में मैं ऐसी चीज़ कभी स्वीकार नहीं करूँगा। Docker images बनाने के लिए Nix का उपयोग करना मुझे व्यक्तिगत रूप से सबसे बुरा लगता है। पहले मैं Go में बने binary में सिर्फ़ Postgres का pg_dump binary जोड़ना चाहता था, लेकिन infra team ने Nix सुझाया, और compressed Go binary 50MB की होने के बावजूद image 1.5GB का दैत्य बन गया। pg_dump तो सिर्फ़ 464KB है। अंत में Bazel, rules_debian, और distroless के संयोजन से कहीं ज़्यादा साफ़ समाधान मिला। ज़्यादातर Nix systems का 1.4GB होना जैसे default-सा लगता है। बड़े C++ projects के builds में भी Nix कोई असाधारण कमाल नहीं दिखाता। बल्कि अपने software builds के लिए कस्टम systems अक्सर ज़रूरतों के ज़्यादा अनुकूल होते हैं। मुझे Bazel पसंद है, और Go projects में मैं बस go build ही इस्तेमाल करना चाहता हूँ। 99% मामलों में मैं Nix के बजाय ऐसे tools चुनूँगा, हालाँकि updates या deployment के लिए flake लिखकर उसे home-manager में इस्तेमाल कर सकता हूँ

• version selection कुछ अजीब लगती है। nixpkgs का version system चलाने या build करने के समय निश्चित ही उचित है। लेकिन अगर कोई platform runtime/compiler उपलब्ध करा रही हो, तो devenv की तरह versions को सीधे उपलब्ध कराना ज़रूरी है। उदाहरण के लिए, nixpkgs-python “हर Python version, Nix के साथ हर घंटे updated” उपलब्ध कराता है। Railway हर build में deployment ID environment variable inject करता है — यह काम install के बाद की layer में भी किया जा सकता था। packages को कई layers में बाँटना भी संभव है, और layers की संख्या के automation का भी प्रबंध किया जा सकता है

• DevOps/SRE अनुभव वाले व्यक्ति के रूप में, मैंने देखा है कि जब कोई dependency management system बनाने की कोशिश करता है, तो वह आम तौर पर दो में से एक दिशा में जाता है (उदाहरण के लिए Python के संदर्भ में)। विकल्प 1: “monorepo + shared environment”, जिसके फायदे हैं आसान management, security patches में सुविधा, और केंद्रीकरण। नुकसान यह कि किसी न किसी को हमेशा special version चाहिए होता है, phased rollout कठिन होता है, और slim image builds मुश्किल हो जाते हैं। विकल्प 2: “हर कोई अपना conda/venv”, जिसके फायदे हैं व्यक्तिगत customization, अनावश्यक packages को हटाना, और gradual upgrades की सुविधा। नुकसान हैं environments की अत्यधिक संख्या, compatibility का परीक्षण न होना, और security management का दुःस्वप्न बन जाना। अंततः अनुभव बढ़ने पर “कोई समाधान नहीं, सिर्फ़ trade-offs हैं” वाली बात और सच्ची लगने लगती है

• “Nix अपने-आप में समस्या नहीं है। समस्या उसके उपयोग के तरीके में थी” — यह मुझे “काम के अनुसार सही tool चुनो” का अच्छा उदाहरण लगता है। Nix कुछ जगहों पर शानदार है, लेकिन कुछ जगहों पर सबसे खराब। समस्या यह है कि इसे सीखने में बहुत समय लगता है, और जब तक आप इतनी familiarity हासिल करते हैं कि सही निर्णय ले सकें, तब तक लगाया गया समय छोड़ना कठिन लगने लगता है। फिर लोग ज़बरदस्ती उसी मूल उद्देश्य के लिए Nix का उपयोग जारी रखते हैं

  • मुझे भी कुछ वैसा ही महसूस होता है। कुछ मायनों में Nix मुझे दूसरे OS की तुलना में अधिक intuitive programming paradigm लगता है। बस अभी हम इसके आदी नहीं हैं। Nix expressions की संरचना inputs (package repositories, key-value pairs आदि) और outputs (Linux system) की है। शायद कुछ वर्षों में यह अधिक परिचित लगे। उदाहरण के लिए, AI का shell.nix या configuration.nix को specification के अनुसार generate कर पाना भी इसी संरचना की वजह से है। मैं भी अक्सर repository-विशिष्ट env को पूरी तरह encapsulated रूप में बनाता हूँ, और flakes के साथ शायद और अधिक reproducible environment बनाया जा सकता है। (flake.nix, shell.nix जैसा है, लेकिन version pinning भी support करता है...)

• ऐसा लगता है जैसे जहाँ versioning है ही नहीं, वहाँ जबरन versioning लाई जा रही हो। “default version” की वजह से dependencies टूट रही हैं? यह कुछ वैसा है जैसे Docker का :latest tag इस्तेमाल करना और हर बदलाव पर server टूट जाना। इस blog की बात मुझे ठीक से समझ नहीं आती। “Nix dependencies को अलग layers में नहीं बाँटा जा सकता” — इससे भी मैं सहमत नहीं हूँ। आप /nix/store को जितना चाहें बाँट सकते हैं, और ऐसा लगता है कि इन्हें containers और Nix को साथ में कैसे इस्तेमाल करना है, इसका ठीक ज्ञान नहीं है। अगर क्षमता इतनी कम है, तो प्रस्तुत विकल्प भी अंततः वही समस्याएँ दोहराएँगे। यह classic NIH (अपना ही tool बनाने) syndrome का उदाहरण है

  • Nix जहाँ उपयुक्त न हो, वहाँ उसका उपयोग न करना स्वाभाविक है। लेकिन पहले से काम कर रही किसी system को, ऐसी समस्या के लिए जिसे दूसरे लोग पहले ही हल कर चुके हैं और जिसे थोड़ी खोजबीन से जाना जा सकता है, शुरू से अंत तक फिर से बनाना मूल रूप से अजीब लगता है। nix2container या flakes शायद इन सभी समस्याओं का समाधान कर सकते थे। version management की बात करें तो, 3 साल पहले लिखी गई flakes आज भी वैसे ही build होती हैं और उनका output भी नहीं बदलता। किसी तरह यह market expansion या funding appeal के लिए platform pivot जैसा लगता है। संदर्भ के लिए, मैंने nixpacks का GitHub देखा तो वह सिर्फ़ rustPlatform का उपयोग कर रहा है, और अगर समस्या Rust की है, तो rust-overlay लगभग वास्तविक उत्तर है

  • अगर आप सोचें कि VC funding आसान किससे मिलेगी, तो nix wrapper के बजाय “deployment platform” का शीर्षक ज़्यादा फायदेमंद होगा

• “Nix dependencies को अलग layer में विभाजित नहीं किया जा सकता” — इस दावे के विपरीत, nix2container ठीक वही विभाजन संभव बनाता है। उदाहरण के लिए, अगर image में bash चाहिए, तो आप bash वाली layer को अलग बना सकते हैं, और यह layer केवल bash बदलने पर ही rebuild/push करनी होगी। “dependencies की वजह से विशाल image एक ही /nix/store layer में बन जाती है” — यह nixpkgs.dockerTools.buildImage function पर लागू हो सकता है, लेकिन nix2container या nixpkgs.dockerTools.streamLayeredImage पर नहीं। यह tool वास्तव में script generate करता है और उसी के माध्यम से image push कराता है। nix2container सभी layers के paths को JSON में बनाता है, और Skopeo का उपयोग करके image को Docker, registry, podman आदि में push करता है। (संदर्भ के लिए, मैं nix2container का लेखक हूँ)

  • मैं सच में nix2container के लिए आपका धन्यवाद कहना चाहता हूँ। मैं इसे AWS (ECR) deployments में उपयोग करता हूँ, और builds के बीच switching time single-digit seconds तक घट गया है

  • हम भी Docker image size की समस्या के कारण nix2container test करने वाले थे। इतना अच्छा tool बनाने के लिए धन्यवाद

• मुझे लगता है कि यहाँ असली समस्या language package managers द्वारा प्रोत्साहित “custom version soup” पर अड़े रहने की मानसिकता है (और यह तरीका टिकाऊ नहीं है)। उसका विकल्प Mise packages के बीच version constraints को समझता ही नहीं, और प्रत्येक package को test भी नहीं करता। उससे उसी स्तर की reliability की उम्मीद नहीं की जा सकती

  • यह सच है कि custom version soup टिकाऊ नहीं है, लेकिन लोग इसे इस्तेमाल करते रहते हैं क्योंकि यह काम करता है। OS-level libraries को बहुत सावधानी से manage किया जाता है, इसलिए वे आसानी से नहीं टूटतीं, और ऊपर से mise या asdf जैसे tools के साथ custom version combinations रखे जाएँ तो भी आम तौर पर सब ठीक चलता है। अगर कुछ टूटे भी, तो versions या settings बदलकर जल्दी ठीक हो जाता है। टूटा हुआ सिस्टम झुंझलाहट भरा है, लेकिन बहुत महत्वपूर्ण नहीं। ऐसे systems जिनमें अतिरिक्त सीखने या effort की ज़रूरत हो, समय की बर्बादी माने जाते हैं। लेकिन जो लोग “न टूटने” की स्थिति को ज़्यादा महत्व देते हैं, वे learning curve और असुविधा के बावजूद Nix को पसंद करते हैं। Railway जैसी जगह, जो बहुत सारे users को target करती है, अंततः पहले समूह — यानी सरलता और inertia — को अधिक ध्यान में रखकर फैसला करती है

  • “custom version soup” से आपका मतलब क्या है, और उसका विकल्प क्या होगा, यह जानने की जिज्ञासा है

  • दोनों ही पर्याप्त रूप से संभव हैं। उदाहरण के लिए, Rust packages को Cargo.lock की जानकारी के आधार पर Nix के साथ आसानी से build किया जा सकता है। Nixpkgs कस्टम version combinations से टकरा सकता है, लेकिन Nix अपने-आप में यह काम अच्छी तरह कर सकता है

• Nix मनमाने versions की गारंटी नहीं देता, बल्कि commit-स्तर की गारंटी देता है। glibc changes या shared library conflicts जैसे edge cases में मुश्किल आ सकती है। शायद अब देर हो चुकी हो, लेकिन Nix को और अधिक सुरुचिपूर्ण ढंग से इस्तेमाल करने के तरीक़े पर consulting भी दी जा सकती है। product अपने-आप में काफ़ी अच्छा लगता है

  • nix shared library conflicts को बहुत मज़बूती से रोकता है। लेकिन छोटे बदलावों — जैसे comments, documentation आदि — पर भी उससे जुड़े सभी downstream dependencies तक सब कुछ rebuild हो जाता है। नतीजा यह होता है कि बहुत बड़े पैमाने पर rebuilds की ज़रूरत पड़ती है, और development कष्टदायक हो सकता है। nixpkgs की staging process देखकर यह समझा जा सकता है

  • मैं Nix की value को पूरी तरह समझता हूँ। बस “सब बर्बाद हो जाएगा” कहना मुझे थोड़ा बढ़ा-चढ़ाकर कहा हुआ लगता है। Nix की तुलना में कुछ बड़ी guarantees ज़रूर खो जाती हैं, लेकिन फिर भी मुझे लगता है कि यह अधिकांश software की तुलना में बहुत बेहतर तरीके से काम करेगा

• समझ नहीं आता कि अपनी खुद की derivations बनाए बिना इन्होंने आखिर nixpkgs hash पर निर्भरता क्यों रखी

• यह देखना दिलचस्प है कि बहुत-सी टिप्पणियों का लहजा ऐसा है: “असल में Nix से सब हल हो सकता है, बस तुम्हें मेरी तरह expert होना चाहिए”

  • अगर कोई company अपनी सारी technology और business JavaScript में चला रही हो, और फिर functions, arrays जैसी मौजूदा मूलभूत अवधारणाओं को समझ न पाने के कारण NIH (अपनी specification वाली नई language बनाना) कर दे, तो वह ज़्यादा उनके भीतर की कमी की समस्या लगेगी

  • Nix की बात आते ही हमेशा यही जाना-पहचाना माहौल बन जाता है

  • यही तो Nix के साथ जुड़ा माहौल है। एक तरह की आदर्शवादी “मैं दुनिया बचाऊँगा” कथा, और जब कोई कहता है “जो feature मुझे चाहिए वह नहीं हो रहा”, तो जवाब हमेशा यही मिलता है: “तुमने इसे सही तरह से इस्तेमाल नहीं किया”