👩🏿‍🍳 🧜🏻 🦔 लिनक्स के सवाल के लिए (एल) 🌑 🧗🏾 🙇🏻

हम इस तथ्य से आगे बढ़ते हैं कि आपको एक पूर्ण ऑपरेटिंग सिस्टम मिलता है, तुरंत पूरी तरह से सब कुछ के लिए भुगतान करना। (एल के साथ प्रतियोगिता के बारे में एक सवाल के जवाब में बिल गेट्स)

जितना अधिक मैं लिनक्स के बारे में सीखता हूं, उतना ही कम मुझे बीजी से नफरत है।

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

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

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

व्यक्तिगत रूप से, मुझे 3 संभावित रणनीतियाँ दिखाई देती हैं:

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

PNP: यह ध्यान दिया जाना चाहिए कि इंटरफ़ेस के लिए मानक केवल आवश्यकता के लिए प्रदान करता है (चित्र 221 पृष्ठ पर 8.31), इनपुट संदेश की प्रतीक्षा करते समय, समय पर नियंत्रण करने और संभावित त्रुटियों में से एक के रूप में प्रक्रिया करने के लिए, अनुरोध 3 बार दोहराएं और फिर लेनदेन विफलता के बारे में संकेत दें। आगे की मेजबान कार्रवाई कार्यान्वयन द्वारा निर्धारित की जाती है। खैर, कम से कम, मुझे मानक में ऐसी जानकारी नहीं मिली, हालांकि यह अंतिम नहीं है।

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

4. एक निश्चित संख्या में अनुरोध को दोहराएं, जिसके थकावट के बाद डिवाइस को दोषपूर्ण के रूप में चिह्नित करना और फिर इसे बंद करना। ।

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

मेरे लिनक्स के परिचितों ने, इस घटना को प्रदर्शित करने के बाद, पहली बार "यह एक बग नहीं है, यह इस तरह की विशेषता है" की शैली में इसे समझाने की कोशिश की (या, पहली बार में, जैसा कि उन्होंने स्वीकार किया, उन्होंने नवीनतम पैच के साथ कर्नेल के पुनर्निर्माण का सुझाव दिया, यह आमतौर पर एल समुदाय के किसी भी संदेश के लिए एक सार्वभौमिक प्रतिक्रिया है। एक संभावित त्रुटि के बारे में), और फिर उन्होंने कहा कि, हां, व्यवहार गलत है, लेकिन, शायद, विधानसभा की कॉन्फ़िगरेशन फ़ाइलों में कहीं एक झंडा है, रीसेट करना या सेटिंग करना, जिसे आप इस सिस्टम व्यवहार को अक्षम कर सकते हैं। यदि यह सत्य है, तो केवल उस ध्वज का नाम जो मैं प्रस्तुत कर सकता हूं, वह है (रूसी में): "मैं वास्तव में to_OS_be_being_being_something_string_descriptor_as_hysthichichka" शैली में चाहता हूं, "जब तक यह कुतिया उसे अपना नाम नहीं बताती, तब तक मैं आपसे बात करने के लिए किसी से भी नहीं पूछ सकता।" मेरी फ्रैंच के लिए माफ करें। खैर, भले ही यह मामला है, वहाँ एक झंडा है,क्या डिफ़ॉल्ट रूप से ओएस को सामान्य रूप से एकत्र नहीं किया जाना चाहिए, विकृत नहीं, मोड? किसी कारण के लिए, विंडोज बस यही करते हैं। बेशक, आपको होस्ट एल के स्रोत पाठ को देखना चाहिए (सबसे अधिक संभावना है, एक विशिष्ट यूएसबी चालक) और यह निर्धारित करें कि क्या ऐसा कोई झंडा है और समान सिस्टम व्यवहार कैसे प्राप्त किया जाए, लेकिन नीचे सूचीबद्ध कारणों के लिए, ऐसा नहीं किया गया था, इसलिए हमने खुद को तथ्य बताते हुए प्रतिबंधित कर दिया है। ।

दूसरी विशेषता (बहुत अधिक त्रुटि की तरह, क्योंकि पहले मामले में डिवाइस गलत था, जिसे मैंने तुरंत जोर दिया) डिवाइस प्रोग्राम त्रुटि को ठीक करने के बाद पता चला था और हमने आगे काम करना शुरू कर दिया।

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

यह सुझाव दिया गया है कि कीबोर्ड से बारीकी से (समय में) घटनाओं को छोड़ दिया जा सकता है, इस मामले में एक बटन जारी करने के बारे में एक संदेश है।

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

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

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

लिनक्स के सवाल के लिए (एल)

जितना अधिक मैं लिनक्स के बारे में सीखता हूं, उतना ही कम मुझे बीजी से नफरत है।

More articles: