Rye और uv: अगस्त Python पैकेजिंग की फसल का मौसम

 (lucumr.pocoo.org)
2 पॉइंट द्वारा GN⁺ 2024-08-23 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • फरवरी 2024 में Rye का प्रबंधन Astral को जाने के बाद, इसके आधार resolver और installer uv में तेजी से सुधार हुआ और यह Python पैकेजिंग tools को एकीकृत करने के उम्मीदवार के रूप में उभरा
  • नवीनतम uv में pyproject.toml में बदलाव, workspace support, local package references, script installation, और Python installation management तक शामिल हैं, और यह Rye के संभाले हुए क्षेत्रों को अपने में समाहित कर रहा है
  • AI और ML निवेश से Python के नए users बढ़े हैं, लेकिन packaging tool के विकल्प बहुत हैं और compatibility अलग-अलग है, इसलिए developer experience अब भी consistent नहीं है
  • packaging ecosystem में ऐसा dominant tool होना चाहिए जिसे सभी इस्तेमाल करें, ताकि निवेश और documentation एक stack पर केंद्रित हों; Rye के uv-केंद्रित बदलाव के लिए migration path बनने की संभावना बड़ी है
  • Astral का VC investment ऐसा risk है जिस पर PSF और Python core project को विचार करना चाहिए, लेकिन uv को ऐसा code माना जा रहा है जिसे सबसे खराब स्थिति में भी fork और maintain किया जा सकता है

Rye से uv में features के जुटने की दिशा

  • फरवरी 2024 में Rye का प्रबंधन Astral को चला गया, और उसके बाद कुछ महीनों में Astral ने Python packaging tools को तेजी से बेहतर किया
  • Rye users महसूस कर सके कि इसका आधार resolver और installer uv और बेहतर व तेज हो गया है
  • नवीनतम uv अब सीधे वे features देने लगा है जिनके लिए पहले Rye की जरूरत पड़ती थी
    • pyproject.toml file में बदलाव
    • workspace support
    • local package references
    • script installation
    • Python installation management
  • जो users अभी Rye इस्तेमाल कर रहे हैं, उन्हें uv को देखना चाहिए और Astral को feedback देना चाहिए

Python packaging tools को एक जगह आने की जरूरत क्यों है

  • EuroPython Prague presentation Python packaging की मौजूदा स्थिति और Rye बनाते समय मिली सीखों पर केंद्रित थी
  • packaging tool का लक्ष्य अपने क्षेत्र का dominant tool बनना होता है
    • जो tool सभी इस्तेमाल करते हैं, वही सबसे अच्छा tool होना चाहिए
    • क्योंकि Python से पहली बार जुड़ने वाला व्यक्ति अपनी programming journey शुरू करते समय इसी tool से मिलता है
  • पिछले 2 वर्षों में AI और ML में निवेश व रुचि के कारण Python नए developers के लिए बहुत गर्म और लोकप्रिय platform बन गया है
  • यह महत्वपूर्ण है कि नए users Python को पुरानी और खराब tools वाली language के रूप में नहीं, बल्कि बेहतरीन developer experience वाली language के रूप में याद रखें
  • लेकिन मौजूदा Python packaging में विकल्प बहुत ज्यादा हैं, tools के बीच compatibility पूरी नहीं है, और जगह-जगह की inconsistency experience को कमजोर करती है
    • कुछ users एक tool के पीछे चलते-चलते दीवार से टकराते हैं, पूरा stack conda पर ले जाते हैं, और फिर वापस आने जैसी स्थिति का सामना करते हैं

uv के dominant tool बनने की संभावना

  • किसी tool का dominant position पाना मतलब है कि अधिकतर investment एक ही stack में केंद्रित हो जाता है
  • Rye और उसके आसपास के कई tools के लिए वांछनीय दिशा यह है कि dominant tool स्थापित होने पर उन्हें स्वतंत्र रूप से बने रहने की जरूरत न रहे
  • इस समय uv को उस भूमिका के लिए सबसे संभावित tool माना जा रहा है
    • अभी यह सभी use cases को पूरा नहीं करता
    • हालांकि लगता है कि यह जल्दी ही उस बिंदु तक पहुंच जाएगा
  • यह वह समय है जब community को uv के इर्द-गिर्द जुटना शुरू करना चाहिए
  • इसका मतलब यह नहीं है कि यह tool हमेशा के लिए अकेला tool बन जाएगा
    • tools आते और जाते रह सकते हैं
    • भविष्य में कोई दूसरा tool भी आ सकता है

Rye की retirement और Python project guidance में बदलाव

  • Rye की अपेक्षित final release में Rye-specific features को retire करके users को uv पर migrate किया जाएगा, और यह ज्यादातर uv के alias की तरह काम करने वाला रूप होगा
  • सिर्फ Rye को retire कर देना पर्याप्त नहीं है
    • अभी Python में कई package management solutions इस्तेमाल हो रहे हैं
    • community को कम tools की guidance देनी चाहिए
  • Rye और uv अपने नीचे के ecosystem के लंबे विकास पर बने हैं
    • setup.py से eggs, और फिर wheels की ओर जाने का flow
    • metadata standards की अनुपस्थिति से standards वाले चरण तक जाने का flow
    • coupled build system से separated build system की ओर जाने का flow
    • redistributable और downloadable Python binaries संभव बनाने वाला काम
    • संबंधित Rust crates और Python library ecosystem
  • community को किसी दिन यह कहने के लिए तैयार रहना होगा कि कुछ tools की अब recommendation नहीं की जाती
    • पहले नए developers की guidance docs में ez_setup.py और easy_install की recommendation की जाती थी
    • बाद में guidance docs से ez_setup.py हटाकर उसकी जगह pip लाया गया
    • कुछ projects ने pip-tools, poetry, PDM की guidance दी
    • अभी कई projects अलग-अलग tools के कारण एक साथ 5 तरह की installation guides दिखाते हैं
  • महत्वपूर्ण Python projects के maintainers को uv खुद इस्तेमाल करके देखना चाहिए और यह आंकना चाहिए कि क्या वे users को uv की guidance दे सकते हैं
  • Astral के Charlie का uv अभी क्या-क्या कर सकता है पर लिखा लेख uv की मौजूदा उपलब्धियां दिखाता है

Astral का VC investment और community risk

  • uv बनाने वाली Astral एक ऐसी company है जिसने VC investment लिया है, यह बात टाली नहीं जा सकती
  • community के नजरिए से, किसी के बहुत पैसा लगाने से नई चुनौतियां पैदा हो सकती हैं
  • PSF और Python core project को इस बात पर विचार करना चाहिए
  • uv के code और behavior को देखते हुए, यह सबसे खराब भविष्य में भी fork किया जा सकने वाला और maintain किया जा सकने वाला target लगता है
  • भले ही Astral बंद हो जाए या licensing के मामले में बहुत संदिग्ध काम करे, community uv के अस्तित्व में आने से पहले की तुलना में बेहतर स्थिति में हो सकती है

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

1 टिप्पणियां

 
GN⁺ 2024-08-23
Hacker News की रायें

  • uv की ताज़ा रिलीज़ पर कल भी चर्चा हुई थी: https://news.ycombinator.com/item?id=41302475
    लिंक किया गया लेख Rye के लेखक ने उस रिलीज़ को देखकर लिखा अपना नजरिया है

  • uv में रुचि रखने वालों के लिए: pip की जगह uv इस्तेमाल करने से Home Assistant की रिलीज़ प्रक्रिया काफी तेज़ हो गई
    रिलीज़ में लगने वाला समय लगभग 2.5 घंटे से घटकर लगभग 20 मिनट हो गया, और विवरण https://developers.home-assistant.io/blog/2024/04/03/build-i... पर हैं। संदर्भ के लिए, मैं बस एक HA यूज़र हूँ

    • समझ नहीं आता कि कोई compiler language भी नहीं है, फिर भी pip को image बनाने में 1 घंटे से ज़्यादा कैसे लग गया
      मैं Python को हल्के-फुल्के तौर पर इस्तेमाल करता हूँ, लेकिन आखिर वह ऐसा क्या कर रहा था कि इतना समय लगा—यह समझ नहीं आता और काफी बेतुका लगता है

  • मुझे पता है कि Python packaging में समस्याएँ हैं, लेकिन निजी तौर पर मैं अब तक सिर्फ plain pip से भी काफी आगे तक काम चला पाया हूँ
    सबसे बड़ा बदलाव मूल virtualenv से built-in venv module पर आना था। अगर dependency management को सच में गंभीरता से करना हो, तो शायद FAANG-स्टाइल monorepo बनाकर package manager से जुड़ी झंझटों से बचूँगा

    • मैं सच में सलाह दूँगा कि monorepo खुद आज़माकर देखें
      मैं production environment में Python monorepo मैनेज कर रहा हूँ और dependency management नरक जैसा है। Poetry की कुछ नई सुविधाएँ लागू करने की कोशिश कर रहा हूँ, लेकिन बड़े monorepo के आसपास ecosystem की हालत भयानक है
    • इस समस्या पर और गहराई से सोचने की ज़रूरत है
      लक्ष्य “मेरे लिए इतना काफी है” नहीं है; हमें package और virtual environment के standard tools चाहिए जो 2 Python developers वाली org से लेकर सैकड़ों-हज़ारों लोगों के scale तक फैल सकें। वरना ecosystem टूटेगा, bugs और मुश्किल documentation बढ़ेंगे, और भाषा का प्रभावी रूप से आगे विकसित होना कठिन हो जाएगा
    • अगर Python version की चिंता नहीं है तो मुझे भी लगता है कि pip + venv काफी है
      लेकिन यह define करने का कोई तरीका नहीं है कि project किस Python version के लिए बनाया गया था। अगर आप package बना रहे हैं, तो शायद कई versions पर test करना होगा; और अगर यह installable distribution package नहीं बल्कि कुछ developers द्वारा साझा किया गया code bundle है, तो machine learning model चलाना, cloud function deploy करना, report बनाना जैसे कामों के लिए आम तौर पर आप सिर्फ एक precise Python version को target करना चाहेंगे
      यह भी सवाल है कि monorepo approach का मतलब क्या numpy और pandas को repository में copy करके डालना है
    • मेरा अनुभव भी बिल्कुल यही है: pip मेरे लिए काफी है

  • शुरुआत में मुझे उम्मीद थी कि नया tool Python की “packaging” समस्या हल करेगा, लेकिन आगे पढ़ने पर लगा कि यह मेरे बनाए Python application को package करने की समस्या से ज़्यादा package management के बारे में है
    निजी तौर पर मुझे Python package management में कोई बड़ी समस्या नहीं हुई; ecosystem में कमियाँ हैं, लेकिन namespaces न होने जैसी चीज़ों को छोड़ दें तो pip कुल मिलाकर ठीक काम करता है
    जो सच में परेशान करता है वह यह है कि Python application को आसानी से executable में wrap करके कहीं deploy नहीं किया जा सकता। production environment में अक्सर git clone और virtualenv बनाते हुए देखा जाता है, जिससे target server पर ज़रूरत से ज़्यादा connectivity चाहिए होती है और development dependencies operating system पर रह भी जाती हैं। security के नजरिए से यह बहुत खराब idea है, इसलिए जब तक यह समस्या हल नहीं होती, मैं end users या production deployment वाले कामों के लिए दूसरी languages को प्राथमिकता दूँगा

    • यह बात गलत नहीं है, लेकिन खोलकर देखें तो मुख्य बात यह है कि दूसरों के लिए application को आसानी से चलाना संभव बनाना ज़रूरी है
      इसके लिए application user तक पहुँचे, वहाँ Python ढूँढे, और यह पूरी प्रक्रिया user के लिए transparent होनी चाहिए। Rye बनाते समय, और uv के साथ भी, Python installation को system न बिगाड़ने वाले तरीके से support करने की कोशिश करने की एक वजह यही थी
      इससे आगे का रूप यह है कि uv सहित पूरी प्रक्रिया automate हो जाए। अभी भी चाहें तो curl to bash installer से uv/Rye और app को app-specific temporary location में install कर सकते हैं और user system को कभी न तोड़ने वाला बना सकते हैं
      उम्मीद है कि किसी दिन यह प्रक्रिया पूरी तरह transparent हो, network access की ज़रूरत न रहे, और Windows के लिए .msi जैसी चीज़ें भी मिलें। लेकिन इसकी शर्त यह है कि uv जैसे tools precompiled Python और सभी ज़रूरी dependencies को user platform के हिसाब से सही location पर मनमाने ढंग से रख सकें
      uv कभी जो अंतिम bonus दे सकता है वह पूरी तरह packaged artifact है, और ऐसा हो जाए तो बहुत अच्छा होगा। उससे पहले का चरण भी Python में बने command-line tools users को देने का अनुभव अब भयावह नहीं रहने दे सकता। uvx इस्तेमाल किया जा सकता है, या चाहें तो uv को पूरी तरह hide भी किया जा सकता है
    • यह इस पर निर्भर करता है कि आप कहाँ और क्या install करना चाहते हैं, लेकिन किसी reasonable deployment target के लिए आम तौर पर उस target के लिए installable binary बनाने वाला tool होता है
      उदाहरण के लिए operating system-specific installers बनाने वाले tools हैं, और Android, iOS या browser जैसी अलग जगहों पर deploy करने वाले tools भी आ गए हैं। स्वाभाविक है कि कोई specific package किसी specific target पर काम न करे, लेकिन standard interface मौजूद है, इसलिए अगर code कहीं चल सकता है तो उस target के लिए tool को ऐसा output बनाना चाहिए जो काम करे

  • npm के venture investment-आधारित rug pull और Microsoft के acquisition, और फिर OpenAI ने यह दिखा दिया कि कानूनी non-profit status भी venture investment के रास्ते में उलझे नेताओं के लिए बेअसर marketing भर है—इसके बाद core path में मौजूद language infrastructure को ऐसे संगठनों को सौंपने में झिझक होती है
    इसमें योगदान देने वाले individual लोग अपने-अपने स्तर पर अच्छे और अक्सर असाधारण होते हैं, लेकिन संगठन-स्तर के financial interests शुरुआत से ही दूषित होते हैं। 1–4 साल बाद मायने संगठन का ही रह जाता है। बात कुछ वैसी है: “या तो hero बनकर मरते हो, या इतना जीते हो कि villain बन जाते हो”
    इसलिए तेज़ linter, type checking, code scan, PR assistant tools ठीक हैं और कभी भी बदले जा सकते हैं। लेकिन install flow और package repository नहीं
    pip और conda की हालत सोचें तो अफ़सोस होता है, लेकिन मुझे reality यही लगती है

    • Python में वह लड़ाई पहले ही हार चुकी है
      मुझे लगता है Microsoft Python का मालिक है, बस इसे सार्वजनिक रूप से दिखाता नहीं है
      कुछ साल पहले मैं kubectl के लिए Python bindings बनाना चाहता था, लेकिन पता चला कि cross-platform काम करने के लिए CGo को हर platform पर Python जैसे ही compiler का इस्तेमाल करना होगा। मगर Windows पर CGO MINGW इस्तेमाल करता है और Python MSVC। उस समय मौजूद Python development mailing list पर मैंने पूछा कि एक “open source” project proprietary compiler क्यों इस्तेमाल करता है, और जवाब मिला कि MSVC ऐतिहासिक choice है और अब इसे बदला नहीं जा सकता। वजह यह बताई गई कि Microsoft, Python Foundation को CI और builds चलाने के लिए मुफ्त infrastructure देता है, और Python interpreter पर काम करने वाले developers भी उपलब्ध कराता है। यानी Microsoft employees, Microsoft के पैसे लेकर Python interpreter पर काम करते हैं, और उन्हें toolchain से Microsoft tools न हटाने का निर्देश मिलता है
      हर साल स्थिति और खराब हुई। मिलते-जुलते projects की तरह, success ने ऐसे लोगों के power में आने की जमीन बनाई जिनमें खास योग्यता नहीं थी, और Python Foundation और PyPA जैसे आसपास के projects ऐसे लोगों से भरने लगे जो उपयोगी code contribute करके नहीं, बल्कि code of conduct pages लिखते हुए पदों पर पहुंचे थे। इस code of conduct और पदों के नियंत्रण को लेकर अंतहीन झगड़ों का नतीजा यह हुआ कि पुराने contributors चले गए या निकाल दिए गए, और हाल ही में Tim sort बनाने वाले Tim को भी ban कर दिया गया
      Microsoft हर उस project में जो agenda आगे बढ़ाता है जिस पर उसका हाथ पड़ता है, वही यहां भी धकेल रहा है। ads के लिए ढेरों बेकार features जोड़ना, project को हर दिशा में डगमगाना, और खासकर trend को जितना हो सके follow करवाना। इसलिए Python, एक पूरी तरह अलग type system वाली language होते हुए भी, machine learning-style types जितना हो सके जोड़ रहा है; और ऐसी language होते हुए भी जिसका आधा इस्तेमाल native libraries को dynamically जोड़ने में होता है, pre-compilation और JIT के पीछे पड़ा है। मूल रूप से इसे बिना curly braces वाला C# बनाने जैसा है
      Microsoft इतना smart है कि उसे पता है अगर वह Python ownership को सार्वजनिक रूप से announce करेगा तो बहुत लोग technology से दूर हो जाएंगे, इसलिए वह इसका बड़ा प्रचार नहीं करता। लेकिन वह developers को अपने tools पर depend करने के लिए लगातार मजबूर कर रहा है, और किसी दिन वह इस investment की वसूली करने आएगा
    • क्या npm शुरू से ही company नहीं था? rug pull क्या था, मुझे नहीं पता, और क्या सच में कुछ काम करना बंद हुआ था?
    • PSF और PyPA अगर संभलकर Python packaging पर अच्छी बात सामने लाते हैं तो उसका हमेशा स्वागत है
      लेकिन अब तक उन्होंने मूल रूप से contributors के अरबों blog posts ही दिए हैं, जिनका सार यह है: “हमने जो system बनाया है वह हमें मददगार होने से रोकता है, और वैसे भी यह हमारी गलती नहीं है”
      वे internal systems और internal politics में इतने डूबे लगते हैं कि अब उन्हें यह भी नहीं पता कि वे वहां हैं क्यों
      इसलिए अगर कोई सच में अच्छा काम करता है और Astral की तरह market पर कब्ज़ा कर लेता है, तो community के रूप में हमें यही परिणाम मिलना चाहिए
      [1]: यहां मेरा मतलब internal politics से है। किसी अजीब far-right किस्म के “DEI hiring!” हंगामे से नहीं

  • इन tools के साथ अभी भी authority की समस्या बची हुई है
    यह cargo से अलग है, क्योंकि इन्हें PyPA ने approve नहीं किया है। साथ ही PyPA सालों तक कोई comprehensive solution नहीं दे पाया, और Python packaging और development tools लगातार बढ़ते गए। सिर्फ 3–4 साल पहले तक poetry और pipenv ऐसे लगते थे जैसे वे Python packaging की उन समस्याओं को हल कर रहे हों जिन्हें pip+virtualenv हल नहीं कर पाए थे
    अब मुझे लगता है PyPA को astral.sh वाली नाव पर चढ़ जाना चाहिए, लेकिन पता नहीं वह किसी level के control के बिना ऐसा करेगा या नहीं

    • हाल में पता चला कि PyPA के नाम Python Packaging Authority में Authority मूल रूप से एक मज़ाक के तौर पर था: https://discuss.python.org/t/remove-the-authority-from-packa...
    • जब से PyPA ने दूसरे options के बजाय Pipenv को approve किया, तब से मैंने PyPA की recommendations की परवाह करना छोड़ दिया
      मेरी नज़र में इसका बड़ा हिस्सा personal relationships की वजह से था, और उस समय Pipenv विनाशकारी था। इरादा अच्छा था, लेकिन company में comparatively कम widely used dependencies वाले repositories में भी lock file update करने के लिए एक घंटा इंतजार करना पड़ता था। वह बस काम नहीं करता था
      practical तौर पर, PyPA जो कठिन technical work करता है उसके लिए मैं बहुत आभारी हूं। लेकिन वह अभी कौन-सा tool bundle recommend करता है, इसकी मुझे ज्यादा परवाह नहीं। मुझे लगता है community जो इस्तेमाल कर रही है वही इस्तेमाल करना बेहतर है और “official” suggestions की चिंता न करना ही ठीक है
    • थोड़ा बाहरी observer के तौर पर, PyPA असल में है क्या यह ठीक से समझ में नहीं आता
      participants की संख्या स्पष्ट नहीं है, और PyPA का core Python या PSF से कितना संबंध है, यह भी पक्का नहीं है
      मुझे लगता है कि जो approval सच में मददगार होगा, वह core Python project से ही आना चाहिए। आदर्श दुनिया में official Python tutorial “Python install करने का तरीका यह है” से शुरू हो और पहले uv install करने को बताए, ठीक वैसे जैसे official Rust docs rustup और cargo की ओर इशारा करते हैं
      मैं बहुत चाहता हूं कि PSF, Astral के साथ कोई ऐसा संबंध बनाए जिससे किसी दिन यह reality संभव हो सके
    • सच कहूं तो इस point पर मुझे PyPA की परवाह नहीं है
      इस context में उसने खुद साबित कर दिया है कि वह ज्यादातर irrelevant है। वह जिस चीज को छूता है वह सड़ती हुई दिखती है, इसलिए अफ़सोस के साथ कहता हूं कि मैं चाहता हूं वह इस समस्या से दूर रहे। ऐसा कहना मुझे बुरा लगता है और मेरी philosophy के भी खिलाफ है, लेकिन यह सिर्फ current state को reflect करने वाला judgment है। मैं 10 साल से Python में full-time काम कर रहा हूं, और दूसरे packaging ecosystems ने practically Python को एक lap से भी ज्यादा पीछे छोड़ दिया है
      अब मुझे इस nuance की भी परवाह नहीं रही कि “यह PyPA की execution problem है या तय role scope गलत है”। ऐसी discussions में खिंच जाना भी अब थका चुका है

  • Armin यह पक्ष रखते हैं कि uv इस क्षेत्र पर हावी हो, लेकिन यह भी मानते हैं कि venture निवेश पर आधारित होने की वजह से इसमें rug pull हो सकता है
    उस संभावित समस्या के समाधान के तौर पर वे कहते हैं, “इसे fork करना बहुत आसान है”, लेकिन क्या fork स्वभाव से और ज़्यादा fragmentation नहीं पैदा करता? वही समस्या जिसे वे हल करना चाहते हैं
    अगर कोई tool Python packaging landscape पर हावी होना चाहता है, तो मेरे हिसाब से उसे community-driven और community-controlled होना चाहिए

    • fork स्वभाव से ज़रूरी नहीं कि और ज़्यादा fragmentation पैदा करे
      rug pull हो चुके tool पर पहले एकजुट होने के बाद fragmentation का स्तर, एकजुट होने से पहले की तुलना में काफी कम भी हो सकता है
      और क्या इस काल्पनिक community को एक बेहतरीन dominant tool बनाने के लिए अभी और कई दशकों की ज़रूरत है?
    • license choice MIT या Apache होने से आसानी से fork किया जा सकता है, लेकिन Rust का चुनाव असल में योगदान कर सकने वाले लोगों की संख्या सीमित करता है
    • क्या npm भी venture निवेश पर आधारित नहीं है?

  • आज सुबह कंपनी में Poetry की धीमी गति की वजह से हमारे software को Poetry से uv पर migrate करने पर नज़र डाली
    अभी तक मैं बहुत documentation पढ़ रहा हूँ, लेकिन असल progress ज़्यादा नहीं हुई है। पहले Poetry पर ले जाने का काम भी मैंने ही किया था, और वह कहीं ज़्यादा simple था। अब तक जो दिख रहा है, उसमें Poetry ने दूसरे package managers की तरह behave करने वाला एक simple package manager बनाने की कोशिश की थी, जबकि uv लगता है Python packages की काफी सारी पागलपन वाली चीज़ें ज्यों की त्यों रखता है

    • कम से कम uv, Poetry की तरह virtualenv से टकराकर पूरा chaos नहीं बनाता
      Poetry के मामूली बदलाव से package.toml format टूट जाना, या transitive dependencies पर काम न करने वाले बेवकूफाना “sources” की वजह से multiple indexes पर resolution time लंबा हो जाना भी नहीं होता
    • क्या आप specifically बता सकते हैं कि uv में क्या मुश्किल था?
    • हाल ही में pip-tools से uv पर shift किया, और यह काफी smooth रहा
      uv असल में standard Python tooling flow में सीधे plug-in हो जाने जैसा महसूस होता है
    • अभी uv बहुत low-level है, शायद आपको Rye चाहिए था?
    • आप किस पागलपन की बात कर रहे हैं?

  • अगर लोग इस बार skip करके 2026 वाले “Python package manager: इस बार हमने सच में solve कर दिया!” का इंतज़ार करें, तो मैं उन्हें दोष नहीं दूँगा
    फिर भी मैं अब भी एक संतुष्ट Nix user हूँ

  • यह framing मुझे सच में बहुत पसंद आई
    बहुत से लोगों ने लंबे समय तक धीरे-धीरे जो काम जमा किया, उसकी वजह से अब हम उस मुकाम पर हैं जहाँ एक company के कुछ लोग मध्यम स्तर की मेहनत से स्थिति को तेजी से बेहतर बना सकते हैं