11 पॉइंट द्वारा GN⁺ 2025-02-21 | 24 टिप्पणियां | WhatsApp पर शेयर करें

Linux kernel में Rust को शामिल करने की ज़रूरत क्यों है

  • पिछले 15 वर्षों में लगभग सभी Linux kernel bug fixes और security issues को देखने के अनुभव के आधार पर, मैं Rust को अपनाने की ज़रूरत पर बात करना चाहता हूँ
  • सभी bug fixes stable version tree में शामिल नहीं होते, लेकिन आम तौर पर महत्वपूर्ण fixes शामिल हो जाते हैं, और मैं उन लोगों में हूँ जो सभी kernel CVE की जाँच करते हैं

C की सीमाएँ और Rust के फायदे

  • Linux kernel में होने वाले अधिकांश bugs की जड़ C भाषा की संरचनात्मक सीमाएँ हैं
  • खासकर, साधारण मानवीय गलतियों से पैदा होने वाले bugs बहुत हैं, और Rust में ऐसी समस्याएँ लगभग नहीं होतीं
    • memory overwrite (Rust हर मामले को नहीं पकड़ता, लेकिन बड़े हिस्से में समाधान दे सकता है)
    • error path cleanup problems
    • error value checks छूट जाना
    • use-after-free bugs
  • अगर kernel में Rust लाया जाए, तो developers और maintainers ऐसी बुनियादी गलतियों से मुक्त होकर, सच में कठिन समस्याओं (logic errors, race conditions आदि) पर ध्यान दे सकते हैं

मौजूदा C codebase को भी बनाए रखना होगा

  • मौजूदा Linux kernel 3 करोड़ से अधिक lines of C code से बना है, और इसे कम समय में Rust से बदलना असंभव है
  • इसलिए Kees, Gustavo और अन्य developers द्वारा किया जा रहा C code security hardening work ज़रूरी है और जारी रहना चाहिए
  • आदर्श तरीका यह है कि Rust मौजूदा code को बदलने के बजाय, नया code (खासकर drivers) Rust में लिखा जाए ताकि समस्याएँ कम हों

Rust द्वारा दी जाने वाली API safety

  • Rust kernel के internal API को ज़्यादा सुरक्षित और इस्तेमाल में आसान तरीके से डिज़ाइन करने में मदद करता है
  • मौजूदा C-आधारित kernel API जटिल हैं, उनमें गलती करना आसान है, और maintainers को अक्सर बहुत बारीकी से review करना पड़ता है
  • उदाहरण के लिए, struct cdev जैसी संरचनाओं को सुरक्षित तरीके से इस्तेमाल करने के कई तरीके हैं, और उन्हें सही ढंग से उपयोग करने के लिए काफी अनुभव चाहिए
  • Rust का उपयोग करने पर API को ज़्यादा स्पष्ट रूप से परिभाषित किया जा सकता है, जिससे developers के गलती करने की संभावना बहुत कम हो जाती है
  • यह बदलाव सिर्फ Rust users के लिए नहीं, बल्कि मौजूदा C code users के लिए भी फायदेमंद है

इस चिंता पर जवाब कि Rust को अपनाना मुश्किल होगा

  • Rust कोई जादुई समाधान नहीं है → लेकिन यह मौजूदा समस्याओं के बड़े हिस्से को हल कर सकता है
  • maintainers पर बोझ बढ़ेगा → लेकिन जो developers Rust लाना चाहते हैं, वही इस पर सीधे काम कर रहे हैं
  • mixed-language codebase की maintenance कठिन होगी → लेकिन Linux kernel अब तक इससे भी कहीं कठिन समस्याएँ हल करता आया है

निष्कर्ष

  • Linux दुनिया भर के अनगिनत developers द्वारा समस्याएँ हल करने के लिए इस्तेमाल किया जाने वाला एक tool है,
  • और अब अगर ऐसे developers की माँग है जो hardware के लिए सुरक्षित code लिखना चाहते हैं, तो इसे नज़रअंदाज़ नहीं किया जाना चाहिए
  • Linux development model ऐसे पैमाने तक बढ़ा है जिसकी किसी ने कल्पना नहीं की थी, और इसने बेहतरीन engineering क्षमता दिखाई है
  • अब Rust को अपनाकर अगले 20+ वर्षों की प्रगति की दिशा में बढ़ने का समय है

हमें नई technologies और ideas को अपनाना चाहिए, और community के साथ मिलकर उन्हें सफल बनाने की कोशिश करनी चाहिए।

24 टिप्पणियां

 
bus710 2025-02-23

Memory safety को ध्यान में रखें तो Rust को अपनाना शायद टालना मुश्किल बदलाव है। शायद कोई उचित समझौता निकालकर फिर से जोड़ने की कोशिश की जाएगी।

लेकिन, व्यक्तिगत रूप से मुझे Rust के keywords नज़र में आसानी से नहीं बैठते, और काफ़ी समय बाद दोबारा देखने पर उन्हें याद करना भी आसान नहीं लगता, इसलिए उस पर हाथ ठीक से नहीं जम पाता ;;;; मुझे पता है कि ये सब ज़रूरी चीज़ें हैं, लेकिन कभी-कभी यह अंग्रेज़ी के irregular verbs को ज़बरदस्ती रटने जैसा महसूस होता है। फिर भी, यह भी सच है कि Rust में लिखे गए नतीजे वास्तविक कामकाजी माहौल में कम समस्याएँ पैदा करते हैं.....

 
lostid 2025-02-22

मुझे लगता है कि अभी पर्याप्त परिपक्व न हुई किसी भाषा को kernel में शामिल नहीं करना इतनी आलोचना की बात नहीं होनी चाहिए। अगर अभी आसपास देखिए और Rust में वास्तव में निपुण लोगों को खोजिए, तो ऐसे लोग लगभग नहीं मिलते, है न? मेरा मानना है कि भाषा थोड़ी और परिपक्व हो जाए और उपयोगकर्ताओं का आधार legacy भाषाओं के users जितना न सही, लेकिन पर्याप्त रूप से बन जाए, तब उसे शामिल किया जाए तो भी देर नहीं होगी. Rust भाषा उपयोगी है, यह बात Linux kernel में लागू किए बिना भी पर्याप्त रूप से साबित की जा सकती है, ऐसा मेरा विश्वास है.

 
pcpenpal 2025-02-22

यह अपने-आप में हैरानी की बात है कि Rust को अभी के स्तर पर भी "अब भी परिपक्व न हुई भाषा" कहा जाता है, लेकिन इससे अलग, कर्नेल में अब तक असुरक्षित भाषाओं का हिस्सा कम करने की कोशिश करना क्या सचमुच इतनी निंदा की बात है, यह भी समझ से बाहर है। अभी अपने आसपास ही देख लीजिए, कितने लोग हैं जो C भाषा में इतना दक्ष हों कि कर्नेल में योगदान देने लायक सुरक्षित कोड लिख सकें? C भाषा से और परिपक्व होने की उम्मीद करने के बजाय, अब जबकि नए युग की ज़रूरतें काफी हद तक स्पष्ट और स्थापित हो चुकी हैं, मुझे लगता है कि यही सही समय है—अब भी देर नहीं हुई है.

Rust पहले से ही उपयोगी है, और कर्नेल में शामिल होने की उसकी कोशिश शायद अपनी उपयोगिता साबित करने के लिए नहीं है।

 
aer0700 2025-02-22

जब पहली बार Rust को अपनाने का फैसला किया गया होगा, तो लगता है इस पर चर्चा हुई होगी।
अगर सोचें कि C में निपुण लोगों का पूल बड़ा है या Rust में निपुण लोगों का, तो C का पलड़ा भारी होना स्वाभाविक है।
हालांकि यह भी लगता है कि जिस प्रोग्रामर के पास डोमेन ज्ञान पहले से पूरा है, उसके लिए एक भाषा और सीखना क्या बहुत बड़ी बात है?
लेकिन kernel पर काम करने वाले लोग जिस स्तर की दक्षता मांगते हैं, वह फिर अलग ही बात होगी...

 
roxie 2025-02-22

यह राय भी अच्छी है

 
nemo1275 2025-02-21

"fork करके अलग निकल जाने" वाली दलील मुझे बिल्कुल समझ नहीं आती। आख़िर Linus को Linux से fork करके अलग क्यों हो जाना चाहिए?

 
regentag 2025-02-22

क्या कोई Linus से भी कह रहा है कि वह fork करके निकल जाए? मुझे नहीं लगता कि मैंने इस बहस में किसी को ऐसा कहते देखा है..

 
cloverhearts 2025-02-21

मैं भी Rust उपयोगकर्ता हूँ, लेकिन अगर Rust code और C code मिले-जुले हों, तो open source में कहाँ तक Rust code की अनुमति है इस पर कोई सख्त नियम न होने तक यह नियंत्रण से बाहर हो सकता है, या कम से कम review और maintenance cost बहुत बढ़ जाएगी। इसलिए मुझे लगता है कि कुछ और जोड़ने के बजाय fork करना सबसे समझदारी भरा विकल्प है।

 
aer0700 2025-02-21

मुझे kernel के बारे में ज़्यादा जानकारी नहीं है, लेकिन अगर C code को Rust में अपने-आप translate किया जा सके तो अच्छा होगा। बेशक, code translation की समस्या के अलावा लोगों से जुड़ी समस्याएँ भी होंगी।

 
regentag 2025-02-21

अगर kernel में Rust को लाना चाहने वाले लोग इतने ज़्यादा हैं, तो क्या वे fork करके एक नया project शुरू नहीं कर सकते? फिर जब वह काफ़ी mature हो जाए, तो बड़े distribution शायद Rust-आधारित kernel पर switch कर लें।
मुझे ठीक से समझ नहीं आता कि वे आपस में क्यों लड़ रहे हैं।

 
gurugio 2025-02-21

मुझे ठीक से नहीं पता कि आपके पास kernel development का अनुभव है या नहीं, इसलिए समझ नहीं पा रहा कि क्या कहूँ।
सबसे पहले, Rust language को अपनाने का मतलब kernel को Rust में बदल देना नहीं है। आप यह कह सकते हैं कि इसे अलग करके कोई दूसरा kernel बना लिया जाए, लेकिन
बात kernel को Rust में बनाने की नहीं है, बल्कि kernel में device drivers के लिए सिर्फ interface का Rust wrapper बनाकर device drivers को ही Rust में
बनाने लायक सुधार करने की है। इसलिए इसे नया project बनाकर ले जाने का कोई मतलब नहीं है।

 
regentag 2025-02-21

मैंने Linux साइड पर कभी development नहीं किया है.
लगता है कि device driver के Rust wrapper ऐसी संरचना में हैं जिन्हें kernel से अलग नहीं किया जा सकता...

 
mammal 2025-02-21

यह सचमुच विडंबनापूर्ण है कि kernel stability के नाम पर जहरीले लहजे को सही ठहराती रही Linux community अब आकर "पसंद नहीं है तो fork कर लो" जैसी प्रतिक्रिया को एक तर्कसंगत जवाब मान रही है।

 
regentag 2025-02-21

मैं Linux कम्युनिटी नहीं हूँ, लेकिन...

 
roxie 2025-02-21

मेरा मानना है कि उन लोगों और इस टिप्पणी लिखने वाले को एक ही समुदाय का हिस्सा नहीं मानना चाहिए।

 
jeiea 2025-02-21

मुझे लगता है कि यह अनुमान लगाना मुश्किल होगा कि fork का नतीजा migration बनेगा या बिखराव का एक युग।
fork के बाद भी upstream के बदलावों को शामिल करना शायद कोई सुखद स्थिति नहीं होगी।

 
savvykang 2025-02-21

https://hi.news.hada.io/topic?id=16860
Realtime Linux fork को 20 साल बाद merge किया गया था, इसे देखते हुए क्या हमें fork करने का फैसला सावधानी से नहीं लेना चाहिए?

 
regentag 2025-02-21

मैं यह बात इसे देखकर कह रहा था।
रियल-टाइम फीचर को लंबे समय तक kernel से अलग एक project के रूप में बनाए रखा जा सका, और जिन्हें इसकी ज़रूरत थी वे इसे लेकर kernel पर apply करके इस्तेमाल कर सकते थे.

 
ilsubyeega 2025-02-21

मैं Rust उपयोगकर्ता हूँ, लेकिन r/rust पर hgwxx7_ की टिप्पणी ने मुझ पर गहरा प्रभाव छोड़ा1.

मुझे लगता है कि Greg यहाँ जिस चीज़ को बहुत अच्छी तरह दिखाते हैं, वह है technical leadership। Leadership का मतलब सही होना नहीं है। वह सही हैं, लेकिन बात वह नहीं है।

Leadership का मतलब है लोगों को उस रास्ते पर साथ लेकर चलना, जिसे वह सबसे बेहतर मानते हैं। वह असहमति रखने वाले maintainers पर दबाव नहीं डालते, न उन्हें डाँटते हैं और न ही मजबूर करते हैं। इसके बजाय, वह पहले दो भाषाओं वाले code base को maintain करने को लेकर उनकी पूरी तरह वाजिब चिंताओं को स्वीकार करते हैं। यह अच्छी बात है, क्योंकि इस मामले में वे सही हैं; चीज़ें आसान होने से पहले उनकी ज़िंदगी सचमुच कठिन होगी।

फिर वह अंत में प्रेरणादायक स्वर अपनाते हैं और बताते हैं कि वे इससे कहीं कठिन काम पहले ही कर चुके हैं, और यह उनके सामर्थ्य के पूरी तरह भीतर है। वह बहुत सहज तरीके से उन्हें R4L devs का स्वागत करने के लिए प्रोत्साहित करते हैं।

Leadership की यह बिल्कुल masterclass है।
जब दूसरे maintainers इसे पढ़ेंगे, तब वे आश्वस्त होंगे या नहीं, यह मुझे नहीं पता। लेकिन मेरे लिए इससे अधिक प्रभावशाली प्रस्तुति की कल्पना करना मुश्किल है।

 
gurugio 2025-02-21

मुझे याद है कि जब stable version में backport की ज़रूरत पड़ती थी और मैं उनसे संपर्क करता था, तो वे अपनी उस व्यस्तता के बीच भी अच्छी तरह जवाब देते थे।

 
codemasterkimc 2025-02-21

"Rust सही जवाब नहीं है, लेकिन Java और Python की तुलना में सही जवाब के ज़्यादा करीब है" -codemaster kimc-

 
GN⁺ 2025-02-21
Hacker News की राय
  • अगर Rust bindings हों, तो kernel का internal ABI स्वतंत्र रूप से evolve नहीं कर सकता, और project के C core और Rust पक्ष में बंट जाने का जोखिम है। हालांकि, अगर internal API स्थिर हो जाए, तो इससे Linux को लाभ हो सकता है
  • community और लोग ही मुख्य मुद्दा हैं। अगर अभी kernel पर काम करने वाले लोग इस दिशा को पसंद नहीं करते, तो यह बड़ी समस्या है
  • ऐसा लगता है कि Linux leadership लोगों से जुड़े मुद्दों पर ध्यान केंद्रित नहीं कर रही है। यह सवाल है कि कहाँ सबूत है कि अभी kernel development करने वाले लोग इस दिशा से सहमत हैं
  • कुछ लोगों का मानना है कि Rust को अपनाने से मिलने वाले लाभ से ज्यादा दर्द है। उनका मानना है कि दूसरे तरीकों से भी वही लाभ मिल सकते हैं
    • उदाहरण के लिए, bounds checking और RAII जैसी सरल allocation/deallocation simplification, Rust के बिना भी संभव हो सकती है
    • Clang को अनिवार्य compiler बनाकर और ऐसे extensions अपनाकर, यह असर अधिक आसानी से हासिल किया जा सकता है
  • अगर नया code/driver Rust में लिखा जाए, तो इस तरह के bug नहीं होंगे। यह सभी के लिए लाभकारी है
  • ज़्यादातर लोग memory safety चाहते हैं, लेकिन समग्र maintainer बनना नहीं चाहते
  • project का वास्तविक लक्ष्य internal kernel API surface को modernize करना है। इस API को Rust में लिखना कितना टिकाऊ है, यही प्रगति मापने का सबसे अच्छा पैमाना है
  • पिछले 15 वर्षों में लगभग सभी kernel bug fixes और security issues देख चुके व्यक्ति के रूप में, अधिकांश bug C के छोटे corner cases से पैदा होते हैं। Rust में ये समस्याएँ गायब हो जाती हैं
  • अगर नया code/driver Rust में लिखा जाए, तो इस तरह के bug नहीं होंगे। C++ यह लाभ नहीं देता
  • Rust, kernel API define करते समय गलती करना लगभग असंभव बना देता है। इससे Linux कुल मिलाकर बेहतर बनता है
  • Rust bindings जादू जैसी लगती हैं, लेकिन इन्हें सीखने और developers के साथ सहयोग करने की इच्छा है
  • Rust सभी समस्याओं का silver bullet नहीं है, लेकिन कई हिस्सों में मदद करता है
  • Linux वह tool है जिससे हर कोई समस्याएँ हल करता है। जब developers hardware के लिए code लिखें, तो वे चाहते हैं कि इस तरह के bug न हों
  • mixed-language codebase का maintenance कठिन होता है, लेकिन हम kernel developers हैं। हमें नए ideas स्वीकार करने चाहिए और साथ मिलकर सफल होने की कोशिश करनी चाहिए
  • इस चर्चा को आगे बढ़ाने के लिए यह बयान ज़रूरी था
  • तकनीकी फायदों पर ध्यान दिया जा रहा है, लेकिन नई programming language/toolchain सीखने में लगने वाली मेहनत का सही आकलन नहीं हो रहा
  • नई programming language में महारत हासिल करना आसान नहीं है, और कुछ maintainers व्यक्तिगत रुचि/प्रेरणा के कारण ऐसा नहीं चाह सकते
  • C++ language committee की समस्याएँ यह संकेत देती हैं कि हर किसी को जितनी जल्दी हो सके उस language को छोड़ देना चाहिए
 
hbahk42 2025-02-22

क्या ऐसी नफ़रत भरी टिप्पणियों की रिपोर्ट नहीं की जा सकती?

 
kodingwarrior 2025-02-22

सहमत हूँ।