एक पीढ़ी बाजार में खो गई

"गुणवत्ता केवल तब आती है जब कोई व्यक्ति व्यक्तिगत रूप से जिम्मेदार होता है । "
- फ्रेडरिक एफ ब्रुक्स



हाय, हेब्रा!

मैं पॉल-हेनिंग काम्प द्वारा निबंध " ए जनरेशन इन द बाज़ार " का एक नि: शुल्क अनुवाद आपके ध्यान में लाता हूं, जो हमें आईटी पेशेवरों की पीढ़ी के दुखद भाग्य के बारे में बताता है जो डॉट-कॉम बूम के दौरान बड़े हुए, साथ ही यूनिक्स में मूलभूत समस्याएं जो सीधे सॉफ्टवेयर की गुणवत्ता और पोर्टेबिलिटी को प्रभावित करती हैं। । पहले बातें पहले।

कैथेड्रल और बाज़ार

अपने लेख में, लेखक एरिक रेमंड के निबंध " द कैथेड्रल एंड द बाज़ार " में वर्णित कैथेड्रल और बाज़ार के रूपक का उपयोग करता है, मुझे निबंध के किसी मान्यता प्राप्त अनुवाद के पाठ का एक अंश उद्धृत करना उचित लगता है:

--- उद्धरण की शुरुआत ---

लिनक्स एक अद्भुत प्रणाली है। किसने सोचा होगा कि कई हजार डेवलपर्स पूरे ग्रह में बिखरे हुए हैं और केवल इंटरनेट के माध्यम से सहयोग करने से एक विश्व स्तरीय ऑपरेटिंग सिस्टम बनाने में सक्षम होगा। किसी भी मामले में, मैंने ऐसा नहीं सोचा था। 1993 के प्रारंभ में जब तक लिनक्स मेरे ध्यान में आया, तब तक लगभग दस वर्षों तक मैं UNIX और ओपन सोर्स सॉफ्टवेयर विकसित करने में लगा रहा।

लिनक्स ने मेरे दिमाग को घुमा दिया है कि मुझे क्या पता है। मैंने सोचा था कि UNIX के लिए छोटे उपकरण विकसित करने में मुख्य बात उनकी तेजी से डिजाइन और वर्षों में विकसित प्रोग्रामिंग थी। और साथ ही, मेरा मानना ​​था कि जैसे-जैसे विकास की जटिलता बढ़ती है, एक अधिक केंद्रीकृत दृष्टिकोण की आवश्यकता होती है। मेरा मानना ​​था कि सबसे परिष्कृत सॉफ्टवेयर (जैसे ऑपरेटिंग सिस्टम या सिर्फ एमएसीएस जैसे महान उपकरण) विकसित करना एक कैथेड्रल के निर्माण की तरह होना चाहिए। ऐसे कार्यक्रमों को व्यक्तिवादी स्वामी या सख्त अलगाव में काम करने वाले जादूगरों के छोटे समूहों द्वारा बनाया जाना चाहिए, जो समय से पहले बीटा संस्करणों को रोकते हैं।

लिनुस टॉर्वाल्ड्स के विकास की शैली से मुझे बहुत आश्चर्य हुआ - लगातार रिलीज, सभी स्रोत ग्रंथों की उपलब्धता और विषम कार्यक्रमों के लिए सहिष्णुता। यह कैथेड्रल के मापा निर्माण के पूरी तरह से विपरीत है, लिनक्स समुदाय एक शोर बाजार की तरह अधिक है, जिसमें कई अलग-अलग दृष्टिकोण और दिशाएं हैं। यह तथ्य कि इस बाजार में एक सुसंगत स्थिर ऑपरेटिंग सिस्टम पैदा हुआ है, चमत्कार की तरह लगता है।
मैं हैरान था कि यह बाज़ार शैली अच्छी तरह से काम करती है। मैंने न केवल व्यक्तिगत परियोजनाओं के विकास में भाग लिया, बल्कि यह भी समझने की कोशिश की कि क्यों लिनक्स दुनिया में न केवल कोई विकार है, बल्कि इसके विपरीत यह एक गति से आगे बढ़ रहा है कि कैथेड्रल के निर्माता केवल ईर्ष्या कर सकते हैं।

1996 के मध्य तक, मुझे ऐसा लगने लगा कि मैं समझने लगा हूं। भाग्य ने मुझे अपने सिद्धांत का परीक्षण करने का एक बड़ा मौका दिया। यह एक ओपन सोर्स सॉफ्टवेयर डेवलपमेंट प्रोजेक्ट था जिसे मैंने जानबूझकर बाज़ार शैली में चलाया था। इस परियोजना की सफलता सभी अपेक्षाओं को पार कर गई।

--- अंत बोली ---
--- अनुवाद की शुरुआत ---

परिचय

तेरह साल पहले प्रकाशित एरिक रेमंड की पुस्तक, द कैथेड्रल एंड द बाज़ार ने नई शब्दावली के साथ हमारी शब्दावली का विस्तार किया है। इसके अलावा, उसने सॉफ्टवेयर विकास के कैस्केडिंग मॉडल के अंत और बड़ी सॉफ्टवेयर कंपनियों के युग के पतन की भविष्यवाणी की, जो कि फ्री सॉफ्टवेयर के लोकप्रिय आंदोलन के लिए धन्यवाद है।

किताब पढ़ने के बाद, मेरे पास सोचने के लिए कुछ था, लेकिन उसने मुझे मना नहीं किया। दूसरी ओर, मेरा ओपन सोर्स सॉफ़्टवेयर की दुनिया से सीधा संबंध है, इसलिए भले ही मैं किसी भी चीज़ में मदद नहीं कर पाऊं, यह बहुत अच्छा होगा यदि लेखक सही था।

एक अन्य पुस्तक, जो इस गर्मी में समुद्र के किनारे मेरे घर में हुई, विचारों को भी प्रेरित करती है। यह रेमंड की पुस्तक की तुलना में स्पष्ट रूप से गहरा है (वैसे, सकारात्मक रूप से इसे संदर्भित करता है), यह फ्रेडरिक पी। ब्रूक्स का - "डिजाइन का डिजाइन" है । और कितनी बार मैंने समझौते में अपना सिर हिलाया, ब्रूक्स की लेखन शैली और सामग्री पेश करने की उनकी क्षमता का आनंद लिया, क्योंकि मैंने जो भी पढ़ा उससे मैं कई बार उदास हो गया।

डॉटकॉम युग

तेरह साल पहले, 90 के दशक के डॉट-कॉम युग के चरमोत्कर्ष पर पहुंच गया था, जब हर स्कूल के छात्र एक वेब प्रोग्रामर थे या हर कॉलेज ड्रॉपआउट पहले से ही अपने स्वयं के वेब स्टार्टअप के मालिक थे। मुझे एक वास्तविक खुशी मिली जब मैंने इन सलाग्स को मौलिक पेशेवर कौशल सिखाने की कोशिश की - स्वचालित तैनाती स्क्रिप्ट, संस्करण नियंत्रण प्रणाली और इतने पर। निस्संदेह, वास्तव में बहुत मजेदार नहीं था।
हम इस बात से इनकार नहीं कर सकते हैं कि संपूर्ण डॉट-कॉम युग सामान्य रूप से आईटी / सीएस उद्योग के लिए और विशेष रूप से यूनिक्स के लिए एक वास्तविक आपदा थी। सॉफ्टवेयर उत्पादों की गुणवत्ता पर हमला हुआ।

मुझे इस बात की सटीक जानकारी नहीं है कि डॉटकॉम की अवधि में आईटी उद्योग की मात्रा कितनी बढ़ी है। मेरा व्यक्तिगत मूल्यांकन यह है कि यदि हम उन व्यवसायों की संख्या की गणना करते हैं जो सामने आए हैं, कि हमारा आला परिमाण के दो आदेशों से बढ़ा है, अर्थात् 10,000% से अधिक ।

कंप्यूटर के साथ प्यार में पड़ना आसान है - लगभग कोई भी एक कार्य कार्यक्रम पर काम कर सकता है, जैसे लगभग कोई भी कुछ प्रयासों में, निश्चित रूप से एक बोर्ड को दूसरे को नाखून दे सकता है। समस्या यह है कि अगर हम घर के फर्नीचर बाजार पर विचार करते हैं तो एक-दूसरे के लिए ऐसे अनप्रोफेशनल नेल्ड बोर्ड का अनुपात बेहद छोटा है। और दो बोर्डों से कुर्सियों के एक अच्छे दिखने वाले सेट में जाने के लिए या एक अंतर्निहित अलमारी में प्रतिभा, अभ्यास और शिक्षा की आवश्यकता होती है। समान (10,000% - 100%) = 9,900% अतिरिक्त लोगों को आईटी उद्योग में प्रवेश करने पर न तो अनुभव था और न ही शिक्षा। और इससे पहले कि उन्हें इसे पाने का मौका मिलता, पार्टी खत्म हो गई और ज्यादातर बिना काम के ही रह गए।

मैं दया दिखाऊंगा और ध्यान दूंगा कि जो लोग इस पद पर रहते हैं, वे निस्संदेह सबसे प्रतिभाशाली और सबसे कुशल हैं, लेकिन इस मामले में भी इस बात से इनकार नहीं किया जा सकता है कि वे जीवन के अनुभव की कमी के कारण आईटी पेशेवर के रूप में सफल नहीं हुए।

बाजार शैली, जिसे ई। रेमंड ने वकालत की, " बस धोया गया ", प्री-डॉटकॉम अवधि से अच्छी तरह से डिजाइन किए गए कैथेड्रल के विपरीत, डॉट-कॉम के पतन के बाद गायब नहीं हुआ, दुर्भाग्य से, आज भी यूनिक्स अपने वजन के नीचे डूब रहा है।

यूनिक्स

मैंने अपना लैपटॉप अपडेट किया। पिछले 18 वर्षों से, मैं इस पर FreeBSD के देव संस्करण को चला रहा हूं और पूरे दिन के लिए स्रोत से न्यूनतम काम के माहौल का निर्माण कर रहा हूं, क्योंकि यह अराजकतावादी कचरा से तर्क और वास्तुकला का निर्माण करने की कोशिश कर रहा है, जिसे ई। रेमंड को बाजार कहा जाता है।

दूर से, ऐसा लगता है कि FreeBSD पोर्ट्स संग्रह एक बिट कार्ड है, जिससे FreeBSD उपयोगकर्ताओं के लिए कुछ भी खोजना आसान हो जाता है। व्यवहार में, यह "नक्शा", फिलहाल, बाजार में प्रत्येक तम्बू के संक्षिप्त विवरण के साथ 22,198 फाइलें हैं - जो अंदर है और इसके बारे में अधिक पढ़ने के लिए कुछ पंक्तियाँ हैं। 23,214 मेकफाइल्स भी हैं जो हमें बता रहे हैं कि हम प्रत्येक सॉफ्टवेयर को टेंट में क्या करते हैं। ये मेकफाइल्स हमें संभावित परिदृश्यों, विभिन्न वैकल्पिक विकल्पों और उनके डिफ़ॉल्ट मूल्यों के बारे में सूचित करने का प्रयास करते हैं। यह कार्ड प्रस्तावित हस्तशिल्प की वक्रता को शांत करने के लिए 24,400 पैच फाइलों के साथ आता है। हालांकि, वास्तव में, इनमें से अधिकांश पैच सॉफ्टवेयर पोर्टेबिलिटी मुद्दों को ठीक करने के लिए उपयोग किए जाते हैं।

अंत में, यह मानचित्र हमें यह बताता है कि यदि हम www / फ़ायरफ़ॉक्स स्थापित करना चाहते हैं, तो हमें सबसे पहले devel / nspr , सुरक्षा / nss , डेटाबेस / sqlite3 इत्यादि डाउनलोड करने होंगे। जैसे ही हम उन्हें नक्शे का उपयोग करते हुए पाते हैं, और फिर उनकी निर्भरता की तलाश करते हैं, और फिर पुन: उनके आश्रितों की निर्भरता की एक सूची प्राप्त करते हैं, तो हमें 122 पैकेजों के लिए खरीद की एक सूची मिलेगी जो हमें www / फ़ायरफ़ॉक्स प्राप्त करने से पहले निश्चित रूप से चाहिए।



हम सभी सॉफ्टवेयर विकास के लिए घटक उन्मुख दृष्टिकोण से प्यार करते हैं। लेकिन यहां तक ​​कि सबसे तुच्छ मामले में, हालांकि, कोड का पुन: उपयोग कार्यप्रणाली पूरी तरह से बाजार के लिए विदेशी है: फ्रीबीएसडी पोर्ट्स संग्रह में कार्यक्रमों में कम से कम 1,342 कॉपी-पेस्ट क्रिप्टोग्राफिक एल्गोरिदम शामिल हैं।

यदि पुन: उपयोग पद्धति की ऐसी उपेक्षा आत्मनिर्भर और स्वतंत्र सॉफ्टवेयर पैकेजों के एक तंत्र के रूप में सन्निहित थी, तो कोड के दोहराव और पैकेज प्रबंधन में आसानी के बीच एक समझौता होगा। लेकिन यह स्पष्ट रूप से हमारा मामला नहीं है - पैकेजों में एक तरह का सिस्टम बेतरतीब निर्भरता का पेचीदा जाल बनाता है, जिससे कोड का और भी अधिक दोहराव होता है और संसाधनों की बर्बादी होती है।

यहाँ एक विडंबनापूर्ण उदाहरण है: सैम लाइफ़र के ग्राफिक्स / लिबेटिफ लाइब्रेरी www / फ़ायरफ़ॉक्स के रास्ते में है, जो एक सामान्य निर्भरता श्रृंखला में उन 122 पैकेजों में से एक है। जबकि लक्ष्य कार्यक्रम - फ़ायरफ़ॉक्स वेब ब्राउज़र - टीआईएफएफ छवियों को प्रदर्शित नहीं कर सकता है । मैंने यह पता लगाने की कोशिश नहीं की कि 122 में से 10 पैकेज को पर्ल और 7 को पायथन की आवश्यकता क्यों है ; और उनमें से एक, devel / glib20 , दोनों भाषाओं की आवश्यकता है, मैं सोच भी नहीं सकता कि क्यों।

इस सूची में आगे ... यहां हमारे पास पीटर सिद्धांत है , जो लगता है कि "एक पदानुक्रमित प्रणाली में, कोई भी कर्मचारी अपनी अक्षमता के स्तर तक बढ़ जाता है", और विश्व स्तर पर इसे इस प्रकार तैयार किया जा सकता है: "किसी भी अच्छी तरह से काम करने वाली चीज या विचार का उपयोग तेजी से कठिन परिस्थितियों में किया जाएगा, जब तक कि एक आपदा का कारण होगा। ” सॉफ्टवेयर इंजीनियरिंग में एक विशेष मामले का उपयोग किया जाता है - "एक मरने वाली परियोजना, जो धीरे-धीरे अपने स्वयं के डेवलपर्स द्वारा समझी जाने वाली जटिल होती जा रही है।" आप देखते हैं, हमें मेक के 3 अलग-अलग संस्करणों की आवश्यकता है, एक मैक्रो प्रोसेसर (एम 4), कोडांतरक और अन्य दिलचस्प पैकेजों का एक गुच्छा। खाद्य श्रृंखला के अंत में, इसलिए बोलना, लिबटूल टूल है, जिसे इस तथ्य को छिपाने के लिए डिज़ाइन किया गया है कि UNIX में डायनामिक लाइब्रेरी ( साझा लाइब्रेरी ) बनाने के लिए एक मानकीकृत विधि नहीं है।

सभी nyxes के लिए इस विधि को मानकीकृत करने के बजाय - उदाहरण के लिए, इसे ld (1) कमांड के लिए एकल ध्वज के रूप में लागू करना - पीटर प्रिंसिपल की भागीदारी के साथ, यह एक अलग libtool योग्यता के परिणामस्वरूप हुआ। और इस मामले में, इस सिद्धांत को अच्छी तरह से लागू किया गया है - डेवेल / लिबेटूल के स्रोत कोड में 414,740 लाइनें हैं। इस कोड का आधा परीक्षण है, जो आम तौर पर प्रशंसनीय है, लेकिन वास्तव में वे पीटर सिद्धांत के परिणाम हैं: परीक्षण उन समस्याओं की पहचान करने के लिए एक जटिल प्रणाली की कार्यक्षमता की कुशलता से जांच करते हैं जो कि उत्पन्न नहीं होनी चाहिए।

कोड की उन पंक्तियों के 31,085 से भी अधिक कष्टप्रद रूप से - एक अपठनीय अनाड़ी शेल स्क्रिप्ट जिसे कॉन्फिगरेशन कहा जाता है । विचार यह है कि यह कॉन्फ़िगर स्क्रिप्ट लगभग 200 स्वचालित परीक्षण करता है ताकि उपयोगकर्ता को libtool के साथ मैनुअल डिस्सैम्ड के साथ बोझ न हो। यह एक कमबख्त बेवकूफ विचार है, जिसकी 80 के दशक में पूरी तरह से आलोचना की गई थी, जब यह पहली बार सामने आया था। बेवकूफ क्योंकि यह स्रोत कोड को पोर्टेबल होने का दावा करने की अनुमति देता है, वास्तव में वास्तव में पोर्टेबिलिटी प्रदान करने के बजाय, एक कॉन्फ़िगर स्क्रिप्ट के पीछे एक मुखौटा के रूप में छुपाता है।
यह बेतुका है कि कॉन्फ़िगर वाला विचार बच गया।

1980 में, हमने कई UNIX कार्यान्वयन देखे: Cray-1s 24-बिट पॉइंटर्स के लिए समर्थन के साथ, Amdahl UTS (IBM मेनफ्रेम के लिए UNIX), कम या ज्यादा सक्षम SysV + BSD को मिनीकंप्यूटर निर्माताओं, डेटा-जनरल जैसी कंपनियों के अंडर-UNIX शिल्प से पूरी तरह लागू किया गया। , यहां तक ​​कि एक पूर्ण UNIX क्लोन - मार्क विलियम्स से सुसंगत ।

उस समय की स्क्रिप्ट्स को हाथ से लिखा गया था और यह पता लगाने जैसे कार्य किए गए थे - यह एक BSD या SysV- जैसे UNIX है, फिर उपयुक्त मेकफाइल और शायद कुछ .h की जोड़ी को सही जगह पर कॉपी करें। बाद में कॉन्फ़िगर स्क्रिप्ट अधिक महत्वाकांक्षी बन गईं, जो पहले से ही दूर से पीटर सिद्धांत के लिए एक मिसाल के रूप में पहचानी जा सकती हैं। लेकिन UNIX को मानकीकृत करने और इन लिपियों की आवश्यकता को समाप्त करने के बजाय, कुछ बुद्धिमान व्यक्ति ने स्वचालित रूप से कॉन्फ़िगर स्क्रिप्ट उत्पन्न करने के लिए एक ऑटोकॉन्फ़ प्रोग्राम लिखा।

आज की UNIX / Posix जैसी प्रणालियाँ, यहां तक ​​कि IBM z / OS मेनफ्रेम के संस्करण पर विचार करते हुए, 1980 से एक पर्यवेक्षक के दृष्टिकोण से लगभग समान हैं। Libtool स्क्रिप्ट के लिए कॉन्फ़िगर कोड की 31,085 पंक्तियाँ अभी भी हैं जो <sys / stat.h> और <stdlib.h> के लिए जाँच करते हैं, भले ही जिन nicks में उनकी कमी थी उनमें libtool चलाने के लिए पर्याप्त मेमोरी नहीं थी ; या डिस्क स्पेस 16 एमबी के लिबेटूल सोर्स कोड को फिट करने के लिए।

यह कैसे हुआ?

खैर, उन कारणों के लिए जो कभी किसी को परेशान नहीं करते हैं, ऑटोकॉन्फ़ कार्यक्रम को एंटीडीलुवियन मैक्रो भाषा एम 4 में लिखा गया था, जिसके कारण परीक्षण दिखाई दिए:



कहने की जरूरत नहीं है, पर्याप्त प्रोग्रामर कभी भी स्वेच्छा से इसमें नहीं फंसना चाहते हैं, भले ही उनके पास कौशल था, इसलिए ये ऑटोकॉन्फ़ स्क्रिप्ट कॉपी-पेस्ट का उपयोग करके बनाई जाती हैं, अक्सर "मानक परीक्षण" को कवर करने वाले अत्यधिक बोल्ड मानक मैक्रोज़ के बीच खो जाते हैं, जिसके बारे में मैं ऊपर उल्लेख किया है।
हां, बहुत परीक्षण जो संगतता समस्याओं की जांच करते हैं जो किसी ने 20 वर्षों तक अनुभव नहीं किया है।

यह भी बताता है कि लिबटूल कम से कम 26 अलग-अलग फोरट्रान कंपाइलर नामों की जांच क्यों करता है जो अभी मेरे सिस्टम पर मौजूद नहीं हैं, और फिर इन 26 गैर-मौजूद संकलकों में से 26 का परीक्षण यह पता लगाने के लिए करता है कि -g ध्वज का समर्थन करता है।

यह रेमंड द्वारा अपनी पुस्तक में प्रशंसा की गई बाजार की दुखद वास्तविकता है। हैक्स के माध्यम से पुराने सड़े हुए का एक गुच्छा, जिसे एक पीढ़ी के अज्ञात लोगों ने ला "आईटी पेशेवरों" से उबला हुआ है। आप उनके कान में "आईटी आर्किटेक्चर!" चिल्ला सकते हैं, लेकिन वे अभी भी नहीं सुनेंगे।

आज यह विश्वास करना मुश्किल है, लेकिन इस कूड़ेदान के तहत जो आंदोलन को बाधित करता है, सुंदर यूनिक्स कैथेड्रल के खंडहर हैं, जो डिजाइन की सादगी, कार्यों की पर्याप्तता, सुरुचिपूर्ण निष्पादन के लिए योग्य हैं ... सब कुछ खराब है, दूसरे शब्दों में।

ब्रुक्स की महान बातों में से एक है "गुणवत्ता केवल तभी आती है जब कोई व्यक्ति व्यक्तिगत रूप से जिम्मेदार होता है।" मुझे आश्चर्य है कि ब्रूक्स इस कथन के लिए एक उदाहरण के रूप में यूनिक्स का हवाला नहीं देता है, क्योंकि हम लगभग सर्जिकल सटीकता के साथ उस क्षण का निर्धारण कर सकते हैं जब यूनिक्स ने टुकड़े करना शुरू कर दिया था - 90 के दशक की शुरुआत में एटी एंड टी ने यूनिक्स को आवंटित किया और इसे नोवेल को सभी अधिकार बेच दिए, जिससे दूर हो गए। अपने वास्तुकारों पर प्रणाली। (डेनिस रिची ने रोटी के लिए आत्मा की बिक्री के साथ इस सौदे की तुलना की - लगभग। अनुवादक )।

अन्य लोग हाल ही में ब्रूक्स के समान निष्कर्ष पर आए हैं। कुछ ने एक तरह की पवित्रता को लागू करने या यहां तक ​​कि कानून को औपचारिक रूप से लागू करने की कोशिश की, तकनीकी मानकों के रूप में, बाजार में व्यवस्था और संरचना को बहाल करने की उम्मीद की। सभी प्रयास शानदार रूप से विफल रहे, क्योंकि बाजार में खो जाने वाली डॉट-वंडरकंड की पीढ़ी ने कैथेड्रल को कभी नहीं देखा था और इसलिए, यह भी कल्पना नहीं कर सकते कि हमें इन कैथेड्रल की आवश्यकता क्यों और कैसे होती है।

यह निश्चित रूप से एक दुखद विडंबना है। जिनके लिए ब्रूक्स के डिजाइन के डिजाइन समर्पित हैं, वे इसे पूरी तरह से समझ में नहीं पाएंगे। खैर, उन कामरेडों के लिए जिन्होंने कम से कम एक बार सोचा था कि वेब ब्राउजर बनाने के लिए 26 फोरट्रान कंपाइलरों की जांच के लिए शेल स्क्रिप्ट उत्पन्न करने के लिए ऑटोकॉफ़ को कॉन्फ़िगर करने के लिए एम 4 मैक्रोज़ का उपयोग करना किसी तरह गधे के माध्यम से होता है, ब्रूक्स ने एक सुविचारित सुझाव दिया आशा है कि हमारे पास सब कुछ ठीक करने का मौका होगा।

--- अनुवाद का अंत ---

इसे ठीक करने का मौका

• "थर्ड पार्टी एप्लिकेशन इंस्टॉल करने के लिए उबंटू अपना खुद का पैकेज प्रारूप विकसित कर रहा है" ;
• लेख "क्यूटी बिल्ड सिस्टम: बिल्ड लाइफबॉय " - मैं इसे पढ़ने की सलाह देता हूं, आलोचना करने के लिए कई संदर्भ हैं, क्यूबीएस के साथ काम करने के अच्छे उदाहरण हैं।

UPD: मुझे अनुवाद में सुधार और पाठ में त्रुटियों को सुधारने के लिए सभी चैनलों पर सलाह मिलती है, मैं उन सभी का आभार व्यक्त करता हूं जिन्होंने ऐसा करने के लिए समय लिया। आपका धन्यवाद
~ एक्सलैब