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

जिस दुनिया में प्रोग्रामर काम करते हैं वह सही कोड की दुनिया है। बेशक, इसमें असंख्य त्रुटियां हैं, लेकिन इन त्रुटियों को ठीक किया जाना चाहिए। यदि ये किसी और के कोड में त्रुटियां हैं, जिन्हें ठीक नहीं किया जा सकता है, तो उन्हें आपके कोड में दर्ज किया जाना चाहिए। लेकिन एक गलती हमेशा इसे खोजने और इसे खत्म करने का एक अवसर है।

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

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

सॉफ्टवेयर समस्या के लिए एक पूरी तरह से अलग दृष्टिकोण है - एक विशुद्ध रूप से व्यावहारिक दृष्टिकोण। हमारे पास एक प्राथमिकता वाला छोटी गाड़ी कोड है जो कभी-कभी काम करता है जैसा हम उससे उम्मीद करते हैं।

और इसके आसपास "कभी-कभी" स्थिरता और उत्पाद-तैयार की पूरी अवधारणा निर्मित होती है।

हम स्वीकार करते हैं कि कार्यक्रम त्रुटियों से भरा है, और यह त्रुटि अन्य कार्यक्रमों में त्रुटियों, त्रुटियों के संयोजन और उनकी अनुपस्थिति के कारण हो सकती है। कभी-कभी हम यह भी जानते हैं कि विभिन्न कार्यक्रमों में दो त्रुटियां पारस्परिक रूप से बेअसर हो सकती हैं।

हम इसे "जैसा है" स्वीकार करते हैं और ऐसी स्थिति के लिए प्रयास करते हैं जिसमें कोई त्रुटि न हो। सबसे कम गलतियाँ कहाँ हैं? यह सही है, जहां उन्होंने सबसे अधिक परीक्षण किया। यदि यह ज्ञात है कि फ़ॉबर 1 2 सही परिणाम देता है, तो सबसे अधिक संभावना है कि कोई त्रुटि नहीं है। जो, वैसे, बिल्कुल भी मतलब नहीं है कि फोबार 2 1 सही तरीके से काम करेगा। फ़ॉबर -1 -1, फ़ॉबर 1.2 2, \\ विंडोज़ \ पाथ \ फ़ॉबोर 1 2, फ़ोबोबार "01" "02", आदि का उल्लेख नहीं है।

दूसरे शब्दों में, हम "सॉफ्टवेयर परीक्षण" की श्रेणी के बारे में बात करना शुरू कर रहे हैं। जाहिर है, सभी डेटा वाले सभी वेरिएंट का परीक्षण नहीं किया जा सकता है - लेकिन कोड की जितनी अधिक विशिष्ट शाखाओं का परीक्षण किया जाता है, उतनी ही अधिक संभावना है कि कुछ त्रुटियां हैं।

तो, और अधिक परीक्षण, बेहतर।

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

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

मैं निराधार नहीं रहूंगा, मैं Selectel के जीवन से एक छोटी सी शिक्षाप्रद कहानी बताऊंगा: काफी समय से हमने अजगर 2.4 (डिफ़ॉल्ट रूप से सेंटोस 5.5 में) का उपयोग किया था। प्रोग्रामर बहुत सारे बगर्स थे और अजगर 2.6 चाहते थे, फिर गंदे हैक्स (केवल 2.6+ के साथ काम करने वाले पुस्तकालयों का उपयोग करके) उन्होंने लगभग एक अल्टीमेटम प्रस्तुत किया। प्रारंभिक परीक्षण के बाद, काम के माहौल में 2.6 लेने का फैसला किया गया था।

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

पायथन 2.4 पर, इसने बहुत अच्छा काम किया। पायथन 2.6 आया ... और हमें निष्क्रिय सिस्टम द्वारा एक महत्वपूर्ण सीपीयू उपयोग मिला। यह python2.6 था जो अपराधी निकला - यह शुरू हुआ (नए पुस्तकालयों के साथ) अजगर 2.4 की तुलना में अधिक लंबा।

प्रोग्रामर के दृष्टिकोण से: क्या नरक है?
सिस्टम प्रशासक के दृष्टिकोण से: सॉफ़्टवेयर को एक नए संस्करण में अपडेट किया गया - अनपेक्षित समस्याएँ।

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

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

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

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

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

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

वैसे, Microsoft, जिसमें सर्वर ओएस के महत्वपूर्ण अपडेट में ब्राउज़र के नए संस्करण शामिल हैं, स्पष्ट मूर्खता बनाता है, स्थिरता की विचारधारा का उल्लंघन करता है।

क्या मुझे सुरक्षा अपडेट की आवश्यकता है?

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

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

रक्तस्रावी धार

स्थिरता के पीछे रक्तस्रावी धार अवधारणा है। नवीनतम संस्करण। कभी-कभी नाइटली बिल्ड से भी (जो कि संस्करण भी नहीं है, लेकिन विकास के दौरान सॉफ़्टवेयर की मध्यवर्ती स्थिति)। ब्लीडिंग एज के वास्तव में फायदे हैं।

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

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

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