डेलिभरी उपकरणहरूको विकास, वा डकर, डेब, जार र थपको बारेमा विचारहरू

कुनै न कुनै बिन्दुमा मैले डकर कन्टेनर र डेब प्याकेजहरूको रूपमा डेलिभरीको बारेमा लेख लेख्ने निर्णय गरें, तर जब मैले सुरु गरें, कुनै कारणले गर्दा मलाई पहिलो व्यक्तिगत कम्प्युटरहरू र क्यालकुलेटरहरूको टाढाको समयमा फिर्ता लगियो। सामान्यतया, डकर र डेबको सुक्खा तुलनाको सट्टा, हामीले विकासको विषयमा यी विचारहरू पायौं, जुन म तपाईंको विचारको लागि प्रस्तुत गर्दछु।

कुनै पनि उत्पादन, चाहे त्यो जे होस्, कुनै न कुनै रूपमा उत्पादन सर्भरमा पुग्नै पर्छ, कन्फिगर गरी लन्च गर्नुपर्छ। यो लेख के बारे मा हुनेछ।

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

त्यसोभए, राम्रो पुरानो दिनहरूमा ... मैले फेला पारेको सबैभन्दा पुरानो तरिका टेप रेकर्डरबाट क्यासेट टेपहरू थिए। मसँग कम्प्युटर BK-0010.01 थियो...

क्याल्कुलेटरको जमाना

होइन, त्यहाँ पहिलेको क्षण थियो, त्यहाँ क्याल्कुलेटर पनि थियो MK-61 и MK-52.

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

अर्को परिमार्जन क्यालकुलेटर थियो MK-52, यसमा पहिले नै गैर-अस्थिर डाटा भण्डारणको केही झलक छ। अब खेल वा कार्यक्रम म्यानुअल रूपमा प्रविष्ट गर्नु पर्दैन, तर बटनहरूसँग केही जादुई पासहरू प्रदर्शन गरेपछि, यो आफै लोड भयो।

क्यालकुलेटर मा सबैभन्दा ठूलो कार्यक्रम को आकार 105 कदम थियो, र MK-52 मा स्थायी मेमोरी को आकार 512 कदम थियो।

खैर, यदि यी क्यालकुलेटरहरूको प्रशंसकहरू छन् जसले यो लेख पढिरहेका छन्, लेख लेख्ने प्रक्रियामा मैले एन्ड्रोइडका लागि क्यालकुलेटर इमुलेटर र यसको लागि कार्यक्रमहरू फेला पारे। विगतमा अगाडि बढ्नुहोस्!

• एन्ड्रोइडका लागि एमके-६१ एम्युलेटर
• MK-61 को लागि कार्यक्रम सूची

MK-52 को बारेमा एक छोटो डिग्रेशन (विकिपिडियाबाट)

MK-52 सोयुज TM-7 अन्तरिक्ष यानमा अन्तरिक्षमा उड्यो। यो अन-बोर्ड कम्प्युटर असफल भएको अवस्थामा ल्यान्डिङ ट्र्याजेक्टोरी गणना गर्न प्रयोग गरिनु पर्ने थियो।

52 देखि, Electronika-Astro मेमोरी विस्तार एकाइको साथ MK-1988 नेभिगेसनल कम्प्युटिङ किटको भागको रूपमा नौसेना जहाजहरूलाई आपूर्ति गरिएको छ।

पहिलो व्यक्तिगत कम्प्युटरहरू

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

क्यासेटमा भण्डारण सामान्यतया एक वा दुई बाइनरी फाइलहरूको रूपमा थियो, अरू सबै कुरा भित्र समावेश थियो। विश्वसनीयता धेरै कम थियो, मैले कार्यक्रमको 2-3 प्रतिहरू राख्नुपर्‍यो। लोडिङ समयहरू पनि निराशाजनक थिए, र उत्साहीहरूले यी कमजोरीहरू हटाउन विभिन्न फ्रिक्वेन्सी एन्कोडिङहरू प्रयोग गरे। त्यस समयमा, म आफैं अझै पनि व्यावसायिक सफ्टवेयर विकासमा संलग्न थिइनँ (बेसिकमा साधारण कार्यक्रमहरू गन्ती गर्दैन), त्यसैले, दुर्भाग्यवश, म तपाईंलाई विस्तृत रूपमा बताउँदिन कि सबै कुरा भित्र कसरी व्यवस्थित गरिएको थियो। कम्प्यूटरसँग धेरै भागको लागि मात्र RAM भएको तथ्यले डाटा भण्डारण योजनाको सरलता निर्धारण गर्दछ।

भरपर्दो र ठूलो भण्डारण मिडिया को उद्भव

पछि, फ्लपी डिस्कहरू देखा पर्‍यो, प्रतिलिपि गर्ने प्रक्रियालाई सरलीकृत गरियो, र विश्वसनीयता बढ्यो।
तर स्थिति नाटकीय रूपमा परिवर्तन हुन्छ जब पर्याप्त मात्रामा स्थानीय भण्डारणहरू HDD को रूपमा देखा पर्दछ।

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

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

त्यो समयमा, लिनक्सको अस्तित्व मेरो लागि खुला थिएन; म एमएस डस र पछि, विन्डोजको संसारमा बसें, र बोर्ल्यान्ड पास्कल र डेल्फीमा लेखें, कहिलेकाहीँ C++ तिर हेर्दै। धेरै व्यक्तिहरूले त्यसबेला उत्पादनहरू डेलिभर गर्न InstallShield प्रयोग गरे। ru.wikipedia.org/wiki/InstallShield, जसले सफ्टवेयरको तैनाती र कन्फिगर गर्ने सबै तोकिएका कार्यहरू सफलतापूर्वक समाधान गर्यो।

इन्टरनेट युग

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

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

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

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

एकै समयमा, PHP मा साधारण साइटहरूको डेलिभरी धेरै आदिम तरिकामा FTP मार्फत लक्षित मेसिनमा सही फाइल प्रतिलिपि गरेर गरिएको थियो। कहिलेकाहीँ यो मामला थिएन - कोड उत्पादन सर्भरमा प्रत्यक्ष सम्पादन गरिएको थियो, र यो विशेष गरी ठाडो थियो यदि त्यहाँ ब्याकअपहरू थिए भने।

RPM र DEB प्याकेजहरू

अर्कोतर्फ, इन्टरनेटको विकासको साथमा, UNIX-जस्तो प्रणालीहरूले अधिक र अधिक लोकप्रियता प्राप्त गर्न थाले, विशेष गरी, त्यो समयमा मैले RedHat Linux 6 पत्ता लगाए, लगभग 2000। स्वाभाविक रूपमा, त्यहाँ सफ्टवेयर डेलिभर गर्ने निश्चित माध्यमहरू पनि थिए; विकिपिडियाका अनुसार, RPM मुख्य प्याकेज प्रबन्धकको रूपमा 1995 मा RedHat Linux 2.0 को संस्करणमा देखा पर्‍यो। र त्यसबेलादेखि र आजसम्म, प्रणाली RPM प्याकेजहरूको रूपमा डेलिभर गरिएको छ र धेरै सफलतापूर्वक अवस्थित र विकास भइरहेको छ।

डेबियन परिवारको वितरणले समान बाटो पछ्यायो र डेब प्याकेजहरूको रूपमा वितरण लागू गर्‍यो, जुन आजसम्म अपरिवर्तित छ।

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

क्लाउड कम्प्युटिङले भौतिक मिडियाबाट मात्र नभई क्लाउड रिपोजिटरीहरूबाट पनि प्याकेज प्रबन्धकहरूमा स्थापना थपेको छ, तर मौलिक रूपमा थोरै परिवर्तन भएको छ।

यो ध्यान दिन लायक छ कि हाल डेबबाट टाढा सर्ने र स्न्याप प्याकेजहरूमा स्विच गर्ने दिशामा केही चालहरू छन्, तर पछि त्यसमा थप।

त्यसोभए, क्लाउड विकासकर्ताहरूको यो नयाँ पुस्ता, जसले DEB र RPM दुवैलाई थाहा थिएन, पनि बिस्तारै बढ्दै गयो, अनुभव प्राप्त भयो, उत्पादनहरू थप जटिल भए, र FTP, bash स्क्रिप्टहरू र यस्तै विद्यार्थी शिल्पहरू भन्दा केही थप उचित वितरण विधिहरू आवश्यक भए।
र यो जहाँ डकर चित्रमा आउँछ, भर्चुअलाइजेशन, संसाधन सीमांकन र डेलिभरी विधिको एक प्रकारको मिश्रण। यो अहिले फैशनेबल र जवान छ, तर यो सबैको लागि आवश्यक छ? के यो एक रामबाण उपाय हो?

मेरा अवलोकनहरूबाट, प्रायः डकरलाई उचित विकल्पको रूपमा प्रस्ताव गरिएको छैन, तर केवल किनभने, एकातिर, समुदायमा यसको बारेमा कुरा गरिन्छ, र यसलाई प्रस्ताव गर्नेहरूलाई मात्र थाहा छ। अर्कोतर्फ, धेरै जसो तिनीहरू राम्रो पुरानो प्याकेजिङ्ग प्रणालीहरूको बारेमा मौन छन् - तिनीहरू अवस्थित छन् र चुपचाप र ध्यान नदिई आफ्नो काम गर्छन्। यस्तो अवस्थामा, त्यहाँ वास्तवमा कुनै अन्य विकल्प छैन - छनौट स्पष्ट छ - डकर।

म कसरी हामीले डकरलाई लागू गर्यौं र परिणामको रूपमा के भयो भन्ने मेरो अनुभव साझा गर्ने प्रयास गर्नेछु।

स्व-लिखित स्क्रिप्टहरू

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

तर स्क्रिप्टका धेरै बेफाइदाहरू छन्:

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

निस्सन्देह, तपाइँ एक परिष्कृत लिपि लेख्न सक्नुहुन्छ, तर, मैले माथि लेखेको रूपमा, यो विकास समय हो, र कम से कम होइन, र, हामीलाई थाहा छ, त्यहाँ सधैं पर्याप्त समय छैन।

यी सबैले स्पष्ट रूपमा यस डिप्लोइमेन्ट विधिको आवेदनको दायरालाई मात्र सरल प्रणालीहरूमा सीमित गर्दछ। यसलाई परिवर्तन गर्ने बेला आएको छ ।

डकर

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

हामीले कस्ता असुविधाहरू सामना गर्यौं?

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

अर्कोतर्फ, एउटै डेब मार्फत जार अभिलेखको रूपमा वसन्त सेवा तैनात गर्नु किन खराब छ? के संसाधन अलगाव साँच्चै आवश्यक छ? के यो सेवालाई धेरै कम भएको कन्टेनरमा भरेर सुविधाजनक अपरेटिङ सिस्टम उपकरणहरू गुमाउनु उपयुक्त हुन्छ?

अभ्यासले देखाएको रूपमा, वास्तवमा यो आवश्यक छैन, डेब प्याकेज 90% केसहरूमा पर्याप्त छ।

राम्रो पुरानो डेब कहिले असफल हुन्छ र हामीलाई कहिले डकर चाहिन्छ?

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

दोस्रो बिन्दु जहाँ हामीले डकर प्रयोग गर्ने योजना बनाउँछौं निलो-हरियो डिप्लोय योजना प्रयोग गरेर सेवाहरू प्रयोग गर्नु हो। तर यहाँ म जटिलतामा क्रमिक वृद्धि प्राप्त गर्न चाहन्छु: पहिले, डेब प्याकेजहरू बनाइन्छ, र त्यसपछि तिनीहरूबाट डकर कन्टेनर बनाइन्छ।

स्न्याप प्याकेजहरू

स्न्याप प्याकेजहरूमा फर्कौं। तिनीहरू पहिलो पटक आधिकारिक रूपमा Ubuntu 16.04 मा देखा पर्‍यो। सामान्य deb प्याकेजहरू र rpm प्याकेजहरूको विपरीत, स्न्यापले सबै निर्भरताहरू बोक्छ। एकातिर, यसले तपाईंलाई पुस्तकालय विवादहरूबाट बच्न अनुमति दिन्छ, अर्कोतर्फ, नतिजा प्याकेज आकारमा ठूलो छ। थप रूपमा, यसले प्रणालीको सुरक्षालाई पनि असर गर्न सक्छ: स्न्याप डेलिभरीको अवस्थामा, समावेश गरिएका पुस्तकालयहरूमा भएका सबै परिवर्तनहरू प्याकेज सिर्जना गर्ने विकासकर्ताद्वारा अनुगमन गरिनुपर्छ। सामान्यतया, सबै कुरा यति सरल छैन र विश्वव्यापी आनन्द तिनीहरूलाई प्रयोग गरेर आउँदैन। तर, जे होस्, यो पूर्ण रूपमा उचित विकल्प हो यदि उही डकर मात्र प्याकेजिङ्ग उपकरणको रूपमा प्रयोग गरिन्छ र भर्चुअलाइजेसनको लागि होइन।

नतिजाको रूपमा, हामी अब दुबै deb प्याकेजहरू र डकर कन्टेनरहरू उचित संयोजनमा प्रयोग गर्छौं, जुन, सायद, केही अवस्थामा हामी स्न्याप प्याकेजहरूसँग प्रतिस्थापन गर्नेछौं।

दर्ता भएका प्रयोगकर्ताहरूले मात्र सर्वेक्षणमा भाग लिन सक्छन्। साइन इन गर्नुहोस्कृपया

तपाईं डेलिभरीको लागि के प्रयोग गर्नुहुन्छ?

• स्व-लिखित स्क्रिप्टहरू

• FTP मा म्यानुअल रूपमा प्रतिलिपि गर्नुहोस्

• deb प्याकेजहरू

• rpm प्याकेजहरू

• स्न्याप प्याकेजहरू

• डकर-छविहरू

• भर्चुअल मेसिन छविहरू

• सम्पूर्ण HDD क्लोन गर्नुहोस्

• कठपुतली

• उत्तरदायी

• अन्य

109 प्रयोगकर्ताहरूले मतदान गरे। २ प्रयोगकर्ताहरू रोकिए।

स्रोत: www.habr.com