▲

왜 Gentoo인가?

 (blogs.gentoo.org)
2P by GN⁺ | ★ favorite | 댓글 1개
  • Gentoo의 핵심 가치는 컴파일 성능 자체보다 소스 빌드가 주는 유연성과 사용자를 위해 만드는 배포판이라는 철학에 있음
  • 회사나 비즈니스 모델 없이 운영되며, Gentoo Foundation 해산과 SPI 이전으로 재정 거버넌스 병목과 의존 위험을 줄이려 함
  • 전담 보안 팀, 자체 인프라, OpenPGP 보호 배포 채널, 강한 QA 정책으로 오래된 의존성·정적 링크·번들 의존성에 대응함
  • 소스 우선 구조와 USE 플래그는 기능, 라이브러리, init 시스템, libc, 빌드 방식을 고르게 해주지만 유지되지 않는 선택지는 제한될 수 있음
  • 롤링 릴리스와 안정·실험 구성의 공존, 오래된 하드웨어 지원, 개발 친화성, 원격 측정 제거 지향이 사용자를 존중하는 방식으로 이어짐

Gentoo의 핵심 정체성

  • Gentoo는 “모든 것을 컴파일하는 배포판”으로 알려져 있지만, 단순한 성능 추구나 극단적 최적화만으로 설명하기 어려움
  • CPU와 컴파일러 최적화, 일반 배포판의 패키지 최적화가 발전하면서 평균적인 Ubuntu 패키지와 CPU에 맞춘 Gentoo 패키지의 성능 차이가 현실적으로 큰 차이를 만들지 않을 수 있음
  • Gentoo의 더 중요한 가치는 소스 빌드가 제공하는 유연성과, Gentoo를 좋아하는 사람들이 스스로를 위해 만드는 배포판이라는 데 있음

독립성

  • Gentoo 뒤에는 회사나 비즈니스 모델이 없으며, Gentoo의 가치에 헌신하는 사람들이 만들고 운영함
  • 일부는 업무의 일부로 Gentoo를 다루지만, 대다수는 자원봉사자이며 수익 동기보다 열정으로 움직임
  • 인프라는 일부 기부받고 일부는 기부금으로 운영되며, 특정 기부자가 Gentoo를 좌우하지 못하도록 한 곳에 의존하지 않음
  • 직접적인 재정 거버넌스가 병목이 되는 위험을 줄이기 위해 Gentoo Foundation을 해산하고 SPI로 옮기는 작업을 진행 중임

보안

  • Gentoo는 패키지 보안을 중요하게 다루며, 때로는 업스트림보다 앞서 패치를 백포트함
  • 전담 보안 팀이 문제 추적, 해결, 사용자 공지를 맡음
  • 자체 인프라를 유지해 탈취 위험을 줄이고, 배포 채널과 미러를 OpenPGP로 보호함
  • Codeberg와 GitHub는 선택적 미러와 기여 채널로만 쓰며, Gentoo가 둘 중 하나에 의존하지 않게 함
  • 강한 QA 정책으로 번들 의존성, 정적 링크, 고정된 의존성 같은 방식에 비판적으로 대응함
  • 심각하게 오래된 의존성 같은 명백한 위협을 막기 위해 노력함

사람이 만드는 배포판

  • Gentoo는 2년 전에 LLM 기여를 금지했으며, 그 결정을 후회하지 않는 입장을 유지함
  • 오염된 코드가 전혀 들어오지 않았다고 100% 보장할 수는 없지만, 신뢰와 경계가 커뮤니티를 떠받치는 핵심으로 여겨짐
  • 업스트림이 같은 입장을 취하지 않는 경우에도 최신·보안 소프트웨어 제공 책임 때문에 LLM 기반 소프트웨어가 Gentoo에 패키징되는 것을 완전히 막을 수는 없음
  • copywashed chardet이나 vibe-coded 암호화 소프트웨어처럼 심각한 경우는 최대한 막으려 함

안정성

  • Gentoo는 시작하기 가장 쉬운 배포판은 아니지만, 설정을 마친 뒤에는 놀라울 만큼 안정적일 수 있음
  • 문제가 생겨도 시스템을 재설치하지 않고 고칠 수 있는 경우가 많음
  • 패키지 트리가 특정 패키지의 단일 버전에 묶이지 않아, 새 버전이 잘 맞지 않으면 다운그레이드할 가능성이 높음
  • 해당 버전이 Gentoo에서 사라졌더라도 비교적 쉽게 복원할 수 있음
  • 롤링 릴리스 배포판이라 여러 배포판 버전으로 나뉘지 않고, 다음 릴리스로 주기적으로 이동할 필요가 없음
  • 사용자는 새 패키지가 추가되는 즉시 받아 쓰는 최신 환경과, 준비가 확인된 뒤 업데이트하는 안정 환경 중에서 선택할 수 있음
  • demize @ unstable.systems는 ACCEPT_KEYWORDS="~amd64", LLVM 프로파일, mold 시스템 링커, 전체 LTO 같은 실험적 구성에서도 다른 데스크톱 Linux보다 안정적인 경험을 했다고 밝힘

유연성

  • 소스 우선 배포판

    • Gentoo의 기본 설치 방식은 소스 빌드지만, 사용자가 의존성을 직접 찾고 빌드 명령을 수동으로 이어 붙이는 구조는 아님
    • 패키지 관리자가 필요한 단계와 그 이상의 작업을 처리해 패키지 설치를 쉽게 만듦
    • 소스 빌드는 패키지가 어떤 기능을 포함하고 어떤 방식으로 빌드되는지 더 세밀하게 제어하게 해줌
    • 필요 없는 기능을 빼면 성능 개선과 공격 표면 축소가 가능하며, RSS 리더나 메일 클라이언트를 취약한 웹 브라우저 컴포넌트 없이 빌드하는 구성도 가능함

  • 라이브러리와 빌드 과정 제어

    • 소스 컴파일은 Gentoo 빌더가 사용한 단일 라이브러리 조합에 사용자를 묶지 않음
    • 특정 라이브러리의 오래된 버전을 유지하거나 더 새 버전을 쓰거나, 완전히 다른 구현을 사용할 가능성이 생김
    • 공식 지원 범위와 실제 동작 가능성에는 한계가 있지만, 순수 바이너리 배포판보다 잠재적 조합이 훨씬 넓음
    • 지원 범위를 넘어서는 경우에도 패치를 적용하거나 빌드 과정을 조정하기 쉬움

  • 선택의 범위와 한계

    • Gentoo가 “선택에 관한 배포판”이라고 불리기도 하지만, 모든 선택지를 계속 유지할 수 있는 것은 아님
    • OpenRC와 systemd, glibc와 musl처럼 합리적인 선택지를 제공할 수 있는 경우가 있음
    • 선택지가 유지되려면 누군가 적극적으로 지원해야 하며, 그렇지 않으면 반쯤 고장난 시스템이 되기 쉬움
    • LibreSSL과 OpenSSL, libav와 ffmpeg처럼 유지보수 비용이 너무 커 포기한 경우도 있음
    • Qt가 업스트림에서 LibreSSL 지원을 거부하면서 LibreSSL 유지는 더 어려워짐

  • 기본값과 선택적 맞춤화

    • Gentoo의 선택지는 대부분 옵트인으로 제공됨
    • 필요한 사람에게는 유연성을 제공하되, 나머지는 좋은 기본값으로 유지하려 함
    • 사용자는 관심 있는 부분만 맞춤화하고 나머지는 기본값에 맡기는 방식으로도 좋은 경험을 얻을 수 있음
    • charon @ hachyderm.io는 서로 다른 아키텍처, libc, init 시스템, 패키지 패치, 기능 구성, 디스플레이 스택을 같은 OS에서 다루고 최신 상태로 유지할 수 있다는 점을 높게 봄
    • Josh @ babka.social는 그래픽 패키지가 전혀 없는 headless 시스템이나 원하는 그래픽 스택을 별도 설치 과정이 아니라 단순한 설정 파일로 구성할 수 있다는 점을 장점으로 봄

즐거움과 실험

  • Gentoo는 단순히 작업을 끝내는 것 이상으로, 사용자가 한 걸음 더 나아가 실험할 수 있는 경험을 지향함
  • 최신 개발 소프트웨어를 써보고 싶다면 업스트림의 stable, testing, development 브랜치 버전을 제공하는 경우가 많음
  • 많은 패키지에는 업스트림 저장소에서 바로 빌드하는 live ebuild가 있어, 최신 개발 브랜치를 unmask하는 것만으로 테스트할 수 있음
  • 평범한 GNU/Linux 시스템을 넘어 musl, GNU Hurd, LLVM 기반 툴체인, FreePG, Sequoia, Samurai, libarchive tar/cpio, 대체 awk 구현 등을 시험할 수 있음
  • 이러한 실험은 안정성과 모순되지 않으며, stable 또는 ~arch 패키지를 출발점으로 삼아 일부만 최신으로 가져가거나 필요한 곳은 LTS 브랜치에 고정할 수 있음

지속 가능성

  • 소스에서 빌드하는 사용자가 많지만, Gentoo는 컴퓨팅의 지속 가능성을 지향함
  • 다양한 설정의 같은 패키지를 빌드할 수 있는 폭넓은 바이너리 패키지 지원을 제공함
  • 사용자는 요구에 맞는 공식 바이너리 패키지를 쓰거나, 맞지 않으면 소스 빌드로 돌아갈 수 있음
  • 여러 대상용 공식 패키지를 쓸 수 있고, 별도로 또는 시스템 설치 과정에서 직접 바이너리 패키지를 빌드해 사용할 수도 있음
  • 오래되거나 덜 흔한 하드웨어를 폭넓게 지원하려 하며, Rust나 V8이 지원하지 않는 하드웨어에서도 동작 가능한 시스템을 제공하려 함
  • 상업 공급자가 수익성이 없다는 이유로 지원을 중단한 컴퓨터를 버리는 것보다, 다소 험난하더라도 계속 사용할 수 있게 하는 편을 선호함

개발자 친화성

  • Gentoo는 모든 것을 소스에서 빌드하기 때문에 사용자가 개발 환경과 밀접하게 맞닿아 있음
  • 패키지를 설치하려면 완전한 툴체인이 필요하고, 패키지를 “런타임”과 “개발” 부분으로 나누는 방식이 Gentoo에서는 큰 의미가 없음
  • Gentoo에서는 좋은 개발 환경이 기본적으로 갖춰지는 경우가 많음
  • 정책적으로 패키지 패치를 싫어하고 가능하면 피하려 하며, 패키지가 업스트림을 따르고 Gentoo에서 개발된 소프트웨어가 올바르고 이식 가능하기를 원함
  • Gentoo는 bzip2 패키지에 비표준 pkg-config 파일을 추가하지 않는 몇 안 되는 배포판 중 하나임
  • Gentoo에서 개발하면 해당 비표준 파일을 요구하는 패키지를 배포하는 흔한 실수를 피할 수 있음
  • Gentoo는 여러 Python 버전을 적극 지원하는 몇 안 되는 배포판 중 하나이며, 특정 Python 버전을 선택할 뿐 아니라 여러 Python 버전용 패키지를 동시에 설치할 수 있음
  • 다양한 Gentoo 구성이 존재하기 때문에 최종 사용자 테스트가 중요하며, 패키지 빌드 중 테스트 스위트를 실행하도록 쉽게 설정할 수 있음
  • rayslava @ mitra.do.rayslava.com는 USE 플래그가 앱을 여러 조합으로 구성하는 최고의 방식이며, Portage가 corporate rpm 패키지도 문제없이 emerge로 소비하게 해줬다고 밝힘
  • 같은 사용자는 pycargoebuild로 Rust 인프라를 별도 도구나 환경 없이 유지하고 있으며, 2004년부터 Gentoo를 사용해 더 나은 것을 찾지 못했다고 밝힘

도움이 되는 배포판

  • Gentoo는 개발 머신, 게임용 PC, 단순 터미널, 서버 등 다양한 사용 사례에 유용한 시스템을 제공하려 함
  • Free Software Foundation 관점에서는 Gentoo에서 proprietary software 설치가 너무 쉬워 좋은 배포판이 아니라고 여겨질 수 있음
  • 동시에 자유 소프트웨어만 유지하는 것도 똑같이 쉬우며, 기본값은 자유 소프트웨어임
  • Linn @ mastodon.social는 Gentoo의 라이선스 접근 방식이 패키지 단위로 허용할 라이선스를 선택하게 하고, 기본값을 자유 소프트웨어로 두어 proprietary software 설치 전에 라이선스를 확인하게 만든다고 봄
  • Gentoo는 발견한 버그를 업스트림에 보고하고 함께 고치려는 정책을 유지함
  • Gentoo는 빌더에서 통과시키기 위한 임시 우회만으로는 충분하지 않고, 모두에게 동작하는 해결책이 필요하다고 봄
  • 이식성과 fringe platform 지원 같은 복잡한 문제를 다루며, 대부분의 배포판이 지원하지 않는 플랫폼까지 고려함
  • danzin @ mastodon.social는 Gentoo 사용자가 아니더라도 업스트림 프로젝트에서 문제를 찾아 보고하고 수정하는 Gentoo의 작업이 Python 생태계 등에서 호환성과 안정성 유지에 중요하다고 봄
  • Gentoo 문서는 과거 Linux 배포판 중 최고 수준으로 여겨졌고, 지금도 꽤 좋은 수준으로 평가됨
  • Gentoo를 사용하다 보면 시스템 설치, ebuild 작성, /etc/portage/patches의 작은 수정, semi-official overlay 기여, 업스트림 버그 제출까지 이어지며 컴퓨팅에 대해 깊이 배우게 됨
  • anton @ icosahedron.website는 Gentoo가 Handbook을 따라 할 수 있는 단계에서 컴퓨팅의 깊은 영역까지 완만한 학습 곡선을 제공하며, 매 단계가 작고 배울 기회가 된다고 봄

사용자를 존중하는 방식

  • Gentoo의 여러 지향점은 공통적으로 사용자를 존중하는 방향으로 이어짐
  • 사용자가 시스템을 어떻게 써야 하는지 과도하게 지시하지 않음
  • 지원 가능한 범위와 심각한 파손을 막기 위한 안전장치는 있지만, 최종 결정은 사용자에게 있음
  • 사용자가 지원 범위를 넘어서는 선택을 해도 그 사용 사례를 의도적으로 깨뜨리려 하지 않지만, 우발적으로 깨지지 않는다고 보장하지도 않음
  • Markus Osterhoff @ troet.cafe는 su로 사용자 ID를 바꾸면 시스템이 지시한 대로 동작하고, vim으로 설정하고 less로 로그를 읽을 수 있다는 점을 성인으로 대우받는 느낌으로 표현함
  • Ilya Shchepetkov @ social.treehouse.systems는 시스템이 사용자가 설정하지 않은 일을 하지 않는다는 통제감을 Gentoo의 장점으로 봄
  • 설치 과정은 마법이 없다는 점을 드러내며, 부팅이 갑자기 실패해도 시스템 안의 무엇이든 고칠 수 있다는 느낌을 남김
  • Gentoo는 좋은 기본값과 안정적인 경험을 제공하고, 보안을 유지하며, 사람의 작업을 존중하고 LLM에 기대지 않으려 함
  • Gentoo는 사용자의 프라이버시를 “가치 평가”의 대상으로 삼기보다 존중하려 하며, Gentoo가 어떻게 사용되는지에 대한 원격 측정도 여전히 얻지 못하고 있음
  • 패키지에서 원격 측정을 발견하면 기본적으로 제거하려 하고, 사용자가 원한다면 업스트림 기본값을 복원하는 USE 플래그를 제공하려 함
  • Gentoo 주변에 친근하고 환영하는 커뮤니티를 만들고, 사용 경험이 즐거우며 사용자를 배신하지 않는 시스템이 되기를 지향함
  • 이 내용은 “how Gentoo is perceived by people” Fediverse thread에 달린 답변들에서 크게 영감을 받았으며, 일부 답변만 인용됨

함께 보면 좋은 글 β

▲
GN⁺   [-]
Lobste.rs 의견들

  • 2019~2022년에 Gentoo를 써봤고, 장단점이 섞인 인상으로 남았음
    한편으로는 글쓴이가 말한 재미가 확실히 있었음. 설치가 클릭 몇 번으로 끝나는 앱이 아니라, 잘 쓰인 가이드를 따라 선택하고 배포판을 취향대로 맞추는 과정이라 내 시스템을 직접 얻어낸 느낌이 강했음
    필요 없는 것을 빼고 사용성을 해치지 않는 선에서 얼마나 가볍게 만들 수 있는지 보는 것도 좋았고, 커널을 직접 설정하는 것도 흥미로웠음. 다만 복구 USB나 백업이 없으면 커널 설정이 Gentoo의 가장 큰 함정이 될 수 있음
    march=native 정도 외에는 튜닝을 크게 하진 않았지만, 그래도 당시 써본 다른 배포판보다 훨씬 빠릿하게 느껴졌음. 벤치마크는 안 해서 강하게 말하긴 어렵지만, 대학 시절 쓰던 낡은 T440p를 꽤 쾌적하게 만들어줬음
    반면 시스템과 계속 싸우는 느낌도 자주 들었음. 빌드 시간이야 예상했지만, emerge 자체가 패키지를 조회하거나 복잡한 의존성을 설치할 때마다 지나치게 느리게 느껴졌고, PC가 멈춘 건지 실수한 건지 걱정될 정도였음
    USE 플래그는 문서화가 부족하거나 예상 못 한 부작용이 있어 귀찮은 디버깅을 부르곤 했음. 어떤 플래그 하나만 켜면 앱이 아예 안 돌고, 겉보기엔 독립적인 다른 플래그도 같이 켜야 하는 식이었음. 이런 기능이 기본 패키지 관리자에 통합되지 않고 웹사이트나 equery로 찾아 flaggie로 설정해야 하는 점도 이상하게 느껴졌음
    커널 설정은 시간을 들여 익혀야 하는 기술인데, 당시 찾은 가이드는 기본 이상으로는 별 도움이 안 됐음. 지금은 Gentoo에 바이너리 커널이 생겨 수동 설정을 피할 수 있지만, 당시에는 지뢰밭을 걷거나 오래 걸리는 비대한 커널을 빌드하는 선택지뿐인 느낌이었음
    qt-webkit은 느린 머신의 재앙이었음. 이 패키지 하나 때문에 매번 원래 설치·업데이트하려던 시간 위에 2~3시간 컴파일이 더 붙었음. Gentoo가 소스 우선 배포판이라는 점에서 결함은 아니지만, 최종 사용자 입장에서는 꽤 고통스러웠음
    마지막으로 Gentoo는 즉흥적으로 쓰기 좋은 시스템이 전혀 아니었음. 뭔가 필요하면 컴파일을 기다릴 시간이 있어야 했고, 큰 앱을 이것저것 바꿔가며 써보는 건 사실상 어렵게 느껴졌음. 밤새 PC를 켜둘 수 없는 경우도 많아서, 모든 처리 능력을 컴파일에 몰아 PC를 못 쓰거나, 코어 하나를 남겨두고 느려진 시스템과 더 긴 컴파일 시간을 감수해야 했음
    결국 학업용 PC에서 계속 손볼 여유가 없어 Arch로 돌아갔지만, Gentoo에 대한 존중은 많이 남았음. 배포판이 어떻게 동작할 수 있는지 완전히 다른 관점을 줬고, 내부 동작도 많이 배웠음. 글을 읽고 내 경험을 떠올리니 향수가 느껴지고, 요즘은 거친 부분도 많이 다듬어졌다고 하니 언젠가 다시 써볼 수도 있겠음
    Gentoo is Rice

    • 나도 비슷한 흐름이었는데, 노트북 RAM 한 랭크에 불량 비트가 있었고 몇 시간 뒤 제출해야 하는 작업 때문에 LaTeX를 돌리려다 Gentoo를 떠났음. 이후 Arch, 그다음 Void로 갔음
      예전에는 Raspberry Pi B에서 Funtoo도 돌렸는데, 2도 3도 4도 5도 아닌 그 모델에서 꽤 재미있었음
      첫 Gentoo 머신은 듀얼 CPU Xserve G4였고 RAM 2GB였음. 부팅되는 커널을 만들려고 계속 다시 빌드하느라 실제 시스템 부팅까지 거의 일주일이 걸렸음
      Gentoo에서 가장 멀어지게 만든 건 즉흥 사용이 어렵다는 점임. 오디오 작업을 하려고 Audacity를 설치했더니 몇 시간이 지나갔음. 컴퓨터는 일을 시키려고 쓰는 건데, 어떤 때는 유지보수 말고 그냥 쓰고 싶음
    • 나도 비슷한 시기에 Gentoo를 썼고, 경험이 꽤 비슷했음. 실제로 쓸 수 있는 커널을 컴파일하는 데 며칠이 걸렸고, 가끔 놀랍게 안 되는 기능이 나오면 결국 설정하지 않은 커널 옵션 때문이었음
      작업 중이면 흐름이 끊기고 또 컴파일을 기다려야 했음
      느린 머신에서 내 재앙은 webkit-gtk2였음. Gnucash가 그래프 표시용으로만 쓰면서도 강한 의존성으로 잡고 있었기 때문임. 오래된 ThinkPad에서 Firefox도 영원히 걸리는 느낌이었고, LibreOffice까지 컴파일 공포 3종 세트였음
    • 내 경험은 정반대였음. Gentoo를 본격적으로 쓴 지 거의 1년 됐는데, 대부분이 전부 처음부터 다시 빌드하려는 것과 달리 나는 liveusb ISO 이미지를 그냥 씀
      이 이미지는 일반 파일처럼 하드디스크에 두고 GRUB 루프백으로 그대로 부팅할 수 있고, 그 단일 ISO 안에 git, make, cc, rust, cmake, autotools 같은 개발 환경이 거의 다 들어 있음
      NixOS ISO로 라이브 부팅해서 비슷한 유틸리티 구성을 얻으려니 디스크가 거의 40~50GB 필요했음. Gentoo는 최신으로 올리는 것도 ISO 다운로드 한 번이면 되고, RAM 2GB짜리 오래된 노트북에서도 아주 빠르게 부팅돼서 만족스럽게 쓰고 있음

  • Gentoo를 좋아함. 핵심 장점 중 하나는 롤링 릴리스 배포판이라는 점임
    15년 동안 계속 돌아간 서버가 있었고 Gentoo를 썼음. 제공업체를 바꾸지 않았다면 계속 갔을 것임. 이미지를 옮기는 것보다 새로 설치하는 편이 쉬웠음
    Debian이나 Fedora에서는 같은 행운이 없었음. 특정 버전에 미리 패키징되지 않은 라이브러리나 앱 버전이 필요하면 둘 다 상당히 번거로웠고, 업그레이드 후에도 뭔가 깨져 다운타임이 눈에 띄었음

    • Gentoo가 이렇게 오래 살아남는 시스템을 가능하게 한 배포판이 됐다는 게 재미있음
      내 개인 서버는 17년 됐음. VM 제공업체 운이 좋아서 계속 높은 가동률로 운영했고, 17년 동안 전체 다운타임은 아마 하루 정도였음. 원래는 가정용 IP에서 이메일 호스팅이 현실적으로 어려워져서 만든 시스템임
      데스크톱 시스템은 2008년부터라 약 18년 됐음. 그때 64비트 사용자 공간으로 옮겼고, 이후 이미지를 다시 만들 이유나 충동이 없었음. 원래 하드웨어는 Datahand 키보드를 빼면 남은 게 없지만, 테세우스의 배처럼 조금씩 교체해온 셈임
      내게 Gentoo는 투명성, 선택, 유연성임. 컴퓨터가 어떻게 동작하길 원하는지에 대한 감각이 늘 강했는데, Gentoo는 그걸 실현하는 데 좋은 도구였음

  • 메인 개발 머신에서 Gentoo를 약 15년째 쓰고 있고, Debian unstable에서 넘어왔음
    솔직히 왜 쓰고 왜 좋아하는지 정확히 말하긴 어렵지만, 결국 그냥 잘 동작하고 바꿀 필요를 못 느낀다는 뜻 같음
    사소한 불편은 있음. ~amd64를 쓰면 새 소프트웨어를 쓸 수 있지만 libreoffice 같은 바이너리 패키지를 못 쓰고 컴파일에 시간이 좀 걸릴 수 있음
    가끔 emerge가 막혀서 손봐야 하지만, Debian sid의 apt와 크게 다르지 않은 경험임
    정말 인상적인 건 패키지 유지관리자와 커뮤니티 전반의 응답성, 기술 역량, 문제 해결 의지임. 살면서 한 번은 bugs.gentoo.org에 뭔가 제출해보길 권함

    • 나도 거의 같은 위치에 있음. 내가 원하는 Linux 배포판처럼 동작하고, 갈아탈 만큼 큰 이유가 없음
      Chimera를 써볼까 생각한 적은 있지만, 생각만 했을 뿐 아직 해보진 않았음

  • 예전에 BOINC를 돌리는 운영 서비스에 Gentoo를 썼음
    PHP, Perl, Apache 같은 패키지를 기본 Fedora 저장소에는 없는 특정 플래그로 컴파일해야 했고, 이전 시스템 관리자는 전부 손으로 컴파일한 뒤 업데이트하지 않았음. 이 상황에서는 Portage가 훨씬 더 나은 해법이었음

  • 메인 데스크톱으로 Gentoo를 14년째 쓰고 있고, 재설치 없이 당시 만든 시스템을 컴퓨터만 옮겨가며 계속 쓰고 있음. 확실히 추천할 만함. 매우 견고함
    당시 Linux 경험은 몇 달뿐이었고 Ubuntu에서 바로 넘어왔는데, 설치 과정만으로도 많은 걸 배웠음. 문서가 훌륭해서 가능했고, 손으로 만지는 접근 덕분에 수년 동안 Linux 지식이 많이 쌓였음
    컴파일된 시스템 업그레이드는 낮은 부하로 백그라운드에서 돌릴 수 있고, 바이너리 기반 시스템보다 훨씬 안정적임. 특히 단일 명령으로 맞춤 교차 컴파일 도구체인을 만드는 crossdev 같은 도구가 매력적임
    수년 동안 Gentoo가 나를 실망시킨 적은 없었음. 아직 안 써봤다면 꼭 확인해볼 만함

  • 모두 훌륭한 목표처럼 들리고, 멋진 프로젝트임. Gentoo를 안 써본 지 수십 년 됐지만, 예전에 밤새 PC가 뭔가를 컴파일하게 놔뒀다가 아침에 보니 의존성을 못 찾아 80%쯤에서 실패했던 기억이 아직도 좋게 남아 있음. 당시엔 전혀 즐겁지 않았지만 지금은 애틋함
    다시 한 번 써봐도 될 것 같음. “Gentoo aims to be fun”이라면 정말 재미있을 것 같음

    • 추억이 떠오름. 요즘은 안정 브랜치를 쓰고 있고 아직도 가끔 빌드 실패를 보지만, 예전, 아마 2006년쯤보다는 덜한 것 같음
      한편으로는 컴퓨터가 강력해져서 대부분 패키지는 금방 컴파일됨. 다른 한편으로는 여전히 컴퓨터를 죽일 수 있는 거인들, 특히 C++ 거인들이 있음

  • CI 서버에서 Gentoo를 쓰는 이유는 성능 때문이 아니라, 특정 패키지에 패치를 적용하거나 특정 플래그로 다시 빌드하는 일이 아주 쉽기 때문임. /etc/portage/packages에 넣으면 끝남

  • 아직도 Portage가 얼마나 좋았는지 그리움. 병렬 설치, 이해 가능한 오류 메시지, 사용자가 /etc/portage/의 알맞은 하위 디렉터리에 파일만 넣어 패치할 수 있는 구조, 빌드 샌드박스, 설정 가능성 등이 좋았음
    하지만 어느 순간부터는 더 이상 컴파일을 기다리고 싶지 않았음. 큰 패키지들이 바이너리 패키지로 제공되더라도 마찬가지였음

    • 참고로 요즘은 주요 프로필 기준으로 ::gentoo의 거의 모든 것에 바이너리 패키지가 있는 듯해서 꽤 좋음
      다만 USE 플래그를 바꾸기 시작하면 여전히 직접 빌드로 돌아가야 함

  • 약 20년 전 고등학생 때 처음 Gentoo를 만났음. Linux를 배우고 싶다고 선배에게 말했더니 stage1부터 Gentoo를 설치하라고 했음
    선배의 유일한 조언은 시작 전에 핸드북을 인쇄하라는 것이었음. 설치가 틀어지면 주머니 속에 브라우저가 없을 테니까
    뭘 시작하는지 전혀 몰랐음. 거의 2주 동안 사실상 집 PC가 제대로 동작하지 않았음. 매일 밤 설치와 싸우고, 다음 날 학교에 가서 학교 컴퓨터로 문서를 읽고, 선배에게 뭘 망가뜨렸는지 물어본 뒤 집에 가서 다시 시도했음
    어느 순간 이해가 됐음. 끝날 때쯤에는 chroot가 무엇인지, 커널을 엉성하게 빌드하는 법, /etc/fstab이 왜 중요한지, 머신을 부팅 불능으로 만드는 게 얼마나 쉬운지를 우연히 배웠음. 그 과정 어딘가에서 Vim도 익혔고 이후로 계속 쓰고 있음
    지금은 Gentoo를 쓰지 않지만, 그 2주에는 여전히 고마움

  • 좋은 이유가 정말 많음. 홈랩을 다시 만들고 있고, VisionFive 2(RISC-V/8GB RAM)에 Alpine Linux나 Gentoo를 올릴 계획이었음
    둘 다 지원하지만 Gentoo는 내가 OpenRC보다 선호하는 systemd를 쓸 수 있고, Gentoo를 몇 번만 써봤기 때문에 재미있을 것 같음

답변달기