Linux용 소프트웨어 패키징이 싫은 이유

터미널 편집기 Fresh를 모든 Linux 사용자가 쉽게 설치할 수 있도록 여러 배포 채널을 지원했지만, 채널이 늘어날수록 릴리스 유지 비용과 장애 가능성도 커짐 npm, Cargo, AppImage, Flatpak, deb, rpm, AUR, Nix, mise 등은 각기 일부 사용자에게만 적합하며 보안·호환성·샌드박스·업데이트 문제가 서로 다름 AppImage는 시작이 느리고, Flatpak은 시스템과 네트워크에 폭넓게 접근하는 TUI에 맞지 않으며, deb와 rpm은 공식 저장소 밖에서는 시스템 업데이트로 새 버전을 받기 어려움 오래된 배포판의 libc 호환성, Debian의 Rust 의존성 정책, mise의 신뢰 루트 장애, AUR의 읽기 전용 전환처럼 개발자가 통제할 수 없는 문제까지 관리해야 함 앞으로는 약 12MB인 정적 musl 바이너리와 사용자가 직접 실행하는 자체 업데이트 기능을 Linux의 권장 배포 방식으로 삼고, 기존 패키지와 소스 빌드도 당분간 유지함 Windows·macOS와 다른 Linux 배포 환경 Fresh를 누구나 어디서든 쉽게 설치할 수 있게 만드는 것이 목표였음 Windows에서는 winget을 사용하며, 초기 설정은 번거로웠지만 현재는 정상 작동함 macOS에서는 Homebrew를 사용 중이며, 추후 제대로 패키징한 네이티브 서명 앱으로 전환할 가능성이 있음 현대 Windows와 macOS는 환경이 비교적 균일해 두 방식 모두 무난하지만, Linux는 배포판과 설치 체계가 다양해 상황이 다름 npm 배포에서 드러난 문제 Fresh의 첫 Linux 배포 방식은 npm 패키지였지만 세 가지 문제가 있었음 npmjs에서 여러 차례 침해 사고가 발생해 보안을 신뢰하기 어려움 npm이 없는 사용자는 Fresh 하나를 설치하기 위해 npm부터 설치해야 함 npmjs에서 받은 스크립트가 GitHub로 이동해 머신에 맞는 바이너리를 내려받으며, 업데이트할 때마다 이 과정을 반복함 늘어난 배포 채널과 유지 부담 피드백과 기여자들의 도움으로 다음 패키지와 설치 경로를 마련함 crates.io의 Rust Cargo와 cargo-binstall AppImage와 Flatpak deb와 rpm 소스 빌드 및 사전 빌드 -bin 변형을 제공하는 Arch Linux AUR Nix, mise, Linux용 Homebrew, npm/npx, Terra, Gentoo GURU tarball 형태의 사전 빌...