키메라 리눅스
(chimera-linux.org)- Chimera는 기존 Linux 생태계에 대한 불만에서 출발한 범용 Linux 기반 OS로, 단순성과 투명성을 유지하면서 실용적인 기능을 갖추려 함
- 처음부터 새로 구축한 배포판이며, 새 도구와 사용자 공간 도구(userland) 를 통해 개념적 단순성과 사용 편의성을 함께 추구함
- 핵심 도구는 FreeBSD, 툴체인은 LLVM, C 라이브러리는 Musl을 조합해 일반적인 Linux 배포판과 다른 구성을 택함
- 바이너리 배포판이면서도 소스 패키지 빌드 시스템을 제공해 새 소프트웨어 패키징과 커스텀 빌드를 지원함
- Intel/AMD, ARM AArch64, POWER, RISC-V 등 여러 프로세서 아키텍처를 대상으로 하며, 중앙 빌드 시스템으로 패키지 제공 범위를 넓히려 함
목표와 설계 방향
- Chimera는 단순성, 투명성, 낮은 진입 장벽을 지향하는 범용 Linux 기반 운영체제임
- 실용성과 풍부한 기능을 포기하지 않으면서, 세심하고 고품질인 소프트웨어 설계로 개념적 단순성과 편의성을 함께 추구함
- 자세한 설명은 Read more에서 확인할 수 있음
배포판을 이루는 주요 특징
-
대체 사용자 공간 도구
- FreeBSD의 핵심 도구, LLVM 툴체인, Musl C 라이브러리를 조합함
- 이 조합으로 기존 배포판과 다른 사용자 경험과 주요 이점을 제공하려 함
-
깔끔하고 일관된 시스템
- 가능한 곳에서 레거시 잔재를 제거하려 함
- 현대적이고 범용적이며 완전한 기능을 갖춘 운영체제를 목표로 함
-
소스에서 빌드 가능
- Chimera는 기본적으로 바이너리 배포판임
- 소스 패키지 빌드 시스템을 제공해 새 소프트웨어 패키징과 커스텀 패키지 빌드를 쉽게 만들려 함
-
여러 아키텍처 지원
- Intel/AMD, ARM AArch64, POWER, RISC-V 등 다양한 프로세서에서 사용할 수 있음
- 중앙 빌드 시스템이 여러 환경에서 패키지를 사용할 수 있게 함
댓글과 토론
Hacker News 의견들
-
오래 GNU 도구(GNU grep, sed, less, awk, find, tar 등)를 써온 사람이라면 생각보다 훨씬 답답할 수 있음
UNIX 시절에는 명령줄 도구마다 미묘한 차이가 있어서 정말 괴로웠고, GNU 도구가 Linux 이전부터 인기를 얻은 이유도 여기에 있었음
irix, hpux, sun 등 어떤 UNIX에도 설치하면 hpux grep과 irix grep 같은 기묘한 차이를 피할 수 있었음- CLI 유틸리티의 API 호환성이 핵심 걱정이라면, Chimera의 핵심 사용자 영역은 “FreeBSD, NetBSD, OpenBSD”가 제공한다고 하니 이 마찰은 이론상 오늘날 BSD나 Mac을 쓸 때의 마찰과 비슷할 것임
- Solaris에 GNU 포트를 여러 번 설치한 적이 있음
다만 Aix와 HP-UX 서버는 내가 통제할 수 없어서, 모든 서버에서 돌아가야 하는 스크립트는 POSIX 호환으로 유지하거나 Perl로 작성해야 했음 - 이런 명령들이 기본적으로 접두사가 붙은 이름으로 설치되지 않는 게 아직도 이상하고 짜증남
awk는 gawk, mawk처럼 명시적으로 설치되는 경우가 흔한데, tar도 bsdtar, gtar처럼 쓰는 게 일반적이면 좋겠음
nixpkgs에서는 상황별로 정확한 버전을 명시하기 쉽지만, 그 외 환경에서는 대부분 추측에 가까움 - 여러 Un*x 구현 사이에서 자주 발목을 잡은 건 tar(1) 였고, 이상하게도 awk(1)의 아주 사소한 차이는 몸에 익어 있었음
root 권한이 있는 Solaris 박스에는 곧바로 gtar를 설치하는 습관이 생겼고, 아카이브 안의 선행 “/” 때문에 특히 그랬음
두 번째로 힘든 건 직장에서는 SunOS와 HP/UX, 밖에서는 Ultrix를 다루는 일이었고, 최악은 MS-DOS를 몇 번 접했을 때 왜 키 입력을 버퍼링하지 않는지 이해하지 못했던 일이었음 - GNU Awk와 OSX의 BSD awk 사이에서도 이런 차이는 아직 존재함
-
Chimera Linux의 여러 설계 선택, 특히 패키징/빌드 시스템은 마음에 들지만, 현재 Alpine Linux를 메인 PC에서 쓰는 입장에서는 여전히 musl을 정당화하기 어렵다고 느낌
작고 단순하고 올바른 소프트웨어를 좋아하지만, musl은 그런 장점에도 불구하고 경험상 glibc보다 느리고 가끔 예측하기 어려운 지점에서 느려짐
musl로 소프트웨어를 이식할 때 잔문제가 꽤 많고, 대부분의 업스트림은 패치를 받아들이는 데 소극적이라 배포판 유지보수 부담이 생김
런타임에서 미묘하게 깨지는 경우도 있어서, 예를 들어 Alpine과 Chimera의 Firefox 빌드는 공식 Mozilla 빌드나 Arch Linux 빌드에는 없는 같은 두 가지 충돌을 보임
결국 Mozilla Firefox 빌드 같은 작업에서 glibc chroot에 너무 자주 의존하게 됨- 때로는, 혹은 자주, musl이 느린 이유가 순전히 메모리 할당자 때문일 수 있음
기억하기로 Chimera는 기본 musl 할당자와 다른 할당자를 사용함 - Alpine에서도 비슷했음
musl은 가치보다 훨씬 많은 문제를 일으키는 쪽으로 귀결됨 - musl은 사실상 필수 선택임
도구 체인 설정상 다른 선택지가 잘 맞지 않고, glibc는 clang+compiler-rt와 어울리지 않음
glibc가 최근에야 clang으로 빌드되기 시작했지만 여전히 gcc 중심 런타임을 가정하고, 실제로 glibc는 libgcc_s를 dlopen함
다른 libc들은 지원 측면에서 훨씬 더 나쁠 가능성이 큼
소프트웨어를 musl로 이식하는 어려움은 과장된 면이 있음
대부분의 소프트웨어는 애초에 이식 작업이 필요 없고, 업스트림도 그렇게까지 소극적이지만은 않음
Firefox의 특정 충돌이 있다면 보고했는지도 궁금함
느림은 대체로 기본 할당자 문제인데 Chimera에는 해당하지 않고, 경우에 따라 더 빠를 수도 있음 - Chimera 외에도 Void Linux를 시도해볼 만함
- 주제에서 조금 벗어나지만, Alpine을 메인 PC에서 쓰기 시작하는 데 추천할 만한 자료나 조언이 있는지 궁금함
System76 장비가 있어서 한번 시도해보고 싶음
- 때로는, 혹은 자주, musl이 느린 이유가 순전히 메모리 할당자 때문일 수 있음
-
완전히 동의하는 것은 아니지만, 이 프로젝트의 systemd에 대한 입장은 지금까지 본 것 중 가장 성숙하고 미묘하며 균형 잡혀 있음
https://chimera-linux.org/docs/faq#what-is-the-projects-take...- 약간 다른 얘기지만, 정반대로 systemd 구성요소를 전면 수용하는 배포판이 있는지 궁금함
Linux 서버를 많이 다뤘고 매우 실용적으로 보는 입장에서는, systemd가 많은 것을 쉽게 만들었고 설정 가능하며 유지보수되고 자주 갱신되며 제대로 표준화돼 있음
통제감을 느끼고 싶어 하는 사람들도 이해하지만, 나는 한 가지 방식으로 동작하는 신뢰성 있는 컴퓨터를 원함
결국 서버는 가축처럼 다루는 대상이니까
그래서 변경 불가능한 시스템 이미지, 서명된 부팅, 위에서 아래까지 systemd 서비스로 구성된, Poettering 블로그의 사고 실험 같은 무언가가 있으면 좋겠음 - 이 문서는 정말 괜찮지만, “systemd는 세상의 모든 이식 불가능한 확장을 의도적으로 남용하도록 작성됐다”는 부분은 더 세분화돼야 함
Linux 전용 커널 기능과 사용자 영역 확장, 즉 GNU 대 POSIX를 나눠 봐야 함
cgroups 같은 Linux 전용 커널 기능을 쓰는 것은 Linux 시스템에서는 좋은 일임
예전에는 부하가 높을 때 sshd가 느려져 로그인하기 어려워지는 일이 흔했는데, systemd는 이런 일이 덜 생기도록 시스템을 설정함
사용자 영역 확장의 경우에는 systemd가 더 작은 도구와 기능 집합 위에 구축하는 것을 순이득으로 봤으면 했지만, 해당 페이지는 그렇지 않은 듯함
그쪽에서 무슨 일이 있었는지 궁금함 - 이는 Void Linux의 입장이기도 함
Void는 단지 systemd-free이기 위해 그런 것이 아니라, 작고 느슨하게 결합된 컴포넌트라는 Unix 유산을 유지하고, 합리적으로 POSIX와 이식성을 지키며(xbps), 사용자가 libc를 고를 수 있는 Linux 시스템을 제공하려는 것임 - systemd를 크게 지지하지만, systemd 이전에도 Ubuntu에서 쓰인 Canonical의 upstart가 있었음
systemd는 upstart의 단점을 해결하려고 만들어졌음
Chimera가 실제로 유용한 systemd 기능을 독립적으로 자체 방식으로 구현하려는 목표는 훌륭함
systemd의 가장 큰 가치는 서비스 파일이 많이 작성돼 있다는 점이고, 내 ~/.config/systemd 디렉터리에도 서비스가 십여 개 있음
그래서 systemd와 호환되는 데 가치가 있다고 봄 - systemd를 크게 지지하지만, systemd 이전에도 Ubuntu에서 쓰인 Canonical의 upstart가 있었음
systemd는 upstart의 단점을 해결하려고 만들어졌음
- 약간 다른 얘기지만, 정반대로 systemd 구성요소를 전면 수용하는 배포판이 있는지 궁금함
-
Chimera Linux의 의도를 이해하려면 Void Linux를 한 단계 더 밀어붙인 것으로 보면 됨
창립자는 예전에 Void의 PPC 유지보수자였고, Chimera의 지원 아키텍처 선택도 그 맥락에서 이해됨
내 해석으로 Chimera는 FreeBSD 사용자가 Linux를 써야 한다면 원할 법한 시스템임
같은 컴파일러와 사용자 영역을 공유하고, 빌드 시스템도 익숙한 느낌을 줌
처음에는 GNOME 선택이 이상해 보이지만, Chimera는 많은 레거시를 피하려고 하고 처음부터 PipeWire와 Wayland 기반임- 꽤 좋아 보이지만, GNOME 선택 때문에 약간 덜 끌림
System76의 COSMIC이 언젠가 고려 대상이 될 만큼 자리 잡을지 궁금함
안정적이고 실용적이며 생산성과 사용자 중심의 새 데스크톱 환경이 부상하면 좋겠음
Plasma는 버그가 좀 많고, GNOME은 실용적이지도 사용자 중심적이지도 않게 느껴지며, 나머지는 어느 정도의 다듬기와 유지보수가 부족해 보임
System76은 여기에 투자할 돈이 있고, 개발자의 이상보다 사용자의 필요와 감각에 맞춘 무언가를 만들 동기도 맞아 보이므로 시간이 지나면 주요 경쟁자가 될 수 있음
- 꽤 좋아 보이지만, GNOME 선택 때문에 약간 덜 끌림
-
멋지긴 하지만, 사용자 친화적인 주류 배포판이 되려는 듯한 것을 볼 때마다 걱정됨
Manjaro가 “대중에게 단순함을” 같은 목표를 내세우며 얼마나 노력했는지, 그런데도 여전히 문제가 얼마나 많은지를 봤기 때문임
이게 실험적이거나 취미용 배포판인지, 아니면 할머니도 쓸 수 있는 것을 목표로 하는지 궁금함
이걸 BSD와 비교해 고르라면 이쪽이나 비슷한 것을 꽤 진지하게 고려하겠지만, Ubuntu나 Windows 대체재처럼 보이지는 않음
단순함은 일반 최종 사용자가 고려하는 요소가 아님
현대적인 소프트웨어를 좋아하고 가벼운 해커 친화적 환경에는 별 관심 없는 개발자로서, 데스크톱 점유율이 최소 1%도 안 되는 것을 쓸 가능성은 매우 낮음
Arch/Kali/BSD/suckless 열성파가 아닌 사람은 “아, 이거 프로젝트 카 생각할 때랑 같은 느낌인데 빠져야겠다”는 감각이 매우 발달해 있음
훌륭하고 가치 있는 프로젝트일 수는 있지만, 땜질 좋아하는 사람들 외의 관심을 끌기는 힘든 싸움일 것이고, 이런 일에는 시간이 많이 들어서 기대치를 관리하지 않으면 성공하지 못했을 때 큰 실망이 될 수 있음
나도 새 프로젝트를 여러 번 시작해봤고, 가까운 시일 안에 어디로도 가지 않을 가능성이 크다는 걸 깨닫는 과정이 꽤 힘들었음
주류 채택을 얻으려면 전체 소프트웨어 생태계 자체가 바뀌어야 할 것 같음
Steam이나 Chrome 같은 현재의 거대 앱을 여기에 이식하려면 문제가 생길 것이라 봄
게다가 동적 링크는 최종 사용자용 친화적 배포판에는 그리 잘 맞지 않아 보임
Snap이나 Flatpak 같은 것이 없다면, 최신 대형 복잡한 서드파티 패키지를 간헐적 호환성 문제 없이 제공하기 어렵다고 봄
동적 링크 기반 배포판 경험이 전반적으로 끔찍하진 않았지만, 늘 이런저런 문제가 있었음
AppArmor 같은 샌드박싱이 있는지도 궁금함- 할머니도 쓸 수 있는 것을 원한다면, 모두가 쓰는 것을 쓰면 됨
Chimera는 실험적 취미 배포판이고 꽤 틈새적이며 여러 표준에 반함
Chimera 특유의 문제를 언제나 마주치게 될 것임
대신 만져볼 수 있는 투명한 빌드 시스템이 있음
Manjaro에 대해서는, Arch 기반으로 잘 동작하는 배포판을 만드는 게 어렵다고 보진 않음
Manjaro 개발자들이 못하는 것뿐임 - 어떤 프로젝트든 성공할 것이라고 기대하면 대체로 실망하게 됨
대부분의 프로젝트는 성공하지 못하기 때문임
이런 일은 대체로 스스로에게 유용하거나 재미있어서 해야지, 성공시키고 싶어서 하면 안 됨
더 취미적인 특정 대상을 목표로 하는 프로젝트도 괜찮다고 봄
모든 프로젝트가 모두를 위한 것일 필요는 없음 - 웹사이트는 주류 운영체제가 되려는 인상을 주지 않음
마케팅은 “musl을 쓰는 가벼운 해커용 배포판이지만 같은 범주의 다른 것들보다 단순함”에 가까움
Linux 배포판들이 기존 Linux 사용자에게 홍보하면서도, 비 Linux 기술 미디어 쪽에 이런 혼란을 우발적으로 만들지 않을 수 있으면 좋겠음
많은 Linux 사용자는 운영체제가 크게 뜨는 것을 원하지 않음
인기가 많아지면 여러 면에서 실제로 더 나빠질 것이기 때문임
“Linux 데스크톱의 해”나 Windows와 비교한 좁은 시각의 제품 약점 이야기는 보통 새 사용자와 기술 미디어에서만 나옴
Fedora는 이런 공적 이미지 문제의 균형을 꽤 잘 잡음
첫 페이지에서는 “모든 종류의 개발자와 제작자”를 위한 것이라고 강조하지만, Fedora Workstation은 실제로 거의 모두에게 쉬운 배포판에 가까워서 “Is Fedora For Me” 페이지에서는 컴퓨터 전반에 호기심이나 열정이 있는 비개발자에게도 맞을 수 있다고 설명함
인용문 역시 Fedora가 호기심 많고 배우려는 컴퓨터 사용자를 위해 만들어졌으며, 누구에게나 맞지는 않을 수 있지만 최신 하드웨어를 지원하는 안정적인 Linux와 FOSS 커뮤니티에 기여할 의지가 있다면 완벽한 시스템일 수 있다고 말함 - Arch를 그 그룹에 묶어야 하는지는 잘 모르겠음
Steam 통계에서는 Ubuntu보다 더 인기 있고, 여기에 SteamOS는 포함되지도 않음
- 할머니도 쓸 수 있는 것을 원한다면, 모두가 쓰는 것을 쓰면 됨
-
“단순한 시스템이 실용적이기 위해 끝없는 설정과 커스터마이징을 요구할 필요는 없다”와 대체 사용자 영역은 잘 어울리지 않음
어떤 대체 사용자 영역이든 많은 것을 깨뜨릴 것이고, 결국 광범위한 조정 작업이 필요해질 것이기 때문임- 둘은 양립하지만, 생각하는 방식과는 다름
Chimera는 저장소에서 무엇을 설치하든 즉시 동작하는 설정이 나오도록 설계됨
데스크톱을 원하면 설치하면 동작하고, dbus, 오디오, Wi-Fi/블루투스 등을 맞추려고 반드시 손댈 필요가 없음
가장 중요한 점은 설치가 일관되게 결정적이고 감사 가능하도록 구성돼 있다는 것임
복잡한 셸 훅이나 그런 종류의 “수정 작업”에 의존하지 않고, 대부분의 패키지는 단순 추출만으로 구성됨
물론 서드파티 셸 스크립트 같은 것을 끌어들이면 호환성 문제를 만날 가능성이 있지만, 생각만큼 자주 일어나지는 않을 수 있음 - 대체물이지만 대체로 호환된다면 조정할 일이 많아 보이지 않음
실질적으로 다르다면 조정 이전에 주로 배워야 할 일이 생길 것임
- 둘은 양립하지만, 생각하는 방식과는 다름
-
Chimera는 Void Linux를 PowerPC로 포팅했던 사람이 개발했음
https://web.archive.org/web/20230811081600/https://voidlinux...
https://voidlinux.org -
Wayland 과열 분위기에 올라탄 것처럼 보이지 않았다면 훨씬 더 기대했을 것 같음
너무 단순하지 않으면서도 충분히 단순하고, 너무 많은 레거시 없이도 충분히 하위 호환성을 챙기는 좋은 결정을 많이 한 것 같지만, 개인적으로 Wayland는 아직 그 같은 위치에 들어맞지 않음- 좋은 소식이라면, contrib 저장소에 xorg 전체 배포판이 있고 조만간, 어쩌면 영원히 사라질 것으로 예상되지 않음
- 큰 회사들이 모두 Wayland에 100% 찬성하는 것처럼 보임
Wayland 자체가 얼마나 좋은지와 별개로, 그들과 호환성을 깨는 것은 번거로워 보임
-
SystemD에 대한 관점이 흥미로움
개인적으로는 매우 유용하다고 보지만, 프로젝트로서의 큰 단점 중 하나는 Benno Rice의 표현을 빌리면 공격적으로 Linux 전용이라는 점임
다만 Chimera의 소프트웨어 선택 자체가 systemd 사용을 막는 것으로 보이고, FAQ의 “유용한 systemd 기능을 독립적으로 자체 방식으로 구현하겠다”는 문장이 이를 잘 요약함
SystemD를 다른 소프트웨어 스택으로 이식하는 것이 가능한지 의문임
문자 그대로 SystemD를 다시 쓰기보다는 이식해보는 편이 충분히 유용해 보이고, 그러면 systemd 지지자와 반대자 모두를 만족시킬 수도 있음
물론 같은 일을 하는 경쟁 제품이 생기면 미래의 혁신으로 이어질 수도 있음- SystemD는 너무 빠르게 움직이고, 너무 강한 의견을 갖고 있으며, 범위가 너무 넓음
그래서 이식할 능력이 있는 사람들도 실제로는 그 작업을 하고 싶어 하기보다, 이 프로젝트처럼 부분 대체품을 쓰고 싶어 할 것임 - Mac이나 Windows에서 SystemD를 쓸 사람은 없을 텐데, Linux 전용인 게 왜 중요한지 모르겠음
- SystemD는 너무 빠르게 움직이고, 너무 강한 의견을 갖고 있으며, 범위가 너무 넓음
-
창립자가 좋아할지는 모르겠지만, 데스크톱에서 Chimera를 쓰는 현재 내가 가장 좋아하는 방식은 그 안에 Arch Linux distrobox를 설치하는 것임
이렇게 하면 기본 Chimera 시스템을 즐기면서도 전체 Arch 저장소와 AUR 목록에 즉시 접근할 수 있음
MUSL에서 문제가 있는 애플리케이션도 distrobox 안에서는 glibc로 실행되니 간단히 돌릴 수 있고, Distrobox가 Wayland를 전달하므로 그래픽 앱도 아주 잘 동작함
목표는 가능한 한 많이 Chimera 네이티브로 실행하는 것이지만, 때로는 그냥 다른 일을 끝내야 할 때가 있음
Chimera 저장소에는 distrobox가 없지만 podman은 포함되어 있어서 대부분은 해결됨
어쨌든 잘 동작하고, 지금 이 글도 Chimera에서 쓰고 있음
어떤 사람들은 Flatpak을 선호하지만 나는 오래된 방식의 패키지 관리를 더 좋아함
Flatpak은 내게 너무 무겁고 불투명하게 느껴지지만, 의견이 다를 수 있다는 건 알고 있음
Distrobox는 콘솔 작업에는 확실히 더 잘 맞음
빠른 샌드박스와 임시 개발 환경을 띄우는 데도 편리한 도구임
Arch는 개인적 선택일 뿐이고, Void나 Debian 등 무엇이든 골랐을 수도 있음