अक्सर पूछे जाने वाले प्रश्न: ओएस इन्फर्नो क्या है और इसकी आवश्यकता क्यों है?मैंने वादा किया था, लेकिन अभी तक एक पोस्ट नहीं लिखा है कि इन्फर्नो को कैसे स्थापित करें और चलाएं, और अविश्वसनीय चीजें करें; मैंने इसे लेखों की एक श्रृंखला में शामिल किया, जिनमें से यह पहला, परिचयात्मक हिस्सा है। मैं नाम स्थान के बारे में थोड़ी बात करने जा रहा हूं। यह OS का एक महत्वपूर्ण हिस्सा है, और उन चीजों में से एक है जो प्लान 9 और इनफर्नो को वर्तमान में आपके कंप्यूटर पर चलने वाले से बहुत अलग बनाते हैं।
इन्फर्नो बहुत कम जाना जाता है, और मुझे उसका प्रचार करने का कोई इरादा नहीं है। मैं इतिहास और व्यवहार के बीच की खाई को कम करने में मदद करना चाहता हूं, यह समझाने के लिए कि इन्फर्नो का उपयोग कैसे किया जाए, और यह काम करने के तरीके को क्यों करता है।
मुझे थोड़ा किनारा करना होगा। मैं नामस्थानों के विकास के बारे में बात करने जा रहा हूं, न कि कालानुक्रमिक क्रम में, बल्कि सुविधाओं के विकास के क्रम में, और फिर दिखाते हैं कि इन्फर्नो की क्षमताओं का उपयोग कैसे किया जाए।
सामग्री
डॉस
डॉस याद है? आपके पास A: और B: आपके ड्राइव हैं। सी था:, आपकी हार्ड ड्राइव, आदि। इनमें से प्रत्येक ड्राइव पर आपके पास एक निर्देशिका पदानुक्रम थी। (हम अनावश्यक विवरणों को छोड़ देते हैं।) आप इसे एक सपाट, ऊपरी-स्तरीय, एकल-अक्षर, लोहे से बंधे नामस्थान के रूप में सोच सकते हैं। एक ड्राइव - एक पत्र।
यूनिक्स, लिनक्स
हालांकि, यूनिक्स में, शीर्ष-स्तरीय निर्देशिका थी, "/"। एक रूट डिस्क वहां लगाई गई थी, और अन्य सभी डिस्क रूट निर्देशिका के उपनिर्देशिकाओं में, उपनिर्देशिकाओं की उपनिर्देशिकाओं में लगाए गए थे - आप इस डिस्क को कहाँ देखना चाहेंगे। आपको यह जानने की आवश्यकता नहीं है कि विभाजन या डिस्क क्या है, जब तक कि आप सिस्टम को स्थापित करने में शामिल नहीं थे या विभाजन में से एक मुक्त स्थान से बाहर नहीं चला था। आप इसे पूरे ओएस के लिए एक पदानुक्रमित नाम स्थान के रूप में सोच सकते हैं।
यह बहुत अधिक लचीला और शक्तिशाली दृष्टिकोण है। प्रोग्राम और उपयोगकर्ताओं को यह जानने की आवश्यकता नहीं है कि किस ड्राइव पर है।
बाद में, यूनिक्स में एक नई प्रकार की फ़ाइल प्रणाली दिखाई दी: सिंथेटिक। उदाहरण के लिए, / खरीद। लिनक्स में / sys भी है, और यह सिंथेटिक फ़ाइल सिस्टम के लिए / dev के लिए भी असामान्य नहीं है। कोई भौतिक डिस्क नहीं है जिस पर इन फ़ाइल सिस्टम की फ़ाइलों को संग्रहीत किया जाएगा, लेकिन, फिर भी, कार्यक्रमों को इसके बारे में कुछ भी जानने की आवश्यकता नहीं है। फ़ाइलें किसी भी अन्य फ़ाइलों की तरह नामस्थान में दिखाई देती हैं, और इन फ़ाइल सिस्टम पर फ़ाइलों को पढ़ने या लिखने में सक्षम होने के लिए कार्यक्रमों को संशोधित करने की आवश्यकता नहीं है।
एक अर्थ में, उनके बीच फ़ाइल सिस्टम हैं, जो हालांकि, वे हमेशा की तरह डिस्क पर फ़ाइलों को संग्रहीत करते हैं, उपयोगकर्ता शायद यह नहीं जान सकता है या साबित नहीं कर सकता है। उदाहरण के लिए, एनएफएस एक दूरस्थ सेवा है जिसमें फ़ाइलों और निर्देशिकाओं का एक पदानुक्रम है।
अगला ऊपर
FUSE है , जो यूजर स्पेस में फाइल सिस्टम प्रदान करता है। स्थानीय OS कर्नेल के साथ इंटरएक्ट करने के लिए FUSE का उपयोग करना, और जो आप ड्राइवर के लिए लिखने जा रहे थे उसे लागू करना, आप किसी भी सिंथेटिक फ़ाइल सिस्टम के लिए एक सेवा बना सकते हैं - बिना ओएस कर्नेल के लिए एक वास्तविक ड्राइवर लिखने के लिए। (मैं बीएसडी को रोक लेता हूं; ऐसा लगता है कि प्लान 9 से कम विशेषताएं थीं, हालांकि
ड्रैगनफली ने कुछ दिलचस्प विचार विकसित किए हैं)।
दूसरी ओर, चूंकि नेमस्पेस पूरे सिस्टम के लिए सामान्य है, इसलिए आपको इसे संशोधित करने के लिए रूट होने की आवश्यकता है। एक यादृच्छिक उपयोगकर्ता की कल्पना करें, जिसने umount कमांड के ऊपर / sbin के ऊपर कुछ चढ़ाया हो। कस्टम माउंट एक मामूली अपवाद हैं, एक अर्थ में एक बैसाखी है जो मौलिक रूप से कुछ भी नहीं बदलता है: आप किसी भी _ your निर्देशिका में FUSE फ़ाइल सिस्टम को माउंट कर सकते हैं। (वैसे, लिनक्स में 9P2000 के लिए एक ड्राइवर है, जो कि प्रोटोकॉल प्लान 9 और इन्फर्नो द्वारा उपयोग किया जाता है।)
पहले, फ़ाइल सिस्टम केवल एक ही स्थान पर रखा जा सकता था। लिनक्स "बिंद माउंट" थोड़ा अधिक लचीलापन प्रदान करता है - अगर फ़ाइल सिस्टम (या इसका कुछ हिस्सा) पहले से ही नाम स्थान में कहीं उपलब्ध है, तो इसे
mount --bind माध्यम से किसी अन्य स्थान से जोड़ा जा सकता है। यह एक अपेक्षाकृत हालिया जोड़ है, और 2.6.26 कर्नेल से पहले रीड-राइट मोड में एक ही फाइल सिस्टम को एक जगह और एक ही समय में दूसरे में केवल-रीड मोड में माउंट करना असंभव था।
योजना 9, इन्फर्नो
योजना 9 और इन्फर्नो ने ऐतिहासिक यूनिक्स शब्दार्थ के कई बड़े हिस्से लिए और उन्हें खिड़की से बाहर फेंक दिया, कुछ मुख्य ओएस मान्यताओं को बाहर निकाल दिया, धारणाएं जो काफी हद तक निहित और अंतर्निहित थीं। मैं अब इन्फर्नो के बारे में बात कर रहा हूं, लेकिन यह लगभग सभी पर लागू होता है (और पहली बार दिखाई देता है) योजना 9. जब मैं कहता हूं "इनफर्नो" में आप सुरक्षित रूप से कोष्ठक में जोड़ सकते हैं "और योजना 9 में"। इन धारणाओं को किसी विशेष क्रम में इंगित नहीं किया गया है; मैंने उन्हें सुविधा के लिए गिना है।
पहली धारणा, जिसे तोड़ना सबसे आसान था, और शायद रेट्रोस्पेक्ट में सबसे स्पष्ट, नाम में फाइलें और निर्देशिका डिस्क पर ऑब्जेक्ट का प्रतिनिधित्व करती हैं।
दूसरी धारणा यह है कि फ़ाइल सिस्टम और आरोह बिंदुओं के बीच एक-से-एक संबंध है। यानी यह फ़ाइल सिस्टम केवल एक स्थान पर जुड़ा हुआ है, और यह केवल एक फ़ाइल सिस्टम इस स्थान से जुड़ा है। इस धारणा से छुटकारा पाने का मतलब है कि फाइल सिस्टम और वह स्थान जहां यह जुड़ा हुआ है एक दूसरे से स्वतंत्र हैं, और यह कि किसी भी संख्या में फाइल सिस्टम एक ही जगह से जुड़ा हो सकता है।
तीसरी धारणा यह है कि एक रनिंग सिस्टम और एक नेमस्पेस के बीच एक-से-एक संबंध है। यदि नामस्थान परिवर्तन केवल उस प्रक्रिया के लिए दिखाई देते हैं जो नाम स्थान और उसके वंश को बदल दिया है, तो उपयोगकर्ताओं को अन्य उपयोगकर्ताओं द्वारा किए गए नाम स्थान परिवर्तन से बचाने की कोई आवश्यकता नहीं होगी, और कौन और कहां जा सकता है, इस पर प्रतिबंध। उपयोगकर्ता के पास इसे माउंट करने के लिए फ़ाइल सिस्टम को पढ़ने का अधिकार होना पर्याप्त है।
नामस्थान के बारे में इन धारणाओं को फेंकने से बहुत अधिक शक्तिशाली प्रणाली प्राप्त करना संभव हो गया, और यह अंतर पहली नज़र में इतनी स्पष्ट रूप से दिखाई नहीं दे सकता है, लेकिन वास्तव में यह डॉस और यूनिक्स नामस्थान के बीच का अंतर जितना बड़ा है।
इन तीनों धारणाओं का यूनिक्स जैसे ऑपरेटिंग सिस्टम में अलग-अलग डिग्री और सफलता की अलग-अलग डिग्री तक उल्लंघन किया गया। पहली धारणा यूनिक्स पर सफलतापूर्वक टूट गई थी। आपके पास / उदाहरण के लिए, लगभग सभी यूनिक्स पर है। FUSE ने उपयोगकर्ताओं को फ़ाइल सिस्टम को माउंट करने की अनुमति दी, यहां तक कि उन्हें (आदर्श रूप से, निश्चित रूप से नहीं) छिपाया, अन्य उपयोगकर्ताओं से, जो व्यक्तिगत नामस्थान का एक उदाहरण दिया, लगभग तीसरी धारणा का उल्लंघन किया। बाइंड माउंट्स ने नामस्थान के एक हिस्से को कहीं और प्रकट करना संभव बना दिया, दूसरी धारणा के उल्लंघन के लिए, लेकिन रूट की आवश्यकता थी। यूनियन मेट्स ने भी यूनिक्स की तरह अपना रास्ता बनाया। लेकिन, पहली धारणा के अपवाद के साथ, ये सभी समाधान पूर्ण नहीं हैं। क्या होगा अगर हम यूनिक्स सामान ले जाने के बिना बहुत शुरुआत से शुरू करते हैं?
चूंकि प्रत्येक प्रक्रिया का नाम स्थान अब अपना है (अधिक सटीक, कोई भी प्रक्रिया, लेकिन नाम स्थान को कांटा नहीं जा सकता है), कोई भी कहीं भी कुछ भी माउंट कर सकता है, या कहीं भी कुछ भी कनेक्ट (बाइंड) कर सकता है, बिना किसी समस्या के। सुरक्षा। चूंकि आरोह बिंदु में किसी भी माउंटेड सिस्टम की संख्या हो सकती है, और सभी एक साथ सुलभ होंगे, एक फाइल सिस्टम को दूसरे पर ओवरले करना संभव हो जाता है। चूँकि कोई भी फाइल सिस्टम "वास्तविक" या "सिंथेटिक" हो सकता है जबकि यह उपयुक्त प्रोटोकॉल (9P2000 Inferno के मामले में) का उपयोग करता है, कुछ भी फाइल सिस्टम हो सकता है और कोई भी प्रोग्राम जो फाइलों के साथ काम करता है वह इसका उपयोग कर सकता है।
कई चीजें जो या तो हैक या कुटिल समाधान हैं वे अचानक गायब हो जाती हैं, क्योंकि उन्हें अब ज़रूरत नहीं है। जाहिर है, जो कुछ रूट करने के लिए दिया गया है, उसकी अब सुडो की तरह जरूरत नहीं है। चुरोट की अब जरूरत नहीं है। प्रतीकात्मक लिंक की जरूरत नहीं है। ओएस के कर्नेल में निर्मित बड़ी संख्या में ड्राइवरों की आवश्यकता नहीं है। एनएसएफ और / आदि / निर्यात की जरूरत नहीं है (अच्छा रिडांस)।
mount -o loop जरूरत नहीं है।
mount --bind जरूरत नहीं है। FUSE की जरूरत नहीं है। यहां तक कि $ PATH की अब आवश्यकता नहीं है, और इसके साथ सॉफ़्टवेयर स्थापित करने के लिए रूट होने की आवश्यकता है।
... अच्छा?
इनफर्नो (और प्लान 9) के लिए दस्तावेज़ीकरण में मुझे गुस्सा करने वाली चीजों में से एक यह है कि वैज्ञानिक लेख, मैन पेज, स्रोत कोड हैं, लेकिन लगभग कोई पाठ्यपुस्तक या दस्तावेज़ नहीं हैं। शायद मैं उस लिनक्स से खराब हो गया हूं जो
HOWTO के साथ आता है कि
कॉफी कैसे बनाते हैं । आरंभ करना आसान काम नहीं है, खासकर यदि आप सिस्टम के बारे में पर्याप्त नहीं जानते हैं कि सिस्टम का उपयोग खुद का अध्ययन करने के लिए करें। आप कोशिश करते हैं, लेकिन एक अपरिचित शेल है जो अपरिचित कमांड चलाता है, और संदर्भ के रूप में लिखे गए मानव-पृष्ठ वास्तव में मदद नहीं करते हैं।
तो मैं इस प्रश्न का उत्तर देने की कोशिश कर रहे दस्तावेज़ का मूल्यांकन कर सकता हूं “अच्छा? मैंने पहले भी लुभावने वादे सुने हैं। मैं इसका उपयोग कैसे कर सकता हूं? ”और मैं कुछ विशिष्ट उदाहरणों के साथ यह बताने जा रहा हूं कि क्या हो रहा है।
अंत में, कुछ आप टाइप कर सकते हैं
इन सभी चीजों को याद रखें जिनकी अब आवश्यकता नहीं है? उनमें से प्रत्येक को कुछ बेहतर से बदल दिया गया है, और उनमें से कुछ को कई चीजों से बदल दिया गया है, जिनमें से प्रत्येक बेहतर है। मैं इन उदाहरणों में प्रमाणीकरण को अनदेखा करने के लिए (सादगी के लिए) जा रहा हूं, लेकिन मैं कहूंगा कि आपके पास इनफर्नो में प्रमाणीकरण और एन्क्रिप्शन विधियों का विकल्प है।
माउंट करने के लिए रूट की आवश्यकता नहीं है
यह बहुत आसान है:
bind '#p' /n/prog
यह / / n / prog में prog फ़ाइल सिस्टम (अनुरूप / खरीद) को मापता है। वैसे, आप प्रबंधन कर सकते हैं, डिबग कर सकते हैं और वह सब कुछ कर सकते हैं जो आमतौर पर यूनिक्स की तरह / प्रोग फाइल सिस्टम के माध्यम से चल रही प्रक्रियाओं के साथ होता है। अंतर यह है कि यदि आप दूरस्थ मशीन को स्थानीय रूप से माउंट / प्रोग करते हैं, तो आप इन सभी चीजों को दूरस्थ प्रक्रियाओं के साथ बिना किसी ssh के और यहां तक कि दूरस्थ मशीन पर चल रहे डिबगर के बिना भी कर सकते हैं। हां, आप स्थानीय रूप से
kill 15 को
kill 15 सकते हैं और यह रिमोट मशीन पर प्रक्रिया 15 को मार देगा।
माउंट-लूप और FUSE की जरूरत नहीं है
मेरे पास अपने कंप्यूटर पर .iso फ़ाइलों का एक गुच्छा है। मान लीजिए कि वे / एन / सीडी में हैं, और मैं उनमें से एक को जोड़ना चाहता हूं:
; 9660srv /n/cds/dfly-i386-3.0.2_REL.iso /n/dfly ; ls /n/dfly
अब वर्तमान प्रक्रिया और इसके वंशज इस सीडी की सामग्री देख सकते हैं। कुछ विशेष की आवश्यकता नहीं है;
9660srv (4) एक तरफ ISO-9660 फाइल सिस्टम को पढ़ना जानता है और दूसरी तरफ 9P2000 प्रोटोकॉल का समर्थन करता है।
Inferno भी उदाहरण के लिए,
tarfs (4) के साथ बंडल में आता है, जो टार आर्काइव को केवल-पढ़ने के लिए फ़ाइल सिस्टम के रूप में मानता है।
कोई कर्नेल ड्राइवर की आवश्यकता नहीं है
खैर, सबसे। वे जो केवल फ़ाइल सिस्टम को निर्यात नहीं करते हैं, और अंत में आप ioctl () के बारे में भूल सकते हैं। कर्नेल द्वारा प्रदान किए गए ड्राइवरों को / dev / ड्राइवरों फ़ाइल में देखा जा सकता है, और यह एक छोटी सूची है, जो कि विशिष्ट उबंटू या यहां तक कि आर्क मशीन पर
lsmod के आउटपुट से कम है।
जहां आपको अधिकांश ऑपरेटिंग सिस्टम पर नई फ़ाइल प्रणाली का समर्थन करने के लिए एक कर्नेल ड्राइवर की आवश्यकता होगी, Inferno को modprobe (और इस प्रकार रूट) की आवश्यकता नहीं है और एक नई फ़ाइल सिस्टम को जोड़ने के लिए कर्नेल को स्पर्श नहीं करता है। आप
ext2fs डाउनलोड करके ext2 (केवल पढ़ने के लिए) समर्थन प्राप्त कर सकते हैं, जैसे कि कर्नेल को उपरोक्त उदाहरण में ISO-9660 के बारे में जानने की आवश्यकता नहीं थी।
चुरोट की जरूरत नहीं है
चूंकि एक प्रक्रिया खुद के लिए एक नाम स्थान बना सकती है, एक अविश्वसनीय प्रक्रिया को दिखाने के लिए खतरनाक सब कुछ नामस्थान से
unmounted किया जा सकता है, और बढ़ते ड्राइवरों से प्रक्रिया को
रोकने के लिए
pctl (2) सिस्टम कॉल का उपयोग किया जा सकता है। एक चरम उदाहरण जो सब कुछ अनमाउंट करेगा (और इसलिए अंतर्निहित शेल कार्यक्षमता का उपयोग करने के अलावा कुछ भी नहीं कर सकता)
; load std ; pctl newns ; pctl nodevs ; unmount / ; ls / sh: ls: './ls' file does not exist
बेशक, आपको हर चीज को अनमाउंट करने की तुलना में थोड़ा अधिक सावधानी से काम करने की जरूरत है यदि आप कुछ उपयोगी चाहते हैं, लेकिन विचार स्वयं सरल है।
यदि आप रूट निर्देशिका में शीर्ष पर मेमोरी में फ़ाइल सिस्टम को माउंट करके चाहते हैं तो आप एक अस्थायी सैंडबॉक्स भी बना सकते हैं:
; mount -bc {memfs -s} / ; echo Mad with power! > /asdf
और, ज़ाहिर है, / asdf कहीं भी दिखाई नहीं देगा। (यह ध्यान दिया जाना चाहिए कि यह केवल नई फाइलें बनाने के लिए लागू होता है।)
सिमलिंक की जरूरत नहीं
बाइंड दूसरों की शीर्ष पर कुछ निर्देशिकाओं को रखने की क्षमता प्रदान करके इस समस्या को हल करता है। उदाहरण के लिए, मैं टिनिटक आइकन को डिफ़ॉल्ट आइकन से अधिक सेट करता हूं, इसलिए मैं विंडो मैनेजर शुरू करने से पहले डिफ़ॉल्ट आइकन को उनके साथ ओवरराइड करता हूं:
; bind -bc /icons/tinytk /icons/tk
तुम भी एक फ़ाइल दूसरे के ऊपर रख सकते हैं:
; echo Hello > some-file ; bind some-file /NOTICE ; cat /NOTICE Hello
चूंकि सिम्फ़िंक्स अनावश्यक और अनुपस्थित हैं, इन्फर्नो में, फ़ाइल सिस्टम में परिपत्र संदर्भों की समस्या लगभग गायब हो जाती है।
सॉफ्टवेयर स्थापित करने के लिए $ PATH, $ LDPATH और रूट विशेषाधिकारों की आवश्यकता नहीं है
मुझे $ PATH के साथ खिलवाड़ करने से नफरत है। मेरे .bashrc के बड़े हिस्से यह पता लगाने के बारे में हैं कि पहले कौन जाता है, और अन्य आर्किटेक्चर के लिए बायनेरिज़ की ओर निरर्थक रास्तों या रास्तों को जोड़ना नहीं है। मेरे पास
योजना 9 पोर्ट स्थापित है, लेकिन मैं उदाहरण के लिए, लिनक्स संस्करण के साथ संघर्ष के लिए योजना 9 मैन संस्करण नहीं चाहता।
इन्फर्नो में, आप जो कुछ भी चलाना चाहते हैं वह / डिस (/ प्लान 9 में बिन) है। यदि आप किसी अन्य स्थान से प्रोग्राम चलाना चाहते हैं, तो आप इसे पहले या बाद में / डिस प्लग कर सकते हैं।
; bind -bc $home/dis /dis
इसलिए यदि आप कुछ स्थापित करना चाहते हैं, लेकिन लिख / डिसाइड नहीं कर सकते हैं, तो आप जहाँ चाहें स्थापित करें, और इसे / डिस के ऊपर प्लग करें। sudo की आवश्यकता नहीं है। वही / देय / और मॉड्यूल के लिए जाता है।
NFS की जरूरत नहीं है
मैं प्रमाणीकरण (-एक ध्वज) और एन्क्रिप्शन को अनदेखा करने जा रहा हूं, इसलिए हम कुछ महत्वपूर्ण निर्यात करेंगे: फिर से
मेफ़्स (4) । पहली कार:
; mount -c {memfs -s} /n/mem ; echo something > /n/mem/asdf ; listen -A 'tcp!*!1234' { export /n/mem & }
दूसरी कार:
; mount -A 'tcp!thefirstmachine!1234' /n/remotememfs ; cat /n/remotememfs/asdf something
चूँकि अधिकांश फ़ाइल सर्वर कमांड एक आरोह बिंदु से जुड़ने के बजाय stdin / stdout के माध्यम से काम कर सकते हैं, फ़ाइल सिस्टम को इसे नेटवर्क पर पहुँच योग्य बनाने के लिए स्थानीय रूप से माउंट करने की आवश्यकता नहीं है:
; styxlisten -A 'tcp!*!1234' {memfs -s}
और दूसरी मशीन पर:
; mount -Ac 'tcp!thefirstmachine!1234' /n/remotememfs
सुनने (1) और डायल (1) कमांड / नेट फ़ाइल सिस्टम के साथ बातचीत के लिए सिर्फ आसान आवरण हैं, जो इन्फर्नो के लिए नेटवर्क इंटरफ़ेस है। यूनिक्स सॉकेट्स को बीएसडी सॉकेट्स लाइब्रेरी (संबंधित सिस्टम कॉल्स के साथ) द्वारा संभाला जाता है और इसका उपयोग करना अधिक कठिन होता है। आप नेटकट समकक्ष के रूप में सुन और डायल कर सकते हैं। styxlisten एक ही है, केवल एक बाइट स्ट्रीम के बजाय 9P2000 प्रोटोकॉल (इसे योजना 9 में स्वीकार किए जाने तक Styx भी कहा जाता है) को प्रसारित करने की उम्मीद है।
शक्तिशाली आदिम का मतलब है कि आपको कभी पछतावा नहीं होगा
यह सब कुछ छोटे आदेशों के साथ हासिल किया जाता है, जो खुद में इन्फर्नो सिस्टम कॉल के आसपास सिर्फ रैपर हैं। आपके पास
बाइंड (1), माउंट (1), और अनमाउंट (1) है । यदि आपको आत्मनिरीक्षण की आवश्यकता है, तो
ns (1) आपकी सहायता करेगा।
फ़ाइल सिस्टम के रूप में सभी ओएस ऑब्जेक्ट्स का प्रतिनिधित्व करने का मतलब है कि बिल्ली, sed और इको जैसे कार्यक्रमों का उपयोग किया जा सकता है, उदाहरण के लिए,
आईपी (3) फ़ाइल सिस्टम का उपयोग करके नेटवर्क तक पहुंच।
ftpfs (4) आपको एक इंटरैक्टिव क्लाइंट के बिना ls और cp का उपयोग करने की अनुमति देता है, जो स्क्रिप्ट के लेखन को सरल करता है (एफ़टीपी क्लाइंट के माध्यम से पुनर्निर्देशन की कोई आवश्यकता नहीं है)। वास्तव में, आपकी स्क्रिप्ट को आमतौर पर यह जानने की आवश्यकता नहीं होती है कि वे एफ़टीपी सर्वर के साथ काम करते हैं न कि डिस्क पर एक नियमित फ़ाइल के साथ।
zipfs आपको एक .zip फ़ाइल माउंट करने की अनुमति देता है। उन्हें संयोजित करके, आप .iso, जो कि अंदर है .zip, जो FTP सर्वर पर है, को माउंट कर सकते हैं और फिर उससे अलग-अलग फ़ाइलों को कॉपी कर सकते हैं।
भविष्य में कहीं
हम पहले से ही एक दिलचस्प बिंदु पर हैं। अधिकांश आबादी के पास कम से कम एक लैपटॉप और एक स्मार्टफोन है, और, उनमें से ज्यादातर के पास भी एक घर का कंप्यूटर है, काम पर एक कंप्यूटर है, एक टैबलेट, आदि। यूनिक्स के हेयड में, एक कंप्यूटर और कई उपयोगकर्ता थे। यह स्पष्ट लगता है, लेकिन हम जल्दी से उस बिंदु पर पहुंच रहे हैं जहां एक सामान्य मामला एक उपयोगकर्ता के लिए बहुत सारे कंप्यूटर होंगे और इसके विपरीत नहीं।
इन सभी संसाधनों (डिस्क और सीपीयू, विशेष रूप से) का प्रबंधन पहले से ही एक बड़ी समस्या है। फाइल सिंक, कॉन्टैक्ट सिंक आदि। यदि आपके फोन में किसी चीज़ को संसाधित करने के लिए पर्याप्त संसाधन नहीं हैं, तो आपको एक नियमित कंप्यूटर (शारीरिक रूप से या ssh) पर जाने की आवश्यकता है। यदि आप अपने फोन पर फिल्म देखना चाहते हैं, तो आपको इसे वहां कॉपी करना होगा। यदि आप अपने फोन पर एक लेख पढ़ते हैं और अपने लैपटॉप पर पढ़ना जारी रखने का निर्णय लेते हैं तो आप क्या करते हैं? अपने आप को एक ईमेल या आईएम भेजें? (यह अभी भी DBUS से बेहतर है, लेकिन यह एक विषयांतर है।)
मुझे नहीं लगता कि यह जारी रहेगा। एक अस्थायी समाधान के रूप में, आप अपने सभी डेटा को Google, फेसबुक या किसी भी "क्लाउड" सेवा को दे सकते हैं, लेकिन ऐसा समाधान वांछित होने के लिए बहुत कुछ छोड़ देता है (और कारणों को सूचीबद्ध करना एक और विषयांतर है)।
कंप्यूटिंग संसाधनों के प्रबंधन और इन सभी मशीनों (स्थानीय और दूरस्थ) के संयोजन की समस्या का एक सॉफ्टवेयर समाधान अपरिहार्य है। कम से कम, मैं एक मंच की भूमिका के लिए सबसे अच्छे उम्मीदवार के रूप में इन्फर्नो को देखता हूं जो यह सब संभव कर देगा। यदि यह पूरी तरह से स्पष्ट नहीं करता है कि मुझे अचानक इस प्रणाली से प्यार क्यों हुआ, तो कम से कम यह आंशिक रूप से करता है।
जारी रखा जाए
यह विवरण बहुत ही सतही है। "सब कुछ एक फाइल सिस्टम है" इनफर्नो पर बनने वाले महान विचारों में से एक है।