Rust की अनिवार्य dependency, मई 2026 से Debian APT में शामिल होने की योजना

 (lists.debian.org)
3 पॉइंट द्वारा GN⁺ 2025-11-02 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • Debian के APT package manager में मई 2026 के बाद से Rust-आधारित code और dependencies शामिल किए जाने की योजना है
  • शुरुआती चरण में Rust compiler, standard library, और Sequoia ecosystem को एकीकृत किया जाएगा
  • .deb, .ar, .tar file parser और HTTP signature verification code ऐसे मुख्य क्षेत्र हैं जहाँ memory safety और unit testing को मजबूत करने के लिहाज़ से बड़े सुधार अपेक्षित हैं
  • जिन ports में Rust toolchain नहीं है, उन्हें 6 महीने के भीतर Rust environment बनाना होगा, नहीं तो उनका support समाप्त (sunset) किया जा सकता है
  • यह कदम पूरे project को आधुनिक tools और technologies की ओर ले जाने के लिए है, ताकि पुरानी hardware compatibility इसकी प्रगति में बाधा न बने

APT में Rust code शामिल करने की योजना

  • APT में Rust code और hard dependency को मई 2026 के बाद शामिल किया जाएगा
    • लागू होने का समय मई 2026 के बाद है; उससे पहले यह लागू नहीं होगा
  • शुरुआती integration का दायरा Rust compiler, standard library, और Sequoia ecosystem तक सीमित है

code quality और safety बेहतर बनाने का उद्देश्य

  • .deb, .ar, .tar file parsing code और HTTP signature verification code Rust अपनाने के मुख्य लक्ष्य हैं
    • स्पष्ट रूप से कहा गया है कि इन क्षेत्रों को memory-safe language और मजबूत unit testing framework के लाभ विशेष रूप से मिलेंगे

port maintainers के लिए आवश्यकताएँ

  • जिन ports में Rust toolchain नहीं है, उन्हें 6 महीने के भीतर Rust environment तैयार करना होगा
    • अन्यथा उन ports को बंद (sunset) किया जा सकता है

project की दिशा

  • इस बात पर ज़ोर दिया गया है कि Debian project को आधुनिक tools और technologies का उपयोग करते हुए आगे बढ़ना चाहिए
    • यह भी कहा गया है कि पुराने hardware या retro computing devices के अनुरूप बने रहने की कोशिश से प्रगति रुकनी नहीं चाहिए

अन्य जानकारी

  • संदेश भेजने वाले Debian और Ubuntu core developer Julian Andres Klode हैं
  • यह मेल Debian developer mailing list debian-devel पर पोस्ट किया गया था
  • संलग्न फ़ाइल के रूप में PGP signature (signature.asc) शामिल है
  • अतिरिक्त technical details या schedule change का कोई उल्लेख नहीं है

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

1 टिप्पणियां

 
GN⁺ 2025-11-02
Hacker News राय

  • लगता है अब इसका समय आ गया है। अविश्वसनीय डेटा को पार्स करने वाला कोड अभी भी C में बनाए रखना समय के साथ बढ़ता हुआ तकनीकी कर्ज़ है
    Rust को लिखना C से बहुत अधिक कठिन भी नहीं है, और अगर आज की कोड सुरक्षा तथा भाषा-डिज़ाइन की समझ के आधार पर C को फिर से बनाया जाए, तो शायद वही भाषा Rust जैसी दिखे
    अगर व्यावहारिक कारणों से 32-बिट x86 सपोर्ट छोड़ा जा सकता है, तो इन आर्किटेक्चर के साथ भी वैसा ही होना चाहिए। अगर इन्हें सच में बनाए रखना है, तो Rust toolchain backend खुद बनाना होगा

    • अभी बेस सिस्टम में कोर applications के लिए मान्य भाषाएँ लगभग C, C++, Shell(bash), Perl, और Python हैं। Python को जोड़ा गया था लगभग 20 साल पहले, और Rust पहली ऐसी भाषा है जो C की भूमिका को बदलने के लिए काफ़ी करीब आती है
      Go कुछ हद तक करीब था, लेकिन systemd जैसे core system में इस्तेमाल होने लायक गंभीर चर्चा तक नहीं पहुँचा। सोचता हूँ कि C++, Python, Perl को जोड़ते समय भी क्या ऐसे ही विवाद हुए होंगे
    • कहा जाता है कि “.deb, .ar, .tar parser और HTTP signature verification code को memory-safe language से फ़ायदा होगा”, लेकिन पिछले 30 साल में स्थिर हुए कोड को नई भाषा में फिर से लिखने से वास्तव में क्या लाभ मिलेगा, इस पर संदेह है
      क्या battle-tested code को छोड़कर नई compatibility problems और bugs बनाना सच में उचित है?
    • पुराने C कोड की security problems हल करने के लिए Fil-C project जैसा अधिक व्यावहारिक तरीका भी है। यह C को लगभग managed language जैसा बना देता है, जिससे दोबारा लिखने की ज़रूरत कम होती है
    • यह सिर्फ memory safety का मुद्दा नहीं है। C community की बढ़ती उम्र के कारण maintainers ढूँढना मुश्किल हो रहा है। हमारी टीम भी अपना सारा C/C++ कोड दूसरी भाषाओं में ले जा रही है। ज़्यादातर C/C++ developers 40s में हैं और नौकरी बदलने की इच्छा कम रखते हैं
    • Rust को C का आधुनिक पुनर्निर्माण कहना स्वीकार करना मुश्किल है। उदाहरण के लिए, COSMIC desktop के clock widget code को देखें, तो वह समान जटिलता वाले C code (जैसे GNU coreutils) से कहीं अधिक पढ़ने में कठिन लगता है

  • Rust में core system को फिर से लिखने की प्रवृत्ति मज़बूत है, लेकिन पुराने tools को rewrite करने से security वास्तव में बेहतर होती है या नहीं, इस पर संदेह है
    यह समझ आता है कि नई systems लाना कठिन है, लेकिन फिर भी ऐसा लगता है जैसे अब भी telegraph युग के design decisions पर परत-दर-परत निर्माण बनाए रखा गया है

    • ऐसे rewrites के लिए आम तौर पर दो कारण दिए जाते हैं।
      पहला, पुराने C/C++ codebase पर काम करना चाहने वाले नए contributors लगभग नहीं मिलते। Rust में ले जाने से नए developers को जोड़ना आसान हो जाता है
      दूसरा, reliability का परीक्षण उपयोग की आवृत्ति से होता है, लेकिन security का परीक्षण केवल हमलों से होता है। यह मान लेना कठिन है कि पुराने code ने हर attack vector देख लिया है। इसलिए proactive security hardening का तर्क मज़बूत है
    • uutils/coreutils MIT license पर है, जबकि GNU coreutils GPL पर, इसलिए license का अंतर है। कंपनियों के लिए यह एक अहम बिंदु हो सकता है
    • किसी न किसी को सीखना तो पड़ेगा, इसलिए सरल और test करने में आसान projects को अभ्यास के लिए rewrite करना ठीक है। लेकिन उसका परिणाम मूल को replace करेगा या नहीं, यह अलग प्रश्न है

  • Debian mail thread के अनुसार, Rust पहले से ही Debian की अधिकांश release architectures पर अनिवार्य है
    संबंधित मेल में केवल alpha, hppa, m68k, sh4 को अपवाद के रूप में बताया गया है। इन architectures का आगे क्या होगा, यह जानने की उत्सुकता है

    • सच में सोचता हूँ कि क्या कोई अभी भी ऐसी पुरानी machines इस्तेमाल करता है। ज़्यादातर hardware 20 साल से भी पुराना है।
      Rust m68k के लिए Tier 3 target देता है, लेकिन बाकी architectures के लिए नहीं। इनके वास्तविक use cases जानना दिलचस्प होगा
    • Debian Supported Architectures के अनुसार, ये platforms अनौपचारिक स्थिति में हैं।
      32-बिट x86 और MIPS के हटने के बाद भी इनका बचे रहना थोड़ा आश्चर्यजनक है। व्यक्तिगत रूप से इसमें nostalgia तो है, लेकिन वास्तविक उपयोग का पता नहीं
    • m68k के लिए पहले से LLVM port मौजूद है, इसलिए Rust implementation संभव है। alpha, hppa, sh4 के LLVM backends की शैक्षिक संदर्भ के रूप में भी क़ीमत है
      पहले LLVM में DEC Alpha backend हुआ करता था, लेकिन वह बहुत पुरानी बात है
    • Ubuntu के नज़रिए से देखें तो इन architectures की कोई commercial value नहीं है
    • ये पूरी तरह obsolete हैं, इसलिए बस आख़िरी supported version पर रुक जाएँ या अपना distro बना लें। Rust support जोड़ना अव्यावहारिक है

  • काश Rust community मौजूदा projects में घुसने के बजाय नई आधुनिक तकनीक खुद बनाकर साबित करती
    Redox जैसे स्वतंत्र projects ऐसे उदाहरण हैं, इसलिए अफ़सोस है कि ऐसे प्रयासों को और आगे क्यों नहीं बढ़ाया जाता

    • यह Debian का Rust dependency जोड़ने का आधिकारिक फ़ैसला है। किसी बाहरी Rust fan ने इसे थोप नहीं दिया
      बेशक “Rust में फिर से लिखो” कहने वाले अतिवादी fans होते हैं, लेकिन यह मामला वैसा नहीं है
    • ripgrep इसका सीधा उदाहरण है। नया बनाया गया, और लोगों को वास्तव में पसंद भी आया

  • Rust standard library का इस्तेमाल ठीक है, लेकिन एक साधारण deb parser build के लिए 500 cargo packages खींच लाना नहीं चाहिए

  • शायद Rust-for-GCC port के स्थिर होने तक इंतज़ार करना तर्कसंगत हो सकता है
    kernel भी GCC support आने से पहले Rust को अनिवार्य नहीं बनाने वाला है।
    कई implementations आने से भाषा कम अस्थिर लगेगी
    लेकिन अगर अभी architecture support हटा दिया गया, तो बाद में Rust toolchain आने पर वापसी की प्रक्रिया जटिल हो सकती है

    • वास्तव में ये architectures पहले से ही 10 साल से अधिक समय से Debian से बाहर हैं। इस बदलाव से वे नई तरह से बाहर नहीं हो रहे
    • इनका कोई आधिकारिक support नहीं है, और यह व्यक्तिगत spare time maintenance के स्तर पर चल रहा है। जब तक कोई कंपनी long-term maintenance न ले, वापसी मुश्किल है
    • GCCRS अभी libcore तक build नहीं कर पाता, और Rust 1.50 स्तर पर है। सामान्य उपयोग के compiler बनने में शायद कई साल लगेंगे
      उल्टा rustc_codegen_gcc के पहले stable होने की संभावना ज़्यादा है
    • ports Debian की official release में शामिल नहीं होते, और केवल unstable channel में वितरित किए जाते हैं

  • यह भी याद रखने लायक है कि Debian Rust discussion mail के लेखक keepassxc package maintainer हैं
    अतीत में upstream developers और users के प्रति उनके कठोर व्यवहार का ज़िक्र करने वाली threads भी हैं

    • मैंने भी वह मेल देखकर तुरंत जाँच की थी, और पुरानी thread याद आकर हँसी आ गई
    • ईमानदारी से कहूँ तो उनकी भाषा कठोर है, लेकिन सीधी है, अपमानजनक नहीं। यह बेवजह का drama लगता है
    • HN पोस्ट खुद आक्रामक नहीं है, लेकिन कुछ लोग शायद उसे ज़रूरत से ज़्यादा तीखे तौर पर ले रहे हैं
    • ऐसी संस्कृति free software दुनिया में आम है। मेरा मानना है कि वास्तविक users से अधिक आदर्श users की कल्पना का पीछा करने की प्रवृत्ति GNOME 3 और Mozilla के दौर से चलती आई है

  • किसी एक व्यक्ति की राय बदलने की प्रक्रिया देखना दिलचस्प है। पुराना बयान

    • समय के साथ सोच बदलने का रवैया अच्छा लगता है
    • APT में Rust का आना भी coreutils transition की तरह प्रशासनिक निर्णय हो सकता है

  • मुझे लगता है Rust सिर्फ hype है। embedded दुनिया में अब भी C ही राजा है।
    मैंने अपने आसपास किसी को वास्तव में Rust इस्तेमाल करते या उस पर विचार करते नहीं देखा

    • “मेरे आसपास नहीं है” के आधार पर निष्कर्ष निकालना ठीक नहीं। बहुत से embedded developers Rust का इस्तेमाल करते हैं
    • AWS के अंदर EC2, IAM, DynamoDB, S3 जैसी core services Rust में लिखी गई हैं।
      performance और memory efficiency बनाए रखते हुए development speed भी तेज़ मिलती है।
      एकमात्र कमी binary size है। मेरे हिसाब से Rust का भविष्य पहले ही काफ़ी मज़बूत हो चुका है
    • embedded में भी Rust शक्तिशाली है, लेकिन manufacturer support कम होने से hardware-specific शुरुआती काम ज़्यादा पड़ता है।
      फिर भी आकर्षण सिर्फ memory safety नहीं, बल्कि पूरी language और toolchain की quality भी है
    • avr-rust, esp-rs, cortex-m जैसी चीज़ों के साथ embedded ecosystem भी धीरे-धीरे बदल रहा है
    • Microsoft, Google आदि में भी Rust पर चर्चा हो रही है और इसे वास्तविक products में लागू किया जा रहा है

  • मुझे लगता है polyglot environment और ज़्यादा समस्याएँ पैदा करता है।
    Python, Node, Go, Rust आदि के लिए अलग-अलग toolchains और package managers चाहिए, जिससे जटिलता बढ़ती है
    Node से buffer overflow तो हट गया, लेकिन supply chain attacks बढ़ गए।
    बेहतर है कि नई शुरुआत की जाए, और अगर Rust को पूरी तरह अपनाना है, तो Redox OS में योगदान करना ज़्यादा उचित है

    • व्यावहारिक रूप से हर भाषा के अपने फायदे और नुकसान हैं, और Debian को एक व्यावहारिक OS के रूप में कई भाषाओं का समर्थन करना चाहिए
      सब कुछ एक ही भाषा में फिर से लिखना अव्यावहारिक है, और Redox को आगे बढ़ाने पर ज़ोर देना भी उल्टा अलाभकारी हो सकता है
      Rust पहले से काफ़ी सिद्ध भाषा है, और C की तुलना में बदलाव करते समय खुद को उड़ा देने की संभावना कम रखने वाली compiled language के रूप में इसका मूल्य है
      पुराने architectures को छोड़ देना भी कोई अनुचित बात नहीं
    • Debian जैसे बड़े project के लिए विकल्पों का दायरा बढ़ाना तर्कसंगत है। Rust को जोड़ना पूरी तरह समझ में आने वाला निर्णय है
      कौन-सी भाषा हटानी है, कौन-सी जोड़नी है, यह Debian maintainers का निर्णय होना चाहिए
    • Linux ने दशकों पहले ही जटिलता से लड़ाई छोड़ दी थी