सॉफ़्टवेयर रोट: Difference between revisions
No edit summary |
No edit summary |
||
| Line 12: | Line 12: | ||
=== एल्गोरिथम परिवर्तन === | === एल्गोरिथम परिवर्तन === | ||
जब प्रोग्राम के एल्गोरिथम में परिवर्तन होते हैं विशेष रूप से ऐसे परिवर्तन जो प्रोग्राम के डिज़ाइनर ने सॉफ़्टवेयर की अपेक्षा नहीं की थी अब वे मूल उद्देश्य के रूप में संचालित नहीं हो सकते हैं। उदाहरण के लिए, कई प्रारम्भिक [[वीडियो गेम]] (खेल) डिजाइनरों ने अपने गेम में सीपीयू [[घड़ी]] की गति को टाइमर के रूप में प्रयोग किया था।<ref>{{Cite book|url=https://books.google.com/books?id=uEkrL23rU98C&pg=PT303 |title=PC Mag|last=Inc|first=Ziff Davis|date=1992-01-28|publisher=Ziff Davis, Inc.|pages=286|language=en}}</ref> हालाँकि, नए सीपीयू मे घड़ियाँ तीव्र थीं इसलिए गेम की गति उसी के अनुसार बढ़ती थी जिससे कारण समय के साथ वीडियो गेम कम उपयोगी हो गए है। | |||
[[File:Blender 2.9 AMD normals bug.webm|thumb|ब्लेंडर (सॉफ़्टवेयर) 2.9 में प्रस्तुत किए गए बग सॉफ्टवेयर की एक स्क्रीन रिकॉर्डिंग [[उन्नत लघु उपकरण|अपडेट लघु उपकरण]] सॉफ्टवेयर में परिवर्तन के परिणाम स्वरूप, प्रकाश के स्ट्रोबिंग डॉट्स और [[सामान्य (ज्यामिति)]] के गलत प्रतिपादन के कारण इन परिवर्तनों को समायोजित करने के लिए, बग को ठीक करने के लिए ब्लेंडर के कोड में अपडेट किए जाने थे।]] | |||
=== वन्सेबिलिटी === | === वन्सेबिलिटी === | ||
एल्गोरिथम में ऐसे रूपांतरण सम्मिलित हैं जो प्रोग्राम के डिज़ाइनर से संबंधित नहीं होते हैं, बल्कि इसके वे उपयोगकर्ता है प्रारंभ में एक उपयोगकर्ता सिस्टम को प्रोग्राम में प्रयुक्त कर सकता है और यह निश्चित समय के लिए त्रुटिपूर्ण रूप से कार्य कर सकता है। लेकिन, जब सिस्टम सही प्रकार से कार्य करना बंद कर देता है या उपयोगकर्ता कॉन्फ़िगरेशन नियंत्रणों तक अभिगम्य बनाना चाहते हैं तो वे अलग-अलग एल्गोरिथम और अनुपलब्ध जानकारी (पासवर्ड भूल जाने, गुप्त निर्देश या जटिल प्रबंधित उपयोगकर्ता) के कारण उस प्रारंभिक चरण को दोहरा नहीं सकते हैं। इंटरफ़ेस जिसे पहले परीक्षण और त्रुटि द्वारा कॉन्फ़िगर किया गया था। एक बार यह विफल हो गया था तब सूचना विकासक 'जोनास सॉडरस्ट्रॉम' ने इस अवधारणा को "वन्सेबिलिटी" नाम दिया है<ref>{{cite web|author=Jonas Söderström|url=https://www.inuse.se/read/onceability-the-consequence-of-technology-rot-inuseful/|title=Onceability: The consequence of technology rot}}</ref> और इसे "तकनीकी प्रणाली में गुणवत्ता के रूप में परिभाषित किया है जो उपयोगकर्ता को सिस्टम को पुनर्स्थापित करने से स्थगित करता है।" | एल्गोरिथम में ऐसे रूपांतरण सम्मिलित हैं जो प्रोग्राम के डिज़ाइनर से संबंधित नहीं होते हैं, बल्कि इसके वे उपयोगकर्ता है प्रारंभ में एक उपयोगकर्ता सिस्टम को प्रोग्राम में प्रयुक्त कर सकता है और यह निश्चित समय के लिए त्रुटिपूर्ण रूप से कार्य कर सकता है। लेकिन, जब सिस्टम सही प्रकार से कार्य करना बंद कर देता है या उपयोगकर्ता कॉन्फ़िगरेशन नियंत्रणों तक अभिगम्य बनाना चाहते हैं तो वे अलग-अलग एल्गोरिथम और अनुपलब्ध जानकारी (पासवर्ड भूल जाने, गुप्त निर्देश या जटिल प्रबंधित उपयोगकर्ता) के कारण उस प्रारंभिक चरण को दोहरा नहीं सकते हैं। इंटरफ़ेस जिसे पहले परीक्षण और त्रुटि द्वारा कॉन्फ़िगर किया गया था। एक बार यह विफल हो गया था तब सूचना विकासक 'जोनास सॉडरस्ट्रॉम' ने इस अवधारणा को "वन्सेबिलिटी" नाम दिया है<ref>{{cite web|author=Jonas Söderström|url=https://www.inuse.se/read/onceability-the-consequence-of-technology-rot-inuseful/|title=Onceability: The consequence of technology rot}}</ref> और इसे "तकनीकी प्रणाली में गुणवत्ता के रूप में परिभाषित किया है जो उपयोगकर्ता को सिस्टम को पुनर्स्थापित करने से स्थगित करता है।" | ||
Revision as of 11:57, 3 March 2023
 | This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these template messages)
(Learn how and when to remove this template message)
|
सॉफ़्टवेयर रोट (बिट रोट, कोड रोट, सॉफ़्टवेयर एरोसिओन, सॉफ़्टवेयर अपव्यय या सॉफ्टवेयर एन्ट्रापी) समय के साथ सॉफ़्टवेयर गुणवत्ता की अपेक्षाकृत कमी या इसकी कम प्रतिक्रियात्मकता है जो अंततः सॉफ़्टवेयर को दोषपूर्ण, अनुपयोगी या अपग्रेड करने की आवश्यकता में क्षमता प्राप्त करती है। यह एक भौतिक घटना नहीं है सॉफ्टवेयर वास्तव में अपव्यय नहीं करता है, बल्कि रूपांतरित एल्गोरिथम के संबंध में उत्तरदायी और अपग्रेड होने की अपेक्षाकृत कमी से युक्त होता है
जिसमें "जार्गन फ़ाइल" हैकर विधि का एक संग्रह, "बिट रोट" को समय के साथ एक सॉफ्टवेयर प्रोग्राम के अपव्यय के लिए एक 'जोक्यूलर व्याख्या' के रूप में परिभाषित करता है, यद्यपि कुछ भी रूपांतरित नहीं होता है तो इसके पीछे का विचार लगभग वैसा ही है जैसे कि प्रोग्राम बनाने वाले बिट्स रेडियोधर्मी अपव्यय पर निर्भर थे।[1]
कारण
सॉफ़्टवेयर रोट के लिए कई कारक उत्तरदायी हो सकते हैं जिसमें मुख्य एल्गोरिथम में रूपांतरण सम्मिलित हैं और जिसमे सॉफ़्टवेयर स्वयं सॉफ़्टवेयर के कुछ भागो के बीच संगतता में कमी और अप्रयुक्त या अपेक्षाकृत रूप से कभी उपयोग किए गए कोड में बग (सॉफ्टवेयर) की उपस्थिति को संचालित करता है।
एल्गोरिथम परिवर्तन
जब प्रोग्राम के एल्गोरिथम में परिवर्तन होते हैं विशेष रूप से ऐसे परिवर्तन जो प्रोग्राम के डिज़ाइनर ने सॉफ़्टवेयर की अपेक्षा नहीं की थी अब वे मूल उद्देश्य के रूप में संचालित नहीं हो सकते हैं। उदाहरण के लिए, कई प्रारम्भिक वीडियो गेम (खेल) डिजाइनरों ने अपने गेम में सीपीयू घड़ी की गति को टाइमर के रूप में प्रयोग किया था।[2] हालाँकि, नए सीपीयू मे घड़ियाँ तीव्र थीं इसलिए गेम की गति उसी के अनुसार बढ़ती थी जिससे कारण समय के साथ वीडियो गेम कम उपयोगी हो गए है।
वन्सेबिलिटी
एल्गोरिथम में ऐसे रूपांतरण सम्मिलित हैं जो प्रोग्राम के डिज़ाइनर से संबंधित नहीं होते हैं, बल्कि इसके वे उपयोगकर्ता है प्रारंभ में एक उपयोगकर्ता सिस्टम को प्रोग्राम में प्रयुक्त कर सकता है और यह निश्चित समय के लिए त्रुटिपूर्ण रूप से कार्य कर सकता है। लेकिन, जब सिस्टम सही प्रकार से कार्य करना बंद कर देता है या उपयोगकर्ता कॉन्फ़िगरेशन नियंत्रणों तक अभिगम्य बनाना चाहते हैं तो वे अलग-अलग एल्गोरिथम और अनुपलब्ध जानकारी (पासवर्ड भूल जाने, गुप्त निर्देश या जटिल प्रबंधित उपयोगकर्ता) के कारण उस प्रारंभिक चरण को दोहरा नहीं सकते हैं। इंटरफ़ेस जिसे पहले परीक्षण और त्रुटि द्वारा कॉन्फ़िगर किया गया था। एक बार यह विफल हो गया था तब सूचना विकासक 'जोनास सॉडरस्ट्रॉम' ने इस अवधारणा को "वन्सेबिलिटी" नाम दिया है[3] और इसे "तकनीकी प्रणाली में गुणवत्ता के रूप में परिभाषित किया है जो उपयोगकर्ता को सिस्टम को पुनर्स्थापित करने से स्थगित करता है।"
अप्रयुक्त कोड
कोड के प्रायः उपयोग किए जाने वाले भाग, जैसे दस्तावेज़ फ़िल्टर या अन्य प्रोग्राम द्वारा उपयोग किए जाने के लिए डिज़ाइन किए गए इंटरफ़ेस में बग (सॉफ्टवेयर) हो सकते हैं जिनमे किसी का ध्यान नहीं जाता हैं। उपयोगकर्ता की आवश्यकताओं और अन्य बाहरी कारकों में परिवर्तन के साथ, इस कोड को बाद में निष्पादित किया जा सकता है जिससे बग सॉफ्टवेयर अपेक्षाकृत अधिक सक्रिय हो जाते हैं और सॉफ़्टवेयर कम कार्यात्मक प्रदर्शित होते है।
ररेलय अपडेट कोड
सॉफ्टवेयर और सिस्टम के सामान्य संरक्षण से भी सॉफ्टवेयर नष्ट हो सकता है। विशेष रूप से, जब एक प्रोग्राम में कई भाग होते हैं जो एक दूसरे से अपेक्षाकृत कम दूरी पर कार्य करते हैं, तो यह विचार करने में विफल रहता है कि कैसे एक भाग में परिवर्तन जो दूसरों को प्रभावित करता है जो बग का परिचय दे सकता है। कुछ स्थितियों में, यह उन लाइब्रेरी का रूप ले सकता है जो सॉफ़्टवेयर का उपयोग इस प्रकार से परिवर्तित करते हैं जो सॉफ़्टवेयर पर प्रतिकूल प्रभाव डालते हैं। यदि किसी लाइब्रेरी का पुराना संस्करण जो पहले सॉफ़्टवेयर के साथ कार्य करता था अन्य सॉफ़्टवेयर के साथ सुरक्षा या पुराने संस्करण में पाए गए सुरक्षा दोषों के कारण अब उपयोग नहीं किया जा सकता है इसलिए प्रोग्राम के उपयोग के लिए आवश्यक लाइब्रेरी का कोई अपडेट संस्करण नहीं हो सकता है।
ऑनलाइन कनेक्टिविटी
आधुनिक व्यावसायिक सॉफ़्टवेयर प्रायः लाइसेंस सत्यापन और जानकारी प्राप्त करने के लिए एक ऑनलाइन सर्वर से जुड़ते हैं। यदि सॉफ़्टवेयर को सशक्त करने वाली ऑनलाइन सेवा स्थगित कर दी जाती है तो यह कार्य करना बंद कर सकते है।[4][5]
2010 के अंत से अधिकांश वेबसाइटें सुरक्षित एचटीटीपीएस सर्वर का उपयोग करती हैं। हालाँकि इसके लिए एन्क्रिप्शन कुंजी की आवश्यकता होती है जिसे रूट प्रमाण पत्र कहा जाता है जिसकी समाप्ति तिथि होती है। प्रमाणपत्रों के समाप्त होने के बाद डिवाइसों की अधिकांश वेबसाइटों से कनेक्टिविटी समाप्त हो जाती है जब तक कि कुंजियों को निरंतर अपडेट नहीं किया जाता है।[6]
वर्गीकरण
सॉफ़्टवेयर रोट को सामान्यतः निष्क्रिय रोट या सक्रिय रोट के रूप में वर्गीकृत किया जाता है।
निष्क्रिय सॉफ़्टवेयर रोट
सॉफ़्टवेयर जो वर्तमान में उपयोग नहीं किया जा रहा है धीरे-धीरे अनुपयोगी हो जाता है क्योंकि अन्य एप्लिकेशन परिवर्तित हो जाते है। जो उपयोगकर्ता की आवश्यकताओं में परिवर्तन और सॉफ्टवेयर एल्गोरिथम मे कमी का कारण उत्पन्न करते हैं।
सक्रिय सॉफ़्टवेयर रोट
सॉफ़्टवेयर जिसे निरंतर संशोधित किया जा रहा है वह समय के साथ अपनी कमी को समाप्त कर सकता है यदि उपयुक्त प्रक्रियाओं को निरंतर प्रयुक्त नहीं किया जाता है। हालाँकि, नई आवश्यकताओं को पूरा करने और बग सॉफ़्टवेयर को ठीक करने के लिए बहुत से सॉफ़्टवेयर में निरंतर परिवर्तन की आवश्यकता होती है और प्रत्येक समय परिवर्तन किए जाने पर सॉफ़्टवेयर को फिर से तकनीकी विधि से सही करना आवश्यक होता है। यह प्रोग्राम के लिए अनिवार्य रूप से एक विकास प्रक्रिया बनाता है जिससे यह मूल इंजीनियर डिजाइन से हट जाता है। इसके परिणामस्वरूप और एक परिवर्तित एल्गोरिथम में, मूल डिजाइनरों द्वारा की गई धारणाएं अस्वीकृत हो सकती हैं, जिससे बग सॉफ़्टवेयर का परिचय भी हो सकता है।
इस प्रक्रिया में, दस्तावेज़ों को अपडेट करने पर नई सुविधाओं को जोड़ने की प्राथमिकता दी जा सकती है दस्तावेज़ीकरण के अतिरिक्त हालांकि, प्रोग्राम के कुछ भागों से संबंधित विशिष्ट ज्ञानकोष को समाप्त किया जाना संभव होता है। कुछ प्रकार के कोडिंग फंक्शनों के लिए सर्वोत्तम सम्मिलित प्रक्रियाओ का अनुसरण करके इसे अपेक्षाकृत कम किया जा सकता है। जब कोई एप्लिकेशन अपने व्यावसायिक प्रक्रिया के अंत के निकट होता है तो सक्रिय सॉफ़्टवेयर रोट धीमा हो जाता है और आगे का विकास बंद हो जाता है। उपयोगकर्ता प्रायः किसी भी अन्य सॉफ्टवेयर बग के आसपास कार्य करना प्रारम्भ करते हैं जिससे सॉफ़्टवेयर की प्रक्रिया सामान्य हो जाती है क्योंकि सॉफ़्टवेयर मे कुछ भी परिवर्तन नहीं किया जा रहा होता है।
उदाहरण
एआई प्रोग्राम उदाहरण
एआई शोध के प्रारम्भिक दिनों से कई मौलिक प्रोग्राम अपूर्णीय (इर्रेपरबल) सॉफ्टवेयर रोट से विपरीत हैं। उदाहरण के लिए, मूल शरड्लु प्रोग्राम (प्रारंभिक प्राकृतिक भाषा समझ प्रोग्राम) किसी भी आधुनिक युग के कंप्यूटर या कंप्यूटर अनुरूपक पर नहीं सक्रिय किया जा सकता है, क्योंकि यह उन दिनों के समय विकसित किया गया था जब लिस्प और प्लैनर (प्रोग्रामिंग भाषा) विकास के चरण में थी और इस प्रकार यह गैर-मानक का उपयोग करता है। मैक्रोज़ और सॉफ़्टवेयर लाइब्रेरी जो अब इसमे सम्मिलित नहीं होती हैं।
ऑनलाइन फ़ोरम के उदाहरण
मान लीजिए कि एक विकासक मुक्त स्रोत सॉफ्टवेयर फ़ोरम सॉफ़्टवेयर का उपयोग करके एक फ़ोरम बनाता है और फिर नई सुविधाओं और विभिन्न विकल्पों को जोड़कर इसे अत्यधिक रूप से संशोधित करता है। इस प्रक्रिया के लिए सम्मिलित कोड में व्यापक संशोधन और उस सॉफ़्टवेयर की मूल कार्यक्षमता की आवश्यकता होती है।
इसमे ऐसे कई तरीके होते हैं जिनसे सॉफ़्टवेयर रोट सिस्टम को प्रभावित किया जा सकता है:
- विकासक गलती से ऐसे परिवर्तन कर सकता है जो एक दूसरे या मूल सॉफ़्टवेयर के साथ कार्य करते हैं जिससे फ़ोरम अप्रत्याशित रूप से प्रक्रिया करता है या सभी प्रकार से अलग हो जाता है। या उन्हें निष्क्रिय स्थिति में छोड़ देता है: चूंकि वे मूल कोड से बहुत अधिक प्रभावित होते हैं इसीलिए तकनीकी सहायता और फोरम को पुनः स्थापित करने में सहायता प्राप्त करना जटिल हो जाता है।
- मूल फ़ोरम स्रोत कोड में एक सुरक्षा भाग खोजा जा सकता है, जिसके लिए सुरक्षा पैच की आवश्यकता होती है। हालाँकि, विकासक ने कोड को इतने व्यापक रूप से संशोधित किया है कि पैच को प्रत्यक्ष रूप से उनके कोड पर प्रयुक्त नहीं किया जा सकता है जिसके लिए विकासक को सॉफ़्टवेयर अपडेट मे जा कर प्रभावी तरीके से प्रोग्राम लिखने की आवश्यकता होती है।
- संशोधन करने वाला विकासक अपना स्थान रिक्त कर सकता है जिससे नए विकासक को एक प्रभावी और अत्यधिक संशोधित फ़ोरम प्राप्त हो जाता है जिसमें पूर्ण दस्तावेज़ीकरण का अभाव होता है। संशोधनों को पूरी तरह से समझने के अतिरिक्त, नए विकासक के लिए विरोधों और बगों को सम्मिलित किए बिना परिवर्तन करना कठिन होता है। इसके अतिरिक्त, मूल प्रणाली का प्रोग्राम अब उपलब्ध नहीं हो सकता है या इससे भी कार्यात्मक आवश्यकताओं में सूक्ष्म अंतर के कारण प्रोग्राम गलत हो सकता है।
रिफैक्टरिंग (पुनर्रचना)
कोड रीफैक्टरिंग रोट की समस्या को दूर करने का एक साधन है। इसे इसके बाहरी प्रक्रिया को प्रभावित किए बिना इसकी संरचना में सुधार के लिए सम्मिलित कोड को फिर से लिखने की प्रक्रिया के रूप में वर्णित किया गया है।[7] इसमें सॉफ़्टवेयर डेड कोड को हटाना और उन कोड को फिर से लिखना सम्मिलित होता है जिन्हें व्यापक रूप से संशोधित किया गया है और जो अब कुशलता से कार्य नहीं करते हैं। इसके लिए सॉफ़्टवेयर की बाहरी प्रक्रिया को शीघ्रता से परिवर्तित किया जाना चाहिए, क्योंकि इससे विभिन्न समस्याए उत्पन्न हो सकती हैं और इस प्रकार स्वयं सॉफ़्टवेयर रोट संशोधित किया जा सकता है।
यह भी देखें
- कोड समेल
- अधीनता हेल
- पीढ़ी संख्या मे कमी
- सॉफ्टवेयर ब्लोट
- सॉफ्टवेयर भंगुरता(ब्रिटटलेनेस)
- सॉफ्टवेयर एन्ट्रापी
- सॉलिड-वस्तु-उन्मुख सॉफ्टवेयर इंजीनियरिंग डिजाइन सिद्धांत
एल्गोरिथम
- ↑ Raymond, Eric. "Bit rot". The Jargon File. Retrieved 3 March 2013.
- ↑ Inc, Ziff Davis (1992-01-28). PC Mag (in English). Ziff Davis, Inc. p. 286.
{{cite book}}:|last=has generic name (help) - ↑ Jonas Söderström. "Onceability: The consequence of technology rot".
- ↑ Amadeo, Ron (31 October 2016). "The (updated) history of Android". Ars Technica (in English). Retrieved 31 October 2021.
- ↑ "Adobe CS2 is Now Available for Free, Sort Of". Mobile Magazine. 2013-01-14. Archived from the original on 2013-01-18. Retrieved 2013-01-20.
- ↑ https://www.tomsguide.com/news/android-cert-mess-averted
- ↑ Fowler, Martin (October 11, 2007). "What Is Refactoring". Retrieved 2007-11-22.
