अपरिवर्तनीय Linux सिस्टम का परिचय

 (dataswamp.org)
3 पॉइंट द्वारा GN⁺ 2023-09-19 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • अपरिवर्तनीय Linux डिस्ट्रीब्यूशन अपग्रेड को चल रहे सिस्टम पर नहीं, बल्कि कहीं और तैयार करके अगले बूट पर लागू करते हैं, जिससे विफल होने पर वापस लौटा जा सकता है
  • “अपरिवर्तनीय” नाम के बावजूद सिस्टम के कई हिस्से अब भी बदले जा सकते हैं, और असली समानता transactional update और rollback के ज्यादा करीब है
  • NixOS·Guix declarative configuration और read-only store को केंद्र में रखते हैं, जबकि OSTree परिवार·MicroOS·Vanilla OS क्रमशः /usr, btrfs snapshot, और A/B root partition के जरिए यह तरीका अपनाते हैं
  • फायदे यह हैं कि package बदलते समय भी सिस्टम स्थिर रहता है और समस्या होने पर बदलाव वापस लिए जा सकते हैं, लेकिन reboot की जरूरत, configuration management tools से टकराव, और बदलावों को track करने की कठिनाई अब भी बनी रहती है
  • असली नई बात snapshot खुद नहीं, बल्कि live न रहने वाले environment में बदलाव लागू करना, और उसे bootloader व user tools में integrate करके संभालना आसान बनाना है

“अपरिवर्तनीय” नाम की वास्तविक सीमा

  • अपरिवर्तनीयता का मूल अर्थ न बदलने वाली object है, लेकिन operating system पर लागू करते ही इसकी परिभाषा धुंधली हो जाती है
  • Linux LIVE-CD हर बार एक ही program के साथ boot होता है और disk media read-only होता है, इसलिए वह अपरिवर्तनीय जैसा दिख सकता है, लेकिन चलते समय file और directory बनाई जा सकती हैं या package install किए जा सकते हैं
  • आज किसी Linux डिस्ट्रीब्यूशन को अपरिवर्तनीय कहने के लिए आम तौर पर तीन शर्तें जरूरी मानी जाती हैं
    • सिस्टम upgrade सीधे live system पर नहीं किया जाता
    • package बदलाव अगले बूट पर लागू होते हैं
    • पिछले state पर rollback किया जा सकता है
  • अलग-अलग implementation में अतिरिक्त features भिन्न हो सकते हैं, लेकिन ये तीन बातें आज के “अपरिवर्तनीय” डिस्ट्रीब्यूशन की न्यूनतम शर्तों के करीब हैं

implementation के अनुसार अंतर

  • NixOS / Guix

    • NixOS और Guix एक ही प्रकार की implementation पर निर्भर हैं; Nix पहली बार 2003 में आया था, और Guix package manager 2010 के शुरुआती वर्षों में Nix से fork होकर 100% free software का लक्ष्य लेकर बना
    • ये दोनों सिस्टम पारंपरिक Unix-परिवार के सिस्टम से काफी अलग हैं और अपरिवर्तनीयता को मूल सिद्धांत मानते हैं
    • सभी package और build की गई files एक खास read-only directory में, जिसे केवल package manager इस्तेमाल कर सकता है, अलग-अलग unique entries के रूप में रखी जाती हैं
    • operating system खुद package manager का output होता है, और user अपनी इच्छित system state को declarative configuration के रूप में लिखता है
    • configuration में user, shell, install किए जाने वाले package, चलने वाली services और उनकी settings, mount होने वाले partitions और options आदि शामिल होते हैं
    • modules default values देते हैं, इसलिए user बनाते समय UID, GID, shell, home directory सब कुछ हाथ से तय करना जरूरी नहीं होता
    • /etc/fstab या /bin/sh जैसी files भी read-only होती हैं, और उन्हें बदलने के लिए package manager से होकर गुजरना पड़ता है
    • configuration switch symbolic link बदलने के करीब होता है, इसलिए तुरंत संभव है, और boot के समय पुरानी configuration चुनकर rollback किया जा सकता है
    • खास store directory को छोड़कर /home, /etc, /var आदि बदले जा सकते हैं; system symbolic link को किसी और से बदला जा सकता है, लेकिन मूल source को संपादित नहीं किया जा सकता
    • NixOS को एक अच्छी implementation माना जाता है, लेकिन यह मौजूदा सिस्टम से इतना अलग है कि फायदों के बावजूद इसका adoption कम है

  • Endless OS

    • Endless OS आम users के लिए जारी शुरुआती अपरिवर्तनीय OS में से एक था, जिसका लक्ष्य ऐसा मजबूत सिस्टम बनाना था जो कम internet या बिजली ढांचे वाले देशों में भी काम कर सके
    • यह Debian-आधारित है, लेकिन OSTree के जरिए अपरिवर्तनीयता लागू करता है
    • OSTree core system image को manage करता है और उसके ऊपर package जैसी layers जोड़ता है, साथ ही अगले boot के लिए नया system image तैयार कर सकता है
    • package बदलाव अगले boot में इस्तेमाल होने वाले नए system version पर लागू होते हैं, और boot के समय पिछले version पर लौटा जा सकता है
    • partitions आम तौर पर writable होते हैं, लेकिन OSTree द्वारा संभाला जाने वाला package area /usr read-only mount होता है
    • /etc में rollback नहीं है
    • user apps Flatpak से install किए जाते हैं, जिससे हर नया package install करने पर reboot की जरूरत कम होती है
    • संशोधित GNOME desktop smartphone menu जैसा दिखता है और गैर-तकनीकी users के लिए परिचित अनुभव देने का लक्ष्य रखता है
    • DevOps tools install करना व्यावहारिक नहीं है, लेकिन असंभव भी नहीं

  • Fedora Silverblue

    • Fedora Silverblue Project Atomic की अगली धारा में आता है, जिसका उद्देश्य Fedora / CentOS / RHEL को अपरिवर्तनीय बनाना था
    • यह OSTree के ऊपर RPM package बदलाव लागू करने के लिए rpm-OSTree का उपयोग करता है
    • सिस्टम हर release के लिए एक single core image और उसके ऊपर जोड़ी जाने वाली package layers से बना होता है
    • install की गई package layers की सूची देखी जा सकती है, और package हटाने पर पूरा stack फिर से बनाया जाता है ताकि हटाने के बाद अवशेष न बचें
    • यह rebuild प्रक्रिया काफी धीमी होती है
    • package install करने पर भी वह मौजूदा boot हुए सिस्टम पर लागू नहीं होता, इसलिए आम तौर पर reboot जरूरी है; boot के समय पिछला system version चुना जा सकता है
    • rpm-OSTree अगले boot के बदलावों को tmpfs overlay के रूप में live system में अस्थायी रूप से merge करने की सुविधा देता है
    • mount policy /etc, /root, /var को छोड़कर read-only है, और home directory डिफ़ॉल्ट रूप से /var/home में होती है, जो अपेक्षा से अलग लग सकती है
    • /etc को rpm-OSTree manage नहीं करता, इसलिए उसका rollback नहीं होता
    • /usr/local वास्तव में /var के अंदर की directory की ओर जाने वाला symbolic link है, इसलिए RPM file के बिना भी user बदलाव inject करना आसान है
    • package install धीमा है और reboot चाहिए, इसलिए Flatpak या toolbox के उपयोग की सिफारिश की जाती है
    • toolbox root privileges के बिना Fedora container बनाता है, ताकि terminal से development libraries या tools इस्तेमाल किए जा सकें

  • OpenSUSE MicroOS / Aeon

    • OpenSUSE MicroOS rolling-release OpenSUSE Tumbleweed का अपरिवर्तनीय spin है और अपनी खुद की implementation इस्तेमाल करता है
    • /home, /var जैसी कुछ directories को छोड़कर पूरा सिस्टम btrfs snapshot पर आधारित है
    • जब system बदलाव की जरूरत हो, तो मौजूदा snapshot को नए snapshot में clone किया जाता है और बदलाव उसी नए snapshot पर लागू किए जाते हैं, जिसे अगले boot में उपयोग किया जाएगा
    • OSTree-आधारित सिस्टम से अलग, /etc भी snapshot का हिस्सा है, इसलिए उसका rollback किया जा सकता है
    • नए snapshot के अंदर shell का उपयोग करके file system की किसी भी file को बदला जा सकता है, जो driver समस्या के समाधान के लिए file inject करने जैसे कामों में उपयोगी है
    • लेकिन ऐसे बदलाव track नहीं होते, इसलिए यह सुनिश्चित करना कठिन है कि सिस्टम “शुद्ध” state में है या नहीं
    • बदलाव transactional-update command से किए जाते हैं; package जोड़े या हटाए जा सकते हैं, या नए snapshot के अंदर shell खोलकर मनचाहे बदलाव किए जा सकते हैं
    • /etc snapshot में शामिल है, लेकिन हमेशा readable रहता है, इसलिए live state में /etc बदलकर नया snapshot बनाने पर वह बदलाव तुरंत inherit हो जाता है
    • डिफ़ॉल्ट तरीका यह मानकर चलता है कि update के बाद रोज reboot की योजना बनाई जाएगी; rolling-release होने के कारण रोज updates आते हैं और reboot से पहले नए packages का लाभ नहीं मिलता
    • automatic reboot को disable किया जा सकता है
    • Silverblue की तरह live system में बदलाव लागू करने की सुविधा अभी experimental है और अभी उपयोग के लिए उपलब्ध नहीं है
    • इसके बजाय distrobox के जरिए कई डिस्ट्रीब्यूशन के non-root containers इस्तेमाल कर user tools install करने की सिफारिश की जाती है

  • Vanilla OS

    • Vanilla OS Ubuntu-आधारित है और जल्द ही Debian-आधारित होने वाला एक नया अपरिवर्तनीय सिस्टम है
    • इसकी अपरिवर्तनीयता ABroot से लागू होती है
    • ABroot में root partition A, root partition B, और /home या /var जैसे persistent data के लिए partition होते हैं
    • boot और बदलाव का प्रवाह इस प्रकार है
      • पहला boot A से होता है और A read-only mount होता है
      • नए package या /etc file बदलाव जैसे system परिवर्तन B पर लागू किए जाते हैं, और tmpfs overlay के जरिए उन्हें live भी लागू किया जा सकता है
      • reboot के बाद B से boot होता है, और यदि सब सफल रहा तो ABroot A और B के अंतर को scan करके B के बदलाव A पर लागू कर देता है
      • जब कोई नया बदलाव नहीं होता, तब A और B हमेशा समान रहते हैं
    • इसकी कमी यह है कि rollback केवल नए version पर boot करने से पहले तक ही संभव है
    • एक बार नए version पर boot हो जाने के बाद बदलाव पुराने boot partition पर भी लागू हो जाते हैं, इसलिए फिर rollback संभव नहीं रहता
    • यह तरीका मुख्य रूप से failed upgrade या live में परखे गए बदलावों को वापस लेने में उपयोगी है
    • Vanilla OS apx package manager देता है
    • apx, distrobox के लेखक का बनाया हुआ tool है, जो non-root user को Arch Linux, Fedora, Ubuntu, Nix आदि कई डिस्ट्रीब्यूशन के package install करने और उन्हें local install की तरह integrate करने देता है
    • Vanilla OS, ABroot, और apx अभी नए हैं और इनमें कई खुरदरे हिस्से हैं

  • Alpine Linux with LBU

    • Alpine Linux lbu command से अपरिवर्तनीयता के करीब एक configuration बना सकता है
    • Alpine installer को base boot system की तरह उपयोग किया जाता है, और “saved configuration” tarball बनाकर boot के समय अपने-आप लागू किया जाता है
    • हर boot पर directories फिर से unpack होती हैं और packages फिर से install होते हैं, और सब कुछ live memory में पूरी तरह writable रहता है
    • सिस्टम हमेशा clean state से शुरू होता है और उसके ऊपर बदलाव लागू किए जाते हैं, इसलिए बदलाव rollback करके फिर से नई शुरुआत की जा सकती है
    • यह ऊपर दी गई अपरिवर्तनीयता की परिभाषा को पूरी तरह पूरा नहीं करता, क्योंकि बदलाव base system के ऊपर लागू होते हैं
    • पूरा सिस्टम memory में होता है और क्या save/restore करना है यह खुद manage करना पड़ता है, इसलिए अच्छी समझ चाहिए और archive बड़ा हो सकता है
    • documentation भी कम है

फायदे और संचालन संबंधी सीमाएँ

  • फायदे

    • समस्या आने पर बदलाव rollback किए जा सकते हैं
    • transactional update package बदलाव के दौरान भी सिस्टम को सही तरह से चलने में मदद करते हैं

  • नुकसान

    • Ansible, Salt, Puppet जैसे configuration management tools के साथ integration बहुत खराब है
    • भले ही उन्हें package बदलाव लागू करने के तरीके के हिसाब से update कर दिया जाए, अगर उन्हें सामान्य सिस्टम की तरह manage करने की कोशिश की जाए तो ज्यादातर मामलों में दिक्कत आती है
    • बदलाव के बाद reboot करना पड़ना परेशान करने वाला है, हालांकि NixOS और Guix में हर बदलाव के लिए reboot जरूरी नहीं होता
    • OSTree-आधारित सिस्टम लचीले नहीं हैं
      • उदाहरण के लिए, अगर किसी netbook में sound के लिए ALSA directory में अतिरिक्त file चाहिए, तो उसे जोड़ने के लिए वह file देने वाला package बनाए बिना काम नहीं चलेगा
    • rollback लगभग blind rollback जैसा है, इसलिए यह समझना मुश्किल होता है कि हर system version में कौन-से बदलाव थे
    • Nix/Guix जैसे programs जिन्हें root file system में directory चाहिए, या ऐसे software जिन्हें package नहीं किया गया है, उनका system-wide install कठिन हो सकता है

अपरिवर्तनीय सिस्टम के बारे में तथ्य और भ्रम

  • सख्ती से देखें तो अपरिवर्तनीयता लगभग एक गलत नाम है, क्योंकि सिस्टम के बहुत से हिस्से अब भी बदले जा सकते हैं
  • अपरिवर्तनीय का अर्थ stateless नहीं होता
  • NixOS और Guix स्थिर package manager के जरिए पूरे सिस्टम को track करते हैं, और source पर version control system भी इस्तेमाल किया जा सकता है, इसलिए इन्हें शुरुआत से सही दर्शन वाले implementation के रूप में देखा जाता है
  • अपरिवर्तनीयता को अक्सर security लाभ से जोड़ा जाता है, लेकिन root privileges पाने वाला attacker live system से छेड़छाड़ कर सकता है और /boot partition को भी बदल सकता है
  • अगले boot के लिए backdoor install होने से रोकने वाली कोई चीज़ नहीं है
  • अपरिवर्तनीयता के लिए अनुशासन और maintenance जरूरी है
    • version control पर ध्यान देना पड़ता है
    • apx, distrobox, devbox जैसे अतिरिक्त programs को सिस्टम से अलग update करना पड़ता है
    • NixOS और Guix में यह हिस्सा integrated है

वास्तव में नया क्या है

  • अपरिवर्तनीय operating system open source system community में काफी ध्यान खींच रहे हैं, लेकिन एक ही शब्द के नीचे कई अलग implementation और use case मिल गए हैं
  • “अपरिवर्तनीय” नाम users में कुछ खास अपेक्षाएँ पैदा करता है, जबकि व्यवहार में यह operating system के लिए transactional update के ज्यादा करीब है
  • transactional update खुद कोई नया विचार नहीं है
    • Solaris और ZFS में boot के समय system snapshot चुना जा सकता था
    • FreeBSD ने भी लगभग 10 साल पहले इसी तरह की सुविधा लागू की थी
    • सामान्य Linux डिस्ट्रीब्यूशन भी btrfs snapshot के साथ boot के समय snapshot चुन सकते हैं
  • सचमुच नई बात यह है कि transactional बदलाव live के बाहर वाले environment में लागू किए जाते हैं, उन्हें bootloader में integrate किया जाता है, और users को उन्हें आसानी से संभालने वाले tools दिए जाते हैं
  • आगे पढ़ने के लिए Colin Walters की “Immutable” → reprovisionable, anti-hysteresis की सिफारिश की जाती है

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

1 टिप्पणियां

 
GN⁺ 2023-09-19
Hacker News टिप्पणियाँ

  • Silverblue को सूची में देखकर अच्छा लगा, लेकिन Fedora CoreOS का न होना खलता है
    FCOS production में इस्तेमाल के लिए अच्छा OS है और CoreOS अधिग्रहण के बाद काफी आगे बढ़ा है। Nix की तुलना में इसे सीखना आसान और इस्तेमाल करना सुविधाजनक है, फिर भी यह immutability बनाए रखता है—एक अच्छा बीच का रास्ता लगता है
    FCOS developers ने जो CoreOS Layering जोड़ा है, वह एक शक्तिशाली feature है: आप Dockerfile से system state define करते हैं, फिर FCOS उसी state पर rebase हो जाता है, और server configuration के लिए बस reboot करना होता है
    अगले project में अगर VM की जरूरत हो तो इसे एक बार आजमाने लायक है। मैंने Bupy नाम का Python-based CLI tool भी बनाया है, जो Linux workstation पर local रूप से Butane file बनाना आसान करता है, और CoreOS Layering से Paperless NGX चलाने का example भी है
    https://github.com/quickvm/bupy
    https://github.com/quickvm/fcos-layer-paperless-ngx
    https://coreos.github.io/rpm-ostree/container/
    https://github.com/coreos/enhancements/blob/main/os/coreos-l...
    https://github.com/coreos/layering-examples

    • CoreOS परिवार के एक और project Flatcar के बारे में भी आपकी राय जानना चाहूँगा
      bare metal environment में ऐसे projects का इस्तेमाल कैसे किया जाए, यही मेरे लिए सबसे मुश्किल था। VM images बनाना अच्छा है, लेकिन असल में अक्सर आप मौजूदा drive पर install करना चाहते हैं, या उसके नीचे ZFS pool रखकर install करना चाहते हैं
    • CoreOS Layering सच में उपयोगी लगता है। अभी मैं कुछ Raspberry Pi और x86_64 server पर openSUSE MicroOS इस्तेमाल कर रहा हूँ, और MicroOS चुनने की एक वजह यह थी कि Raspberry Pi installation काफी सरल था
      जानना चाहूँगा कि Raspberry Pi पर CoreOS install करना कितना मुश्किल है। इंटरनेट पर कुछ installation guides काफी जटिल लगती हैं

  • ऐसे immutable systems के परिचय में एक और धुरी अक्सर छूट जाती है: image-based approach
    https://universal-blue.org/ पर मैं अपने से कहीं ज्यादा कुशल लोगों के साथ काम कर रहा हूँ, जहाँ Fedora Silverblue base और कई desktop editions के ऊपर OCI container images build किए जाते हैं
    इन images को rpm-ostree से boot किया जा सकता है—या ज्यादा सही कहें तो rebase किया जा सकता है—और यह layering की तुलना में system को extend करने का ज्यादा मजबूत तरीका है। वही बदलाव कोई भी आसानी से inherit या use कर सकता है। अपनी खुद की image बनाना भी बहुत आसान है
    VanillaOS और SUSE भी कुछ ऐसा ही करते दिखते हैं, लेकिन हम कोई OS project नहीं हैं; हम बस Fedora के downstream हैं। Fedora की official support भी process में है, और जितना अभी काम कर रहा है, उसी के आधार पर कहूँ तो Nvidia drivers देना जैसे कामों के लिए यह अनुभव में सबसे मजबूत और आसान तरीकों में से एक है

    • थोड़ा अलग विषय है, लेकिन करीब 2009 में मैंने Windows remote desktop hosts चलाने वाला एक बड़ा hypervisor देखा था और हैरान रह गया था। शायद वह Citrix था
      VM image से boot होती थी, और image व delta disk सब RAM में थे। user profiles hard disk पर थे, लेकिन 25 लोगों वाला desktop host remote login लेने की स्थिति तक लगभग 4 seconds में boot हो जाता था
      वह patch करने के लिहाज से सबसे कम दर्दनाक Windows system था
    • मैं थोड़ा उलझन में हूँ कि Fedora Silverblue भी image-based नहीं है क्या
      मेरी समझ थी कि default installation layering का इस्तेमाल नहीं करता, और layering सिर्फ तब आती है जब आप additional RPM packages install करना चाहते हैं
    • लगता है UBlue GitHub Actions से images को नियमित रूप से फिर से build करता है ताकि package updates शामिल हो सकें। सोचता हूँ इसका खर्च कौन देता है
      यह भी जानना चाहूँगा कि images भी GitHub से serve होती हैं या नहीं, GitHub external transfer पर charge करता है या नहीं, और अगर बहुत से users वही image download करना चाहें तो क्या होता है

  • immutable systems से ज्यादा मेरी रुचि preconfigured systems में है
    यहाँ NixOS और Home Manager अलग दिखते हैं, लेकिन configuration का तरीका सच में बेहद खराब है। मैं पूरी configuration को source control में रखना चाहता हूँ और जानना चाहता हूँ कि current system state उसी configuration के बराबर है; बाकी सभी changes reboot पर मिट जाएँ। reboot से पहले जो बदला है वह highlight हो जाए तो अच्छा होगा
    Silverblue जैसी चीजों के साथ मेरे सीमित अनुभव में, base system configure किया जा सकता है, लेकिन Firefox जैसे applications जोड़ना शुरू करते ही आप Flatpak इस्तेमाल करने लगते हैं, और मैं अच्छी तरह नहीं जानता कि इच्छित सभी Flatpak installations और उनकी settings को साथ में declare कैसे किया जाए
    शायद Flatpak को bulk में install करके बाकी चीजें dotfiles से संभालने का कोई तरीका हो
    https://universal-blue.org/tinker/mindset/#resist-the-urge-t...

    • अगर आप चाहते हैं कि “reboot पर बाकी सब मिट जाए”, तो जानना चाहूँगा कि आपने Impermanence आजमाया है या नहीं
      https://nixos.wiki/wiki/Impermanence
    • क्या आपने Silverblue पर nix package manager आजमाया है
      https://julianhofer.eu/blog/01-silverblue-nix/
      इससे Nix configuration के उस हिस्से को कम करने में मदद मिलती है, जिसके बारे में मैं सहमत हूँ कि वह बेहद खराब है

  • Flatpak और immutable approach में कुल मिलाकर जो समस्या आई, वह यह है कि आप इसे ऐसे तरीके से संशोधित नहीं कर सकते जिसे developer support नहीं करता
    उदाहरण के लिए, मैं decsync से calendar sync करता हूँ, और मेरी जानकारी में Evolution Flatpak में decsync plugin जोड़ना संभव नहीं है
    जब तक ऐसे immutable systems उन use cases के लिए custom overlay filesystem layers को first-class feature के रूप में support नहीं करते जिन्हें developer support नहीं कर सकता या नहीं करता, लोग mutable systems का इस्तेमाल करते रहेंगे

    • NixOS ठीक इसी तरह का control कई तरीकों से देता है
      nixpkgs के कुछ packages और अधिकतर NixOS तथा Home Manager modules plugins, additional packages आदि configure करने के लिए कई options expose करते हैं
      Nix custom packages या मौजूदा packages के variants जोड़ने के लिए overlays और override भी देता है, और package के कुछ हिस्से बदले भी जा सकते हैं। अगर फिर भी पर्याप्त न हो, तो code में सीधे patches डाल सकते हैं या upstream repository के fork से build कर सकते हैं
      सच कहूँ तो यही Nix में मुझे सबसे ज्यादा पसंद आने वाली चीज़ों में से एक है। “इस package को build करते समय इस dependency को मेरे version से बदल दो” कहना आसान है, इसलिए मैं open source में ज्यादा बार contribute करने लगता हूँ
    • “Evolution Flatpak में decsync plugin जोड़ना” जैसी चीज़ Linux GUI software में बहुत आम है
      इस क्षेत्र के बाहर, अधिकतर software जरूरी features के साथ ही आते हैं। उदाहरण के लिए Solidworks ने कभी optional dependencies download करने को नहीं कहा, लेकिन FreeCAD ने CAD/CAM/simulation/rendering flow के अगले step पर जाते ही सचमुच हर 15 मिनट में कुछ न कुछ माँगा
      https://www.joelonsoftware.com/2001/03/23/strategy-letter-iv... भी देखने लायक है
      मुख्य बात यह है कि “वह 20% जिसे सब इस्तेमाल करते हैं” कभी भी एक जैसा नहीं होता। पिछले 10 सालों में मैंने ऐसी दर्जनों companies के बारे में सुना है जिन्होंने सिर्फ 20% features वाला “lite” word processor लाने की कोशिश की, लेकिन जब कोई journalist review लिखते समय word count feature खोजता है और वह “वह 80% जिसे कोई इस्तेमाल नहीं करता” में शामिल होता है, तो अंत में वह लिखता है कि “हल्का program अच्छा है और bloat बुरा है, लेकिन यह कमबख्त word count नहीं कर सकता इसलिए इस्तेमाल लायक नहीं है” — यह कहानी PC जितनी पुरानी है
    • अगर custom overlay filesystem को first-class feature की तरह layer करने तक जाना है, तो शायद बस mutable system ही इस्तेमाल कर लेना चाहिए
      यह 10 साल पहले सबके NoSQL की ओर भागने और फिर तुरंत हर project के अंदर schema को फिर से invent करने की याद दिलाता है
    • Flatpak applications में भी plugins जोड़े जा सकते हैं, और ऐसे plugins को extension packages के रूप में बनाया जा सकता है
      OBS इसका उदाहरण है। Flathub पर com.obsproject.Studio.Plugin.* रूप में कई OBS plugins हैं

  • परिभाषा ऐसी रखना बेहतर होगा: चाहे जितने packages install करें और भविष्य में किसी भी समय किसी भी order में उन्हें remove करें, system ऐसी equivalent state में आना चाहिए जैसे वे शुरू से install ही न किए गए हों
    इस definition में कुछ distributions बाहर हो जाएँगे, लेकिन मेरे हिसाब से इस concept का महत्वपूर्ण हिस्सा यही property है

    • user-facing systems में वह property practically impossible है, यही main point लगता है
      जब आप word processor या text editor हटाते हैं, तो क्या आप चाहते हैं कि उससे लिखी गई सारी files भी साथ में गायब हो जाएँ? Browser हटाने पर क्या downloaded files भी सभी मिट जानी चाहिए? अगर नहीं, तो भरोसेमंद तरीके से यह अलग करने का कोई तरीका नहीं कि कौन-सी file program ने automatically बनाई और कौन-सी user ने उस program से बनाई
      install के दौरान बनाई गई चीज़ें आसानी से remove की जा सकती हैं, लेकिन उसके बाद की हर change नहीं
      ऐसी स्थिति भी सोच सकते हैं जहाँ आपने DNS implementation बदला और बाद में default DNS server बदल दिया। provider हटाकर पुराने implementation पर लौटते समय यह चुनना पड़ेगा कि पुराने server पर भी लौटना है या new server setting बनाए रखनी है। निजी तौर पर मैं सिर्फ provider बदलना और new server बनाए रखना चाहूँगा
      कई machines द्वारा shared directories भी इसे मुश्किल बनाती हैं। अगर /home/${USER} को NFS या Samba mount पर रखकर कई workstations में वही files इस्तेमाल कर रहे हों, तो किसी program ने XDG config directory में files बनाई हों और किसी एक workstation से वह program हटाते समय क्या सभी machines की files भी हटानी चाहिए? सभी devices identical होने चाहिए या सिर्फ home directory identical होनी चाहिए, यह जानने का कोई तरीका single system का package manager के पास नहीं है
    • सवाल यह है कि आप उस property को कितनी गहराई तक लागू करना चाहते हैं
      unique representation data structures और history-independent data structures देखना उपयोगी होगा
      block devices, जैसे SSD, को history से independent तरीके से blocks allocate करने के लिए खास ध्यान देना होगा
    • उसे reproducibility कहा जाने वाला property कहते हैं, और इसका मतलब है कि वही configuration हमेशा वही system state बनाती है
    • मुझे वह definition पसंद है
      यह भी कहा जा सकता है कि packages का set एक lattice बनाता है, और packages के किसी subset तक पहुँचने पर path से स्वतंत्र रूप से state सिर्फ एक ही होती है

  • मैं Fedora Silverblue इसके लॉन्च के समय से इस्तेमाल कर रहा हूँ, और यह निश्चित रूप से भविष्य है
    मुझे लगता है सभी को ostree इस्तेमाल करना चाहिए

    • मुझे लगा कि Silverblue पर्सनल कंप्यूटर के लिए पर्याप्त लचीला नहीं है
      शायद मैं Linux को थोड़ा ad-hoc तरीके से इस्तेमाल करता हूँ, लेकिन /usr या /bin जैसे folders में write permission न होना हर दो हफ्ते में एक बार मुझे पागल कर देता था
      उदाहरण के लिए, किसी Ubuntu user का लिखा script Ubuntu-स्टाइल नाम और location वाली library ढूँढ रहा था, जबकि Fedora उसी library के लिए अलग नाम इस्तेमाल करता है। ऐसे में मेरी instinct होती है कि Ubuntu नाम का symbolic link बना दूँ जो Fedora RPM द्वारा manage की जा रही library की ओर point करे
      लेकिन असल में उसे चलाने के लिए मुझे script fork करना पड़ा, उसे local build के लायक बनाना पड़ा, दोनों library names खोजने के लिए fix करना पड़ा, local tests चलाने पड़े, upstream को PR भेजना पड़ा वगैरह। जो काम आम तौर पर shell की एक line में खत्म हो जाता, वह 90 मिनट का task बन गया
    • एक साल से इस्तेमाल कर रहा हूँ और यह सचमुच अच्छा है। सोचता हूँ क्या Red Hat को पता है कि उनके पास क्या है। सिर्फ Silverblue नहीं, Fedora खुद भी
      मैंने Quora के एक जवाब में पढ़ा था कि Windows OS development budget को salary के आधार पर करीब 18 अरब डॉलर आँका गया था। सोचिए अगर Red Hat Fedora में 2 अरब डॉलर invest करके उसे desktop OS दुनिया का Firefox बना दे; Microsoft के खिलाफ सिर्फ 10% market share भी बहुत बड़ा होगा
      हजारों open source packages के ऊपर इतने कम resources से यह यहाँ तक पहुँचा है। वह पैसा ऐसे projects को जिंदा रखने और development के दौरान sponsor करने में लगाया जा सकता है। Red Hat के कर्मचारी पहले से ही उनमें से कई projects में शामिल हैं
    • ostree का idea मुझे पसंद है, लेकिन सरसरी तौर पर देखने पर यह normal या intermediate users के लिए Docker जितना friendly नहीं लगा। Docker कोई individual user आधे दिन में सीख सकता है
      “Debian distribution को ostree snapshot के रूप में distribute” करने के point तक कैसे पहुँचना है, यह स्पष्ट नहीं था
      सोचता हूँ क्या यह सिर्फ professional system administrators या system builders के लिए design किया गया है
    • अगर आपने Nix इस्तेमाल किया है तो तुलना कैसी है, यह जानना चाहूँगा
      मैंने Silverblue इस्तेमाल नहीं किया, लेकिन Nix भी भविष्य जैसा महसूस होता है
    • अभी servers पर Ubuntu इस्तेमाल कर रहा हूँ और देखा है कि repository में ostree है, लेकिन अभी तक try नहीं कर पाया
      अगर संभव हो तो मौजूदा system को जस का तस रखते हुए version control शुरू करना चाहूँगा। अगर यह बहुत कठिन या असंभव हुआ तो किसी दिन server को Silverblue पर shift करने का सोचूँगा। ostree का idea मुझे सच में पसंद है

  • इस गर्मी में मैं Tinycore में खो गया
    कुछ दिन पहले यहाँ जिन Qubes, Tails, Whonix की बात की थी, उनके पीछे की “एक OS, एक function” security philosophy को complement करने के लिए यह अच्छा है
    यह इतना हल्का है कि mail server के लिए एक VM, database के लिए एक VM, firewall/router के लिए एक VM—हर एक को कुछ ही seconds में start किया जा सकता है
    Tinycore खुद immutable है, इसलिए vdisk में “packages” और configuration डालकर उसे read-only mark कर दें, बस। एक Virsh script “service” के start और stop को handle करता है, और हर service एक Tinycore instance है
    मज़ेदार है और अब तक मजबूत रहा है, लेकिन अभी भरोसा नहीं कि इसे किसी की production में डालूँगा या नहीं

    • TinyCore ऐसे immutable Linux introductions में हमेशा छूट जाता है। यह बहुत पहले से मौजूद है और design भी शानदार है
      implementation में कुछ कमियाँ हैं, और शायद कोई corporate sponsor भी नहीं है जो समझाए कि लोग इसे अच्छी तरह क्यों नहीं जानते
      दूसरी immutable Linux distros के उलट यह मजबूत और सरल है

  • Fedora Sericea आने के बाद से मैं लगातार इसे इस्तेमाल कर रहा हूँ। मूल रूप से यह Fedora Silverblue है, लेकिन Gnome-wm की जगह Sway-wm इस्तेमाल करता है
    असल में काफी usable है, और rpm-ostree install command के हर बार reboot करने की जरूरत भी नहीं। rpm-ostree live-apply इसे systemd-based overlay से handle कर देता है

    • पिछले 2 हफ्तों से मैं Fedora Workstation इस्तेमाल कर रहा हूँ, और 20 साल बाद Linux फिर से इस्तेमाल करने वाले के तौर पर कह सकता हूँ कि experience बेहद बेहतर हो गया है
      अभी तक Windows में वापस boot करने की जरूरत नहीं पड़ी। अगर अगले 6 महीनों तक भी यही स्थिति रही, तो मैं पूरी तरह Linux पर चला जाऊँगा और Windows partition मिटा दूँगा
    • फिर भी नया kernel वास्तव में apply करने के लिए reboot तो चाहिए नहीं? या क्या kernel kexec जैसी किसी चीज़ से बदलता है, यह जानना चाहूँगा

  • “immutability एक झूठ है और system के कई हिस्से mutable हैं। बस इस family को और किस तरह describe किया जाए, समझ नहीं आता—transactional कुछ?” इस बात पर, Nix के मामले में यह reproducibility पर ज्यादा focus जैसा लगता है
    मतलब ऐसा लगता है कि Nix config file को दूसरे computer पर रखें तो /home के अलावा लगभग वही system मिलना चाहिए
    बाकी चीजें existing tools द्वारा दिए जाने वाले snapshot और rollback features को दूसरे implementation से provide करने के ज्यादा करीब लगती हैं

    • “immutable” शब्द यहाँ लगाना अजीब है
      अगर मतलब यह है कि live system पर system upgrade नहीं होते, package changes अगली boot पर apply होते हैं, और changes rollback किए जा सकते हैं, तो यह database जैसे atomic transaction के करीब है। बस commit करने के लिए system बंद करना पड़े, यह थोड़ा ज्यादा है
      Microsoft ने कुछ साल पहले filesystem में atomic transactions डाले थे, लेकिन filesystem transactions ज्यादा इस्तेमाल नहीं हुए
      installation system में अच्छा होगा कि सभी changes एक साथ commit हों, और installation के दौरान problem आए तो कुछ भी commit किए बिना पिछले state में rollback किया जा सके। theory में यह transactional filesystem से संभव होगा, लेकिन practically लगता है filesystem के अलावा बहुत सारी दूसरी state भी उलझी होगी

  • server side में Amazon का Bottlerocket OS है
    idea यह है कि upgrades के लिए A/B partitions इस्तेमाल हों, और base system के अलावा सब कुछ containers में चले
    boot time पर user-defined configuration के लिए boot container इस्तेमाल होता है, और long-running services के लिए host-container, या Kubernetes में DaemonSet इस्तेमाल करने का तरीका है
    https://github.com/bottlerocket-os/bottlerocket