एलेक्सी फेडोरचुक
2005

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

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

यह स्थिति क्रॉस-प्लेटफ़ॉर्म एप्लिकेशन लिखना कठिन बना देती है। और इसलिए एक फ़ाइल पदानुक्रम मानकीकरण परियोजना - FHS (फ़ाइलसिस्टम पदानुक्रम मानक) सक्रिय रूप से विकसित हो रही है।

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

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

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

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

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

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

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

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

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

POSIX सिस्टम निर्देशिकाओं का एक विशिष्ट सेट

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

आप कमांड के साथ रूट डायरेक्टरी की संरचना देख सकते हैं

$ls -1/

जो किसी भी POSIX सिस्टम पर निर्देशिकाओं का एक निश्चित न्यूनतम सेट दिखाएगा:

बिन/ बूट/ आदि/ रूट/ sbin/

उनमें वे सभी फ़ाइलें होती हैं जिनके बिना सिस्टम अस्तित्व में नहीं रह सकता। अन्य निर्देशिकाएँ कुछ इस प्रकार हैं:

होम/ एमएनटी/ ऑप्ट/ टीएमपी/ यूएसआर/ वर/

वे a) आवश्यक नहीं हैं (कम से कम सैद्धांतिक रूप से - व्यवहार में उनके बिना ऐसा करना मुश्किल है), b) उनमें से प्रत्येक सभी प्रणालियों और वितरणों में मौजूद नहीं है, और c) उनमें से प्रत्येक हो सकता है (और अक्सर होता है - यदि आप सब कुछ समझदारी से करते हैं)) फ़ाइल ट्री की अपनी शाखा का आरोह बिंदु।

इसके अलावा, ज्यादातर मामलों में, POSIX-संगत ऑपरेटिंग सिस्टम के फ़ाइल सिस्टम के रूट में दो और उपनिर्देशिकाएँ होती हैं:

देव/प्रोक/

ये आम तौर पर वर्चुअल फ़ाइल सिस्टम के लिए माउंट पॉइंट होते हैं - क्रमशः डिवाइस और प्रक्रियाएं (हालांकि यदि डिवाइस फ़ाइल सिस्टम का उपयोग नहीं किया जाता है, तो /dev निर्देशिका रूट फ़ाइल सिस्टम का एक घटक होना चाहिए। अंत में, लिनक्स सिस्टम पर, एक नियम के रूप में) , फ़ाइल ट्री की जड़ में एक /lib निर्देशिका भी होती है, जो मुख्य सिस्टम लाइब्रेरीज़ के लिए होती है। और udev तंत्र का उपयोग करते समय, एक अपरिहार्य /sys निर्देशिका भी होती है, जिसमें sysfs वर्चुअल फ़ाइल सिस्टम माउंट किया जाता है।

रूट फ़ाइल सिस्टम

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

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

इसके अनुसार, मशीन की शुरुआत /boot और /etc निर्देशिका फ़ाइलों द्वारा सुनिश्चित की जाती है। पहले में सिस्टम कर्नेल शामिल है - एक "विशेष प्रयोजन" निष्पादन योग्य फ़ाइल - और इसे लोड करने के लिए आवश्यक सब कुछ: लिनक्स में, उदाहरण के लिए, यह सिस्टम मैप (फ़ाइल /etc/System.map) है, और फ्रीबीएसडी में - लोड करने योग्य कर्नेल मॉड्यूल. हालाँकि, कभी-कभी कर्नेल सीधे फ़ाइल सिस्टम के रूट पर स्थित होता है, और तब /boot निर्देशिका पूरी तरह से अनुपस्थित हो सकती है, और /modules निर्देशिका कर्नेल मॉड्यूल के लिए आवंटित की जा सकती है।

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

न्यूनतम आवश्यक कार्यक्षमता /bin और /sbin निर्देशिकाओं की सामग्री द्वारा प्रदान की जाती है - उनमें सबसे महत्वपूर्ण उपयोगकर्ता की निष्पादन योग्य फ़ाइलें होती हैं और सिस्टम प्रोग्राम, क्रमशः, वही जो आपको मरम्मत और बचाव उपायों का एक सेट पूरा करने और विफलता के बाद मशीन को मानव रूप में वापस लाने की अनुमति देगा।

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

POSIX प्रोग्राम चलाने के लिए (/bin और sbin निर्देशिकाओं में एकत्रित कार्यक्रमों सहित), एक नियम के रूप में, आपको सिस्टम-वाइड लाइब्रेरीज़ (मुख्य रूप से मुख्य glibc लाइब्रेरी) के कार्यों तक पहुंच की आवश्यकता होती है। और इसलिए (लगभग) रूट निर्देशिका का एक अनिवार्य घटक /lib उपनिर्देशिका है, जिसमें उन्हें एकत्र किया जाता है।

लिनक्स में, /lib निर्देशिका एक अन्य महत्वपूर्ण उद्देश्य को पूरा करती है - इसकी उपनिर्देशिका (/lib/modules) में लोड करने योग्य कर्नेल मॉड्यूल होते हैं (FreeBSD में उनका स्थान /boot/kernel निर्देशिका है)।

फ्रीबीएसडी में, /lib निर्देशिका रूट फ़ाइल सिस्टम में नहीं पाई जाती है - संबंधित घटक यहां /usr/lib में स्थित हैं (नीचे देखें)। ऐसा इसलिए है, क्योंकि ऐतिहासिक रूप से, फ्रीबीएसडी ने महत्वपूर्ण सिस्टम-वाइड प्रोग्राम बनाए ताकि उनके लिए आवश्यक लाइब्रेरी फ़ंक्शन उनके निष्पादन योग्य में बनाए जा सकें (स्थैतिक लिंकिंग के रूप में जाना जाता है, अध्याय 14 में चर्चा की गई है)। फ्रीबीएसडी शाखा 5 में, /bin और /sbin निर्देशिकाओं के प्रोग्राम गतिशील रूप से जुड़े हुए हैं, अर्थात, /usr निर्देशिका की अनुपस्थिति में (और फ्री में यह लगभग हमेशा फ़ाइल सिस्टम की एक अलग शाखा है), वे कार्य नहीं करते हैं . इसकी भरपाई के लिए, एक गैर-मानक /पुनर्स्थापना निर्देशिका प्रदान की जाती है, जिसमें समान प्रोग्राम होते हैं, लेकिन स्थिर रूप से जुड़े होते हैं (जैसा कि निर्देशिका के नाम से पता चलता है, इसकी सामग्री का एकमात्र उद्देश्य आपातकालीन बचाव कार्य है)।

और अंत में /root . यह उसी नाम के उपयोगकर्ता, यानी सिस्टम प्रशासक की सामान्य होम निर्देशिका है। चूँकि यह कोई व्यावहारिक कार्य नहीं करता है (या कम से कम इसे नहीं करना चाहिए), इसकी सामग्री केवल सुपरयूज़र की अपनी कॉन्फ़िगरेशन फ़ाइलें (उपयोगकर्ता का कमांड शेल, पसंदीदा संपादक, आदि) हैं।

शाखा/यूएसआर

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

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

लिनक्स में, /usr निर्देशिका उन सभी प्रोग्रामों (और उनके घटकों) के लिए एक भंडार के रूप में कार्य करती है जो मानक रूप से वितरण में शामिल हैं। और /usr/local उपनिर्देशिका आमतौर पर उन प्रोग्रामों के लिए होती है जो स्रोतों से स्वतंत्र रूप से संकलित होते हैं।

किसी भी स्थिति में, /usr निर्देशिका की सामान्य संरचना इस प्रकार है (ls -1 कमांड से आउटपुट के रूप में):

X11R6/ बिन/ आदि/ शामिल/ lib/ libexec/ स्थानीय/ sbin/ शेयर/ src/

जैसा कि पहले ही उल्लेख किया गया है, /usr/local उपनिर्देशिका फ़ाइल ट्री की एक अलग शाखा है, और इसलिए इस पर अलग से विचार किया जाएगा। अन्य निर्देशिकाओं का उद्देश्य इस प्रकार है:

/usr/bin और /usr/sbin उपयोगकर्ता और सिस्टम प्रोग्राम की निष्पादन योग्य फ़ाइलों के लिए अभिप्रेत हैं (यहां उनके बीच की सीमा रूट निर्देशिका के मामले की तुलना में और भी अधिक मनमाना है), जिसका उद्देश्य बुनियादी कामकाज सुनिश्चित करने से परे है प्रणाली;
/usr/etc व्यक्तिगत अनुप्रयोगों की कॉन्फ़िगरेशन फ़ाइलों के लिए है;
/usr/include में निष्पादन योग्य फ़ाइलों को लाइब्रेरी घटकों के साथ जोड़ने के लिए आवश्यक तथाकथित हेडर फ़ाइलें शामिल हैं;
/usr/lib और /usr/libexec साझा पुस्तकालयों के लिए निर्देशिकाएं हैं जिन पर उपयोगकर्ता एप्लिकेशन निर्भर करते हैं;
/usr/share - तथाकथित की एक विस्तृत विविधता के लिए एक कंटेनर। वास्तुशिल्प रूप से स्वतंत्र घटक: यहां आप विभिन्न प्रारूपों में दस्तावेज़ीकरण, कॉन्फ़िगरेशन फ़ाइलों के उदाहरण, कंसोल प्रबंधन कार्यक्रमों (फ़ॉन्ट, कीबोर्ड लेआउट) द्वारा उपयोग किए गए डेटा और समय क्षेत्रों के विवरण देख सकते हैं;
/usr/src - स्रोत कोड के लिए निर्देशिका; लिनक्स में, केवल सिस्टम कर्नेल के स्रोत कोड सामान्यतः यहां रखे जाते हैं, बीएसडी क्लोन में - पूरा स्थिरकॉम्प्लेक्स का स्रोत कोड, जिसे फ्रीबीएसडी में डिस्ट्रीब्यूशन कहा जाता है; एक नियम के रूप में, स्व-इकट्ठे कार्यक्रमों के स्रोत कोड को यहां रखना उचित नहीं है;
/usr/X11R6 - एक्स विंडो सिस्टम के घटकों के लिए निर्देशिका - निष्पादन योग्य फ़ाइलें (/usr/X11R6/bin), लाइब्रेरीज़ (/usr/X11R6/lib), हेडर (/usr/X11R6/include), दस्तावेज़ीकरण (/usr/ X11R6/ आदमी); एक्स एप्लिकेशन फ़ाइलें यहां नहीं रखी जानी चाहिए (विंडो प्रबंधकों के संभावित अपवाद के साथ) - उनका स्थान सिस्टम के आधार पर /usr, /usr/local या /opt में है।

इसके अलावा, /usr निर्देशिका में उपनिर्देशिकाएं /usr/var और /usr/tmp शामिल हो सकती हैं - आमतौर पर रूट निर्देशिका की संबंधित शाखाओं के प्रतीकात्मक लिंक। और कुछ लिनक्स वितरणों में, मुख्य सिस्टम-व्यापी दस्तावेज़ - मैन पेज - सीधे /usr (/usr/man उपनिर्देशिका में) में रखे जाते हैं।

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

शाखा/यूएसआर/स्थानीय

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

बिन/आदि/शामिल/lib/man/sbin/शेयर/

उपनिर्देशिकाओं की सामग्री भी समान है: निष्पादन योग्य प्रोग्राम फ़ाइलें (/usr/local/bin और /usr/local/sbin), उनकी कॉन्फ़िगरेशन (/usr/local/आदि), लाइब्रेरीज़ जिनके साथ वे जुड़े हुए हैं, और उनकी हेडर फ़ाइलें (/usr/ local/lib और /usr/local/include , क्रमशः), मैन पेज (/usr/local/man) और सभी प्रकार की आर्किटेक्चर-स्वतंत्र सामग्री (/usr/local/share), जिसमें अन्य प्रारूपों में दस्तावेज़ शामिल हैं .

शाखा/ऑप्ट

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

ऐतिहासिक रूप से, लिनक्स में /opt निर्देशिका का उद्देश्य व्यावसायिक अनुप्रयोगों और पूरी तरह से मुक्त प्रकृति के सभी प्रकार के कार्यक्रमों के लिए नहीं था। आजकल, इसका उद्देश्य बड़े आत्मनिर्भर सॉफ्टवेयर कॉम्प्लेक्स की मेजबानी करना है, जैसे कि क्यूटी लाइब्रेरी, केडीई अपने सभी घटकों और अनुप्रयोगों के साथ, ओपनऑफिस.org और इसी तरह। निर्देशिका संरचना इस प्रकार होनी चाहिए: /opt/pkg_name. यह मेरे सिस्टम (आर्क्लिनक्स) पर ऐसा दिखता है:

$ ls -1 /opt gnome/ kde/ OpenOffice.org1.1.2/ qt/

प्रत्येक उपनिर्देशिका की अपनी आंतरिक संरचना होती है:

$ ls -1 /opt/* /opt/gnome: bin/ lib/ man/ share/ /opt/kde: bin/etc/ include/ lib/ share/ /opt/OpenOffice.org1.1.2: सहायता/ लाइसेंस लाइसेंस। html प्रोग्राम/ README README.html setup@ शेयर/ [email protected] उपयोगकर्ता/ /opt/qt: बिन/ doc/ शामिल/ lib/ mkspecs/ वाक्यांशपुस्तकें/ प्लगइन्स/ टेम्पलेट्स/ अनुवाद/

/opt/pkg_name के अंदर उपनिर्देशिकाओं का उद्देश्य /usr और /usr/local के अनुरूप अनुमान लगाना आसान है। उदाहरण के लिए, /opt/kde/bin KDE सिस्टम और उसके अनुप्रयोगों की निष्पादन योग्य फ़ाइलों के लिए है, /opt/kde/etc इसकी कॉन्फ़िगरेशन फ़ाइलों के लिए है, /opt/kde/include हेडर फ़ाइलों के लिए है, /opt/kde/lib है पुस्तकालयों के लिए है और /opt/kde/share - दस्तावेज़ीकरण सहित साझा फ़ाइलों के लिए है। केडीई के पास मैन प्रारूप में दस्तावेज़ीकरण नहीं है, लेकिन यदि यह अस्तित्व में है, तो (जैसा कि गनोम के मामले में - मैंने इसे स्थापित नहीं किया था, जिम्प और इसी तरह के जीटीके अनुप्रयोगों ने इसे खींचा था) आप उपनिर्देशिका /opt/pkg_name/ देख सकते हैं आदमी ।

आप देख सकते हैं कि /opt निर्देशिका की संरचना समान घटकों को निर्देशिकाओं - निष्पादन योग्य फ़ाइलों, पुस्तकालयों आदि में संयोजित करने की ऐतिहासिक (और आंतरिक रूप से उचित POSIX-परंपरा) से भटकती है और इसमें बड़ी संख्या में प्रोग्राम स्थापित होने से, यह निश्चित बनाता है कठिनाइयाँ: आपको या तो वेरिएबल को $PATH मानों के साथ ओवरलोड करना होगा, जो कमांड तक त्वरित पहुंच प्रदान करता है (जिसकी चर्चा अध्याय 12 में की जाएगी), या एक विशेष निर्देशिका /opt/bin बनाएं और उसमें निष्पादन योग्य प्रोग्राम बायनेरिज़ के लिए प्रतीकात्मक लिंक रखें। इसलिए, कई लिनक्स वितरणों में (उदाहरण के लिए, CRUX में), निर्देशिका/ऑप्ट का उपयोग सिद्धांत के रूप में नहीं किया जाता है, जैसा कि सभी बीएसडी प्रणालियों में होता है। यह बहुत संभव है कि यह इस तरह से बेहतर हो...

/var शाखा

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

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

निर्देशिका /mnt

/mnt निर्देशिका, एक नियम के रूप में, हटाने योग्य मीडिया पर स्थित, अस्थायी रूप से उपयोग की जाने वाली फ़ाइल सिस्टम को माउंट करने के लिए अभिप्रेत है। पूरी तरह से स्थापित सिस्टम में, यह आमतौर पर खाली होता है, और इसकी संरचना किसी भी तरह से विनियमित नहीं होती है। उपयोगकर्ता अलग-अलग प्रकार के मीडिया के लिए इसमें उपनिर्देशिकाएँ बनाने के लिए स्वतंत्र है। उदाहरण के लिए, मेरे सिस्टम पर यह /mnt/cd, /mnt/dvd, /mnt/usb और /mnt/hd है - सीडी, डीवीडी, फ्लैश ड्राइव और हटाने योग्य हार्ड ड्राइव के लिए।

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

शाखा/घर

/होम निर्देशिका का उद्देश्य उपयोगकर्ता होम निर्देशिकाओं को शामिल करना है। इसकी सामग्री किसी भी तरह से विनियमित नहीं है, लेकिन आमतौर पर यह /home/(username1,...,username#) जैसा दिखता है। हालाँकि कई उपयोगकर्ताओं वाले बड़े सिस्टम पर उनकी होम निर्देशिकाओं को एक साथ समूहीकृत किया जा सकता है।

/होम निर्देशिका में न केवल वास्तविक बल्कि कुछ आभासी उपयोगकर्ताओं की होम निर्देशिकाएं भी शामिल हो सकती हैं। इसलिए, यदि मशीन का उपयोग वेब या एफ़टीपी सर्वर के रूप में किया जाता है, तो आप क्रमशः /home/www या /home/ftp जैसी उपनिर्देशिकाएँ देख सकते हैं।

शाखा/tmp

अस्थायी फ़ाइलों को संग्रहीत करने के लिए निर्देशिका - /tmp के बारे में बात करने के लिए एकमात्र चीज़ बची है। /var घटकों की तरह, वे विभिन्न कार्यक्रमों द्वारा उनके सामान्य कामकाज के हिस्से के रूप में उत्पन्न होते हैं। लेकिन, /var के विपरीत, /tmp घटकों को वर्तमान सत्र के बाहर सहेजे जाने की उम्मीद नहीं है। इसके अलावा, सभी सिस्टम प्रशासन मैनुअल इस निर्देशिका को नियमित रूप से (उदाहरण के लिए, मशीन को पुनरारंभ करते समय) या समय-समय पर साफ करने की सलाह देते हैं। और इसलिए, /tmp के रूप में, फ़ाइल सिस्टम को RAM - tmpfs (लिनक्स में) या mfs (FreeBSD में) में माउंट करने की सलाह दी जाती है। इस तथ्य के अलावा कि यह सुनिश्चित करता है कि रिबूट पर इसकी सामग्री साफ़ हो जाती है, यह प्रदर्शन में भी सुधार करता है, उदाहरण के लिए, उन प्रोग्रामों का संकलन जिनके अस्थायी उत्पाद डिस्क पर नहीं लिखे गए हैं, लेकिन /tmp/obj जैसी वर्चुअल निर्देशिका में रखे गए हैं।

कई प्रणालियों पर आपको /usr/tmp और /var/tmp जैसी निर्देशिकाएँ दिखाई देंगी। ये आमतौर पर /tmp के प्रतीकात्मक लिंक होते हैं।

फ़ाइल सिस्टम विभाजन रणनीति

फ़ाइल पदानुक्रम के बारे में बातचीत के समापन में, इस बात पर जोर दिया जाना चाहिए कि यह गारंटी दी जाती है कि केवल पैराग्राफ में सूचीबद्ध निर्देशिकाएं एक फ़ाइल सिस्टम पर स्थित होनी चाहिए (लाक्षणिक रूप से कहें तो, एक डिस्क विभाजन पर, हालांकि यह पूरी तरह से सटीक नहीं है) रूट फ़ाइल सिस्टम. अन्य सभी निर्देशिकाएँ - /usr, /opt, /var, /tmp और निश्चित रूप से, /home अलग-अलग भौतिक मीडिया या उनके विभाजन पर स्वतंत्र फ़ाइल सिस्टम के लिए माउंट पॉइंट का प्रतिनिधित्व कर सकती हैं।

इसके अलावा, स्थानीय नेटवर्क पर, ये निर्देशिकाएँ विभिन्न मशीनों पर भी स्थित हो सकती हैं। तो, एप्लिकेशन सर्वर के रूप में कार्य करने वाले एक कंप्यूटर में नेटवर्क पर साझा की गई /usr और /opt निर्देशिकाएं शामिल हो सकती हैं, दूसरे - एक फ़ाइल सर्वर - में सभी उपयोगकर्ता होम निर्देशिकाएं शामिल हो सकती हैं, इत्यादि।

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

जाहिर है, रूट फ़ाइल सिस्टम, जिसमें /bin, /boot, /etc, /root, /sbin निर्देशिकाएं शामिल हैं, जिसमें डेटा होता है जिसे वितरण मीडिया से आसानी से पुनर्स्थापित किया जा सकता है और व्यावहारिक रूप से अपरिवर्तनीय है, एक अलग डिस्क विभाजन पर स्थित होना चाहिए . लिनक्स पर, इसमें एक /lib निर्देशिका भी शामिल होनी चाहिए। दूसरी ओर, GRUB को बूटलोडर (ऑपरेटिंग सिस्टम की परवाह किए बिना) के रूप में उपयोग करते समय, /boot निर्देशिका को एक अलग विभाजन पर रखने की अनुशंसा की जाती है।

लिनक्स के बारे में पुराने स्रोतों में, आप /बूट निर्देशिका के लिए और डिस्क की शुरुआत में एक विभाजन आवंटित करने के एक अन्य कारण के बारे में पढ़ सकते हैं: 1023 से अधिक सिलेंडर संख्या से लिलो प्रोग्राम द्वारा कर्नेल लोड करने की असंभवता के कारण बूटलोडर्स के आधुनिक संस्करणों में ऐसे कोई प्रतिबंध नहीं हैं। हालाँकि, यदि /बूट के लिए एक विभाजन पहले से ही बनाया जा रहा है, तो इसे डिस्क पर पहला बनाना और स्वैप विभाजन को सीधे इसके पीछे रखना उचित है: इससे स्वैपिंग करते समय पांच सेंट का प्रदर्शन जुड़ जाएगा।

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

यह भी उतना ही स्पष्ट है कि फ़ाइल सिस्टम की परिवर्तनीय शाखाएँ - /var और /tmp निर्देशिकाएँ - को रूट विभाजन के बाहर ले जाया जाना चाहिए। इसके अलावा, जैसा कि पहले भी कई बार कहा जा चुका है, आमतौर पर इसे रैम (tmpfs या mfs) में फ़ाइल सिस्टम पर रखने की सलाह दी जाती है। यदि /var निर्देशिका में पोर्ट-जैसे पैकेज प्रबंधन प्रणालियों के लिए उपनिर्देशिकाएं शामिल हैं, जैसे /var/abs , /var/cache/pacman/src और /var/cache/pacman/pkg आर्कलिनक्स में, तो इन्हें अलग फ़ाइल सिस्टम भी बनाना चाहिए

अब - /usr निर्देशिका, जिसमें या तो बेस सिस्टम के घटक शामिल हैं (जैसा कि बीएसडी में है), या अधिकांश उपयोगकर्ता एप्लिकेशन (जैसा कि अधिकांश लिनक्स वितरण में है)। इसमें आसानी से पुनर्प्राप्त करने योग्य डेटा शामिल है और, निष्पक्ष होने के लिए, व्यावहारिक रूप से अपरिवर्तनीय होना चाहिए, और इसलिए, निश्चित रूप से, एक अलग अनुभाग में आवंटित किया जाना चाहिए। इसके अलावा, इसकी संरचना से, एक ओर, उपनिर्देशिकाओं /usr/X11R6 और /usr/local को अलग करने की सलाह दी जाती है, दूसरी ओर - पोर्ट-जैसे पैकेज प्रबंधन प्रणालियों के लिए उपनिर्देशिकाएँ: /usr/ports, /usr/pkgsrc और /usr/pkg BSD सिस्टम में, /usr/portages Gentoo Linux पर, इत्यादि। इसके अलावा, पोर्ट बनाते समय नेटवर्क से डाउनलोड किए गए स्रोतों को संग्रहीत करने के लिए बाद वाले को उपनिर्देशिकाओं में अलग किया जाना चाहिए - /usr/ports/distfiles, /usr/pkgsrc/disfiles, /usr/portages/distfiles और इसी तरह।

बीएसडी सिस्टम में, इसके अलावा, /usr निर्देशिका से उपनिर्देशिकाओं /usr/src और /usr/obj का चयन करना समझ में आता है जिसमें मूल घटकों (कर्नेल सहित) और उनके संकलन के मध्यवर्ती उत्पादों के स्रोत कोड शामिल होते हैं, जो एक के रूप में बनते हैं। मेक बिल्डवर्ल्ड और मेक बिल्डकर्नेल प्रक्रियाओं का परिणाम।

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

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

इसका अतिरिक्त लाभ यह है कि फ़ाइल ट्री की अलग-अलग शाखाओं के लिए, उस पर स्थित डेटा की प्रकृति के आधार पर, लिनक्स में आप भौतिक रूप से इष्टतम फ़ाइल सिस्टम का चयन कर सकते हैं। उदाहरण के लिए, /boot विभाजन के लिए Ext2fs के अलावा किसी अन्य चीज़ का उपयोग करने का कोई मतलब नहीं है। आमतौर पर रूट विभाजन को विश्वसनीय और सबसे अधिक संगत Ext3fs में प्रारूपित करने की अनुशंसा की जाती है। बड़ी संख्या में छोटी फ़ाइलों वाली निर्देशिकाओं के लिए, जैसे आर्कलिनक्स में /var/abs, Gentoo में /usr/portages, ReiserFS का उपयोग करने की सलाह दी जाती है: आखिरकार, छोटी फ़ाइलों का कुशल प्रबंधन ही इसकी प्रोफ़ाइल है। और /होम निर्देशिका में, जहां बड़ी मल्टीमीडिया फ़ाइलें दिखाई दे सकती हैं (और जो आमतौर पर बहुत बड़ी होती हैं), एक्सएफएस काम में आ सकता है (हालांकि, जैसा कि माप से पता चलता है, रीइज़रएफएस यहां काफी सभ्य दिखता है)। ऐसे उपाय डेटा भंडारण की विश्वसनीयता और फ़ाइल संचालन की गति दोनों को बेहतर बनाने में मदद कर सकते हैं।

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

पॉज़िक्स और आरटी ओएस: व्यवस्थितकरण का एक प्रयास

सर्गेई ज़ोलोटारेव, निकोले गोर्बुनोव

इस लेख का उद्देश्य रीयल-टाइम ऑपरेटिंग सिस्टम (आरटीओएस) के संबंध में POSIX मानक के विकास के इतिहास में कुछ स्पष्टता लाने का प्रयास करना है।

एक परिचय के रूप में: सॉफ़्टवेयर इंटरफ़ेस मानकीकरण क्यों आवश्यक है?

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

अतीत और समानांतर परियोजनाओं से कोड का पुन: उपयोग करना;
अन्य ऑपरेटिंग सिस्टम से कोड स्थानांतरित करना;
अन्य परियोजनाओं से डेवलपर्स को आकर्षित करना (अन्य ऑपरेटिंग सिस्टम का उपयोग करने सहित)।

यह सब एक मानकीकृत एपीआई वाले ओएस के उपयोग के कारण संभव है। इसके अलावा, यदि पहले मामले में किसी संगठन के लिए किसी प्रकार का आंतरिक मानक (जो विशेष रूप से मालिकाना ऑपरेटिंग सिस्टम के लिए विशिष्ट है) होना पर्याप्त है, तो दूसरे दो मामलों में आम तौर पर मान्यता प्राप्त मानकों की उपस्थिति की आवश्यकता होती है - उदाहरण के लिए, POSIX।

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

POSIX विकास में कौन क्या है?

और हम शुरुआत POSIX मानक से नहीं, बल्कि इस पर काम करने वाले संगठनों की भूमिका को सुव्यवस्थित करने से करेंगे।

पहला प्रतिभागी है आईईईई(इलेक्ट्रिकल और इलेक्ट्रॉनिक्स इंजीनियर्स संस्थान), पेशेवरों का सार्वजनिक गैर-लाभकारी संघ। IEEE की स्थापना 1884 में हुई (औपचारिक रूप से 1963 से), यह 150 देशों के 380,000 व्यक्तिगत सदस्यों को एकजुट करता है, कंप्यूटर, नियंत्रण, विद्युत और सूचना प्रौद्योगिकी के अनुप्रयोग से संबंधित एक तिहाई तकनीकी साहित्य प्रकाशित करता है, साथ ही 100 से अधिक पत्रिकाएँ भी प्रकाशित करता है, जो लोकप्रिय हैं। पेशेवर; इसके अलावा, एसोसिएशन प्रति वर्ष 300 से अधिक प्रमुख सम्मेलन आयोजित करता है। IEEE ने 900 से अधिक मौजूदा मानकों (www.ieee.ru/ieee.htm) के विकास में भाग लिया है। आज यह संस्थान मानकों की तैयारी, समन्वय, अनुमोदन और प्रकाशन में लगा हुआ है, लेकिन इसकी औपचारिक स्थिति के कारण इसे अंतरराष्ट्रीय या राष्ट्रीय मानकों जैसे दस्तावेजों को अपनाने का अधिकार नहीं है। इसलिए, आईईईई की समझ में "मानक" शब्द को "विनिर्देश" के रूप में समझा जाना चाहिए, जो एसोसिएशन द्वारा स्वीकार किए गए दस्तावेजों की स्थिति के साथ अधिक सुसंगत है। IEEE के अनुसार, कई अंतरराष्ट्रीय और क्षेत्रीय संगठनों के कार्यक्रमों में भाग लेता है - IEC, ISO, ITU (अंतर्राष्ट्रीय दूरसंचार संघ), ETSI (यूरोपीय दूरसंचार मानक संस्थान), CENELEC (इलेक्ट्रोटेक्निकल मानकीकरण के लिए यूरोपीय समिति) और राष्ट्रीय कार्यक्रमों में, उदाहरण के लिए एएनएसआई जैसे संगठन के कार्यक्रम में।

IEEE में PASC (पोर्टेबल एप्लिकेशन स्टैंडर्ड्स कमेटी) शामिल है, एक एसोसिएशन कमेटी जो मानकों के POSIX परिवार को विकसित करती है (www.pasc.org/)। PASC को पहले ऑपरेटिंग सिस्टम तकनीकी समिति के रूप में जाना जाता था।

कार्य में दूसरा भागीदार - एएनएसआई(अमेरिकन नेशनल स्टैंडर्ड इंस्टीट्यूट) एक निजी गैर-लाभकारी संगठन है जो संयुक्त राज्य अमेरिका में मानकीकरण गतिविधियों का प्रबंधन और समन्वय करता है। इसमें केवल 75 लोग कार्यरत हैं, लेकिन एएनएसआई सदस्यों में 1,000 से अधिक कंपनियां, संगठन, सरकारी एजेंसियां और संस्थान (www.ansi.org) शामिल हैं। एएनएसआई दो प्रमुख अंतरराष्ट्रीय मानक संगठनों, आईएसओ और आईईसी में संयुक्त राज्य का प्रतिनिधित्व करता है।

तीसरा प्रतिभागी - आईएसओ(मानकीकरण के लिए अंतर्राष्ट्रीय संगठन, मानकीकरण के लिए अंतर्राष्ट्रीय संगठन)। इसे 1946 में मानकों के समन्वय के लिए समिति और संयुक्त राष्ट्र महासभा के निर्णय द्वारा बनाया गया था और 23 फरवरी, 1947 (www.iso.org) पर आधिकारिक तौर पर काम शुरू हुआ। आईएसओ 146 देशों (एक देश - एक आईएसओ सदस्य) के राष्ट्रीय मानकीकरण संस्थानों का एक नेटवर्क है जिसका केंद्रीय सचिवालय जिनेवा (स्विट्जरलैंड) में है। आईएसओ मानक तकनीकी समितियों में विकसित किए जाते हैं, जिसका पहला परिणाम ड्राफ्ट इंटरनेशनल स्टैंडर्ड (डीआईएस) होता है, जो कई अनुमोदनों के बाद फाइनल ड्राफ्ट इंटरनेशनल स्टैंडर्ड (एफडीआईएस) में बदल जाता है। इसके बाद, इस दस्तावेज़ के अनुमोदन के मुद्दे पर मतदान किया जाता है; यदि परिणाम सकारात्मक है, तो यह एक अंतरराष्ट्रीय मानक बन जाता है।

और अंत में - आईईसी(इंटरनेशनल इलेक्ट्रोटेक्निकल कमीशन, इंटरनेशनल इलेक्ट्रोटेक्निकल कमीशन - IEC), 1906 में स्थापित। IEC सभी इलेक्ट्रिकल, इलेक्ट्रॉनिक और संबंधित प्रौद्योगिकियों (www.iec.ch/) के लिए अंतर्राष्ट्रीय मानक तैयार और प्रकाशित करता है। 1 नवम्बर 2004 तक 64 देशों की राष्ट्रीय समितियाँ इस आयोग की सक्रिय सदस्य थीं। आईईसी सिफारिशें भी जारी करता है, जो अंग्रेजी और फ्रेंच में प्रकाशित होती हैं और इन्हें अंतरराष्ट्रीय मानकों का दर्जा प्राप्त है। इनके आधार पर क्षेत्रीय एवं राष्ट्रीय मानक विकसित किये जाते हैं। तकनीकी समितियाँ (टीसी) आईईसी गतिविधियों के विभिन्न क्षेत्रों में मानकों की तैयारी के लिए जिम्मेदार हैं, जिसके काम में किसी विशेष टीसी की गतिविधियों में रुचि रखने वाली राष्ट्रीय समितियाँ भी भाग लेती हैं।

IEC अंतर्राष्ट्रीय मानक तैयार करने में प्रमुख संगठन है सूचान प्रौद्योगिकी. इस क्षेत्र में सूचना प्रौद्योगिकी पर एक संयुक्त तकनीकी समिति, जेटीसी 1 है, जिसका गठन 1987 में आईईसी और आईएसओ के बीच एक समझौते के अनुसार किया गया था। JTC1 में 17 उपसमितियाँ हैं जो सभी विकासों की देखरेख करती हैं सॉफ़्टवेयरप्रोग्रामिंग भाषाओं के लिए, कंप्यूटर चित्रलेखऔर छवि संपादन, उपकरण और सुरक्षा विधियों का अंतर्संबंध।

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

कई अन्य संगठन POSIX मानकों के विकास और अपनाने में शामिल हैं।

समूह खोलेंएक अंतरराष्ट्रीय सॉफ्टवेयर मानक संगठन है जो सूचना प्रौद्योगिकी (www.opengroup.org/) के क्षेत्र में काम करने वाले लगभग 200 निर्माताओं और उपयोगकर्ता समुदायों को एक साथ लाता है। ओपन ग्रुप 1995 में अपने दो पूर्ववर्तियों: एक्स/ओपन और ओपन सॉफ्टवेयर फाउंडेशन (ओएसएफ) को मिलाकर बनाया गया था। ओपन ग्रुप विशिष्ट आवश्यकताओं के अनुपालन के लिए सॉफ्टवेयर प्रमाणन पद्धति विकसित करने और परीक्षण करने में माहिर है। विशेष रूप से, ओपन ग्रुप सीओई प्लेटफॉर्म, कॉर्बा, एलडीएपी, लिनक्स स्टैंडर्ड बेस, स्कूल इंटरऑपरेबिलिटी फ्रेमवर्क (एसआईएफ), एस/एमआईएमई गेटवे, सिंगल यूनिक्स स्पेसिफिकेशन, वायरलेस एप्लिकेशन प्रोटोकॉल स्पेसिफिकेशंस (डब्ल्यूएपी) और जैसे क्षेत्रों के लिए प्रमाणन में लगा हुआ है। अंततः, POSIX परिवार के मानक (www.opengroup.org/certification/)।

ऑस्टिन सामान्य मानक संशोधन समूह (सीएसआरजी)- निर्माण और रखरखाव के लिए आईएसओ, आईईसी और ओपन ग्रुप द्वारा 2002 में एक संयुक्त तकनीकी कार्य समूह का गठन किया गया नवीनतम संस्करणमानक 1003.1, जो आईएसओ/आईईसी 9945-1-1996, आईएसओ/आईईसी 9945-2-1993, आईईईई कक्षा 1003.1-1996, आईईईई कक्षा 1003.2-1992 और एकल यूनिक्स विशिष्टता (www.opengroup.org/press/) पर आधारित होगा। 14nov02.htm).

राष्ट्रीय मानक एवं प्रौद्योगिकी संस्थान (एनआईएसटी)वाणिज्य विभाग के प्रौद्योगिकी प्रशासन (www.nist.gov/public_affairs/general2.htm) के अंतर्गत एक संघीय एजेंसी है, जिसकी स्थापना 1901 में संयुक्त राज्य अमेरिका में की गई थी। NIST का मिशन उत्पाद की गुणवत्ता में सुधार के लिए मानकों और प्रौद्योगिकियों को विकसित करना और बढ़ावा देना है। एनआईएसटी में एक सूचना प्रौद्योगिकी प्रयोगशाला (आईटीएल) शामिल है, जिसका एक परिणाम संघीय सूचना प्रसंस्करण मानक (एफआईपीएस, www.opengroup.org/testing/fips/general_info.html) है। NIST/ITL ने FIPS PUB 151-1 1990 के तहत 1991 में POSIX प्रमाणन के लिए परीक्षणों का प्रारंभिक सेट प्रस्तावित किया।

पॉज़िक्स क्या है?

औपचारिक रूप से शब्द पॉज़िक्सरिचर्ड स्टॉलमैन द्वारा संक्षिप्त नाम के रूप में प्रस्तावित पीपोर्टेबल हे perating एससंयुक्त राष्ट्र के लिए सिस्टम इंटरफ़ेस नौवीं(पोर्टेबल इंटरफ़ेस ऑपरेटिंग सिस्टमयूनिक्स के लिए)। POSIX को स्रोत स्तर पर एप्लिकेशन पोर्टेबिलिटी सुनिश्चित करने के लक्ष्य के साथ UNIX-जैसे ऑपरेटिंग सिस्टम (उनका पहला संस्करण 1970 के दशक की शुरुआत में) के लिए विकसित किया गया था।

इंटरफ़ेस का प्रारंभिक विवरण 1986 में प्रकाशित हुआ था, तब इसे IEEE-IX (IEEE का UNIX का संस्करण) कहा जाता था, नाम जल्दी से बदल गया, POSIX बन गया, और पहले से ही अगले प्रकाशन (1986 में) में यह नया संस्करण था। कुछ समय के लिए, POSIX को संबंधित दस्तावेज़ों के समूह IEEE 1003.1-1988 और ISO/IEC 9945 के कुछ हिस्सों के संदर्भ (या पर्यायवाची) के रूप में समझा जाता था, और एक पूर्ण और अनुमोदित अंतर्राष्ट्रीय मानक के रूप में, ISO/IEC 9945.1:1990 POSIX को समझा जाता था। 1990 में अपनाया गया। POSIX विनिर्देश एक एप्लिकेशन प्रोग्राम और एक ऑपरेटिंग सिस्टम के बीच बातचीत के लिए एक मानक तंत्र को परिभाषित करते हैं और वर्तमान में IEEE, ISO, IEC और ANSI के तत्वावधान में 30 से अधिक मानक शामिल हैं।

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

POSIX मानक के विकास का इतिहास

आईईईई कक्षा 1003.1 विनिर्देश का पहला संस्करण 1988 में प्रकाशित हुआ था। इसके बाद, आईईईई कक्षा 1003.1 के कई संस्करणों को अंतरराष्ट्रीय मानकों के रूप में अपनाया गया है।

POSIX विकास चरण:

1990

1988 में जारी संस्करण को संशोधित किया गया और यह आगे के संस्करणों और परिवर्धन का आधार बन गया। इसे ISO/IEC 9945-1:1990 द्वारा एक अंतरराष्ट्रीय मानक के रूप में अनुमोदित किया गया है।

1993

संशोधन 1003.1बी-1993 जारी किया गया है।

1996

आईईईई कक्षा 1003.1बी-1993, आईईईई कक्षा 1003.1सी-1995, और 1003.1आई-1995 में संशोधन किया गया है, लेकिन दस्तावेज़ का मुख्य भाग अपरिवर्तित है। आईईईई कक्षा 1003.1 के 1996 संस्करण को आईएसओ/आईईसी 9945-1:1996 द्वारा एक अंतरराष्ट्रीय मानक के रूप में भी अपनाया गया था।

1998

"वास्तविक समय" के लिए पहला मानक सामने आया - आईईईई कक्षा 1003.13-1998। यह एम्बेडेड रीयल-टाइम अनुप्रयोगों के लिए POSIX मानक का विस्तार है।

1999

पिछले 10 वर्षों में मानक के मुख्य पाठ में पहला महत्वपूर्ण परिवर्तन करने का निर्णय लिया गया, जिसमें मानक 1003.2 (शेल और उपयोगिताएँ) के साथ एकीकरण भी शामिल था, क्योंकि उस समय ये अलग मानक थे। PASC ने IEEE 1003.1a, 1003.1d, 1003.1g, 1003.1j, 1003.1q, और 1003.2b मानकों के पूरा होने के बाद आधार पाठ परिवर्तनों को अंतिम रूप देने का निर्णय लिया।

2004

1003.1 मानक का नवीनतम संशोधन 30 अप्रैल को प्रकाशित हुआ था और ऑस्टिन कॉमन स्टैंडर्ड्स रिवीजन ग्रुप के तत्वावधान में जारी किया गया था। इसे औपचारिक रूप से मानक के 2001 संस्करण द्वारा संशोधित किया गया है, 2004 संस्करण को आईईईई कक्षा 1003.1, 2004 संस्करण, द ओपन ग्रुप टेक्निकल स्टैंडर्ड बेस स्पेसिफिकेशंस, अंक 6 के रूप में जाना जाता है और इसमें आईईईई कक्षा 1003.1-2001, आईईईई कक्षा 1003.1-2001/ शामिल है। कोर 1-2002 और आईईईई कक्षा 1003.1-2001/कोर 2-2004।

RT OS के लिए सबसे महत्वपूर्ण POSIX मानक

रीयल-टाइम ऑपरेटिंग सिस्टम के लिए, सात मानक विनिर्देश सबसे महत्वपूर्ण हैं (1003.1ए, 1003.1बी, 1003.1सी, 1003.1डी, 1003.1जे, 1003.21), लेकिन केवल तीन को वाणिज्यिक ऑपरेटिंग सिस्टम में व्यापक समर्थन प्राप्त हुआ है:

1003.1ए (ओएस परिभाषा)मुख्य ओएस इंटरफेस, कार्य प्रबंधन, सिग्नल, फ़ाइल सिस्टम और डिवाइस फ़ंक्शन, उपयोगकर्ता समूह, पाइपलाइन, फीफो बफ़र्स को परिभाषित करता है;
1003.1बी (रीयलटाइम एक्सटेंशन)वास्तविक समय सिग्नल, प्राथमिकता शेड्यूलिंग, टाइमर, सिंक्रोनस और एसिंक्रोनस I/O, सेमाफोर, साझा मेमोरी, संदेश जैसे वास्तविक समय एक्सटेंशन का वर्णन करता है। प्रारंभ में (1993 तक) इस मानक को POSIX.4 नामित किया गया था।
1003.1सी (थ्रेड्स)सहायक थ्रेड्स (थ्रेड्स) के लिए कार्यों को परिभाषित करता है - थ्रेड प्रबंधन, थ्रेड विशेषताएँ, म्यूटेक्स, प्रेषण। मूल रूप से POSIX.4a नामित।

इन मानकों के अलावा, निम्नलिखित मानक आरटी ओएस के लिए महत्वपूर्ण हैं, जिन्हें एसटीडी 1003.1-2001 परियोजना पर काम के हिस्से के रूप में लागू किया गया था:

आईईईई 1003.1डी-1999।अतिरिक्त वास्तविक समय एक्सटेंशन. मूल रूप से POSIX.4b के रूप में नामित;
आईईईई 1003.1जे-2000।बेहतर (उन्नत) वास्तविक समय एक्सटेंशन;
आईईईई 1003.1q-2000।पता लगाना।

प्रमाणीकरण प्रक्रिया

POSIX मानक का अनुपालन करने के लिए, ऑपरेटिंग सिस्टम को उपयुक्त परीक्षण सूट के परिणामों के अनुसार प्रमाणित किया जाना चाहिए। POSIX की शुरुआत के बाद से, परीक्षण सूट में औपचारिक और तथ्यात्मक परिवर्तन हुए हैं।

1991 में, NIST ने FIPS 151-1 (http://standards.ieee.org/regauth/posix/POSIX-A.FM5.pdf) के भाग के रूप में POSIX परीक्षण कार्यक्रम विकसित किया। यह परीक्षण विकल्प IEEE 1003.3 "POSIX के अनुरूपता को मापने के लिए परीक्षण विधियों के लिए मानक" ड्राफ्ट 10, 3 मई, 1989 पर आधारित था। 1993 में, NIST ने FIPS 151-1 के लिए POSIX परीक्षण कार्यक्रम पूरा किया और FIPS 151 -2 के लिए कार्यक्रम शुरू किया। (www.itl.nist.gov/fipspubs/fip151-2.htm)। FIPS 151-2 ने "सूचना प्रौद्योगिकी-पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस (POSIX)-भाग 1: सिस्टम एप्लिकेशन प्रोग्राम इंटरफ़ेस (API)" को अनुकूलित किया, जो एक ISO/IEC 9945-1:1990 मानक है। FIPS 151-2 के लिए परीक्षण सूट IEEE 2003.1-1992 "POSIX के अनुरूपता को मापने के लिए परीक्षण विधियों के लिए मानक" पर आधारित थे।

एनआईएसटी दो प्रमाणन पद्धतियों के बीच अंतर करता है: स्व-प्रमाणन और आईईईई मान्यता प्राप्त POSIX परीक्षण प्रयोगशालाओं (एपीटीएल) द्वारा प्रमाणन। पहले मामले में, कंपनी स्वतंत्र रूप से परीक्षण करती है, लेकिन एनआईएसटी द्वारा अनुमोदित योजना के अनुसार। दूसरे मामले में, स्वचालित परीक्षण किट का उपयोग करके एक स्वतंत्र प्रयोगशाला द्वारा परीक्षण किया जाता है। कुल मिलाकर, दो एपीटीएल प्रयोगशालाओं को मान्यता दी गई: माइंडक्राफ्ट (www.mindcraft.com) और पेरेनियल (www.peren.com)।

1997 में, NIST/ITL ने चालू वर्ष के अंत में (आधिकारिक तौर पर 31 दिसंबर, 1997) FIPS 151-2 प्रमाणन बंद करने के अपने इरादे की घोषणा की, जबकि ओपन ग्रुप ने घोषणा की कि उसका इरादा 1 अक्टूबर, 1997 से प्रमाणन अपने हाथ में लेने का है। उसी वर्ष, एनआईएसटी/आईटीएल कार्यक्रम के आधार पर एफआईपीएस 151-2 के अनुसार प्रमाणन सेवा। 1 जनवरी, 1998 को आईईईई स्टैंडर्ड्स एसोसिएशन (आईईईई-एसए) द्वारा समान कार्य संभाले गए, यह भी FIPS 151-2 पर आधारित था।

2003 में, IEEE-SA और ओपन ग्रुप ने POSIX के नवीनतम संस्करणों को प्रमाणित करने के लिए एक नए संयुक्त कार्यक्रम की शुरुआत की घोषणा की, जिसकी शुरुआत IEEE 1003.1™ 2001 से हुई। ओपन ग्रुप के पास अब कई परीक्षण सूट हैं जो IEEE Std 1003.1-1996, IEEE को कवर करते हैं। कक्षा 1003.2-1992, आईईईई कक्षा 1003.1-2003 और आईईईई कक्षा 1003.13-1998 (www.opengroup.org/testing/testsuites/posix.html)। किसी उत्पाद को POSIX प्रमाणित माना जाता है यदि उसने पूर्ण प्रमाणीकरण प्रक्रिया पारित कर ली है, परीक्षण परिणामों के आधार पर सभी आवश्यकताओं को पूरा करता है, और प्रमाणित उत्पादों के आधिकारिक रजिस्टर में शामिल है।

परीक्षण सुइट्स में शामिल हैं:

VSX-PCTS1990 (www.opengroup.org/testing/testsuites/vsxpcts1990.htm) - सिस्टम इंटरफेस IEEE Std 1003.1-1990 के लिए अनुरूपता परीक्षणों का एक सेट;
VSPSE54 (www.opengroup.org/testing/testsuites/VSPSE54.htm) - IEEE कक्षा 1003.13-1998 प्रोफ़ाइल PSE54 (बहुउद्देश्यीय वास्तविक समय) के लिए अनुरूपता परीक्षणों का एक सेट;
VSX-PCTS2003 (www.opengroup.org/testing/testsuites/vsxpcts2003.htm) - सिस्टम इंटरफेस IEEE Std 1003.1-2003 (केवल अनिवार्य भाग) के लिए अनुरूपता परीक्षणों का एक सेट;
VSC-PCTS2003 (www.opengroup.org/testing/testsuites/vscpcts2003.htm) - IEEE कक्षा 1003.1-2003 (शेल और उपयोगिताएँ - केवल अनिवार्य भाग) के लिए अनुरूपता परीक्षणों का एक सेट।

इसके अलावा, ओपन ग्रुप ने POSIX रीयलटाइम मानकों और एंबेडेड POSIX मानक प्रोफ़ाइल के लिए परीक्षण विकसित किए हैं। POSIX रीयलटाइम परीक्षण सूट (www.opengroup.org/testing/testsuites/realtime.html) में निम्नलिखित परीक्षण शामिल हैं:

IEEE POSIX 1003.1b-1993/1003.1i-1995 रीयलटाइम एक्सटेंशन और IEEE POSIX 1003.1,2003 संस्करण;
IEEE Std POSIX 1003.1c-1995 थ्रेड्स (pthreads) एक्सटेंशन और IEEE POSIX 1003.1,2003 संस्करण;
IEEE POSIX 1003.1d-1999 अतिरिक्त रीयलटाइम एक्सटेंशन और IEEE POSIX 1003.1,2003 संस्करण;
IEEE POSIX 1003.1j-2000 उन्नत रीयलटाइम एक्सटेंशन और IEEE POSIX 1003.1,2003 संस्करण;
IEEE POSIX 1003.1q-2000 ट्रेस और IEEE POSIX 1003.1,2003 संस्करण और IEEE POSIX 1003.1,2003 संस्करण;

एंबेडेड POSIX मानक प्रोफ़ाइल परीक्षण सूट (www.opengroup.org/testing/testsuites/embedded.html) में निम्नलिखित परीक्षण शामिल हैं:

आईईईई पॉज़िक्स 1003.1-1990 (5310 परीक्षण);
IEEE POSIX 1003.1b-1993/1003.1i-1995 रीयलटाइम एक्सटेंशन (1430 परीक्षण);
आईईईई कक्षा पॉज़िक्स 1003.1सी-1995 थ्रेड्स (पीथ्रेड्स) एक्सटेंशन (1232 परीक्षण);
आईईईई पॉज़िक्स 1003.13-1998 प्रोफ़ाइल 52।

शब्दावली में भ्रम के बारे में थोड़ा

मानकों के POSIX समूह के संबंध में अंग्रेजी भाषाप्रायः एक नहीं, बल्कि तीन शब्दों का प्रयोग किया जाता है। दुर्भाग्य से, वे अर्थ में समान हैं और अक्सर एक ही तरह से अनुवादित किए जाते हैं, जिससे कुछ भ्रम पैदा होता है। ये शर्तें हैं:

अनुकूलता (शाब्दिक रूप से "संगतता");
अनुपालन (शाब्दिक रूप से "अनुपालन");
अनुरूपता (शाब्दिक रूप से "स्थिरता")।

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

प्रमाणित ओएस आर.वी

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

लिंक्सओएस v.3(लिंक्स रियल-टाइम सिस्टम्स का एक उत्पाद, जिसे अब लिनक्सवर्क्स, इंक., www.lynuxworks.com कहा जाता है) का उद्देश्य ओईएम और दूरसंचार उपकरण निर्माताओं, विशेष रूप से सैन्य एयरबोर्न सिस्टम निर्माताओं द्वारा हार्ड रियल-टाइम एम्बेडेड सिस्टम सॉफ़्टवेयर का विकास करना है। विकास लक्ष्य प्रणाली (स्वयं-होस्टेड) और एक वाद्य कंप्यूटर (होस्ट) दोनों पर किया जा सकता है, तैयार सॉफ़्टवेयर लक्ष्य प्रणाली (लक्ष्य) पर काम करने के लिए डिज़ाइन किया गया है। लिंक्सओएस v.3 इंटेल और पावरपीसी प्लेटफॉर्म पर POSIX मानक के अनुरूप होने के लिए प्रमाणित है। इसके बारे में जानकारी IEEE वेबसाइट http://standards.ieee.org/regauth/posix/posix2.html पर पाई जा सकती है। लिंक्सओएस को माइंडक्राफ्ट द्वारा POSIX 1003.1-1996 के लिए प्रमाणित किया गया है, जो NIST FIPS 151-2 अनुरूपता परीक्षण सूट के मुकाबले एक IEEE POSIX मान्यता प्राप्त POSIX परीक्षण प्रयोगशाला है। प्रमाणन दस्तावेज़ संख्या: संदर्भ फ़ाइल: IP-2LYX002, संदर्भ फ़ाइल: IP-2LYX001।

सत्यनिष्ठा v.5(ग्रीन हिल्स सॉफ्टवेयर का एक उत्पाद, www.ghs.com) को जुलाई 2004 में पावरपीसी आर्किटेक्चर के लिए POSIX 1003.1-2003, सिस्टम इंटरफेस के अनुरूप प्रमाणित किया गया है (http://get.posixcertified.ieee.org/select_product. tpl) . वीएसएक्स-पीसीटीएस 2003 परीक्षण सूट।

POSIX और QNX ऑपरेटिंग सिस्टम

QNX v.4.20 (QNX सॉफ्टवेयर सिस्टम्स, www.qnx.com द्वारा विकसित) प्लेटफॉर्म के लिए POSIX 1003.1-1988 के अनुपालन के लिए प्रमाणित है। इंटेल कंपनीडेटाफोकस शामिल। परीक्षण 13 सितंबर 1993 को आयोजित किया गया था, और दस्तावेज़ 1 नवंबर 1993 को जारी किया गया था। एनआईएसटी पीसीटीएस 151-1 टेस्ट सूट, संस्करण 1.1।

QNX न्यूट्रिनो (संस्करण 6.3) निम्नलिखित POSIX परिवार मानकों (www.qnx.com/download/download/8660/portability.pdf) का अनुपालन करता है:

पॉज़िक्स.1 (आईईईई 1003.1);
POSIX.1a (IEEE 1003.1a);
पॉज़िक्स.2 (आईईईई 1003.2);
पॉज़िक्स.4 (आईईईई 1003.1बी);
POSIX.4a (IEEE 1003.1c);
POSIX.1b (IEEE 1003.1d), IEEE 1003.1j;
POSIX.12 (IEEE 1003.1g)।

QNX न्यूट्रिनो के निर्माता, QNX सॉफ्टवेयर सिस्टम्स ने भी QNX न्यूट्रिनो को इनमें से कुछ मानकों के अनुरूप बनाने की योजना बनाई है; कार्य की योजना 2005 के लिए है (www.qnx.com/news/pr_959_1.html)।

साहित्य

आईईईई स्टैंडर्ड्स एसोसिएशन ऑपरेशन मैनुअल।आईईईई, अक्टूबर 2004।
केविन एम. ओबेलैंड. रीयल-टाइम में POSIX, एंबेडेड सिस्टम प्रोग्रामिंग, 2001।
आईईईई/एएनएसआई मानक 1003.1: सूचना प्रौद्योगिकी - (POSIX) - भाग 1: सिस्टम अनुप्रयोग: प्रोग्राम इंटरफ़ेस (एपीआई)।
गैलमिस्टर, बी.ओ. वास्तविक दुनिया के लिए प्रोग्रामिंग, POSIX.4सेबेस्टोपोल, सीए: ओ'रेली एंड एसोसिएट्स, 1995।
राष्ट्रीय मानक एवं प्रौद्योगिकी संस्थान, पीसीटीएस:151-2, पॉज़िक्स टेस्ट सूट।
POSIX: IEEE और द ओपन ग्रुप द्वारा प्रमाणित।प्रमाणित नीति. ओपन ग्रुप, 21 अक्टूबर 2003, संशोधन 1.1.

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

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

पॉज़िक्स क्या है?

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

POSIX मानक के संदर्भ में, "पोर्टेबल" का तात्पर्य है सोर्स कोड(उन बायनेरिज़ के लिए नहीं जो इन्हीं स्रोतों से इकट्ठे किए गए हैं)। आइए अब जानें कि "इंटरफ़ेस" क्या है। प्रोग्रामिंग में, एक "इंटरफ़ेस" यह है कि आपका कोड अन्य कोड के साथ कैसे इंटरैक्ट करता है। इंटरफ़ेस अपेक्षा करता है कि आपका कोड कुछ जानकारी प्रदान करे। बदले में, आपका कोड इंटरफ़ेस से कुछ जानकारी प्राप्त करने की अपेक्षा करता है। C में fopen() फ़ंक्शन एक अच्छा उदाहरण है। यह दो भागों में जानकारी की अपेक्षा करता है: फ़ाइल का पथ और वह मोड जिसमें इसे खोला जाएगा। इस डेटा का उपयोग करके, ऑपरेटिंग सिस्टम एक अन्य प्रकार की जानकारी लौटाता है जिसे "फ़ाइल डिस्क्रिप्टर" कहा जाता है। किसी फ़ाइल को पढ़ने या फ़ाइल में लिखने के लिए फ़ाइल हैंडल का उपयोग किया जा सकता है। यह इंटरफ़ेस है. इस सब से यह निष्कर्ष निकलता है कि POSIX-अनुपालक कोड को किसी भी POSIX-अनुपालक ऑपरेटिंग सिस्टम के लिए बड़े बदलावों के बिना संकलित किया जा सकता है, जिसका अर्थ है कि यह पोर्टेबल होगा।

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

POSIX मानक 1985 में रिचर्ड स्टॉलमैन द्वारा एक ड्राफ्ट के रूप में सामने आया और बाद में इसे IEEE Std 1003.-1998 के रूप में औपचारिक रूप दिया गया। जैसा कि शीर्षक से पता चलता है, 1998 आधिकारिक प्रकाशन का वर्ष था। तब से, POSIX में बड़ी संख्या में परिवर्धन और एक्सटेंशन जारी किए गए हैं, जो धीरे-धीरे मानकों के एक पूरे परिवार में विकसित हो रहा है, जिसे औपचारिक रूप से IEEE 1003 के रूप में जाना जाता है, जिसे अंतर्राष्ट्रीय रूप से मान्यता प्राप्त है, पदनाम SO/IEC 9945 के साथ, जिसे केवल POSIX परिवार कहा जाता है। मानक।

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

मुझे आशा है कि हमने "POSIX क्या है" प्रश्न पर कुछ प्रकाश डाला है। क्या आपके पास इस विषय पर रोचक जानकारी है? कृपया इसे टिप्पणियों में साझा करें।

- (IPAEng|ˈpɒzɪks) या पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस वेब का हवाला दें | शीर्षक = पॉज़िक्स | यूआरएल = http://standards.ieee.org/regauth/posix/ | कार्य = मानक | प्रकाशक = आईईईई] आईईईई ... विकिपीडिया द्वारा निर्दिष्ट संबंधित मानकों के एक परिवार का सामूहिक नाम है

पॉज़िक्स- इंस्टीट्यूट ऑफ इलेक्ट्रिकल एंड इलेक्ट्रॉनिक्स इंजीनियर्स और फॉर्मेलेमेंट डिजाइन आईईईई 1003 के अनुसार एक वर्ष पहले स्थापित मानक।

पॉज़िक्स- आईईईई और फॉर्मेलेमेंट डिजाइन आईईईई 1003 के अनुसार 1988 में मानक परिभाषा का एक नया नाम। एपीआई के मानकीकरण परियोजना में सीईएस मानक उभरे और विभिन्न प्रणालियों के लिए एक कार्यात्मक समाधान स्थापित किया गया।

पॉज़िक्स- पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस का विवरण; एपीआई की पहचान के लिए यूनिक्स से पहले एक्स। आईईईई की मांग के जवाब में रिचर्ड स्टॉलमैन द्वारा दी गई अंतिम चेतावनी, रिकॉर्डर की एक नई सुविधा प्राप्त करना। एक परंपरा...विकिपीडिया Español

पॉज़िक्स- 1986 में यूनिक्स में सिस्टम फंकशन के लिए आईईईई द्वारा मानक 1003.1 का उपयोग किया गया। सोवोहल यूनिक्स Sy...यूनिवर्सल-लेक्सिकॉन

पॉज़िक्स- स्टैंडअर्टई स्टेटसस टी सर्टिस इंफॉर्मेटिका एपीब्रिज़िटिस स्टैंडआर्ट ग्रुप, एपीब्रेज़िएन्टी ऑपरेसिनेस सिस्टमोस सज़ाजस टारप जोजे वेइकियानसीओ प्रोग्राम बीईई टार्निबो। पिरमुओसियस स्टैंडआर्टस सुकरी इलेक्ट्रोस इर इलेक्ट्रॉनिकोस इनज़िनिरीज़ इंस्टिट्यूट (आईईईई) लिनक्स… … Enciklopedinis kompiuterijos žodynas

पॉज़िक्स- पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस का एक संक्षिप्त विवरण, यूनिक्स के एक्स का उपयोग करके एपीआई के महत्व को जानें (यूनिक्स में पोर्टेबल ऑपरेटिंग सिस्टम को कैसे समझें)। एस्टोस सन एक फैमिलिया डे एस्टांडेरेस डे लामाडास अल सिस्तेमा… … एनसाइक्लोपीडिया यूनिवर्सल

पॉज़िक्स- (यूनिएक्स पर आधारित पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस) एन। ऑपरेटिंग सिस्टम के लिए मानकों का संग्रह जो यूनिक्स (कंप्यूटर) पर आधारित हैं... अंग्रेजी समकालीन शब्दकोश

पॉज़िक्स

पॉज़िक्स- पोर्टेबल ऑपरेटिंग सिस्टम इंटरफ़ेस (POSIX [ˈpɒsɪks]) को IEEE और यूनिक्स मानकीकृत एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस के लिए ओपन ग्रुप द्वारा निर्मित किया गया है, जो एप्लिकेशन प्रोग्रामिंग इंटरफ़ेस को जोड़ता है... ... Deutsch विकिपीडिया

पुस्तकें

, स्टीफन ए. रागो, डब्ल्यू. रिचर्ड स्टीवंस। "UNIX. प्रोफेशनल प्रोग्रामिंग" एक विस्तृत संदर्भ मार्गदर्शिका है जो 20 वर्षों से मदद कर रही है पेशेवर प्रोग्रामरविशेष रूप से C भाषा में लिखें...
यूनिक्स। स्टीवंस डब्ल्यू रिचर्ड, रागो स्टीवन ए द्वारा प्रोफेशनल प्रोग्रामिंग। यह पुस्तक दुनिया भर के गंभीर प्रोग्रामरों के बीच काफी लोकप्रिय है क्योंकि इसमें यूनिक्स और लिनक्स कर्नेल के प्रबंधन के बारे में सबसे महत्वपूर्ण और व्यावहारिक जानकारी शामिल है। इनके बिना...

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

आईईईई मानक 1003.1-1988 (317 पृष्ठ) पहला पॉज़िक्स मानक था। इसने निम्नलिखित क्षेत्रों में सी भाषा और यूनिक्स-प्रकार कर्नेल के बीच इंटरफ़ेस को परिभाषित किया: प्रक्रियाओं को लागू करने के लिए आदिम (कांटा, निष्पादन कॉल, सिग्नल और टाइमर), प्रक्रिया वातावरण (उपयोगकर्ता आईडी, प्रक्रिया समूह), फ़ाइलें और निर्देशिकाएं (सभी) I/O फ़ंक्शंस), टर्मिनल, सिस्टम डेटाबेस (पासवर्ड और समूह फ़ाइलें), टार और सीपीआईओ संग्रह प्रारूपों के साथ काम करना।

टिप्पणी

पहला पॉज़िक्स मानक 1986 में IEEEIX नाम से कार्यशील रूप में जारी किया गया था। पॉज़िक्स नाम रिचर्ड स्टॉलमैन द्वारा सुझाया गया था।

फिर IEEE 1003.1-1990 मानक (356 पृष्ठ) सामने आया। यह अंतर्राष्ट्रीय मानक ISO/IEC 9945-1:1990 भी था। 1988 संस्करण की तुलना में, 1990 संस्करण में परिवर्तन न्यूनतम थे। शीर्षक जोड़ा गया था: "भाग 1: सिस्टम एप्लिकेशन प्रोग्राम इंटरफ़ेस (एपीआई)" ("भाग 1: सिस्टम एप्लिकेशन प्रोग्राम इंटरफ़ेस (एपीआई) [सी लैंग्वेज]"), जिसका अर्थ था कि मानक प्रोग्राम इंटरफ़ेस (एपीआई) का वर्णन करता है सी भाषा ।

आईईईई 1003.2-1992 कुल 1300 पृष्ठों के दो खंडों में आया, और इसके शीर्षक में "भाग 2: शैल और उपयोगिताएँ" पंक्ति शामिल थी। इस भाग ने दुभाषिया को परिभाषित किया (बॉर्न शेल के आधार पर)। यूनिक्स प्रणालीवी) और लगभग सौ उपयोगिताएँ (प्रोग्राम आमतौर पर दुभाषिया से बुलाए जाते हैं - awk और बेसनेम से vi और uass तक)। इस पुस्तक में हम इस मानक को पॉज़िक्स नाम से संदर्भित करेंगे। 2.

IEEE 1003.1b-1993 (590 पृष्ठ) को मूल रूप से IEEE P1003.4 के नाम से जाना जाता था। यह मानक 1003.1-1990 मानक के अतिरिक्त था और इसमें विकसित वास्तविक समय एक्सटेंशन शामिल थे काम करने वाला समहू P1003.4: फ़ाइल सिंक्रनाइज़ेशन, एसिंक्रोनस I/O, सेमाफोर, मेमोरी प्रबंधन, शेड्यूलिंग, घड़ियां, टाइमर और संदेश कतारें।

आईईईई 1003.1, 1996 संस्करण (743 पृष्ठ), इसमें 1003.1-1990 (बेस एपीआई), 1003.1बी-1993 (रीयल-टाइम एक्सटेंशन), 1003.1-1995 (पाथ्रेड्स - पॉज़िक्स प्रोग्राम थ्रेड्स), और 1003.1i-1995 (तकनीकी संशोधन) शामिल हैं 1003.1बी). इस मानक को ISO/IEC 9945-1: 1996 भी कहा जाता है। इसमें थ्रेड्स पर तीन अध्याय और थ्रेड सिंक्रोनाइज़ेशन (म्यूचुअल और कंडीशन वेरिएबल्स), थ्रेड शेड्यूलिंग, सिंक्रोनाइज़ेशन शेड्यूलिंग पर अतिरिक्त अनुभाग जोड़े गए हैं। इस पुस्तक में हम इस मानक को पॉज़िक्स.1 कहते हैं।

टिप्पणी

मानक के 743 पृष्ठों में से एक चौथाई से अधिक "तर्कसंगत और नोट्स" नामक परिशिष्ट थे। यह तर्क ऐतिहासिक जानकारी और उन कारणों की व्याख्या प्रदान करता है कि क्यों कुछ विशेषताएं मानक में शामिल थीं या नहीं थीं। अक्सर तर्क स्वयं मानक से कम उपयोगी नहीं होता है।

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

अंत में, ध्यान दें कि रीड-राइट लॉक पॉज़िक्स मानकों का हिस्सा नहीं हैं। इसे अध्याय 8 में अधिक विस्तार से बताया गया है।

भविष्य में रिलीज करने की योजना है नया संस्करण IEEE 1003.1, जिसमें P1003.1g मानक शामिल है, नेटवर्क इंटरफेस(सॉकेट और एक्सटीआई), जिनका वर्णन इस पुस्तक के पहले खंड में किया गया है।

1996 पॉज़िक्स.1 मानक की प्रस्तावना में कहा गया है कि आईएसओ/आईईसी 9945 में निम्नलिखित भाग शामिल हैं:

1. सिस्टम प्रोग्राम डेवलपमेंट इंटरफ़ेस (एपीआई) (सी भाषा)।

2. दुभाषिया और उपयोगिताएँ।

3. सिस्टम प्रशासन (विकास में)।

भाग 1 और 2 को हम पॉज़िक्स.1 और पॉज़िक्स.2 कहते हैं।

पॉज़िक्स मानकों पर काम चल रहा है, और उनसे संबंधित पुस्तकों के लेखकों को एक गतिशील लक्ष्य पर शूटिंग से निपटना पड़ता है। के बारे में वर्तमान स्थितिमानक http://www.pasc.org/standing/sd11.html पर पाए जा सकते हैं।