ऑपरेटिंग सिस्टम (OS) एक व्यापक विषय है। दशकों से, एक दृष्टिकोण यहाँ हावी रहा है: यूनिक्स। दरअसल, अधिकांश आधुनिक सिस्टम, जिनमें अधिकांश GNU / लिनक्स वितरण शामिल हैं, * BSD और macOS, यूनिक्स वास्तुकला का पालन करते हैं। (कोई विंडोज नहीं है, लेकिन इस विषय पर लगभग कुछ भी दिलचस्प नहीं है)।

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

2006 में, एल्को डोसोत्र्रा ने अपने शोध प्रबंध, "ए फुल्ली फंक्शनल सॉफ्टवेयर डिप्लॉयमेंट मॉडल" को प्रकाशित किया, जो कार्यात्मक एनजीए पैकेज मैनेजर का वर्णन करता है। 2008 में, लेखक ने निक्सोस: पूरी तरह कार्यात्मक लिनक्स वितरण प्रकाशित किया । हालांकि निक्सओएस यूनिक्स प्रणालियों के लिए बहुत सारे मुफ्त सॉफ्टवेयर का पुन: उपयोग करता है, यह यूनिक्स डिजाइन और दर्शन से इतना दूर है कि इसे शायद ही "यूनिक्स प्रणाली" कहा जा सकता है।

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

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

सौभाग्य से, यह अनावश्यक निराशावाद अदूरदर्शी निकला और लंबे समय तक नहीं रहा: बस कुछ साल बाद, निक्स प्रणाली ने इसे गलत साबित कर दिया।

गुइसा रूप

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

Guix Unix ऑपरेटिंग सिस्टम से काफी अलग है। आप दस्तावेज़ देख सकते हैं और परिवर्तन की डिग्री का मूल्यांकन कर सकते हैं:

• आधिकारिक गाइड और फ़ीचर सूची
• गुइक्स पैकेज गाइड एक तकनीकी परिचय है ( यहां कॉपी करें )।

गुह्य लाभ

गुइक्स के लाभ उस बिंदु के लिए क्रांतिकारी हैं जहां बाकी ओएस इसकी तुलना में विरासत प्रणालियों की तरह दिखता है।

मेरी व्यक्तिगत पसंदीदा विशेषताएं:

• सिस्टम की अयोग्यता: सिस्टम और उपयोगकर्ता दोनों स्तरों पर Guix सभी परिवर्तनों का इतिहास रखता है। यदि अपडेट कुछ टूट जाता है, तो आप हमेशा वापस रोल कर सकते हैं। यह प्रणाली को वस्तुतः अजेय बनाता है।
  
• वफ़ादारी: चूंकि कॉन्फ़िगरेशन घोषणात्मक है, यह उपयोगकर्ता या सिस्टम प्रशासक को पूर्ण नियंत्रण देता है। अन्य यूनिक्स वेरिएंट पर, यह कहना बहुत मुश्किल है कि कब कुछ यादृच्छिक कॉन्फ़िगरेशन फ़ाइल बदल जाती है।
  
• पूरी तरह से प्रोग्राम करने योग्य ओएस: प्रोग्राम सिस्टम कॉन्फ़िगरेशन और एक संस्करण नियंत्रण प्रणाली का उपयोग करें। कई सिस्टम सेवाओं को गाइल स्कीम में कॉन्फ़िगर किया जा सकता है: udev नियमों से लेकर Xorg, PAM, आदि। Guile के लिए धन्यवाद, कॉन्फ़िगरेशन हार्डवेयर या यहां तक ​​कि होस्ट नाम पर सशर्त हो सकता है!
  
• अन्य के लिए प्रत्यक्ष प्रतिस्थापन (इतना अच्छा नहीं) पैकेज मैनेजर: यदि सभी के लिए एकल इंटरफ़ेस है (तो नीचे देखें ) Emacs, Python या TeXlive पैकेजों को अलग-अलग क्यों प्रबंधित करें ! उपयोगकर्ता प्रोफाइल के लिए घोषणाओं को लिखना और बनाए रखना आसान है।
  
• गुइल पैकेज परिभाषाएँ: थोक में पैकेज परिभाषाएँ विकसित करना बहुत अधिक कुशल है। यह विशेष रूप से पोर्टेज USE झंडे ( नीचे देखें ) जैसी अवधारणाओं को बदल देता है।
  
• पैकेज जारी करने के कई तरीके: एक Guix पैकेज में कई "जारी करने के तरीके" हो सकते हैं, जिनका उपयोग विभिन्न घटकों (पुस्तकालयों, अतिरिक्त उपकरण, प्रलेखन, आदि) को अलग करने के लिए किया जाता है। अन्य ऑपरेटिंग सिस्टम (आमतौर पर डेबियन) पर, यह अनुमान लगाना कठिन है कि कौन से पैकेज एक साथ फिट होते हैं।
  
• गैर-गुणा करने वाले इनपुट: Guix शब्दावली में, "इनपुट" पैकेज निर्भरताएं हैं। उपयोगकर्ता प्रोफ़ाइल और पर्यावरण में केवल उपयोगकर्ता द्वारा स्पष्ट रूप से स्थापित पैकेज होते हैं और जरूरी नहीं कि उनकी निर्भरता हो। उदाहरण के लिए, सिस्टम जानकारी रिपोर्टिंग के लिए एक उपकरण inxi देखें: यदि मैं केवल inxi प्रणाली / उपकरण पर रिपोर्ट में रुचि रखता हूं, तो PATH दो से तीन दर्जन अतिरिक्त कमांड लाइन उपकरण जोड़ना आवश्यक नहीं है। गुइक्स आपको उपयोगकर्ता की प्रोफ़ाइल में केवल वही दिखाने की अनुमति देता है जो उसे वास्तव में चाहिए।
  
• गुइक्स वातावरण: जब आप guix environment SOME-PACKAGES चलाते guix environment SOME-PACKAGES एक अस्थायी वातावरण स्थापित करते हैं जहाँ SOME-PACKAGES आवश्यकताओं के लिए SOME-PACKAGES । इसका उपयोग प्रोजेक्ट के लिए बिल्ड वातावरण, साथ ही अन्य उद्देश्यों के लिए आसानी से कॉन्फ़िगर करने के लिए किया जा सकता है (नीचे देखें)। एक महान गुणवत्ता - वे आपको उपयोगकर्ता प्रोफ़ाइल में स्थापित किए बिना प्रोग्राम चलाने की अनुमति देते हैं।
  
• आंशिक अद्यतन: 100% समर्थित। यह शायद आर्क लिनक्स और जेंटू जैसे फ्लोटिंग रिलीज़ में टूटने का मुख्य कारण है: चूंकि केवल एक ही समय (आमतौर पर केवल एक) पर कई संस्करणों का समर्थन किया जाता है, पूरे सिस्टम को एक पूरे के रूप में अपडेट किया जाना चाहिए। इसका मतलब है कि हर अपडेट के साथ अधिक ट्रैफ़िक। Guix के साथ, किसी भी पैकेज को व्यक्तिगत रूप से अपडेट किया जाता है।
  
• निरंतर एकीकरण या गुइक्स पैकेज मेंटेनर्स के बिना काम क्यों कर सकता है: प्रतिलिपि प्रस्तुत करने योग्य बिल्ड और आंशिक अपडेट के लिए समर्थन के लिए धन्यवाद, अगर पैकेज गुइक्स पर काम करता है, तो यह "हमेशा" काम करेगा और अगले निर्भरता के दौरान कुछ निर्भरता नहीं टूटेगी (अधिक सटीक रूप से, अगर निर्भरता पैकेज को तोड़ती है, तो) फिर यह पुस्तकालय के सही संस्करण का उपयोग करने के लिए तुच्छ रूप से तय किया गया है)। इस प्रकार, पैकेज के साथ काम को "असेंबली फ़ार्म" (निक्स परियोजना से हाइड्रा पर एक, कुइरास पर अन्य) में स्थानांतरित किया जा सकता है। इसकी तुलना अन्य जीएनयू / लिनक्स समुदायों से करें, जिन्हें हजारों पैकेजों के उन्नयन के लिए दर्जनों अनुरक्षकों की आवश्यकता होती है। यह दृष्टिकोण स्केल नहीं करता है: अंत में, ये वितरण कुछ हज़ार पैकेजों पर स्थिर हो जाते हैं। गुइक्स में, पैकेज की संख्या पतन के डर के बिना चुपचाप बढ़ सकती है। इसी समय, योगदानकर्ताओं का अधिक कुशलता से उपयोग किया जा सकता है।
  
  गुइक्स में, स्रोत से निर्माण करना उतना ही आसान है। वास्तव में, अंतिम उपयोगकर्ता के लिए यह इतना महत्वपूर्ण नहीं है: यदि तैयार पैकेज उपलब्ध नहीं है तो गुइक्स आसानी से स्रोतों से विधानसभा में लौट सकते हैं।
  
• guix import और guix refresh : पैकेज परिभाषाएँ स्वचालित रूप से और पुनरावर्ती रूप से बनाएँ या अपडेट करें। सैकड़ों परिभाषाएँ एक साथ संसाधित होती हैं। ऐसी विशेषताएं ओएस में एक वास्तविक प्रोग्रामिंग भाषा के लाभों पर जोर देती हैं। जो कि अधिकांश ऑपरेटिंग सिस्टम पर एक मुश्किल काम है, गुइक्स में इसे लागू करना अपेक्षाकृत आसान है।
  
• गुइक्स चैनल: मेरी पसंदीदा विशेषताओं में से एक! आर्क लिनक्स या जेंटू के लिए आपको एक स्थानीय रिपॉजिटरी बनाने की आवश्यकता होती है। चूंकि वे आंशिक अपडेट का समर्थन नहीं करते हैं, उपयोगकर्ता को समय-समय पर कुछ रखरखाव करने की आवश्यकता होती है (यानी, सुनिश्चित करें कि निर्भरता अपडेट पैकेज नहीं तोड़ते हैं)। गुइक्स चैनल लाभप्रद रूप से आर्क लिनक्स और जेंटू से एयूआर ओवरले को प्रतिस्थापित करते हैं, जिससे कोई भी अपने पैकेज की परिभाषाओं को वितरित कर सकता है, उदाहरण के लिए, गिट रिपॉजिटरी से। फिर, यह पूरी पारदर्शिता (किकबैक, इतिहास, आदि) की गारंटी देता है।
  
• Emacs-Guix : जहाँ तक मुझे पता है, Guix एकमात्र वितरण है जो सबसे शक्तिशाली Emacs उपयोगकर्ता इंटरफ़ेस के साथ आता है!
  
• गुइक्स पैक : डोकर जैसे कंटेनरों के लिए एक वास्तविक विकल्प। अधिकांश कंटेनर सिस्टम गंभीर समस्याओं से ग्रस्त हैं: उन्हें वापस नहीं खेला जा सकता है और वास्तव में वे अपारदर्शी बायनेरी हैं, जो उन उपयोगकर्ताओं के लिए स्पष्ट रूप से अस्वीकार्य है जो विश्वास, सुरक्षा और गोपनीयता की परवाह करते हैं। इसके विपरीत, गुइक्स पैक बिल्कुल स्पष्ट, प्रतिलिपि प्रस्तुत करने योग्य और पारदर्शी हैं।
  
• guix system vm और guix system disk-image : guix system disk-image इसे संपूर्ण वर्तमान प्रणाली को लाइव USB के रूप में, VM के अंदर या दूरस्थ मशीन पर चलाने के लिए तुच्छ बनाता है।

प्रतियोगियों के साथ तुलना में गुक्स

डेबियन, आर्क लिनक्स और अधिकांश अन्य GNU / लिनक्स वितरण

जीएनयू / लिनक्स वितरण में आमतौर पर गुइक्स के पूर्वोक्त लाभ नहीं होते हैं। सबसे महत्वपूर्ण कमियां:

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

जेंटू, * बीएसडी

पोर्टेज पैकेज मैनेजर के साथ जेंटू और अन्य वितरण में एक प्रसिद्ध विशेषता है: पूरे सिस्टम में कार्यों को सक्रिय करने के लिए USE झंडे (उदाहरण के लिए, म्यूट, GUI समर्थन सक्षम करें, आदि)।

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

तुलना करके, गुइक्स आपको पूरी तरह से सब कुछ अनुकूलित करने की अनुमति देता है, भले ही थोड़ा और योजना कोड के साथ। छद्म कोड में, यह कुछ इस तरह दिखता है:

 (loop-over (TARGET-PACKAGES) (package (inherit TARGET) (changes-here... including patches, build options, etc.)) 

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

मुझे गेंटू से प्यार था, लेकिन गुइक्स में जाने के बाद, पोर्टेज की सीमाएं स्पष्ट हो गईं।

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

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

व्यवहार में, गुइक्स पूर्व-संकलित पैकेज प्रदान करता है - जेंटू की तुलना में एक बड़ा समय बचाने वाला (हालांकि पोर्ट बाइनरी पैकेज वितरण का समर्थन करता है)।

* BSD सिस्टम (उदाहरण के लिए FreeBSD) make config में समान समस्याओं से ग्रस्त है।

सिफ़र

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

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

"अपनी प्रोग्रामिंग भाषा को लागू करना" सॉफ्टवेयर विकास में एक बहुत ही गलत धारणा है। इसने बहुत सी परियोजनाओं को प्रभावित किया जहां विन्यास या प्रोग्रामिंग भाषा को निम्नलिखित नुकसान हुए:

• सीमित अभिव्यक्ति और क्षमताओं;
  
• सीखने के लिए एक और भाषा (लेकिन कुछ बहुत उपयोगी और सार्वभौमिक नहीं), जिसे उपयोगकर्ता से कुछ प्रयास की आवश्यकता होती है और इस प्रकार, एक प्रवेश बाधा पैदा करता है;
  
• कम पठनीय कोड (कम से कम पहले);
  
• अक्सर खराब प्रदर्शन।

देसी या बहुत सीमित भाषाओं में बहुत सारी परियोजनाएँ हैं:

• XML, HTML (इससे भी बेहतर: S-XML )
• मेक, ऑटोकॉनफ, ऑटोमैटिक, सीमेक, आदि।
• बैश, Zsh, मछली (और भी बेहतर: Eshell या scsh )
• JSON, TOML, YAML
• OS पैकेज परिभाषाओं के लिए Nix Ebuild और कई अन्य वाक्यविन्यास नियमों का विवरण
• फ़ायरफ़ॉक्स जब XUL का इस्तेमाल किया (मोज़िला ने इसे छोड़ दिया है) और एक्सटेंशन के लिए अधिकांश अन्य होमग्रोन भाषाएं
• एसक्यूएल
• ऑक्टेव, आर, PARI / GP, अधिकांश वैज्ञानिक कार्यक्रम (जैसे सामान्य लिस्प, रैकेट और अन्य योजना)
• नियमित अभिव्यक्ति ( Emacs में आरएक्स , रैकेट में खूंटी , आदि)
• sed, AWK, आदि।
• सिस्टमिट सहित अधिकांश इनिट कॉन्फ़िगरेशन, (और भी बेहतर: जीएनयू शेफर्ड )
• क्रोन (इससे भी बेहतर: mcron )
• शंकु (पूरी तरह से प्रोग्राम करने योग्य नहीं है, हालांकि यह एक समान कार्यक्रम की सबसे प्रत्याशित विशेषता होनी चाहिए)
• TeX, LaTeX (और सभी डेरिवेटिव), Asymptote (और भी बेहतर: स्क्रिबल , स्क्रीबीलो ) अभी भी विकास में है; जनवरी 2019 तक, TeX / LaTeX अभी भी पीडीएफ तैयार करने में एक मध्यवर्ती कदम के रूप में उपयोग किया जाता है)
• कॉन्फ़िगरेशन वाले अधिकांश प्रोग्राम जो सामान्य-प्रयोजन प्रोग्रामिंग भाषा का उपयोग नहीं करते हैं।

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

सिर्फ डेस्कटॉप के लिए नहीं

Guix कई आर्किटेक्चर (i686, x86_64, ARMv7, और AArch64 जनवरी 2019 तक) का समर्थन करता है, और लिनक्स इकोसिस्टम के बाहर अधिक कोर का समर्थन करने की योजना बनाता है (चलो कहते हैं * बीएसडी, जीएनयू हर्ड, या शायद आपका अपना सिस्टम!)।

यह Guix को तैनात (प्रतिलिपि प्रस्तुत करने योग्य) सर्वर और अन्य विशेष प्रणालियों के लिए एक महान उपकरण बनाता है। मुझे लगता है कि एम्बेडेड सिस्टम में, Guix OpenWRT के साथ बहुत अच्छी तरह से प्रतिस्पर्धा कर सकता है (हालांकि यह एम्बेडेड सिस्टम को पोर्ट करने के लिए कुछ काम लेगा)।

स्व-पुनरुत्पादन लाइव यूएसबी

ऊपर, मैंने guix system disk-image उल्लेख किया है: उदाहरण के लिए, यह आपको USB फ्लैश ड्राइव पर वर्तमान सिस्टम को फिर से बनाने की अनुमति देता है।

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

जाहिर है, क्लोनिंग उस मशीन से आगे काम करती है जिस पर क्लोन स्थापित होता है: "नग्न" गुइक्स के बजाय, एक पूर्ण ओएस तैनात है, काम करने के लिए तैयार है।

अन्य पैकेज प्रबंधकों की जगह

Emacs, Python, Ruby ... और guix environment की शक्ति

गुइक्स प्रोग्रामिंग भाषाओं के पैकेज प्रबंधकों सहित किसी भी पैकेज प्रबंधक को बदल सकता है। इसके कई फायदे हैं:

• सर्वव्यापी प्रजनन।
  
• सर्वव्यापी रोलबैक।
  
• कोई और पैकेज मैनेजर सीखने की जरूरत नहीं है।

इस बिंदु पर, आपको guix environment उल्लेख करना चाहिए। यह कमांड virtualenv तरह केवल एक विशिष्ट सेट के साथ एक अस्थायी वातावरण सेट करता है। हत्यारा विशेषता यह है कि यह सभी भाषाओं और उनके संयोजन के लिए सार्वभौमिक है।

TeXlive

(डिस्क्लेमर: जनवरी 2019 तक, गुक्स के लिए TeXlive बिल्ड सिस्टम को नया रूप दिया जा रहा है)।

TeXlive को एक विशेष उल्लेख प्राप्त हुआ क्योंकि यह विशेष रूप से भयानक है :), जो एक बार फिर गुइक्स की बचत भूमिका की पुष्टि करता है!

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

वैकल्पिक रूप से, आप TeXlive को मैन्युअल रूप से स्थापित कर सकते हैं, लेकिन इसका सामना करते हैं: tlmgr सिर्फ एक बुरा पैकेज प्रबंधक है, और इसके लिए थकाऊ अतिरिक्त कार्य की आवश्यकता होती है।

Guix का उपयोग करते हुए, TeXlive पैकेज अलग से स्थापित किए जाते हैं, जैसे कि सब कुछ, जो आपको TeXlive पैकेज के अपने सेट को बनाए रखने में मदद करता है या यहां तक ​​कि विशिष्ट दस्तावेज़ों को संकलित करने के लिए वर्चुअल वातावरण विनिर्देश भी बनाता है।

कोर

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

जेंटू को अनुशंसित (अनिवार्य?) स्थापना चरण के रूप में उपयोगकर्ता कर्नेल को "आवश्यक" करने के लिए जाना जाता है। हालांकि, यह शायद ही एक शर्त है, और उपयोगकर्ताओं को स्वयं कर्नेल कॉन्फ़िगरेशन का समर्थन करना चाहिए।

गुइक्स में, कर्नेल किसी भी अन्य की तरह एक पूरी तरह से अनुकूलन नियमित पैकेज है। आप सब कुछ कॉन्फ़िगर कर सकते हैं और कर्नेल कॉन्फ़िगरेशन फ़ाइल को पैकेज परिभाषा में पास कर सकते हैं।

उदाहरण के लिए, निम्नलिखित iwlwifi ड्राइवर के साथ एक गैर-मुक्त लिनक्स कर्नेल की परिभाषाएं हैं (चेतावनी: मैं दृढ़ता से मालिकाना ड्राइवरों का उपयोग करने की सलाह नहीं देता, क्योंकि वे आपकी गोपनीयता और स्वतंत्रता के लिए एक गंभीर खतरा पैदा करते हैं):

 (define-module (ambrevar linux-custom) #:use-module (guix gexp) #:use-module (guix packages) #:use-module (guix download) #:use-module (guix git-download) #:use-module (guix build-system trivial) #:use-module ((guix licenses) #:prefix license:) #:use-module (gnu packages linux) #:use-module (srfi srfi-1)) (define-public linux-nonfree (package (inherit linux-libre) (name "linux-nonfree") (version (package-version linux-libre)) (source (origin (method url-fetch) (uri (string-append "https://www.kernel.org/pub/linux/kernel/v4.x/" "linux-" version ".tar.xz")) (sha256 (base32 "1lm2s9yhzyqra1f16jrjwd66m3jl43n5k7av2r9hns8hdr1smmw4")))) (native-inputs `(("kconfig" ,(local-file "./linux-custom.conf")) ,@(alist-delete "kconfig" (package-native-inputs linux-libre)))))) (define (linux-firmware-version) "9d40a17beaf271e6ad47a5e714a296100eef4692") (define (linux-firmware-source version) (origin (method git-fetch) (uri (git-reference (url (string-append "https://git.kernel.org/pub/scm/linux/kernel" "/git/firmware/linux-firmware.git")) (commit version))) (file-name (string-append "linux-firmware-" version "-checkout")) (sha256 (base32 "099kll2n1zvps5qawnbm6c75khgn81j8ns0widiw0lnwm8s9q6ch")))) (define-public linux-firmware-iwlwifi (package (name "linux-firmware-iwlwifi") (version (linux-firmware-version)) (source (linux-firmware-source version)) (build-system trivial-build-system) (arguments `(#:modules ((guix build utils)) #:builder (begin (use-modules (guix build utils)) (let ((source (assoc-ref %build-inputs "source")) (fw-dir (string-append %output "/lib/firmware/"))) (mkdir-p fw-dir) (for-each (lambda (file) (copy-file file (string-append fw-dir (basename file)))) (find-files source "iwlwifi-.*\\.ucode$|LICENSE\\.iwlwifi_firmware$")) #t)))) (home-page "https://wireless.wiki.kernel.org/en/users/drivers/iwlwifi") (synopsis "Non-free firmware for Intel wifi chips") (description "Non-free iwlwifi firmware") (license (license:non-copyleft "https://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/tree/LICENCE.iwlwifi_firmware?id=HEAD")))) 

कस्टम कर्नेल और फर्मवेयर को वर्तमान सिस्टम कॉन्फ़िगरेशन (कुछ config.scm फ़ाइल) में सशर्त रूप से शामिल किया जा सकता है:

 (define *lspci* (let* ((port (open-pipe* OPEN_READ "lspci")) (str (get-string-all port))) (close-pipe port) str)) (operating-system (host-name "...") ;;... (kernel (cond ((string-match "Network controller: Intel Corporation Wireless 8888" *lspci*) linux-nonfree) (#t linux-libre))) (firmware (append (list linux-firmware-iwlwifi) %base-firmware)) 

फिर एक नया सिस्टम कॉन्फ़िगरेशन स्थापित करने के लिए इन चरणों का पालन करें:

 sudo -E guix system reconfigure config.scm 

यहां तक ​​कि एक नया कर्नेल स्थापित किए बिना, आप सीधे यूएसबी ड्राइव से बूट करने के लिए तैयार छवि बना सकते हैं।

खेल

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

दुर्भाग्य से, गेमिंग उद्योग एक मुफ्त सॉफ्टवेयर दर्शन से दूर है, और बहुत कम गेम आधिकारिक गुइक्स परियोजना के हिस्से के रूप में पैक किए गए हैं।

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

कुछ लाभ:

• guix environment आपको एक पृथक कंटेनर में किसी भी एप्लिकेशन को चलाने की अनुमति देता है जो नेटवर्क तक पहुंच को प्रतिबंधित करता है, फ़ाइल सिस्टम को छुपाता है (कोई जोखिम नहीं है कि मालिकाना कार्यक्रम आपकी कुछ फ़ाइलों को चोरी कर देगा, जैसे कि बिटकॉइन वॉलेट या पीजीपी कुंजी) और यहां तक ​​कि सिस्टम-स्तरीय जानकारी जैसे उपयोगकर्ता नाम के रूप में। यह किसी भी अविश्वसनीय बंद स्रोत कार्यक्रम को चलाने के लिए आवश्यक है।
  
• कार्यात्मक पैकेज प्रबंधन: बंद-स्रोत कार्यक्रम आमतौर पर समय की कसौटी पर खड़े नहीं होते हैं और तब टूटते हैं जब एक पुस्तकालय निर्भरता अपने एपीआई को बदल देती है। चूंकि गुइक्स किसी भी निर्भरता के किसी भी संस्करण के शीर्ष पर संकुल को परिभाषित करता है (वर्तमान प्रणाली के साथ संघर्ष के बिना), गुइक्स आपको बंद स्रोत कोड वाले खेलों के लिए पैकेज बनाने की अनुमति देता है जो हमेशा के लिए काम करेंगे।
  
• Reproducible पर्यावरण: बंद-स्रोत कार्यक्रम आमतौर पर खराब तरीके से पोर्ट किए जाते हैं और थोड़ा अलग निर्भरता वाले सिस्टम पर अलग तरह से व्यवहार कर सकते हैं। गुइक्स की प्रजनन योग्यता का तात्पर्य यह है कि यदि हम गुइक्स पैकेज को एक बार काम करते हैं, तो यह हमेशा काम करेगा (हार्डवेयर ब्रेकडाउन या हार्डवेयर कॉन्फ़िगरेशन परिवर्तन को छोड़कर)।

इन कारणों से, गुइक्स बंद-सोर्स गेम को पैकेजिंग और वितरित करने के लिए एक आदर्श उपकरण है।

हालाँकि, यह एक बड़ा अलग विषय है, जो किसी अन्य लेख के लिए बेहतर है।

टिप्स और ट्रिक्स

Emacs-Guix

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

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

हेल्म सिस्टम पैकेज इंटरफ़ेस भी है, जो आंशिक रूप से Emacs-Guix के साथ ओवरलैप होता है, लेकिन यह मुझे त्वरित पैकेज खोजों और त्वरित संचालन के लिए अधिक सुखद लगता है।

डेटा भंडारण

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

मेरे अनुभव में, 2018 में, 25 जीबी विभाजन को महीने में एक बार साफ करना पड़ता था (इस बात को ध्यान में रखते हुए कि मेरे पास पैकेजों की संख्या के बारे में बड़े अनुरोध हैं), और पूरे वर्ष के लिए 50 जीबी विभाजन को अप्राप्य छोड़ा जा सकता है।

स्टोरेज को साफ करने के लिए कमांड का उपयोग करना सुविधाजनक है guix gc, लेकिन यह "बहुत सारे पैकेज" को हटा सकता है, अर्थात, ऐसे पैकेज जिन्हें अगले अपडेट के दौरान तुरंत जरूरत होगी।

Emacs-Guix में एक कमांड है mx guix-store-dead-itemजो आकार के अनुसार मृत पैकेजों को क्रमबद्ध करता है और आपको उन्हें व्यक्तिगत रूप से हटाने की अनुमति देता है।

यदि आपको निर्भरता का विश्लेषण करने की आवश्यकता है, तो देखें guix gc --referencesऔर guix gc --requisites। यह guix build ...निर्भरता ग्राफ के विभिन्न तत्वों को देखने के लिए आउटपुट के साथ जोड़ा जा सकता है ।

उदाहरण के लिए, बिल्ड स्क्रिप्ट में से किसी एक के लिए कोड देखने के लिए, निम्नलिखित कमांड द्वारा दी गई फ़ाइल खोलें:

 $ guix gc --references $(guix build -d coreutils) | grep builder /gnu/store/v02xky6f5rvjywd7ficzi5pyibbmk6cq-coreutils-8.29-guile-builder 

उदासीन पीढ़ी

किसी प्रोफ़ाइल में इंस्टॉल किए गए सभी पैकेजों के प्रकटन को उत्पन्न करने के लिए अक्सर उपयोगी होता है ।

यह निम्न लिपि का उपयोग करके किया जा सकता है:

 (use-modules (guix profiles) (ice-9 match) (ice-9 pretty-print)) (match (command-line) ((_ where) (pretty-print `(specifications->manifest ',(map manifest-entry-name (manifest-entries (profile-manifest where)))))) (_ (error "Please provide the path to a Guix profile."))) 

उदाहरण के लिए, इसे अपनी प्रोफ़ाइल पर चलाएँ ~/.guix-profile:

 $ guile -s manifest-to-manifest.scm ~/.guix-profile 

मेरे dotfiles स्थापित संकुल के इतिहास को ट्रैक करते हैं। चूंकि मैं गुइक्स का संस्करण भी रखता हूं, इसलिए मैं अतीत में किसी भी समय अपने सिस्टम की सटीक स्थिति में लौट सकता हूं।

संदर्भ

कुछ वेब इंटरफेस:

• Guix पैकेज सूची
  
• त्रुटि संदेश ट्रैकर
  
• इच्छाओं

दस्तावेज:

• जीएनयू गुइक्स "स्टेजिंग" कोड ( लिस्प ने विकास में एक महत्वपूर्ण भूमिका क्यों निभाई)
  
• पीटर के नोट्स

अनौपचारिक पैकेज:

• क्रोमियम पैकेज चैनल
  
• ओलेग पायखलोव के पैकेज