- Direct Memory Access API को लागू करने वाला Rust code Linux kernel repository में pull request के रूप में भेजा गया।
- Linux kernel के मध्य-स्तरीय maintainer Christoph Hellwig ने यह कहते हुए इसे अस्वीकार कर दिया कि Rust code को Linux kernel में नहीं लाया जाना चाहिए, और यहीं से विवाद शुरू हुआ।
- विवाद का आकार बढ़ता गया और Christoph Hellwig ने Rust की तुलना cancer cells से की।
- Asahi Linux के प्रमुख Hector Martin ने इस cancer cells वाली टिप्पणी का विरोध किया और सोशल मीडिया पर Linus Torvalds को इसमें घसीटते हुए तीखी आलोचना की।
- Linus Torvalds ने Hector Martin से कहा, "समस्या आप खुद हैं" और चेतावनी दी कि "सोशल मीडिया पर brigading मत कीजिए।"
- फिलहाल Hector Martin ने Apple Arm-compatible hardware को support करने वाले upstream Linux code maintainer पद से इस्तीफा देने का अनुरोध किया है।
28 टिप्पणियां
सारांश में सिर्फ हुई घटनाओं का ही ज़िक्र है, लेकिन मूल लेख (यह कोरियाई में है) के आखिर में इस घटना को बेहतर समझने के लिए दो अतिरिक्त पृष्ठभूमि जानकारियाँ भी जोड़ी गई हैं।
मुझे लगता है कि प्रोजेक्ट को एक ही भाषा में मैनेज करना बेहतर है, लेकिन उससे अलग इसे अपने सहकर्मी को समझाने का तरीका वाकई सबसे खराब है।
सत्ता के बल पर किसी को घुटने टेकने पर मजबूर करना बेतुका है।
यह उस PR की मेल थ्रेड है:
https://lwn.net/ml/all/…
ऐसा नहीं लगता कि इसमें DMA implementation को बदला गया है, या DMA API को सीधे छुआ गया है; यह तो Rust से DMA API तक पहुंचने के लिए FFI binding लिखने वाला PR लगता है।
ऐसे PR को
No rust code in kernel/dma, please.जैसी एक-पंक्ति की प्रतिक्रिया देकर ठुकरा दिया गया, https://lwn.net/ml/all/20250108135951.GA18074@lst.de/फिर जब पूछा गया कि ऐसा कैसे किया जाए, तो जवाब मिला
Keep the wrappers in your code instead of making life painful for others.https://lwn.net/ml/all/20250108151858.GB24499@lst.de/(जैसा कहा गया था, वैसा ही किया गया था। PR ने
kernel/dmaनहीं, बल्किrust/kernelsubtree को संशोधित किया था।)बेशक, FFI binding जुड़ने पर DMA API बदलने की स्थिति में Rust FFI binding को भी अपडेट करना पड़ेगा—यह एक अतिरिक्त बोझ हो सकता है,
लेकिन जब Rust पर काम करने वाली तरफ ने खुद कहा था कि वे इसे ठीक से संभाल लेंगे, तब उस tree के प्रभारी भी नहीं होने वाला कोई व्यक्ति इस तरह के रवैये से विरोध करे, क्या यह सही है—इस पर मुझे संदेह है।
(Christoph Hellwig
kernel/dmaके maintainer हैं: https://docs.kernel.org/process/maintainers.html#dma-mapping-helpers)इसीलिए शायद Hector Martin ने Linus को इस थ्रेड में खींच लिया:
https://lwn.net/ml/all/2b9b75d1-eb8e-494a-b05f-59f75c92e6ae@marcan.st/
लेकिन ठीक उससे पहले वाली थ्रेड में जो बात हुई, वह काफ़ी दिलचस्प है,
बात यह थी कि अगर API में breaking change आ जाए और Rust टीम उसका जल्दी जवाब न दे पाए, तो build टूट जाएगा और Linus PR स्वीकार नहीं करेंगे।
किसी breaking change बनाने वाले module और किसी दूसरे module के बीच की समस्या के रूप में देखें, तो मुझे तो Rust वाला पक्ष बेहतर लगता है।
मान लीजिए x module ने breaking change किया, और y module तुरंत उसके मुताबिक़ ढल नहीं पाया,
Linux kernel में Rust के जो हिस्से
unsafeइस्तेमाल करते हैं, वे ज़्यादातर C के साथ wrapping वाले हिस्से हैं.इसके अलावा कुछ hardware control वाले हिस्से भी हैं जहाँ memory को सीधे संभालना पड़ता है, लेकिन वे बहुत कम हैं.
जहाँ Rust लागू होता है, वह driver development है. Memory management या block layer जैसी kernel की अपनी चीज़ों को छूने की न ज़रूरत है और न ही ऐसा किया जा सकता है.
Kernel के अपने code से कहीं ज़्यादा code driver code होता है. और जिन जगहों पर समस्याएँ आती हैं, वे भी ज़्यादातर driver code ही होती हैं.
मेरा मानना है कि driver development, C की तुलना में ज़्यादा memory safety और बेहतर security वाली भाषा में होना चाहिए.
वह Rust हो या Zig, या कुछ और, यह मैं नहीं जानता.
मैं भी इस बात से सहमत हूँ कि Rust सामान्य application development के लिए ज़रूरत से ज़्यादा complex है और C language developers के लिए उसे जल्दी सीखना भी कठिन है.
फिर भी, भाषा कोई भी हो, मेरी इच्छा है कि कम-से-कम driver development तो modern language में बदले.
मैंने अपनी पिछली कंपनी में कुछ हज़ार lines से भी कम वाले एक driver को develop और stabilize करने में लगभग 7 साल लगाए थे; इसे पूरी तरह सरल बनाकर नहीं कहा जा सकता, लेकिन उनमें से लगभग 3 साल शायद सिर्फ debugging में गए.
उनमें से ज़्यादातर memory-related bugs थे. Deadlock जैसी logical errors बहुत कम थीं.
इतने बड़े प्रोजेक्ट को अपनी भाषा के टेस्टबेड की तरह इस्तेमाल करना अच्छा नहीं लगता।
बात न बने तो पुराने दिनों की तरह फिर से fork कर देना भी ज़रूरी है।
पूरे डिवाइस इकोसिस्टम को संभालने वाले kernel में rust का इस्तेमाल करके भी, जैसे ही
unsafeलिखना शुरू करते हैं, वह बस ऐसा कोड बन जाता है जिसमें पढ़ने में मुश्किल पैदा करने वाली समस्याएँ होती हैं।यह कोई ऐसा प्रोजेक्ट भी नहीं है जिसमें 0.91 0.92 0.99 0.991 जैसी main release ही न हों; समझ नहीं आता कि जो हिस्से अच्छी तरह चल रहे थे उन्हें क्यों port किया जा रहा है।
कोई बड़ा bug निकल आया हो और उसे ठीक करते-करते सुरक्षित रूप से बदल दिया गया हो, ऐसा भी नहीं है।
यह PR पोर्टिंग नहीं है। यह ऐसा PR है जिसमें Rust की तरफ FFI bindings जोड़ी गई हैं ताकि मौजूदा DMA API को Rust-आधारित modules में भी इस्तेमाल किया जा सके जो नए सिरे से लिखे जा रहे हैं। और DMA के प्रभारी ने उसी को रोक दिया।
अफ़सोस है कि लेख के मुख्य भाग में उद्धृत मूल पाठ नहीं था। जिज्ञासा में मैंने मूल पाठ ढूँढकर पढ़ा, और भले ही मैं इसे पूरी तरह सही समझ नहीं पाया हूँ, लेकिन सिर्फ़ मूल पाठ की तरह सीधी बात कहना मुश्किल लगता है क्योंकि इसके पीछे की कहानी काफ़ी ज़्यादा है।
लेख का शीर्षक मूल नाम में बदल दिया गया है।
प्रोसेस करने के लिए धन्यवाद
बड़े C codebase में Rust को जोड़ना उतना मज़ेदार नहीं निकला, जितना सोचा था। memory safety बढ़ाने की बात करें तो आखिरकार
unsafeक्षेत्र वैसे भी बड़ा हो जाता है, इसलिए इसकी वास्तविक उपयोगिता बहुत ज़्यादा नहीं लगती.... और यह Rust के इस्तेमाल वाले हिस्से के बढ़ने से आगे कोई खास मायने भी नहीं रखता.... इसलिए मौजूदा C developers की तरफ से इसका विरोध होना एक स्वाभाविक क्रम लगता है। शायद सच में शुरू से Rust पर बने kernel project पर ध्यान देना बेहतर हो सकता है।अरे, मुख्य लेख की quality उम्मीद से बेहतर है। मज़े से पढ़ा, अच्छा लगा।
टॉर्वाल्ड्स ने जो कहा कि समस्या आप हैं, उसका आशय Rust अपनाने से अलग यह था कि तकनीकी समस्याओं का समाधान SNS नहीं हो सकता, लेकिन केवल इस सारांश को देखें तो गलतफ़हमी की गुंजाइश लगती है।
हेक्टर मार्टिन के लिए यह एक मजबूरी भरा फैसला था.
Linux के मिडल मैनेजर सभी C एक्सपर्ट्स से भरे हुए हैं, तो फिर कम संख्या वाले Rust डेवलपर्स की राय जैसी चीज़ को वे भला क्यों स्वीकार करते?
https://youtu.be/opTJH76wJxs?si=WHR0_1uPpSlpDTHr यह दिखाता है कि यह कैसे एक विवाद में बदल गया।
क्या Torvalds भी Rust को अनुमति नहीं दे रहे थे?
टॉरवाल्ड्स ने उस बहस में Rust के बारे में एक शब्द भी नहीं कहा।
जब तकनीकी राय को लेकर विवाद हो, तो चर्चा तकनीकी आधार पर होनी चाहिए,
SNS पर जनमत बनाकर विवाद खत्म करने की कोशिश नहीं करनी चाहिए।
अगर तुम लोग इतने ही काबिल हो, तो kernel को fork करके पूरा का पूरा Rust में लिखो। कैंसर की तरह धीरे-धीरे अंदर घुसने की कोशिश मत करो। लगता है, ऐसे विचार बहुत हैं।
अगर वह कोड
rustमें इस्तेमाल करना आसान बनाने के लिएkernel/dmaतरफ बदलाव करने वाला कोड होता तो बात अलग थी,वह
kernel/dmaको wrap करने वाली FFI layer कोrust/kernel/dmaमें जोड़ने वाला कोड था।मूल कोड को छुआ ही नहीं गया था।
असल में मुद्दे का सार यह है:
Rust में बनाए गए आधिकारिक DMA FFI का गलत इस्तेमाल करके फिर मुझसे सवाल पूछने आने वाले मामले मुझे पसंद नहीं हैं। बस इतना ही...
और फिर इसके बाद यह कहना कि हर driver अपनी तरफ से FFI खुद बना ले, आगे-पीछे से मेल न खाने वाली बात थी।
वह Redox है। अभी कुछ हिस्सों का समर्थन नहीं है, इसलिए शायद Linux की ओर जा रहे होंगे...
https://vt.social/@lina/113064510447670892
आपने जो लिखा है, वह पूरी तरह Helwig के बयान जैसा ही लगता है, लेकिन मुझे नहीं पता कि क्या ऐसी राय को बहुमत की राय माना जा सकता है।
नमस्ते। अच्छी पोस्ट साझा करने के लिए धन्यवाद। मैंने इसे आनंद लेकर पढ़ा।
लेकिन मूल लेख को देखने और उसका शीर्षक जांचने के बाद, मुझे थोड़ा चिंता का विषय लगा, इसलिए यह टिप्पणी लिख रहा हूँ।
https://news.hada.io/guidelines
> मूल रूप से, कृपया पोस्ट का मूल शीर्षक ही लगाएँ, या शीर्षक का कोरियाई में अनुवाद करके पोस्ट करें।
ऐसा सुझाया गया है। और जब मैंने उस लेख की सामग्री पढ़ी, तो मुझे लगा कि "लिनक्स कर्नेल Rust विवाद, फिर से भड़क उठा।" के बजाय "Linus Torvalds: 'समस्या आप हैं'" जैसा शीर्षक, मूल शीर्षक की तुलना में भी लेख की सामग्री के बारे में गलतफ़हमी पैदा कर सकता है।
सारांश और लेख का परिचय साझा करने के लिए एक बार फिर धन्यवाद। आपका दिन शुभ हो।
सुपरमैन
संदर्भ के लिए रखूंगा।
'm 'b आपका दिन शुभ हो! आपकी वजह से अच्छा लेख पढ़ने को मिला, धन्यवाद। (__ )
ज़्यादा सटीक विवरण के लिए शीर्षक में अपनी तरफ़ से उपशीर्षक जोड़ना मेरी आदत थी, लेकिन वह शीर्षक दूसरे व्यक्ति को उपयुक्त नहीं लगा और मुझे यह भी नहीं पता था कि ऐसा एक नियम है। आगे से मैं मूल पाठ को जैसा है वैसा ही प्रस्तुत करूँगा।
मूल शीर्षक से तुरंत समझ में आ जाता है कि बात किस बारे में है, जबकि आपके बदले हुए शीर्षक से अनजाने में clickbait जैसा गलतफ़हमी पैदा होने की गुंजाइश लगती है। यह मेरी व्यक्तिगत राय है।
राय के लिए धन्यवाद।
मैंने सोचा कि Linus की टिप्पणी सबसे महत्वपूर्ण है, इसलिए उसे शीर्षक के रूप में रखा था, लेकिन लगता है कि वह काफी विकृत हो गई।
मैं निश्चित रूप से आगे से सावधान रहूंगा।