लिनस टोरवाल्ड्स लिनक्स कर्नेल कोड की पठनीयता को फिर से बनाने के लिए एआई का उपयोग करता है और गलती से तीन कमजोरियों का पता लगाता है जो दस वर्षों से अधिक समय से मौजूद हैं।

सार:

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

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

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

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

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

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

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

लिनक्स कर्नेल में एसोसिएटिव ऐरे एक डेटा संरचना है जिसका उपयोग कुंजी मान द्वारा डेटा को व्यवस्थित और पुनर्प्राप्त करने के लिए किया जाता है। सामान्य सरणियों के विपरीत, जो पूर्णांक सबस्क्रिप्ट के माध्यम से तत्वों तक पहुंचते हैं, सहयोगी सरणियाँ विशिष्ट कुंजियों के आधार पर संबंधित डेटा पा सकती हैं, इसलिए वे उन परिदृश्यों के लिए उपयुक्त हैं जिनके लिए लचीले अनुक्रमण और वस्तुओं के प्रबंधन की आवश्यकता होती है।

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

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

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

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

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

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

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

यह ध्यान देने योग्य है कि यह पहली बार नहीं है जब टोरवाल्ड्स ने हाल ही में लिनक्स कर्नेल विकास में एआई के उपयोग का सार्वजनिक रूप से प्रदर्शन किया है।

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

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

दोनों कार्यों के तकनीकी लक्ष्य अलग-अलग हैं, लेकिन वे एक समान विकास मॉडल का प्रतीक हैं: कर्नेल से परिचित इंजीनियर समस्या का निर्धारण करते हैं, फिर जटिल कार्यान्वयन को समझने, कोड लिखने या समायोजित करने में मदद करने के लिए एआई का उपयोग करते हैं, और अंत में परीक्षण के माध्यम से परिणामों को सत्यापित करते हैं।

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

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

साथ ही, AI-जनरेटेड कोड की भी सीमाएँ हैं। बड़े भाषा मॉडल जटिल नियंत्रण प्रवाह को गलत समझ सकते हैं, दुर्लभ सीमा स्थितियों को अनदेखा कर सकते हैं, या ऐसे संशोधनों का प्रस्ताव कर सकते हैं जो उचित प्रतीत होते हैं लेकिन वास्तव में शुद्धता की गारंटी नहीं देते हैं। ऑपरेटिंग सिस्टम कर्नेल के लिए, ये मुद्दे विशेष रूप से महत्वपूर्ण हैं क्योंकि कोड त्रुटियाँ सिस्टम स्थिरता, मेमोरी सुरक्षा और यहां तक ​​कि पूरे सिस्टम के विश्वसनीय संचालन को प्रभावित कर सकती हैं।

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

टोर्वाल्ड्स का एआई प्रोग्रामिंग टूल्स के प्रति हमेशा व्यावहारिक रवैया रहा है। उन्होंने विकास प्रक्रिया में मदद करने के लिए एआई के महत्व को पहचाना, लेकिन इस बात की वकालत नहीं की कि डेवलपर्स को बिना समीक्षा के मशीन-जनरेटेड कोड स्वीकार करना चाहिए। इस बार उन्होंने सार्वजनिक रूप से कहा कि वह कोड का विश्लेषण करने के लिए एलएलएम का उपयोग करते हैं, जिससे आगे पता चला कि एआई कर्नेल डेवलपमेंट टूलबॉक्स में एक सहायक विकल्प बन रहा है।

अधिक व्यापक रूप से, यह घटना बड़े सॉफ़्टवेयर प्रोजेक्टों को बनाए रखने में लंबे समय से चली आ रही कठिनाई पर भी प्रकाश डालती है: कोड को न केवल सही ढंग से चलाने की आवश्यकता है, बल्कि भविष्य के डेवलपर्स के लिए भी समझने योग्य होनी चाहिए। बुनियादी सॉफ़्टवेयर के लिए जिसे दस वर्षों या दशकों से भी अधिक समय से बनाए रखा गया है, पठनीयता स्वयं विश्वसनीयता को प्रभावित करने वाला एक महत्वपूर्ण कारक है।

यह संशोधन जटिल कार्यों को विभाजित करके कोड संरचना में सुधार करता है, और पहले छूटी हुई समस्याओं का पता लगाने के लिए परीक्षण का उपयोग करता है, जो कोड पठनीयता और दोष समस्या निवारण के बीच घनिष्ठ संबंध को प्रदर्शित करता है। जब प्रोग्राम तर्क स्पष्ट होता है, तो डेवलपर्स के लिए संभावित त्रुटि पथों की पहचान करना और प्रासंगिक व्यवहारों को कवर करने वाले परीक्षण बनाना आसान होता है।

यदि पैच का यह सेट अंततः लिनक्स मेनलाइन में प्रवेश करता है, तो इसका महत्व न केवल चार पहचानी गई समस्याओं को ठीक करेगा, बल्कि बाद के रखरखाव के लिए एक स्पष्ट कोड आधार भी प्रदान करेगा।

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

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