लिविंग रूम PC के लिए SteamOS को fork करने की प्रक्रिया

 (iliana.fyi)
1 पॉइंट द्वारा GN⁺ 2024-01-01 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • SteamOS 3 “Holo” Steam Deck के लिए Arch-आधारित distribution है, लेकिन लिविंग रूम PC में suspend से resume की समस्या ठीक करने के लिए kernel commit को revert करना पड़ा और rootfs image तक खुद fork करनी पड़ी
  • update संरचना A/B तरीके पर आधारित है, जिसमें निष्क्रिय partition पर नया read-only rootfs install किया जाता है और फिर reboot किया जाता है; /etc overlayfs के ज़रिए बदलाव सुरक्षित रखता है
  • Valve kernel patches के लिए pacman source mirror के linux-neptune-61-6.1.52.valve9-1.src.tar.gz जैसे source tarball से bare Git repository clone की जाती है, फिर अपने tags और PKGBUILD से package build किया जाता है
  • rootfs repack करने में SteamOS RAUC bundle से rootfs.img.caibx निकालना, उसे image में बदलना, Btrfs UUID बदलना, package बदलना, buildid बदलना, update URL और RAUC certificate बदलना, फिर दोबारा RAUC bundle बनाना शामिल है
  • अगर अपना web server live.json serve करे और steamos-atomupd के QueryUrl, ImagesUrl, MetaUrl बदल दिए जाएं, तो मौजूदा SteamOS install को भी अपनी image से update किया जा सकता है

SteamOS को लिविंग रूम PC के लिए fork करने की वजह

  • SteamOS 3 “Holo”, Valve Software के handheld PC gaming device Steam Deck के लिए Arch-आधारित Linux distribution है
  • इसका update तरीका A/B atomic update संरचना पर आधारित है, जिसमें नया read-only rootfs निष्क्रिय partition पर डाउनलोड होता है और फिर उसी partition में reboot किया जाता है
  • user steamos-devmode चलाकर rootfs lock हटा सकता है और pacman database को सामान्य कर सकता है, जिससे इसे एक सामान्य Linux distribution की तरह इस्तेमाल किया जा सकता है
  • लक्ष्य यह था कि steamos-devmode से आसान bypass करने के बजाय, rootfs image को सीधे modify करने वाला एक proper fork बनाया जाए
  • लिविंग रूम PC पर SteamOS लगभग सही चल रहा था, लेकिन सिर्फ suspend से resume विफल हो रहा था
    • उसी कंप्यूटर पर mainline या stable kernel इस्तेमाल करने वाले दूसरे distribution में suspend-resume काम कर रहा था
    • Valve kernel source ढूंढकर git bisect चलाने पर पता चला कि एक commit, जो शायद Steam Deck hardware पर suspend-resume ठीक करने के लिए था, इस PC पर समस्या पैदा कर रहा था
    • उसी commit को revert करके खुद kernel build करना इस पूरे काम का सीधा कारण था
  • Arch आदि सीधे इस्तेमाल करने का विकल्प था, लेकिन अगर gaming Linux distribution को modify करना ही है, तो Valve द्वारा test किए गए package set पर निर्भर रहना बेहतर लगा

SteamOS की partition और update संरचना

  • SteamOS system 8 partitions का इस्तेमाल करता है
    • EFI system partition में stage 1 bootloader और A/B partition set selection metadata होता है
    • हर A/B set में stage 2 bootloader के रूप में GRUB, root filesystem, और /var partition होता है
    • बाकी disk space एक single home partition भरता है
  • boot के समय कई pseudo-filesystem अतिरिक्त रूप से mount होते हैं
    • /var/log, /root, /nix समेत लगभग 12 directories को /home/.steamos/offload से bind mount करके data persist किया जाता है
  • /etc को overlayfs से संभाला जाता है
    • बदलाव /var/lib/overlays/etc/upper में store होते हैं
    • machine-id, NetworkManager connections जैसी चीजें, जो सामान्यतः /etc में रहनी चाहिए, बनी रहती हैं
    • जिन config files को नहीं छुआ गया, वे update हो सकती हैं
    • यह तरीका package manager logic के बिना भी A/B partition संरचना में config preservation और updates दोनों को संभालता है
  • system update Steam client या terminal user द्वारा steamos-update चलाने पर शुरू होता है
    • यह command Python program steamos-atomupd-client चलाती है
    • client वर्तमान OS जानकारी और user के update channel settings को /etc/steamos-atomupd/client.conf में दिए गए URL पर भेजकर जांचता है कि नया update है या नहीं
  • नया update होने पर server RAUC bundle का path लौटाता है
    • client bundle download करता है और rauc install चलाता है
    • RAUC bundle signature verify करता है और rootfs.img.caibx ढूंढता है
    • casync extract से नई image chunks डाउनलोड करके निष्क्रिय rootfs partition पर लिखी जाती हैं
    • post-install script सक्रिय /var से निष्क्रिय /var में चुनिंदा data sync करती है और EFI system partition के stage 1 bootloader config को बदलकर नए partition set से boot कराती है

Valve kernel source से package बनाना

  • Valve, SteamOS में काफी modified Linux kernel का इस्तेमाल करता है, और उसका source download किया जा सकता है
  • वर्तमान SteamOS image के source Valve के pacman mirror के sources/holo-3.5 और sources/jupiter-3.5 में मिलते हैं
  • लेखन के समय stable image kernel 6.1.52-valve9-1-neptune-61 था, और उसका source tarball 2.9GiB का था
  • tarball बड़ा होने की वजह यह है कि उसमें पूरा Linux Git tree शामिल है
    • tarball के अंदर PKGBUILD, config, config-neptune, archlinux-linux-neptune/ आदि शामिल हैं
    • archlinux-linux-neptune/ कोई सामान्य working tree नहीं बल्कि एक bare repository है
  • PKGBUILD source के रूप में git+ssh://git@gitlab.steamos.cloud/jupiter/linux-integration.git#tag=$_tag जैसी private GitLab repository को point करता है
    • इसे सीधे clone नहीं किया जा सकता और न ही commit links खोले जा सकते हैं
    • makepkg source से हर tag का पूरा commit history वाला snapshot मिल सकता है
    • इसी संरचना की वजह से लिविंग रूम PC का suspend तोड़ने वाले commit का bisect संभव हुआ
  • काम का तरीका यह है कि bare repository को एक सामान्य working tree के रूप में clone किया जाए और अपने branch व tag बनाए रखें
    • उदाहरण में 6.1.52-valve9 tag से my-branch बनाया गया
    • अपने बदलाव किसी अलग Git host पर push किए जाते हैं और PKGBUILD के source को उस repository और custom tag की तरफ बदला जाता है
    • उदाहरण repository के रूप में linux दिया गया है
  • makepkg से kernel package बनाया जा सकता है
    • makepkg MAKEFLAGS=-j$(nproc) या /etc/makepkg.conf update करना, अगर मशीन छोटी VM नहीं है, तो उपयोगी है
    • देखे गए दायरे में SteamOS-specific packages भी पहले source के रूप में Git repository इस्तेमाल करने वाली समान संरचना अपनाते थे
  • आगे के steps आसान बनाने के लिए अपना pacman repo सेट किया गया
    • packages को directory में रखकर repo-add $REPO_NAME.db.tar.zst [PACKAGES...] चलाया जाता है और फिर web host पर upload किया जाता है
    • यह repo बाद में steamos-devmode चलाने पर भी tools को सही तरह काम करने में मदद करता है

root filesystem लाना और mount करना

  • release engineering scripts नहीं मिलीं, इसलिए मौजूदा root filesystem को जरूरत के मुताबिक repack करने का तरीका चुना गया
  • बिना description और comments वाली scripts fauxlo में हैं
  • SteamOS rootfs image पाने का सामान्य तरीका Steam Deck खरीदना या Steam Deck recovery image download करना है, लेकिन दोनों के लिए Steam End User License Agreement से सहमत होना पड़ता है
  • वर्तमान release version update system के fallback URL जैसे दिखने वाले snapshot JSON से पता की जा सकती है
    • लेखन के समय stable version 20231122.1 था
    • preview channel के लिए अलग snapshot JSON भी है
  • rootfs download करने की प्रक्रिया steamos-atomupd-client जैसी ही है
    • .raucb file के रूप में RAUC bundle download किया जाता है
    • bundle, जो एक SquashFS filesystem है, उससे rootfs.img.caibx निकाला जाता है
    • casync extract .castr store से chunks लेकर rootfs.img बनाता है
    • .castr store का URL, RAUC bundle URL में .raucb को .castr से बदलकर बनता है
    • यह behavior steamos-atomupd में hardcode है
    • automation script fetch-current.sh में है
  • पास में दिखने वाली .img.zip और .img.zst files rootfs नहीं बल्कि अलग bootable recovery images हैं
    • recovery image से rootfs partition निकालकर आगे इस्तेमाल किया जा सकता है
    • लेकिन वह RAUC और casync से मिली image के bit-for-bit समान नहीं था, और update bundle दोबारा बनाने के लिए वैसे भी उन tools की जरूरत पड़ती है
  • rootfs modify करने से पहले filesystem UUID बदलना जरूरी है
    • अगर मूल SteamOS image से custom image पर update करते समय UUID नहीं बदला गया, तो दो अलग filesystems का UUID एक ही हो जाएगा
    • यह समस्या पैदा कर सकता है
    • उदाहरण: btrfstune -fu rootfs.img
  • Valve zstd compression वाली Btrfs image इस्तेमाल करता है
    • बदलाव करते समय compression बनाए रखने के लिए mount -o compress=zstd rootfs.img rootfs से mount किया जाता है
    • SteamOS, Btrfs के readonly subvolume property का इस्तेमाल करता है, इसलिए btrfs property set -ts rootfs ro false से इसे हटाया जाता है
  • Linux kernel जैसे packages modify करने पर /dev और /proc मांगने वाली scripts trigger हो सकती हैं
    • devtmpfs और proc को rootfs के नीचे mount किया जाता है
    • जिन directories पर booted system में mount होना है, उनमें write न हो, इसलिए /tmp, /run, /var, /home पर tmpfs mount किया जाता है
    • chroot के अंदर name resolution काम करे, इसके लिए host का /etc/resolv.conf bind mount किया जाता है

package बदलना और image metadata modify करना

  • अपना repository /etc/pacman.conf में पहले repo entry के रूप में जोड़ा जाता है
    • इससे Valve repo में newer version होने पर भी अपने packages को प्राथमिकता मिलती है
    • बाद में steamos-devmode चलने पर भी अपने packages दोबारा install किए जा सकते हैं
  • उदाहरण repo stanza में [fauxlo], Server = https://fauxlo.ili.fyi/pacman/$arch, SigLevel = Never इस्तेमाल होता है
    • SigLevel = Never का मतलब है package signatures न होने पर भी उन्हें स्वीकार करना
    • GPG-signed packages install करने के लिए pacman keyring भरना पड़ेगा
    • /etc/pacman.d/gnupg के खाली keyring को छेड़ने के बजाय tmpfs पर नया keyring भरने का तरीका इस्तेमाल किया गया
  • package install pacman --sysroot rootfs --noconfirm -Sy linux-neptune-61 जैसे किया जाता है
    • वास्तविक script में -y से बचा गया और केवल अपने repo database को pacman के पीछे sync किया गया
    • इससे दूसरी repositories की state उस समय पर freeze रखी जा सकती है जब मूल image build हुई थी
    • यह image diff में दिखने वाले बदलाव कम करने के लिए चुना गया
  • steamos-atomupd वर्तमान image version और build ID को /lib/steamos-atomupd/manifest.json से पढ़ता है, और अगर वह न हो तो /etc/os-release का इस्तेमाल करता है
    • अगर server द्वारा दी गई update का build ID वर्तमान image जैसा ही हो, तो update अस्वीकार कर दिया जाता है
    • यह यह पहचानने में भी उपयोगी है कि कौन सी image चल रही है
  • build ID का format अनिवार्य रूप से YYYYMMDD.N होना चाहिए
    • format गलत होने पर steamos-atomupd Python traceback के साथ बंद हो जाता है
    • manual increment से बचने के लिए N में HHMMSS या Unix timestamp रखा जा सकता है
    • manifest.json के buildid और os-release के BUILD_ID दोनों बदले जाते हैं
    • इसके लिए Bash script snippet repack.sh में है
  • RAUC trust configuration के लिए X.509 certificate इस्तेमाल करता है
    • trusted certificate /etc/rauc/keyring.pem में होता है
    • एक साधारण self-signed certificate पर्याप्त है
    • नया certificate rootfs/etc/rauc/keyring.pem में install किया जाता है
  • rootfs/etc/steamos-atomupd/client.conf के URLs भी अपने server पर बदले जाते हैं
    • QueryUrl
    • ImagesUrl
    • MetaUrl
  • 5GiB Btrfs image space के भीतर रहते हुए दूसरे बदलाव भी किए जा सकते हैं
    • उदाहरण के लिए, अगर network पर hostname.local से SteamOS device ढूंढना हो, तो rootfs/usr/lib/systemd/resolved.conf.d/00-disable-mdns.conf हटाया जा सकता है
    • /etc overlay config से इसे override भी किया जा सकता है, लेकिन इसे झंझट वाला माना गया
  • जो बदलाव image के बिना आसानी से किए जा सकते हों, उन्हें rootfs में न डालना बेहतर है
    • उदाहरण के लिए Firefox को rootfs में install किया जा सकता है
    • लेकिन हर Firefox security update पर image फिर से repack करनी पड़ेगी

rootfs unmount करना और RAUC bundle बनाना

  • बदलाव पूरे होने के बाद filesystem को फिर से read-only के रूप में mark किया जाता है
    • btrfs property set -ts rootfs ro true
  • unused blocks को fstrim -v rootfs से discard किया जाता है
  • unmount के लिए umount --recursive rootfs उपयोगी है
    • इससे पहले mount किए गए pseudo-filesystem भी साथ में हट जाते हैं
  • RAUC bundle बनाने से पहले casync store और blob index बनाया जाता है
    • उदाहरण: casync make --store=rootfs.img.castr bundle/rootfs.img.caibx rootfs.img
  • RAUC bundle के लिए तीन files चाहिए
    • manifest.raucm
    • rootfs.img.caibx
    • filesystem UUID वाली UUID
  • manifest.raucm में update जानकारी और rootfs image की जानकारी होती है
    • compatible=steamos-amd64
    • version=$version
    • sha256
    • size
    • filename=rootfs.img.caibx
  • UUID file blkid -s UUID -o value rootfs.img >bundle/UUID से बनाई जाती है
  • तीनों files तैयार होने के बाद rauc bundle चलाया जाता है
    • --signing-keyring, --cert, --key में certificate और key दिए जाते हैं
    • आउटपुट rootfs.img.raucb होता है
  • rootfs.img.raucb और rootfs.img.caibx को उस web server पर upload किया जाता है, जिसकी तरफ client.conf का ImagesUrl point करता है
    • दोनों files एक ही directory में होनी चाहिए

अपना update server और उसका उपयोग

  • QueryUrl और MetaUrl के लिए इस्तेमाल होने वाला web server JSON files serve करना चाहिए
  • सरल setup में सिर्फ एक live.json काफी है
    • .minor.candidates[0].image object image के अंदर मौजूद /lib/steamos-atomupd/manifest.json जैसा होना चाहिए
    • update_path वह path है जिसे update client ImagesUrl के बाद जोड़कर bundle download करता है
  • उदाहरण Caddy configuration में steamos-atomupd के QueryUrl और MetaUrl requests को live.json पर rewrite किया जाता है
    • /updates को /live.json पर rewrite किया जाता है
    • /meta/*/*/*/*.json और /meta/*/*/*/*/*.json को /live.json पर rewrite किया जाता है
    • file_server browse इस्तेमाल किया जाता है
  • असली SteamOS में QueryUrl और MetaUrl के पीछे शायद और ज्यादा logic है, लेकिन इस setup से भी steamos-atomupd नया update ढूंढ सकता है
  • अगर जो image पहले से advertise की जा रही है वही वर्तमान में चल रही हो, तो update से बचने का logic मौजूद है
  • मौजूदा SteamOS install को अपनी image पर update करने के लिए /etc/rauc/keyring.pem और /etc/steamos-atomupd/client.conf बदलना काफी है
    • steamos-readonly disable की जरूरत नहीं है
    • बदलाव /etc overlay में चले जाते हैं
    • steamos-update चलाने के बाद /var/lib/overlays/etc/upper से इन बदलावों को साफ करने पर विचार किया जा सकता है
  • Valve recovery images में से किसी एक को modify करके rootfs को अपनी image से बदलने पर बदला हुआ SteamOS install करना भी संभव लग सकता है, लेकिन इस तरीके का परीक्षण नहीं किया गया

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

1 टिप्पणियां

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

  • मुझे ऐसे लेख पसंद हैं जिनमें अपने डिवाइस के software/OS को गहराई से customize किया जाता है। यह भी अच्छी बात है कि Steam Deck पर Tivoization की चिंता नहीं करनी पड़ती
    लेख में मेरे लिए सबसे दिलचस्प हिस्सा /nix partition था। मुझे नहीं पता था कि Steam Deck nixpkgs को support करता है, लेकिन और खोजने पर पता चला कि भले ही यह default install न हो, फिर भी पूरे OS को fork किए बिना इसे डिवाइस पर डाला जा सकता है

    • Nix को मूल रूप से किसी भी *nix OS पर “पूरा OS fork” किए बिना install किया जा सकता था
      Nix repository को किसी भी writable location पर रखा जा सकता है, और $PATH को symbolic link directory की ओर point करने के लिए बदलना होता है
    • क्या किसी को पता है कि Steam Deck पर nixpkgs में से क्या इस्तेमाल होता है? मैं भी nixpkgs काफी इस्तेमाल करता हूँ, इसलिए उत्सुक हूँ, लेकिन अफसोस मेरे पास Steam Deck नहीं है

  • वाकई बहुत बारीक और दिलचस्प लेख है। निजी तौर पर मैं शायद कभी इतना आगे नहीं जाऊँगा
    Linux से मेरा पाला भी बस Raspberry Pi इस्तेमाल करने के दिनों में पड़ा था, और वह भी शायद 1% ही, इसलिए लेखक कमाल के लगते हैं

    • मेरी स्थिति भी लेखक जैसी ही थी। काफी लंबे समय तक एक बहुत अजीब वजह से मुझे खुद Red Hat kernel build करना पड़ता था; RMRR check को bypass करके GPU को Windows VM में passthrough करने के लिए
      https://github.com/kiler129/relax-intel-rmrr जैसा, लेकिन मेरा repository नहीं
      मूल कारण सिर्फ manufacturer के ROM update से ही ठीक हो सकता है, लेकिन मेरा पुराना DL360 HPE support से बाहर हो चुका है
      patch खुद तो एक line का बदलाव है, लेकिन kernel update करना झंझट भरा है। SRPM लेना पड़ता है, Git repository नहीं है, इसलिए SRPM को unpack करके patch apply करना, फिर दुबारा build और install करना पड़ता है
    • अगर आपको TV चाहिए, तो जल्द ही सचमुच विकल्प खत्म हो सकते हैं

  • पहले से ही SteamOS components पर आधारित ऐसी distributions हैं जो PC और controller use के लिए tuned हैं। ChimeraOS तो Steam Deck के add-on tool EmuDeck तक शामिल करता है और मेरे setup में काफी बिना दिक्कत चलता है

  • मैंने unRaid NAS server पर Steam Headless को एक बढ़िया Docker image के रूप में चलाने और Windows laptop से Moonlight जैसे client के जरिए connect करने के लिए GPU order किया है
    अगर यह ठीक चला, तो ज्यादातर idle पड़े NAS के बावजूद gaming desktop hardware फिर से खरीदने से कहीं बेहतर होगा। बस इस्तेमाल न होने पर Nvidia card की power setting को idle state में रखना होगा। उम्मीद है nvidia-persistenced call से यह हो जाए
    1: https://github.com/Steam-Headless/docker-steam-headless

    • मैंने भी लगभग वही चीज़ GOW के साथ चलाने की कोशिश में काफी समय लगाया था। उम्मीद से कहीं ज्यादा मुश्किल था, और X server setup सही करने के लिए HDMI dummy plug तक चाहिए पड़ा
      1: https://github.com/games-on-whales/gow
    • एक और alternative के तौर पर, GPU passthrough वाला KVM चला सकते हैं और cloud-init से Sunshine और games run कर सकते हैं, या बस सीधे monitor इस्तेमाल कर सकते हैं
      https://kubevirt.io/user-guide/virtual_machines/host-devices...
      declarative cloud-native game execution!
      kubectl apply -f crysis.yaml
    • अच्छा लग रहा है। अभी Sunshine + Moonlight इस्तेमाल कर रहा हूँ, और जल्द ही Steam Headless performance test करने वाला हूँ
    • काफी दिलचस्प है। इस तरह local network पर streaming करते समय क्या input lag या video quality की limitations महसूस होती हैं?
    • बढ़िया। मैं काफी समय से ऐसा setup सोचता रहा हूँ जिसमें Civilization जैसे turn-based hotseat games server पर चलें, और browser से remote access करके दोस्तों के साथ कभी भी, कहीं से भी लंबे turn वाले games खेले जा सकें

  • आज RAUC(https://rauc.io/) के बारे में पता चला। सोच रहा था Valve ने A/B update तरीका कैसे implement किया होगा

  • Netscape का meteor shower favicon थोड़ा याद नहीं आता?

  • दिलचस्प लेख है। A/B upgrades थोड़े overkill लगते हैं। समस्या हो तो live distribution boot कर सकते हैं, या पुराने version का recovery system अलग partition में install कर सकते हैं
    पिछले कुछ साल NixOS इस्तेमाल करने के बाद मैं Arch पर वापस आया हूँ; उससे पहले भी लंबे समय तक Arch इस्तेमाल किया था, और मुझे लगता है लेखक की चिंता गलत दिशा में है
    Arch निश्चित रूप से बहुत serious और mature distribution है, और Valve से ज्यादा भरोसेमंद है
    Arch पर जाने की वजह package quality थी। main repository सचमुच तेजी से update होती है और AUR में बहुत सारे useful packages हैं

    • तुम और मैं live distribution boot कर सकते हैं, लेकिन भारी बहुमत में computer users ऐसा नहीं कर सकते। Valve स्पष्ट रूप से average users के लिए बनाने पर focus कर रहा है, और Linux distributions चाहे जितनी अच्छी हों, अभी भी इसमें बहुत सफल नहीं हैं
      upgrade fail होने के बाद system का अपने-आप recover होना आज के low-maintenance OS में लगभग जरूरी है
    • Steam Deck users से यह उम्मीद नहीं करनी चाहिए कि वे टूटा हुआ upgrade ठीक करने के लिए live distribution boot करेंगे। यह seamless होना चाहिए और background में अपने-आप handle होना चाहिए
    • संभव तो होगा, लेकिन अब इसे unnecessary बनाने वाली technology मौजूद है और disk भी इतनी महंगी नहीं है, तो इसे न करने की कोई खास वजह नहीं
    • Steam Deck मूल रूप से videogames के लिए Chromebook जैसा ही है, इसलिए ChromeOS का hard-to-break partition तरीका समझदारी भरा idea लगता है
    • क्या तुम NixOS से Arch पर package quality की वजह से जाने का कोई example दे सकते हो?
      मुझे आम तौर पर NixOS packages की quality ऊँची लगती है

  • हाल ही में गेमिंग हैंडहेल्ड Legion Go मिला है और Linux को और ज्यादा आज़मा रहा/रही हूँ। पहले यह अंतहीन छेड़छाड़ में समय बर्बाद करने जैसा लगता था, और जिन चीज़ों को सच में इस्तेमाल करना चाहता/चाहती था/थी उनके साथ compatibility भी सीमित थी, इसलिए दूर रहा/रही
    immutable filesystem और पारंपरिक Linux में हर तरह के मनमाने software को root permission आसानी से दे देने वाली बात पढ़कर जिज्ञासा हुई
    अभी NixOS इस्तेमाल कर रहा/रही हूँ; यह सच में tinkering में समय खपा सकता है, लेकिन exploration के लिए अच्छा है। अलग-अलग components को आसानी से आज़माया जा सकता है, और अगर उन्हें बनाए नहीं रखना है तो ~/.config में थोड़ी गंदगी छोड़ने के अलावा पूरी तरह हटाया जा सकता है। install से पहले patch करना भी मामूली काम है, इसलिए gaming handheld जैसे अजीब hardware पर Linux चलाने लायक kernel patches भी आसानी से जोड़े जा सकते हैं
    Jovian नाम की NixOS community Valve के मनमाने SteamOS tarballs को GitHub पर tagged commits के रूप में फिर से तैयार कर रही है, इसलिए source को Valve employee की तरह देखा जा सकता है। Nix configuration में बस कुछ lines जोड़कर NixOS के ऊपर अपना SteamOS copy install करने की सुविधा दी गई है
    ये लोग साफ तौर पर Linux experts हैं, और source देखने पर पता चलता है कि power button location को hardcode न करके जांचने जैसे simple tweaks को छोड़कर वे Valve packages को untouched रूप में लेते हैं
    अगर आप pure SteamOS experience चाहते हैं लेकिन Valve update system का mirror खुद नहीं चलाना चाहते, या 3GB tarball लिए बिना Valve source explore करना चाहते हैं, तो Jovian आज़माने लायक है
    installation guide: https://jovian-experiments.github.io/Jovian-NixOS/getting-st...
    Valve source mirror: https://github.com/orgs/Jovian-Experiments/repositories?type...

    • मैं भी Steam Deck पर Jovian-NixOS बिना किसी परेशानी के अच्छी तरह इस्तेमाल कर रहा/रही हूँ, इसलिए strongly recommend करता/करती हूँ

  • bazzite.gg भी यह काम बहुत अच्छे से करता है। AMD hardware पर 120Hz VRR तुरंत चल पड़ा, और HDR support भी alpha testing में आज़माया जा सकता है

    • Bazzite के बारे में पहली बार सुना
      “Bazzite एक OCI image है जिसे Steam Deck के alternative operating system के रूप में इस्तेमाल किया जा सकता है, और यह desktop computers, living room home theater PCs, और कई handheld PCs के लिए game-ready SteamOS जैसा environment है”
      https://github.com/ublue-os/bazzite/
      रुचि न भी हो, तो भी README देखने लायक है। इसमें शामिल चीज़ों की list बहुत लंबी है, और खासकर gamers या streamers के लिए कई चीज़ें काफी cool और useful लगती हैं
    • Bazzite और कुल मिलाकर immutable Linux रोचक हैं
      इतना गहराई में नहीं गया/गई कि इसे HN comment में संक्षेप में और पूरी तरह समझा सकूँ, लेकिन मूल बात यह है कि root पर read-only, verified Linux distro रहता है और उसके ऊपर packages layers के रूप में चढ़ाए जाते हैं। इसका design server-side containers से काफी प्रेरित है
      इसका लक्ष्य traditional Linux से ज्यादा secure, ज्यादा reliable, reproducible और customize करने में आसान होना है। आप जिन packages को चाहते हैं उन्हें container manifest में लिख देते हैं; upgrade आने पर upgrade चलाया जाता है और फिर उसके ऊपर packages दोबारा install किए जाते हैं
    • इससे ज्यादा संबंधित बात यह है कि Bazzite को अपेक्षाकृत आसानी से fork करके missing packages या जरूरी settings अपनी custom image में जोड़ी जा सकती हैं, और infrastructure work का अधिकतर हिस्सा GitHub Actions को सौंपा जा सकता है
      https://universal-blue.org/guide/fork-your-own/
      और क्योंकि यह immutable OS है, अगर कोई समस्या आए तो पिछली image पर rollback भी किया जा सकता है
    • Steam के year-end recap के हिसाब से 2023 पहला साल था जब मैंने सिर्फ Linux पर games खेले, और इसमें इस साल के कुछ releases भी शामिल थे
      ज्यादातर मैंने Steam Deck पर या GPU passthrough वाले virtual machine में Bazzite चलाकर खेले, और यह वाकई बहुत अच्छी तरह बनाया गया है
    • हैरानी है कि Bazzite ज्यादा famous नहीं है। यह बिल्कुल वही चीज़ है जिसका मैं सपना देखता/देखती था/थी, लेकिन हाल तक मुझे इसके मौजूद होने का पता भी नहीं था

  • living room PC—क्या अब HTPC या “media center” जैसे शब्द ज्यादा इस्तेमाल नहीं होते?