GoboLinux, एक प्रयोगात्मक Linux distribution जो filesystem को package DB की तरह इस्तेमाल करता है

 (gobolinux.org)
3 पॉइंट द्वारा GN⁺ 2024-03-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह एक प्रयोगात्मक distribution है जो पारंपरिक Linux distribution की directory conventions को काफी बदलकर सिस्टम संरचना को program-specific directories के आधार पर समझने लायक बनाता है
  • अलग package database की जगह filesystem को ही database की तरह इस्तेमाल किया जाता है, और program को /Programs/Nano/8.3 जैसे paths में version के हिसाब से रखा जाता है
  • नवीनतम release 017.01 पिछली ISO release के लगभग 5 साल बाद आया bug-fix update है, जो इस दौरान सामने आए कुछ महत्वपूर्ण मुद्दों को संबोधित करता है
  • संस्थापक Hisham Muhammad 25 साल तक संचालन करने के बाद पीछे हट गए हैं, और project अब GitHub user @fyrak1s ने संभाल लिया है
  • इसे Live environment के रूप में सीधे चलाया जा सकता है या hard drive पर install किया जा सकता है, ताकि सामान्य distributions से अलग filesystem structure को वास्तव में आज़माया जा सके

filesystem से packages को व्यवस्थित करने का तरीका

  • GoboLinux एक प्रयोगात्मक Linux distribution है जो पूरे filesystem hierarchy को फिर से परिभाषित करता है
  • इसका मूल विचार यह है कि अलग package database रखने के बजाय filesystem को database की तरह इस्तेमाल किया जाए
    • हर program अपनी directory में रखा जाता है
    • उदाहरण: /Programs/Nano/8.3, /Programs/GCC/14.2.0
  • इसकी संरचना सामान्य Linux distributions से अलग है, इसलिए पहली बार इस्तेमाल करने वाले users के लिए पहले documentation पढ़ना बेहतर रहेगा

017.01 release और संचालन में बदलाव

  • वर्तमान version 017.01 है
    • यह USB drive और DVD से चलने वाला Live environment है
    • इसे hard drive पर भी install किया जा सकता है
    • ISO को Downloads से डाउनलोड किया जा सकता है
  • v017.01 लगभग 5 साल के अंतराल के बाद आया bug-fix update है
    • यह पिछली ISO release के बाद सामने आए कुछ महत्वपूर्ण मुद्दों को संबोधित करता है
    • विस्तृत बदलाव release notes में देखे जा सकते हैं
  • project के संचालन में भी बदलाव हुआ है
    • संस्थापक और 25 साल तक GoboLinux का नेतृत्व करने वाले Hisham Muhammad ने आधिकारिक रूप से पद छोड़ा है
    • project अब @fyrak1s के संचालन में जारी है
    • Lucas Correia Villa Real, उर्फ paranoidd, जून 2021 तक Hisham के साथ GoboLinux को maintain करते रहे थे
  • community के मुख्य केंद्र chat, forum और wiki में बँटे हुए हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2024-03-01
Hacker News की राय

  • अगर किसी को GoboLinux के डिज़ाइन से तीखी तुरंत अस्वीकृति वाली भावना आती है, तो 20 साल पुराने “I am not clueless”¹ दस्तावेज़ में इसकी पृष्ठभूमि और तर्क काफ़ी विस्तार से दिए गए हैं
    मेरी अस्वीकृति अभी पूरी तरह खत्म नहीं हुई है, लेकिन पहले जितनी तीखी भी नहीं रही ;)
    ¹ https://gobolinux.org/doc/articles/clueless.html

    • लेख का टोन HTMX या Tailwind docs जैसा लगता है
      इसे मोटे तौर पर यूँ संक्षेप किया जा सकता है: “हमें पता है कि हम अलग हैं। यह बहुत सरल है। शायद आपको इसकी आदत न हो, लेकिन इसे समझना और संभालना आसान है। इस्तेमाल न करना चाहें तो न करें। हमें यह पसंद है और हम इससे संतुष्ट हैं”
    • लिंक किए गए लेख के make all programs relocatable हिस्से में कहा गया है कि libprefix इस्तेमाल करके सभी apps को फिर से लिखना होगा; यहाँ libprefix से क्या मतलब है, यह जानने की उत्सुकता है
      वेब खोज से कोई काम का नतीजा नहीं मिला
    • सोचता हूँ कि इस reflexive अस्वीकृति का बड़ा हिस्सा functional चीज़ों से ज़्यादा ऊपरी डिज़ाइन से तो नहीं आता
      जैसे पहली प्रतिक्रिया का बड़ा हिस्सा uppercase लिखावट से आता है; capital P वाला Programs, Windows के Program Files की याद दिलाता है और भावनात्मक तौर पर खटकता है
      libx11 की जगह LibX11 टाइप करना पड़े तो थोड़ा झुंझलाहट हो सकती है
      Linux filesystem आम तौर पर case-sensitive होता है, लेकिन package names में सिर्फ case से अलग duplicates से बचा ही जाएगा, और user-friendly hierarchy चाहने वाला कोई distro root में सिर्फ case से अलग directories रखेगा, इसकी संभावना भी कम लगती है
      फिर भी अगर examples /packages/libx11/1.6.9, /packages/gcc/9.2.0 होते, तो शुरुआती प्रतिक्रिया कहीं कम होती, और ऐसे नाम रखने से फायदे ज़रा भी कम नहीं होते

  • सच में अफसोस है कि GoboLinux का idea mainstream Linux community में जगह नहीं बना पाया
    Linux का filesystem structure पूरी तरह बिखरा हुआ है

    • सहमत हूँ, लेकिन यह देखकर अच्छा लगता है कि Nix, Guix, और Spack—जिस पर मैं सबसे ज़्यादा काम करता हूँ—मूल रूप से उसी दिशा में बढ़ रहे हैं और धीरे-धीरे momentum पा रहे हैं
      इसे ठीक से काम कराना हमेशा मामूली काम नहीं होता, और इसे efficient बनाना और भी मुश्किल है
      मुझे लगता है कि हाल के कुछ वर्षों में ही अधिकांश software distribution के लिए यह model वास्तव में maintainable स्तर के करीब पहुँचा है
    • Nix धीरे-धीरे लोकप्रिय हो रहा है
      GoboLinux model में /Programs/Xorg/7.0 जैसी version directories को manually manage करना पड़ता है, जबकि Nix package का install path build recipe के hash से तय करके उस समस्या को खत्म कर देता है
    • अभी जो consistent तौर पर समझ में आते हैं, वे बस /home और /tmp जैसे हिस्से हैं
      बाकी सब लगभग ऐसी रद्दी-टोकरी जैसा है जहाँ जो मन हो, कहीं भी डाल दिया जाता है
    • उन ideas ने निश्चित रूप से मुझे inspire किया
      GoboLinux वह पहला project था जिसने दिखाया कि Linux में सचमुच अपनी मर्ज़ी से चीज़ें की जा सकती हैं
    • /opt और /srv, और पसंद के हिसाब से /usr/local/opt, GoboLinux की तरह components को एक-एक करके manage करने के फायदे काफ़ी हद तक देते हैं
      distro के नज़रिए से सब कुछ अपने-अपने ढंग से समझ में आता है
      dpkg -S this-file चलाएँ तो /usr के अंदर कोई file क्यों है, यह जल्दी पता चल जाता है, और distro पूरी तस्वीर समझाने की भूमिका निभाता है
      जानना चाहूँगा कि आपको कौन सा हिस्सा सबसे ज़्यादा गड़बड़ लगता है

  • यह दिलचस्प है कि traditional paths को GoboLinux के corresponding paths पर map करके Unix heritage के साथ compatibility को transparent रखा गया है
    इसमें कोई खास जादू नहीं है: /bin, /System/Index/bin का link है, और /usr/bin व /usr/sbin भी वैसे ही सभी “binary” directories को उसी जगह point करते हैं
    इससे किसी भी standard path से access करने पर file काम करती है, इसलिए यह आम distros से उलटे ज़्यादा compatible हो सकता है, जहाँ वास्तविक file /usr/local/bin/foo में होती है लेकिन script /usr/bin/foo को refer करके टूट जाती है

  • बिना ज़्यादा जानकारी के पूछ रहा हूँ: क्या macOS कुछ हद तक इसी तरह काम करता है?
    applications का हमेशा drag-and-drop से manage होने वाली एक “file” जैसा दिखना मुझे वाकई अच्छा लगा था
    Ubuntu में कुछ कहाँ है और कहाँ install होता है, यह समझने की कोशिश करूँ तो खुद को बेवकूफ जैसा महसूस करता हूँ

    • Ubuntu में क्या कहाँ है और कहाँ जाता है, यह पता लगाना इसलिए और मुश्किल हो जाता है क्योंकि Linux file managers home folder या mounted drives के अलावा filesystem के हिस्सों को छिपाने की कोशिश करते हैं
      क्यों करते हैं, यह समझ में आता है
      औसत Linux install की directory structure technical लोगों के लिए भी उलझाने वाली भूलभुलैया है, और major distros जिन सामान्य users को target करते हैं, उनके लिए तो और भी ज़्यादा
      लेकिन आखिरकार यह कारण नहीं, लक्षण का इलाज है; मुझे लगता है कि और Linux distros को Gobo की तरह filesystem structure को modernize करने पर गंभीरता से सोचना चाहिए
      खुद आज़माने का भी मन है
      लक्ष्य ऐसा structure बनाना है जो तर्कसंगत और self-explanatory हो, beginners को खतरनाक areas से दूर guide करे, और file manager को लगभग कुछ भी छिपाने की ज़रूरत न पड़े
    • macOS के bundles एक अच्छा idea थे और अब भी हैं, लेकिन apps फिर भी आम तौर पर ~/Library जैसी अजीब जगहों पर चीज़ें बिखेर देते हैं
      Minecraft launcher जैसे cases मज़ेदार हो जाते हैं, जहाँ bundle के अंदर सब कुछ, worlds और save files तक मौजूद होते हैं
    • सिद्धांत रूप में मैं इस बात से सहमत हूँ कि application एक “file” जैसी दिखती है, लेकिन असल में कई apps ~/Library और /Library में कई files डालती हैं
      macOS पर भी कुछ apps हटाने के लिए कई steps वाली manual deletion guide follow करनी पड़ती है, ऐसा होना दुर्लभ नहीं है
      खासकर अगर app login items जोड़ती हो, तो यह और महत्वपूर्ण हो जाता है
      Windows का Add/Remove Programs कम से कम uninstall चलाने के लिए एक central जगह देता है, और ज़्यादातर apps उस तरीके का ठीक से पालन करती हैं
    • Fedora में rpm database query करना आसान है
      क्या dpkg से भी वही काम नहीं किया जा सकता?
    • Mac में मुझे ठीक वही बात सचमुच नापसंद है

  • पहले directory नाम को बड़े अक्षर से शुरू करना मुझे खास पसंद नहीं है
    path navigate करते समय यह extra काम जैसा लगता है, और हर बार किसी letter या digit के साथ Shift दबाना रोज़मर्रा के command-line use में काफ़ी झंझट है

    • ऊपर link किए गए लेख के मुताबिक, GoboLinux के default shell की तरह ठीक से configured shell में /Programs टाइप करने में /usr जितनी ही key presses लगती हैं
      slash, lowercase p, Tab बस इतना ही
    • PowerShell या cmd.exe में navigate करते समय यह बिल्कुल परेशान क्यों नहीं करता? क्योंकि shell मदद करता है
      usability sacrifice करके PDP-11 के कीमती ticks और memory बचाने के लिए मजबूर नहीं करता
      “case-sensitivity सबसे बढ़िया!” वाले fans का यह भूल जाना हमेशा मज़ेदार लगता है कि यह असल में पुराने system constraints का नतीजा भर था
      feature नहीं
      ऊपर से यह हिस्सा explicitly handle किया गया है
      सिर्फ set completion-ignore-case On करने से ही ज़िंदगी काफी बेहतर हो जाती है
      क्योंकि GoboLinux न भी इस्तेमाल करें, तो भी uppercase से शुरू होने वाले हर filename पर Shift एक बार कम दबाना पड़ेगा
      या फिर 1977 की तरह जीते रहिए
      आपका VT100, आपके rules
      बाद में “normal navigation के लिए bash को वैसे ही क्यों नहीं इस्तेमाल करते और दूसरा shell क्यों install करते हो” जैसी बात देखी, यानी उसे अपना shell भी ठीक से नहीं पता
    • एक नज़र में यह directory है या normal file, यह बताने वाली convention के तौर पर मुझे पसंद है
      और कोई भी shell case-insensitive autocomplete दे सकता है; Fish तो default में देता है
    • uppercase का मकसद FSH/legacy directories से clash बचाना है
    • पसंद नहीं
      Windows जैसा feel आता है

  • इस project में हमारा cognitive load काफी घटाने की potential है
    उम्मीद है यह सफल हो
    Edit: अब देखा तो यह 20 साल पुराना project है

  • इतना rational है कि आँसू आ जाएँ
    libraries की कई copies को deduplicate करने का काम, अगर वाकई ज़रूरी हो, तो filesystem को संभालना चाहिए
    आखिर यह file-level duplication है, तो उसी level पर हल होना चाहिए

  • बहुत खराब closed-source applications user system से बहुत ज़्यादा उम्मीदें रखती हैं
    Steam client ऐसा ही उदाहरण है: यह sh script नहीं बल्कि bash script देता है, Linux mount user-space container requirements की वजह से Debian/Ubuntu-style file layout को मजबूती से assume करता है, और कई commands के GNU-only अजीब options भी मांगता है
    32-bit libraries भी बहुत हैं
    फिर भी लगता है ABI अभी इनके control में है, और शायद binutils gas का .symver directive इस्तेमाल करता है
    कम-से-कम मौजूदा mess तो Steam हमारे गले उतार रहा है, और अगर distro games से दूर नहीं है तो इससे बचना मुश्किल है

    • ज़्यादातर लोग games नहीं खेलते, और Linux users में भी बहुत से लोग शायद शुरू से ही proprietary apps इस्तेमाल नहीं करेंगे
      gamers के group में भी काफी लोगों के पास अलग dedicated gaming PC होने की संभावना बड़ी है

  • मुझसे कहीं ज़्यादा smart कोई समझाए कि यह snap/Flatpak या NixOS जैसे distros से क्यों बेहतर है, या सच में बेहतर है भी या नहीं
    गहराई से समझे बिना ऊपर-ऊपर से देखने पर यह तरीका सबसे simple लगता है
    बेशक यह मेरी knowledge की कमी मानकर कही गई बात है

    • अगर बात सिर्फ हर app को अपने folder में रखने की है, तो इतना अकेले isolation के लिए काफी नहीं है और इसे कितना आगे बढ़ाते हैं उस पर निर्भर करते हुए यह बेहद wasteful हो सकता है
      Flatpak और NixOS ज्यादा complex हैं तो उसकी वजह है
      उदाहरण के लिए, वे disk पर dependencies के ठीक वही version duplicate store नहीं करते
    • snap और Flatpak distribution पर ज्यादा focus करते हैं और “sandboxed” हैं
      quotes इसलिए लगाए हैं क्योंकि security issues हैं
      NixOS existing programs के साथ compatibility तोड़ता है, जबकि Gobo ऐसा नहीं करता
      लेकिन NixOS की package repository Gobo से भारी तौर पर बेहतर maintained है, और Gobo वाली incomplete है और कई साल पीछे है
      फिर भी यहां जिन सबका जिक्र है, वे सभी Android के apps store करने के तरीके से पीछे हैं
      Android में हर application को एक single file के रूप में distribute किया जा सकता है जिसे distribute करना आसान है, वह ठीक से sandboxed होती है, और उसका अपना directory होता है
      बाकी तरीकों ने जो बात छोड़ी है: हर app के पास अपने state को store करने के लिए app directory के नीचे subdirectory होती है, और वह per-user भी अलग होती है

  • GoboLinux डेवलपर्स ने इंसानों के समझ में आने वाली फाइलसिस्टम व्यवस्था को सचमुच “बुद्धिमत्तापूर्ण” बना दिया था
    मुझे लगता है कि आज के दौर में, जब 8.3 नाम की सीमा, स्टोरेज की कमी, 1GB से बड़े फाइलों की समस्या जैसी बाधाएँ नहीं रहीं, अभी इस्तेमाल हो रही पुरानी UNIX परंपराएँ काफी पेचीदा हैं
    पहले version control software होस्ट करने वाले सर्वर पर मैंने GoboLinux 012~015 कई साल चलाया था, और कुल मिलाकर यह बहुत अच्छा था
    अड़चन यह थी कि अगर जरूरी package नहीं होता, तो recipe बनानी पड़ती थी
    GoboLinux की recipe लिखने की भाषा अपने-आप में समझने में आसान थी, लेकिन अक्सर एक package दर्जन-भर या कई दर्जन libraries पर निर्भर होता था, इसलिए उन्हें track करना, versions मिलाना, libraries और package URL ढूँढना, और फिर recipe बनाना—इन सब में बहुत समय जाता था
    आखिरकार मैं Debian पर चला गया, लेकिन आज भी configuration files को /etc में और binaries को /usr/bin या /usr/local/bin में जाते देखता हूँ तो झिझक महसूस होती है
    मेरी राय में systemd झंझट भरा और ऑक्टोपस जैसा है
    संबंधित .service फाइल खोजने के लिए find इस्तेमाल करना आम बात है, यह भरोसा नहीं किया जा सकता कि वह एक ही जगह होगी, और command line भी सहज नहीं है
    इसके उलट Gobo में services manage करने वाली scripts का समूह बहुत सरल और संभालने में आसान था
    फिर भी जरूरत की चीज़ को सीधे apt get या dpkg -i से install कर पाने की सुविधा, GoboLinux के कहीं ज्यादा तार्किक और बुद्धिमत्तापूर्ण design पर भारी पड़ती है
    आजकल supported Linux distributions की संख्या पहले की अनगिनत choices से घट गई है, और लगभग हमेशा Debian या Ubuntu default में शामिल होते हैं, इसलिए repository के बाहर भी किसी package या program को install न कर पाने की संभावना कम है
    macOS भी निश्चित रूप से कुछ हद तक GoboLinux जैसी पद्धति अपनाता है, और इसलिए हाल की काफी user-hostile versions से पहले command line से macOS को संभालना काफी आसान था
    उदाहरण के लिए USB drives /Volumes में होती हैं, और program configuration files ~/Library के नीचे होती हैं

    • वैसे, अगर service loaded है, तो सिर्फ systemctl status foo चलाने पर भी दूसरी line से ही यह ठीक-ठीक बता देता है कि कौन-सी files शामिल हैं
      उदाहरण के लिए systemctl status getty@tty1.service के output में Loaded: loaded (/lib/systemd/system/getty@.service; enabled; preset: enabled) जैसा आता है, इसलिए /lib/systemd/system/getty@.service तुरंत पता चल जाता है