거실 PC용으로 SteamOS를 포크한 과정

 (iliana.fyi)
1P by GN⁺ | ★ favorite | 댓글 1개
  • SteamOS 3 “Holo”는 Steam Deck용 Arch 기반 배포판이지만, 거실 PC의 suspend 복귀 문제를 고치려면 커널 커밋을 되돌리고 rootfs 이미지까지 직접 포크해야 했음
  • 업데이트 구조는 비활성 파티션에 새 읽기 전용 rootfs를 설치한 뒤 재부팅하는 A/B 방식이며, /etc는 overlayfs로 변경분을 보존함
  • Valve 커널 패치는 pacman 소스 미러의 linux-neptune-61-6.1.52.valve9-1.src.tar.gz 같은 소스 tarball에서 bare Git 저장소를 복제하고, 자체 태그와 PKGBUILD로 패키지를 빌드하는 흐름임
  • rootfs 재패킹은 SteamOS RAUC 번들에서 rootfs.img.caibx를 추출해 이미지화하고, Btrfs UUID 변경·패키지 교체·buildid 변경·업데이트 URL과 RAUC 인증서 교체를 거쳐 다시 RAUC bundle로 묶는 작업임
  • 자체 웹 서버가 live.json을 제공하고 steamos-atomupd의 QueryUrl, ImagesUrl, MetaUrl을 바꾸면 기존 SteamOS 설치도 자체 이미지로 업데이트할 수 있음

SteamOS를 거실 PC에 맞춰 포크한 이유

  • SteamOS 3 “Holo”는 Valve Software의 휴대용 PC 게임기 Steam Deck용 Arch 기반 Linux 배포판임
  • 업데이트 방식은 새 읽기 전용 rootfs를 비활성 파티션에 내려받고 그 파티션으로 재부팅하는 A/B 원자적 업데이트 구조임
  • 사용자는 steamos-devmode를 실행해 rootfs 잠금을 풀고 pacman 데이터베이스를 정상화하면 일반 Linux 배포판처럼 다룰 수 있음
  • 목표는 steamos-devmode로 쉽게 우회하는 대신, rootfs 이미지 자체를 수정할 수 있는 제대로 된 포크를 만드는 것이었음
  • 거실 PC에서는 SteamOS가 거의 동작했지만 suspend 복귀만 실패함
    • 같은 컴퓨터에서 mainline 또는 stable 커널을 쓰는 다른 배포판은 suspend 복귀가 동작함
    • Valve 커널 소스를 찾아 git bisect를 수행한 결과, Steam Deck 하드웨어의 suspend 복귀를 고치는 것으로 보이는 커밋이 이 PC에서는 문제를 일으킴
    • 해당 커밋을 되돌리고 직접 커널을 빌드해야 했던 것이 전체 작업의 직접적인 이유였음
  • Arch 등을 직접 쓰는 선택지도 있었지만, 게임 실행용 Linux 배포판을 손봐야 한다면 Valve가 테스트한 패키지 집합에 기대는 쪽을 선호함

SteamOS의 파티션과 업데이트 구조

  • SteamOS 시스템은 8개 파티션을 사용함
    • EFI system partition에는 stage 1 bootloader와 A/B 파티션 세트 선택 메타데이터가 있음
    • 각 A/B 세트에는 stage 2 bootloader인 GRUB, root filesystem, /var 파티션이 있음
    • 나머지 디스크 공간은 단일 home 파티션이 채움
  • 부팅 시 여러 pseudo-filesystem이 추가로 마운트됨
    • /var/log, /root, /nix 등 거의 12개 디렉터리가 /home/.steamos/offload에서 bind mount되어 데이터를 영속화함
  • /etc는 overlayfs로 처리됨
    • 변경분은 /var/lib/overlays/etc/upper에 저장됨
    • machine-id, NetworkManager 연결처럼 일반적으로 /etc에 남아야 하는 항목은 유지됨
    • 건드리지 않은 설정 파일은 업데이트될 수 있음
    • 이 방식은 패키지 매니저 로직 없이도 A/B 파티션 구조에서 설정 파일 유지와 업데이트를 함께 처리함
  • 시스템 업데이트는 Steam 클라이언트나 터미널 사용자가 steamos-update를 실행하면서 시작됨
    • 이 명령은 Python 프로그램 steamos-atomupd-client를 실행함
    • 클라이언트는 현재 OS 정보와 사용자의 업데이트 채널 설정을 /etc/steamos-atomupd/client.conf의 URL로 보내 새 업데이트가 있는지 확인함
  • 새 업데이트가 있으면 서버는 RAUC bundle 경로를 응답함
    • 클라이언트는 번들을 다운로드하고 rauc install을 실행함
    • RAUC는 번들 서명을 검증하고 rootfs.img.caibx를 찾음
    • casync extract로 새 이미지 조각을 내려받아 비활성 rootfs 파티션에 기록함
    • post-install 스크립트는 활성 /var에서 비활성 /var로 데이터를 선택적으로 동기화하고, EFI system partition의 stage 1 bootloader 설정을 바꿔 새 파티션 세트로 부팅하게 함

Valve 커널 소스로 패키지 만들기

  • Valve는 SteamOS에서 많이 수정된 Linux 커널을 사용하며, 소스는 다운로드 가능함
  • 현재 SteamOS 이미지의 소스는 Valve의 pacman 미러에 있는 sources/holo-3.5와 sources/jupiter-3.5에서 찾을 수 있음
  • 작성 시점 stable 이미지 커널은 6.1.52-valve9-1-neptune-61이며, 해당 소스 tarball은 2.9GiB임
  • tarball이 큰 이유는 전체 Linux Git tree가 들어 있기 때문임
    • tarball 안에는 PKGBUILD, config, config-neptune, archlinux-linux-neptune/ 등이 포함됨
    • archlinux-linux-neptune/는 바로 작업할 수 있는 일반 working tree가 아니라 bare repository임
  • PKGBUILD는 git+ssh://git@gitlab.steamos.cloud/jupiter/linux-integration.git#tag=$_tag 형태의 비공개 GitLab 저장소를 소스로 가리킴
    • 직접 clone하거나 커밋 링크를 걸 수는 없음
    • makepkg 소스에서 각 태그의 전체 커밋 히스토리가 들어 있는 스냅샷을 얻을 수 있음
    • 이 구조 덕분에 거실 PC의 suspend를 깨뜨리는 커밋을 bisect할 수 있었음
  • 작업 방식은 bare repository를 일반 working tree로 clone하고 자체 브랜치와 태그를 유지하는 흐름임
    • 예시는 6.1.52-valve9 태그에서 my-branch를 만드는 방식임
    • 자체 변경은 별도 Git 호스트에 올리고 PKGBUILD의 source를 그 저장소와 자체 태그로 바꿈
    • 예시 저장소로 linux가 있음
  • makepkg로 커널 패키지를 만들 수 있음
    • makepkg MAKEFLAGS=-j$(nproc) 또는 /etc/makepkg.conf 업데이트가 작은 VM이 아닐 때 유용함
    • 살펴본 범위에서 SteamOS 특화 패키지도 첫 번째 source로 Git 저장소를 쓰는 비슷한 구조였음
  • 이후 단계를 쉽게 만들기 위해 자체 pacman repo를 구성함
    • 패키지를 디렉터리에 두고 repo-add $REPO_NAME.db.tar.zst [PACKAGES...]를 실행한 뒤 웹 호스트에 업로드함
    • 이 repo는 나중에 steamos-devmode를 실행할 경우에도 도구가 정상 동작하는 데 도움이 됨

root filesystem 가져오기와 마운트

  • release engineering 스크립트는 찾지 못했기 때문에 기존 root filesystem을 필요에 맞게 재패킹하는 방식을 선택함
  • 설명과 주석 없는 스크립트는 fauxlo에 있음
  • SteamOS rootfs 이미지를 얻는 일반적 방법은 Steam Deck을 사거나 Steam Deck 복구 이미지를 다운로드하는 것이지만, 둘 다 Steam End User License Agreement 동의가 필요함
  • 현재 릴리스 버전은 업데이트 시스템의 fallback URL로 보이는 snapshot JSON에서 확인할 수 있음
    • 작성 시점 stable 버전은 20231122.1이었음
    • preview 채널용 별도 snapshot JSON도 있음
  • rootfs 다운로드는 steamos-atomupd-client와 같은 순서를 따름
    • RAUC bundle인 .raucb 파일을 다운로드함
    • SquashFS 파일시스템인 번들에서 rootfs.img.caibx를 추출함
    • casync extract로 .castr store에서 조각을 받아 rootfs.img를 생성함
    • .castr store URL은 RAUC bundle URL의 .raucb를 .castr로 바꾼 것임
    • 이 동작은 steamos-atomupd에 하드코딩되어 있음
    • 자동화 스크립트는 fetch-current.sh에 있음
  • 인접한 .img.zip과 .img.zst 파일은 rootfs가 아니라 별도 부팅 가능한 복구 이미지임
    • 복구 이미지에서 rootfs 파티션을 추출해 다음 단계에 쓸 수도 있음
    • 하지만 RAUC와 casync로 받은 이미지와 bit-for-bit 동일하지 않았고, 다시 update bundle을 만들 때 어차피 해당 도구가 필요함
  • rootfs를 수정하기 전에는 filesystem UUID를 바꿔야 함
    • 기존 SteamOS 이미지에서 커스텀 이미지로 업데이트할 때 UUID를 바꾸지 않으면 서로 다른 두 filesystem이 같은 UUID를 갖게 됨
    • 이 상태는 문제를 일으킬 수 있음
    • 예시는 btrfstune -fu rootfs.img임
  • Valve는 zstd 압축을 쓰는 Btrfs 이미지를 사용함
    • 변경 중 압축을 유지하려면 mount -o compress=zstd rootfs.img rootfs로 마운트함
    • SteamOS는 Btrfs의 readonly subvolume 속성을 쓰므로 btrfs property set -ts rootfs ro false로 해제함
  • Linux 커널 같은 패키지 수정은 /dev와 /proc을 요구하는 스크립트를 트리거할 수 있음
    • devtmpfs와 proc을 rootfs 아래에 마운트함
    • 부팅된 시스템에서 마운트될 디렉터리에 쓰기가 발생하지 않도록 /tmp, /run, /var, /home에는 tmpfs를 마운트함
    • chroot에서 이름 해석이 되도록 호스트의 /etc/resolv.conf를 bind mount함

패키지 교체와 이미지 메타데이터 수정

  • 자체 repository는 /etc/pacman.conf의 첫 번째 repo 항목으로 추가함
    • 이렇게 하면 Valve repo에 더 최신 버전 패키지가 있어도 자체 패키지가 우선됨
    • 나중에 steamos-devmode를 실행해도 자체 패키지를 다시 설치할 수 있음
  • 예시 repo stanza는 [fauxlo]와 Server = https://fauxlo.ili.fyi/pacman/$arch, SigLevel = Never를 사용함
    • SigLevel = Never는 패키지 서명이 없어도 허용함
    • GPG 서명 패키지를 설치하려면 pacman keyring을 채워야 함
    • /etc/pacman.d/gnupg의 빈 keyring을 건드리는 대신 tmpfs 위의 새 keyring을 채우는 방식이 사용됨
  • 패키지 설치는 pacman --sysroot rootfs --noconfirm -Sy linux-neptune-61 형태로 수행함
    • 실제 스크립트에서는 -y를 피하고 자체 repo 데이터베이스만 pacman 뒤에서 동기화함
    • 이렇게 하면 다른 repository 상태를 원래 이미지가 빌드된 시점으로 고정할 수 있음
    • 이미지 diff에 나타나는 변경을 줄이기 위한 선택임
  • steamos-atomupd는 현재 이미지 버전과 build ID를 /lib/steamos-atomupd/manifest.json에서 읽고, 없으면 /etc/os-release를 사용함
    • 서버가 제공하는 업데이트의 build ID가 현재 이미지와 같으면 업데이트를 거부함
    • 어떤 이미지를 실행 중인지 식별하는 데도 유용함
  • build ID는 반드시 YYYYMMDD.N 형식이어야 함
    • 형식이 맞지 않으면 steamos-atomupd가 Python traceback과 함께 종료됨
    • 수동 증가를 피하려고 N에 HHMMSS 또는 Unix timestamp를 넣는 방식이 가능함
    • manifest.json의 buildid와 os-release의 BUILD_ID를 함께 바꿈
    • 이 작업을 위한 Bash 스크립트 조각은 repack.sh에 있음
  • RAUC는 신뢰 설정에 X.509 인증서를 사용함
    • 신뢰할 인증서는 /etc/rauc/keyring.pem에 있음
    • 단순 self-signed certificate로 충분함
    • 새 인증서를 rootfs/etc/rauc/keyring.pem에 설치함
  • rootfs/etc/steamos-atomupd/client.conf의 URL도 자체 서버로 바꿈
    • QueryUrl
    • ImagesUrl
    • MetaUrl
  • 5GiB Btrfs 이미지 공간을 넘지 않는 한 다른 변경도 가능함
    • 예를 들어 네트워크에서 hostname.local로 SteamOS 장치를 찾고 싶으면 rootfs/usr/lib/systemd/resolved.conf.d/00-disable-mdns.conf를 제거할 수 있음
    • /etc overlay 설정으로도 override할 수 있지만 번거롭다고 판단함
  • 이미지 없이 쉽게 할 수 있는 변경은 rootfs에 넣지 않는 쪽이 원칙임
    • Firefox를 rootfs에 설치할 수는 있음
    • 하지만 Firefox 보안 업데이트마다 이미지를 다시 repack해야 함

rootfs 언마운트와 RAUC bundle 생성

  • 수정이 끝나면 filesystem을 다시 read-only로 표시함
    • btrfs property set -ts rootfs ro true
  • 사용하지 않는 블록은 fstrim -v rootfs로 discard함
  • 마운트 해제에는 umount --recursive rootfs가 유용함
    • 앞서 마운트한 pseudo-filesystem까지 함께 처리할 수 있음
  • RAUC bundle을 만들기 전에 casync store와 blob index를 생성함
    • 예시는 casync make --store=rootfs.img.castr bundle/rootfs.img.caibx rootfs.img임
  • RAUC bundle에는 세 파일이 필요함
    • manifest.raucm
    • rootfs.img.caibx
    • filesystem UUID를 담은 UUID
  • manifest.raucm에는 update 정보와 rootfs 이미지 정보가 들어감
    • compatible=steamos-amd64
    • version=$version
    • sha256
    • size
    • filename=rootfs.img.caibx
  • UUID 파일은 blkid -s UUID -o value rootfs.img >bundle/UUID로 만듦
  • 세 파일을 준비한 뒤 rauc bundle을 실행함
    • --signing-keyring, --cert, --key에 인증서와 키를 지정함
    • 결과물은 rootfs.img.raucb임
  • rootfs.img.raucb와 rootfs.img.caibx는 client.conf의 ImagesUrl이 가리키는 웹 서버에 업로드함
    • 두 파일은 같은 디렉터리에 있어야 함

자체 업데이트 서버와 적용

  • QueryUrl과 MetaUrl에 쓰는 웹 서버는 JSON 파일을 제공해야 함
  • 간단한 구성에서는 live.json 하나로 충분함
    • .minor.candidates[0].image 객체는 이미지 안의 /lib/steamos-atomupd/manifest.json과 같아야 함
    • update_path는 업데이트 클라이언트가 ImagesUrl 뒤에 붙여 bundle을 내려받을 경로임
  • 예시 Caddy 설정은 steamos-atomupd가 QueryUrl과 MetaUrl로 보내는 요청을 live.json으로 rewrite함
    • /updates를 /live.json으로 rewrite함
    • /meta/*/*/*/*.json과 /meta/*/*/*/*/*.json을 /live.json으로 rewrite함
    • file_server browse를 사용함
  • 실제 SteamOS의 QueryUrl과 MetaUrl은 더 많은 로직이 있는 것으로 보이지만, 이 구성만으로도 steamos-atomupd가 새 업데이트를 찾을 수 있음
  • 이미 광고된 이미지가 현재 실행 중이면 업데이트를 피하는 로직이 있음
  • 기존 SteamOS 설치를 자체 이미지로 업데이트하려면 /etc/rauc/keyring.pem과 /etc/steamos-atomupd/client.conf를 수정하면 됨
    • steamos-readonly disable은 필요 없음
    • 변경은 /etc overlay에 들어감
    • steamos-update 실행 후에는 /var/lib/overlays/etc/upper에서 해당 변경을 정리하는 것을 고려함
  • Valve 복구 이미지 중 하나를 수정해 rootfs를 자체 이미지로 교체하면 변형 SteamOS를 설치할 수도 있을 것으로 보이지만, 이 방법은 테스트되지 않았음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 내가 가진 기기의 소프트웨어/OS를 깊게 커스터마이즈하는 이런 글이 좋음. Steam Deck에서는 Tivoization을 걱정하지 않아도 된다는 점도 반가움
    글에서 가장 흥미로웠던 부분은 /nix 파티션이었음. Steam Deck이 nixpkgs를 지원한다는 걸 몰랐는데, 더 찾아보니 기본 설치는 아니어도 전체 OS를 포크하지 않고도 기기에 올릴 수는 있더라

    • Nix는 원래 어떤 *nix OS에도 “전체 OS를 포크”하지 않고 설치할 수 있었음
      Nix 저장소는 쓰기 가능한 아무 위치에나 둘 수 있고, $PATH를 심볼릭 링크 디렉터리로 가리키게 바꾸면 됨
    • Steam Deck에서 nixpkgs 중 뭘 쓰는지 아는 사람 있나? 나도 nixpkgs를 많이 쓰는 편이라 궁금한데, 아쉽게도 Steam Deck은 없음

  • 정말 꼼꼼하고 흥미로운 글임. 개인적으로는 절대 이렇게까지 하진 않을 듯함
    Linux를 만져본 것도 Raspberry Pi 쓰던 시절이 전부고, 그마저도 1% 정도라서 글쓴이가 대단해 보임

    • 나도 글쓴이와 비슷한 상황이었음. 꽤 오랫동안 아주 특이한 이유로 직접 Red Hat 커널을 빌드해야 했는데, RMRR 검사를 우회해서 GPU를 Windows VM에 패스스루하기 위해서였음
      https://github.com/kiler129/relax-intel-rmrr와 비슷하지만 내 저장소는 아님
      근본 원인은 제조사의 ROM 업데이트로만 해결 가능한데, 내가 쓰는 오래된 DL360은 HPE 지원이 끝났음
      패치 자체는 한 줄 변경이지만 커널 업데이트가 번거로움. SRPM을 받아야 하고, Git 저장소가 없어서 SRPM을 풀고 패치를 적용한 뒤 다시 빌드하고 설치해야 함
    • TV를 원한다면 곧 진짜 선택지가 없어질 수도 있음

  • 이미 SteamOS 요소를 기반으로 PC와 컨트롤러 사용에 맞춘 배포판들이 있음. ChimeraOS는 Steam Deck용 부가 도구인 EmuDeck까지 포함해서 내 환경에서는 꽤 문제없이 동작함

  • unRaid NAS 서버에서 Steam Headless를 멋진 Docker 이미지로 돌리고, Windows 노트북에서는 Moonlight 같은 클라이언트로 접속하려고 GPU를 주문했음
    잘 되면 대부분 유휴 상태인 NAS를 두고 게임용 데스크톱 하드웨어를 또 사는 것보다 훨씬 나음. 다만 쓰지 않을 때 Nvidia 카드 전력 설정을 유휴 상태로 유지해야 함. 아마 nvidia-persistenced 호출로 가능하길 바람
    1: https://github.com/Steam-Headless/docker-steam-headless

    • 나도 거의 같은 걸 GOW로 돌려보려고 시간을 꽤 많이 썼음. 생각보다 훨씬 어려웠고, X 서버 설정을 맞추려면 HDMI 더미 플러그까지 필요했음
      1: https://github.com/games-on-whales/gow
    • 다른 대안으로, GPU 패스스루가 있는 KVM을 띄우고 cloud-init으로 Sunshine과 게임을 실행하거나 그냥 모니터를 직접 써도 됨
      https://kubevirt.io/user-guide/virtual_machines/host-devices...
      선언형 클라우드 네이티브 게임 실행이라니!
      kubectl apply -f crysis.yaml
    • 좋아 보임. 지금은 Sunshine + Moonlight를 쓰고 있는데, 곧 Steam Headless 성능을 테스트해볼 예정
    • 꽤 흥미롭다. 이런 식으로 로컬 네트워크에서 스트리밍할 때 입력 지연이나 영상 품질 한계가 느껴지나?
    • 좋네. Civilization 같은 턴제 핫시트 게임을 서버에 띄워두고, 브라우저로 원격 접속해서 친구들과 언제 어디서든 긴 턴 게임을 할 수 있게 만드는 구성을 계속 상상해왔음

  • 오늘 RAUC(https://rauc.io/)를 알게 됨. Valve가 A/B 업데이트 방식을 어떻게 구현했는지 궁금했었음

  • Netscape의 유성우 favicon이 좀 그립지 않나?

  • 흥미로운 글임. A/B 업그레이드는 약간 과해 보임. 문제가 생기면 라이브 배포판을 띄우거나, 예전 버전의 복구 시스템을 별도 파티션에 설치하면 되니까
    최근 몇 년간 NixOS를 쓰다가 Arch로 돌아왔는데, 그 전에도 오래 Arch를 썼고, 글쓴이의 걱정은 빗나간 것 같음
    Arch는 확실히 매우 진지하고 성숙한 배포판이며, Valve보다 더 신뢰할 수 있음
    Arch로 옮긴 이유는 패키지 품질 때문임. 메인 저장소는 정말 빠르게 업데이트되고 AUR에는 유용한 패키지가 많음

    • 너와 나는 라이브 배포판을 띄울 수 있지만, 압도적 다수의 컴퓨터 사용자는 못 함. Valve는 분명 평균 사용자를 위해 만드는 데 집중하고 있고, Linux 배포판들은 아무리 좋아해도 아직 그걸 잘하진 못함
      업그레이드 실패 후 시스템이 자동으로 복구되는 것은 지금 시점의 저관리 OS에서는 필수에 가까움
    • Steam Deck 사용자가 망가진 업그레이드를 고치려고 라이브 배포판 부팅을 해야 한다고 기대하면 안 됨. 매끄럽고 뒤에서 알아서 처리되어야 함
    • 가능은 하겠지만, 이제 그런 걸 불필요하게 만들 기술이 있고 디스크도 그렇게 비싸지 않으니 굳이 안 할 이유가 없음
    • Steam Deck은 본질적으로 비디오게임용 Chromebook에 가까우니, ChromeOS의 잘 깨지지 않는 파티션 방식은 합리적인 아이디어로 보임
    • Arch 패키지 품질 때문에 NixOS에서 옮겼다는 부분의 예시를 들어줄 수 있나?
      나는 대체로 NixOS 패키지 품질이 높다고 봄

  • 최근 게임용 휴대기기인 Legion Go를 손에 넣고 Linux를 더 접해보고 있음. 예전에는 끝없는 땜질 시간 낭비처럼 보였고, 실제로 쓰고 싶은 것들과의 호환성도 제한적이라 피해왔음
    불변 파일시스템과 전통적인 Linux가 온갖 임의의 소프트웨어에 루트 권한을 쉽게 내준다는 내용을 보면서 호기심이 생겼음
    지금은 NixOS를 쓰고 있는데, 확실히 땜질 시간 낭비가 될 수는 있지만 탐색용으로는 좋음. 다양한 구성요소를 쉽게 시험해보고, 유지하지 않기로 하면 ~/.config 오염 정도를 제외하고는 완전히 제거할 수 있음. 설치 전에 패치하는 것도 사소한 일이라, 게임용 휴대기기처럼 특이한 하드웨어에서 Linux를 쓸 수 있게 하는 커널 패치도 쉽게 추가 가능함
    Jovian이라는 NixOS 커뮤니티가 Valve의 임의 SteamOS tarball들을 GitHub의 태그 달린 커밋으로 재구성하고 있어서, Valve 직원처럼 소스를 둘러볼 수 있음. Nix 설정에 몇 줄만 추가하면 NixOS 위에 자기만의 SteamOS 사본을 설치할 수 있게 해두었음
    이들은 분명 Linux 전문가들이고, 소스를 보면 전원 버튼 위치를 하드코딩하지 않고 검사하는 식의 단순한 조정만 제외하면 Valve 패키지를 손대지 않은 상태로 받는다는 걸 확인할 수 있음
    순수한 SteamOS 경험을 원하지만 Valve 업데이트 시스템의 미러를 직접 운영하고 싶지 않거나, 3GB tarball을 받지 않고 Valve 소스를 탐색하고 싶다면 Jovian을 써볼 만함
    설치 안내: https://jovian-experiments.github.io/Jovian-NixOS/getting-st...
    Valve 소스 미러: https://github.com/orgs/Jovian-Experiments/repositories?type...

    • 나도 Steam Deck에서 Jovian-NixOS를 문제없이 잘 쓰고 있어서 강력 추천함

  • bazzite.gg도 이걸 아주 잘함. AMD 하드웨어에서는 120Hz VRR이 바로 동작했고, HDR 지원도 알파 테스트할 수 있음

    • Bazzite는 처음 들어봤음
      “Bazzite는 Steam Deck의 대체 운영체제로 쓸 수 있는 OCI 이미지이며, 데스크톱 컴퓨터, 거실 홈시어터 PC, 여러 휴대용 PC를 위한 바로 게임 가능한 SteamOS 유사 환경이다”
      https://github.com/ublue-os/bazzite/
      관심이 없더라도 README는 볼 만함. 포함된 것들의 목록이 엄청 길고, 특히 게이머나 스트리머에게 꽤 멋지고 유용해 보이는 항목이 많음
    • Bazzite와 불변 Linux 전반이 흥미로움
      HN 댓글 하나로 간결하고 완벽하게 설명할 정도로 깊이 파고들진 않았지만, 핵심은 루트에 읽기 전용의 검증된 Linux 배포판을 두고 그 위에 패키지를 계층으로 얹는 방식임. 서버 쪽 컨테이너에서 많은 영감을 받은 구조임
      전통적인 Linux보다 더 안전하고, 더 신뢰 가능하며, 재현 가능하고, 커스터마이즈하기 쉬운 걸 목표로 함. 원하는 패키지를 컨테이너 매니페스트에 적어두면, 업그레이드가 나올 때 업그레이드를 실행한 뒤 그 위에 패키지를 다시 설치함
    • 더 관련 있는 점은 Bazzite를 비교적 쉽게 포크해서 빠진 패키지나 필요한 설정을 자기 커스텀 이미지에 추가하고, 인프라 작업 대부분을 GitHub Actions에 맡길 수 있다는 것임
      https://universal-blue.org/guide/fork-your-own/
      그리고 불변 OS라서 문제가 생기면 이전 이미지로 롤백할 수도 있음
    • Steam의 연말 결산 기준으로 2023년은 처음으로 Linux에서만 게임한 해였고, 올해 출시작도 일부 포함됐음
      대부분은 Steam Deck이나 GPU 패스스루를 적용한 가상 머신에서 Bazzite를 돌려서 했는데, 정말 잘 만들어졌음
    • Bazzite가 더 유명하지 않다는 게 놀라움. 내가 꿈꾸던 바로 그것인데, 최근까지 존재하는지도 몰랐음

  • 거실 PC라니, 이제 HTPC나 “미디어 센터”라는 표현은 잘 안 쓰나?

답변달기