GNU coreutils का क्रॉस-प्लैटफ़ॉर्म Rust पुनर्लेखन

मूल लेख ↗ Hacker News चर्चा ↗

GNU coreutils को Rust में पुनः लागू करने का एक लंबे समय से चल रहा प्रयास फिर चर्चा में है, क्योंकि इसकी compatibility test suite अब GNU के अधिकांश tests पास कर रही है। टिप्पणीकार संभावित लाभों — memory safety, साफ़ आधुनिक कोड, आसान cross-compilation, और एक permissive MIT license जो GPL obligations से बचाता है — को लेकर बहस करते हैं, जबकि longevity, सूक्ष्म असंगतियों, और यह कि non-GPL rewrite copyleft के लक्ष्यों को कमजोर करता है या नहीं, जैसी चिंताएँ भी उठती हैं। यह परियोजना Windows, macOS, और embedded environments के लिए विशेष रूप से आकर्षक मानी जाती है, लेकिन कई लोगों को संदेह है कि निकट भविष्य में यह mainstream Unix systems पर GNU coreutils की जगह ले लेगी।

परियोजना के लक्ष्य और स्थिति

  • uutils एक दशक पुराना Rust प्रोजेक्ट है, जिसका उद्देश्य GNU coreutils का एक क्रॉस-प्लैटफ़ॉर्म, ड्रॉप-इन विकल्प बनना है।
  • GNU व्यवहार से होने वाले अंतर को स्पष्ट रूप से बग माना जाता है; साझा टेस्ट सूट दिखाता है कि अब पास होने वाले टेस्ट, फेल होने वालों से काफ़ी अधिक हैं।
  • कई टिप्पणीकार कहते हैं कि “अंतिम 10% में 50% समय लगता है” और उम्मीद करते हैं कि लोग इसे सिस्टम डिफ़ॉल्ट के रूप में इस्तेमाल करने से पहले लगभग-पूर्ण समानता का इंतज़ार करेंगे।

अपनाना और उपयोग के मामले

  • कई लोगों को संदेह है कि पारंपरिक Unix/Linux वितरण जल्द ही बदलाव करेंगे, क्योंकि GNU coreutils का 30+ साल का रिकॉर्ड और व्यापक उपयोग है।
  • अन्य लोग स्पष्ट उपयोग-क्षेत्र देखते हैं: macOS (बहुत पुराने BSD टूल्स से बचने के लिए), Windows (जहाँ WSL/VMs/Cygwin असुविधाजनक, धीमे या प्रतिबंधित हैं), embedded systems, और NixOS जैसी सेटअप्स जहाँ coreutils बदलना आसान है।
  • कुछ परिवेशों में Rust का cross-compilation, C की तुलना में आसान माना जाता है।

Rust बनाम C: सुरक्षा, रखरखाव, प्रदर्शन

  • Rust के पक्ष में तर्क: memory safety, बेहतर integer/UTF-8 handling, अधिक मज़बूत tooling, और “ancient, terse, clever” GNU C sources की तुलना में अधिक सुलभ आधुनिक कोड। कुछ लोग embedded/robotics कोड को Rust में ले जाने के बाद वास्तविक दुनिया के बग्स में बड़े पैमाने पर कमी की रिपोर्ट करते हैं।
  • संदेह करने वाले नोट करते हैं कि coreutils में गंभीर CVEs बहुत कम हैं और ज़्यादातर non-memory bugs हैं; उनके लिए यहाँ memory issues से अधिक logic/semantic bugs महत्वपूर्ण हैं।
  • BusyBox/Toybox और plain C की तुलना में binary size और portability को लेकर चिंताएँ उठाई जाती हैं।

लाइसेंसिंग: MIT बनाम GPL

  • MIT license एक बड़ा विवाद बिंदु है।
  • आलोचक इसे GPL “virality” से बचने की कोशिश मानते हैं, जिससे corporations बिना अपने बदलाव साझा किए core tools को integrate और extend कर सकती हैं, और इसे copyleft से दूर जाने की व्यापक, चिंताजनक प्रवृत्ति का हिस्सा मानते हैं।
  • समर्थकों का तर्क है कि permissive licenses अपनाने में आसानी देती हैं, मौजूदा प्रथा को दर्शाती हैं (कई महत्वपूर्ण घटक पहले ही BSD/MIT/Apache हैं), और GPL obligations (विशेषकर v3/AGPL) कंपनियों पर वास्तविक बोझ हैं।
  • इस पर बहस होती है कि क्या copyleft वास्तव में उपयोगकर्ताओं और छोटी कंपनियों के लिए बेहतर परिणाम देता है, और क्या GPL के तहत योगदान देने में corporations की अनिच्छा उचित है।

कानूनी और clean-room चिंताएँ

  • कुछ लोग सवाल उठाते हैं कि GPL’d coreutils का like-for-like MIT पुनर्लेखन वास्तव में स्वतंत्र है भी या नहीं, पहले के copied identifier names के निष्कर्षों और “no one looked” की गारंटी देने की कठिनाई की ओर इशारा करते हुए।
  • अन्य लोग ज़ोर देते हैं कि स्वतंत्र पुनर्निर्माण कानूनी है; clean-room एक defense है, आवश्यकता नहीं, और इस संदेह को FUD कहते हैं।
  • कुल मिलाकर, कानूनी स्थिति पर बहस जारी है लेकिन थ्रेड में यह अनिर्णीत है।

व्यापक चिंतन

  • चर्चा परियोजना की longevity (Lindy-effect तर्क बनाम उस तर्क की आलोचना), ऐतिहासिक रूप से size-optimized C और आधुनिक readability के बीच tradeoff, और ऐसे प्रोजेक्ट्स को system tools के लिए Rust की “नई C” के रूप में उपयुक्तता की कसौटी के तौर पर इस्तेमाल करने तक जाती है।