उस तरीके का क्या लाभ है जो लिनक्स स्थापित कार्यक्रमों की फाइलों को व्यवस्थित करता है? [बन्द है]

Question

विंडोज में, सिस्टम ड्राइव C:में एक निर्देशिका होती है program_files, जिसके तहत प्रत्येक प्रोग्राम की अपनी निर्देशिका होती है।

लिनक्स में, के तहत /usr/और , आदि /usr/local/हैं /bin, /etc, /share, /src।

इसलिए विंडोज़ में, प्रत्येक प्रोग्राम की सभी फाइलों को एक ही डायरेक्टरी में समूहीकृत किया जाता है, जबकि लिनक्स में, सभी प्रोग्रामों से एक ही प्रकार की फाइलें होती हैं।

मुझे लगता है कि जिस तरह से विंडोज स्थापित कार्यक्रमों को व्यवस्थित करता है वह लिनक्स के तरीके से अधिक तार्किक है, और इस प्रकार स्थापित प्रोग्राम मैन्युअल रूप से प्रबंधित करने के लिए अधिक आसान हैं।

उस तरीके का क्या लाभ है जो लिनक्स स्थापित कार्यक्रमों की फाइलों को व्यवस्थित करता है? धन्यवाद।

मुझे यह सवाल है जब शेल चलाने के लिए $ HOME में स्थापित प्रोग्राम को व्यवस्थित करने की समस्या होने पर उन्हें चलाने के लिए उन्हें कैसे खोजना चाहिए? , जहां मैं अपने कार्यक्रमों $HOMEको विंडोज के तरीके से व्यवस्थित करने की कोशिश करता हूं , लेकिन कार्यक्रमों के लिए खोज पथ निर्दिष्ट करने की कुछ समस्या है।

Comments

@RandallStewart आपके " अप्रत्याशित और बिखरे हुए " हमारे तर्कसंगत प्लेसमेंट और DLL का गैर-दोहराव है।

— रॉनजॉन

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

— थोरबजोरन रावन एंडर्सन

मुझे सबसे पहले यह बताना चाहिए कि विंडोज वर्तमान में प्रत्येक प्रोग्राम की सभी फाइलों को smae डायरेक्टरी में नहीं रखता है। "प्रोग्राम फाइल्स" और "प्रोग्राम फाइल्स (x86)" के अलावा, "लोकल", "लोकल", "लोकल्लो" और "रोमिंग" की "यूजर \ <यूजरनेम> \ एपडाटा" निर्देशिका हैं। न ही विंडोज़ ने हमेशा कार्यक्रमों के लिए "प्रोग्राम फाइल्स" फ़ोल्डर का उपयोग किया है या अपने इतिहास के माध्यम से लगातार इसका उपयोग किया है। * यह समय के साथ फ़ाइलों के संचालन में बहुत अधिक सुसंगत है।

— 20

@JAB, सहमत है, और इसे समझते हैं। मैं इंगित कर रहा था कि ओपी द्वारा बयान, अर्थात् "तो विंडोज़ में, प्रत्येक प्रोग्राम की सभी फाइलें एक ही निर्देशिका में समूहीकृत हैं" बस सच नहीं है। मैंने विंडोज रजिस्ट्री पर चर्चा भी नहीं की, जिसे विंडोज प्रोग्राम के बारे में स्टोरेज कॉन्फ़िगरेशन और अन्य डेटा के रूप में भी देखा जा सकता है और यह "प्रोग्राम फाइल्स" डायरेक्टरी का हिस्सा नहीं है।

— येलर

लिनक्स स्थापित कार्यक्रमों की फाइलों को व्यवस्थित करता है? कब से?

— 5:18

Answer 1

लिनक्स में आमतौर पर अलग-अलग स्थानों पर, जब अच्छी तरह से बनाए रखा जाता है, तो कुछ तर्क दर्पण करें। उदाहरण के लिए .:

• /bin सबसे बुनियादी उपकरण (कार्यक्रम) शामिल हैं
• /sbin सबसे बुनियादी व्यवस्थापक कार्यक्रम शामिल हैं

इन दोनों में बूटिंग और मौलिक समस्या निवारण द्वारा उपयोग किए जाने वाले प्राथमिक कमांड हैं। और यहाँ आप पहला अंतर देखते हैं। कुछ कार्यक्रम नियमित उपयोगकर्ताओं द्वारा उपयोग किए जाने के लिए नहीं हैं।

फिर अंदर देखिए /usr/bin। यहां आपको कमांड (कार्यक्रमों) का एक बड़ा विकल्प मिलना चाहिए, आमतौर पर उनमें से 1000 से अधिक। वे मानक उपकरण है, लेकिन की तरह ही आवश्यक नहीं हैं /binऔर /sbin।

/usr/binसम्‍मिलन सम्‍मिलित हैं, जबकि विन्यास फाइल कहीं और रहती है। यह दोनों कार्यात्मक संस्थाओं (कार्यक्रमों) और उनके कॉन्फ़िगरेशन और अन्य फ़ाइलों को अलग करता है, लेकिन उपयोगकर्ता की कार्यक्षमता के संदर्भ में, यह काम आता है, क्योंकि कमांड कुछ और के साथ इंटरमिक्स नहीं PATHकरते हैं, निष्पादन योग्य को इंगित करने वाले चर के सरल उपयोग के लिए अनुमति देता है । यह स्पष्टता का भी परिचय देता है। जो कुछ भी किया जाना चाहिए निष्पादन योग्य है।

मेरी तरफ देख लो PATH,

$ echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/home/tomas/bin
/usr/local/bin
/usr/bin
/bin
/usr/local/games
/usr/games

आज्ञाओं वाले ठीक छह स्थान हैं जिन्हें मैं सीधे कॉल कर सकता हूं (यानी उनके पथों द्वारा नहीं, बल्कि उनके निष्पादन योग्य नामों से)।

• /home/tomas/bin मेरे निजी निष्पादन के लिए मेरे होम फ़ोल्डर में मेरी निजी निर्देशिका है।
• /usr/local/bin मैं नीचे अलग से समझाता हूँ।
• /usr/bin ऊपर वर्णित है।
• /bin ऊपर भी वर्णित है।
• /usr/local/games/usr/local(नीचे समझाया जा करने के लिए) और खेल का एक संयोजन है
• /usr/gamesखेल हैं। उपयोगिता निष्पादन योग्य के साथ मिश्रित होने के लिए नहीं, उनके अलग स्थान हैं।

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

अंत में, PATHमेरे मूल उपयोगकर्ता पर एक नज़र डालें :

# echo "$PATH" | perl -F: -anlE'$,="\n"; say @F'
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin

इसमें ये शामिल हैं:

• /usr/local/sbin, जिसमें टाइप के एडमिन कमांड होते हैं /usr/local
• /usr/local/bin, जो वही हैं जो नियमित उपयोगकर्ता उपयोग कर सकते हैं। फिर से, उनके प्रकार के रूप में वर्णित किया जा सकता है /usr/local।
• /usr/sbin गैर-आवश्यक प्रशासन उपयोगिताओं हैं।
• /usr/bin गैर-आवश्यक प्रशासन और नियमित उपयोगकर्ता उपयोगिताओं हैं।
• /sbin आवश्यक व्यवस्थापक उपकरण हैं।
• /bin व्यवस्थापक और नियमित उपयोगकर्ता आवश्यक उपकरण हैं।

Comments

धन्यवाद। मुझे इस बात में बहुत दिलचस्पी है कि आप कैसे स्थापित किए जाने वाले कार्यक्रमों को व्यवस्थित करते हैं /home/tomasz/bin/, देखें unix.stackexchange.com/questions/431793/…

— टिम

मेरे समझ थी कि जब तक की जुदाई /binऔर /usr/binनेटवर्क पर लगे साथ से बचने के मुद्दों के लिए वास्तव में था /usrनिर्देशिका, की जुदाई /usrऔर /usr/localविक्रेता-आपूर्ति की फ़ाइलें (के बीच अंतर करने के लिए है /usr) और फ़ाइलों को मैन्युअल रूप से मशीन में ही (पर स्थापित /usr/local) और के साथ कोई संबंध नहीं था नेटवर्क-बढ़ते मुद्दे। क्या यह सही है?

— केइजी

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

— चार्ल्स डफी

यह सब 2018 में ऐसा एक बुरा विचार है

— अमारा

Answer 2

आजकल मुझे लगता है कि यह क्लासिक यूनिक्स से ऐतिहासिक विरासत है।

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

इसके अलावा, यूनिक्स पर्यावरण को तैयार उत्पाद (प्रलेखन तैयार करने के लिए) माना जाता था। इसलिए सभी साधनों के लिए पथ-एस निश्चित किया गया था।

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

Comments

सम्मोहक फायदे हैं जो आज उपयोगी हैं। में बाइनरी रखते हुए /usr/bin, में स्थिर डेटा फ़ाइलों /usr/shareऔर फ़ाइलों जिसमें संशोधित किया जा सकता /varया /usr/varमतलब है कि सुरक्षा उपायों में कि कुछ भी नहीं लागू करने के लिए इस्तेमाल किया जा सकता shareया var(का उपयोग करके निष्पादन योग्य है noexecउनके माउंट के लिए झंडे); बाहर कुछ भी varसंशोधित नहीं किया जा सकता है ( dm_verityहस्ताक्षरित, केवल-पढ़ने के लिए मीडिया को उत्पन्न करने के लिए या इसी तरह के उपायों का उपयोग करने वाले सिस्टम पर ); आदि

— चार्ल्स डफी

Answer 3

आप एक आधुनिक यूनिक्स जैसी प्रणाली के रूप में जो देखते हैं वह वास्तव में पारंपरिक नहीं है।

आम तौर पर, काफी न्यूनतम होगा //usr केवल सिस्टम उपयोगिताओं के साथ और पदानुक्रम होंगे, और प्रोग्राम को अलग से एक उपनिर्देशिका में स्थापित किया जाता है /usr/local, और फिर प्रतीकात्मक लिंक बनाकर उपलब्ध कराया जाता है।

जीएनयू सॉफ्टवेयर के लिए एक बहुत ही विशिष्ट सेटअप को संकलित और स्थापित करना था

./configure
make
make install prefix=/usr/local/DIR/program-1
cd /usr/local/DIR
stow program-1

जीएनयू स्टोव यूटिलिटी सॉफ्टवेयर को मानक पथ पर उपलब्ध कराने के लिए प्रतीकात्मक लिंक बनाती है, बिना किसी निर्देशिका को पैठ चर में जोड़े बिना (जैसा कि विंडोज करता है, और cruft वहाँ जमा हो जाता है)।

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

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

उसके लिए मेरा पारंपरिक सेटअप एक निर्देशिका है ~/software/DIRजिसे मैं प्रोग्राम स्थापित करता हूं, फिर स्टोव का उपयोग करके DIRबनाने के लिए ~/software/bin, ~/software/shareआदि। इसका मतलब है कि मुझे केवल ~/software/binअपने सभी इंस्टॉल किए गए सॉफ़्टवेयर को प्राप्त करने के लिए पैठ चर में जोड़ना होगा।

उपयोग:

./configure --prefix=~/software
make
make install prefix=~/software/DIR/program-1
cd ~/software/DIR
stow program-1

यह स्थापित करने के लिए कि प्रोग्राम GNU सम्मेलनों का अनुसरण करता है या नहीं।

Answer 4

आप व्यक्तिगत रूप से फाइलों को विभाजित करने की शैली के बारे में बात करते हुए दिखाई देते हैं ( /usr/binनिष्पादन के लिए, /usr/libपुस्तकालयों के लिए) आवेदन पैकेज के बजाय (एक dir में C ++ कंपाइलर, दूसरे में छवि संपादन प्रोग्राम)। हालांकि यूनिक्स प्रणालियों में इस ऐतिहासिक कारण के लिए बहुत कुछ है, वर्तमान समय की ताकतें भी हैं जो यूनिक्स जैसी प्रणालियों को इस ओर झुकाव देती हैं: पैकेज प्रबंधक जो एक सिस्टम पर अधिकांश कार्यक्रमों का प्रबंधन करते हैं।

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

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

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

कहा कि, यूनिक्स में "अलग-अलग निर्देशिका प्रति एप्लिकेशन" स्थापना की एक लंबी परंपरा है, आमतौर पर /optनिर्देशिका के तहत ।