GoboLinux
GoboLinux Unix-जैसे फाइलसिस्टम लेआउट को नाटकीय रूप से सरल बनाने में रुचि फिर से जगाता है, जहाँ हर प्रोग्राम अपनी स्पष्ट रूप से नामित डायरेक्टरी में इंस्टॉल होता है (जैसे, `/Programs/App/Version`) और पारंपरिक पथों के साथ संगतता के लिए symlinks का उपयोग किया जाता है। टिप्पणीकार इस मानव-पठनीय दृष्टिकोण की तुलना ऐतिहासिक, अक्सर उलझे हुए FHS लेआउट और Nix, Guix, Flatpak, तथा containers जैसी अधिक जटिल प्रणालियों से करते हैं, जो पारदर्शिता की बजाय reproducibility या isolation को प्राथमिकता देती हैं। कई लोग GoboLinux को एक सुंदर लेकिन विशिष्ट experiment मानते हैं, जिसके विचार मुख्यधारा प्रणालियों में अधिक सुलभ packaging और filesystem मॉडलों को प्रेरित कर सकते हैं.
GoboLinux का मुख्य विचार
- पारंपरिक Unix FHS को प्रति-एप्लिकेशन ट्री से बदलता है: उदाहरण के लिए,
/Programs/App/Version/…, जिसमें/System/Index/binजैसे केंद्रीय इंडेक्स होते हैं। - विरासती पथ (
/bin,/usr/bin,/usr/sbin, आदि) इन इंडेक्सों की ओर symlink होते हैं, इसलिए पारंपरिक सॉफ़्टवेयर फिर भी काम करता है। - लक्ष्य: मानव-पठनीय, स्व-व्याख्यात्मक लेआउट; ऐप इंस्टॉलेशन/रिमूवल आसान बनाना; “यह फ़ाइल कहाँ गई?” वाली उलझन कम करना।
फाइलसिस्टम डिज़ाइन पर प्रतिक्रियाएँ
- कई लोगों को यह “स्पष्ट रूप से तर्कसंगत” और ऐतिहासिक Unix लेआउट से अधिक सहज लगता है, जिसे कुछ लोग विरासती हार्डवेयर बाधाओं के संचय के रूप में देखते हैं।
- अन्य लोग FHS का बचाव करते हैं: इसके ठोस (यदि ऐतिहासिक) कारण हैं; इसे “गड़बड़” कहना स्थिरता और संस्थागत ज्ञान की अनदेखी है; इसे बदलने से एक अलग प्रकार का “तकनीकी ऋण” जोखिम में पड़ता है।
- एक उपसमूह को सौंदर्यगत पहलू पसंद नहीं: बड़े अक्षरों वाले डायरेक्टरी नाम (जैसे
/Programs) Windows के “Program Files” की याद दिलाते हैं और टाइप करने में अटपटे लगते हैं, हालांकि case-insensitive shell completion इससे काफी हद तक निपट लेती है।
macOS, Windows, Android से तुलना
- कई लोग macOS app bundles और Windows के
Program Filesसे समानता नोट करते हैं, जहाँ ऐप्स अपनी अलग डायरेक्टरियों में रहते हैं। - प्रतिवाद: macOS और Windows फिर भी config/state (जैसे
~/Library, registry) को इधर-उधर बिखेरते हैं, और uninstall करना messy हो सकता है। - Android को एक अधिक पूर्ण रूपांतरण के रूप में उद्धृत किया जाता है: single-file app distribution, मजबूत per-app directories, और sandboxing।
Nix, Guix, Spack, Flatpak, आदि से संबंध
- कुछ लोग Gobo को उन समस्याओं का पहले का, सरल उत्तर मानते हैं जिन्हें बाद में Nix/Guix/Spack और containers ने संभाला।
- Nix/Guix: सख्त reproducibility के लिए hash-based store paths का उपयोग करते हैं; तकनीकी रूप से अधिक शक्तिशाली लेकिन बहुत कम मानव-पठनीय, जिसे कुछ लोग adoption के लिए एक बड़ी बाधा मानते हैं।
- Spack को एक मध्य मार्ग के रूप में हाइलाइट किया गया है: name–version–hash paths के साथ configurable “views” जो अधिक semantic tree जैसी दिख सकती हैं।
- Flatpak/Snap: वितरण और sandboxing पर ध्यान देते हैं; उनकी जटिलता और duplication Gobo के filesystem clarity पर केंद्रित होने से अलग है।
उपयोगिता, सीखने की सहजता, और multi-user चिंताएँ
- समर्थक तर्क देते हैं कि Gobo cognitive load कम करता है और गैर-विशेषज्ञों के लिए यह समझना आसान बनाता है कि सॉफ़्टवेयर कहाँ रहता है।
- आलोचक multi-user/server निहितार्थों और परिचित conventions के नुकसान को लेकर चिंतित हैं, हालांकि Gobo versioned directories के माध्यम से isolation बनाए रखता है और packages को मिलाता नहीं है।
- कुछ लोग मौजूदा distros के ऊपर Gobo-जैसे layouts उपलब्ध देखना चाहते हैं; Gobo उपयोगकर्ता के home directory में “rootless” mode का समर्थन करता है।
परिपक्वता और अपनाया जाना
- परियोजना लगभग 20 साल पुरानी है, एक छोटे, धीमी गति से चलने वाले ecosystem के साथ; recipes/packages mainstream distros की तुलना में पीछे रह सकते हैं।
- कई लोग इसकी निरंतरता के लिए nostalgia और प्रशंसा व्यक्त करते हैं, लेकिन breadth और packaging की सुविधा के लिए फिर भी Debian/Ubuntu/etc. को default मानते हैं।