なぜGentooなのか？
(blogs.gentoo.org)- 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 リーダーやメールクライアントを脆弱な Web ブラウザコンポーネントなしでビルドする構成も可能になる
-
ライブラリとビルド工程の制御
- ソースコンパイルは、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 バージョンを選ぶだけでなく、複数バージョン向けのパッケージを同時にインストールできる
- 多様な 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 に付いた返信から大きな着想を得ており、引用されているのはその一部のみである
1件のコメント
Lobste.rsの意見
2019〜2022年にGentooを使ってみたが、長所と短所が入り混じった印象が残った。
一方で、筆者が語っていた楽しさは確かにあった。インストールが数回クリックして終わるアプリではなく、よく書かれたガイドに従って選択し、ディストリビューションを自分好みに合わせていく過程なので、自分のシステムを自力で手に入れた感覚が強かった。
不要なものを削りつつ使い勝手を損なわない範囲でどこまで軽くできるかを見るのもよかったし、カーネルを自分で設定するのも興味深かった。ただし、復旧USBやバックアップがないと、カーネル設定はGentoo最大の落とし穴になり得る。
march=native程度を除けば大きなチューニングはしなかったが、それでも当時使った他のディストリビューションよりかなり軽快に感じられた。ベンチマークはしていないので強くは言えないが、大学時代に使っていた古いT440pをかなり快適にしてくれた。反面、システムとずっと格闘しているように感じることも多かった。ビルド時間は想定内だったが、
emerge自体がパッケージを検索したり複雑な依存関係をインストールしたりするたびに過度に遅く感じられ、PCが止まったのか自分が何かミスしたのか不安になるほどだった。USEフラグはドキュメントが不足していたり、予想外の副作用があったりして、面倒なデバッグを招きがちだった。あるフラグを1つ有効にしただけでアプリがまったく動かず、見た目には独立している別のフラグも一緒に有効にしなければならない、といった具合だった。こうした機能が基本のパッケージマネージャに統合されておらず、Webサイトや
equeryで調べてflaggieで設定しなければならない点も奇妙に感じられた。カーネル設定は時間をかけて習得すべき技能だが、当時見つけたガイドは基礎以上の部分ではほとんど役に立たなかった。今ではGentooにバイナリカーネルがあり手動設定を避けられるが、当時は地雷原を歩くか、時間のかかる肥大化したカーネルをビルドするかしかないように感じられた。
qt-webkitは遅いマシンにとって災厄だった。この1つのパッケージのせいで、毎回もともとインストールやアップデートにかかる時間にさらに2〜3時間のコンパイルが上乗せされた。Gentooがソース優先のディストリビューションである以上欠陥ではないが、エンドユーザーの立場ではかなりつらかった。最後に、Gentooは気軽に使うのに向いたシステムではまったくなかった。何かが必要になればコンパイルを待つ時間が必要で、大きなアプリをあれこれ切り替えて試すのは事実上難しく感じられた。PCを一晩中つけっぱなしにできないことも多かったので、すべての処理能力をコンパイルに回してPCを使えなくするか、コアを1つ空けておいて遅くなったシステムとより長いコンパイル時間を受け入れるか、という状態だった。
結局、学業用PCで手をかけ続ける余裕がなくてArchに戻ったが、Gentooへの敬意は強く残った。ディストリビューションがどう動き得るのかについてまったく異なる視点を与えてくれたし、内部動作についても多くを学べた。この記事を読んで自分の経験を思い出し、懐かしさを感じたし、最近では荒い部分もかなり磨かれたようなので、いつかまた使ってみるかもしれない。
Gentoo is Rice
昔はRaspberry Pi BでFuntooも動かしていたが、2でも3でも4でも5でもないそのモデルでなかなか面白かった。
最初のGentooマシンはデュアルCPUのXserve G4で、RAMは2GBだった。起動するカーネルを作ろうと何度もビルドし直し、実際にシステムが起動するまでほぼ1週間かかった。
Gentooから最も離れる理由になったのは、気軽に使いにくい点だった。音声作業をしようとAudacityをインストールしたら数時間が過ぎていた。コンピューターは仕事をさせるために使うものだが、ときには保守ではなくただ使いたいこともある。
作業中だと流れが切れて、またコンパイル待ちになってしまった。
遅いマシンでの自分の災厄は
webkit-gtk2だった。Gnucashがグラフ表示のためだけに使うのに、強い依存関係として引っ張っていたからだ。古いThinkPadではFirefoxも永遠にかかるように感じられ、LibreOfficeまで加わってコンパイル恐怖の三種の神器だった。このイメージは通常のファイルのようにハードディスクに置いて、GRUBのループバックでそのまま起動でき、その単一のISOの中にgit、make、cc、rust、cmake、autotoolsのような開発環境がほぼ一式入っている。
NixOSのISOでライブ起動して似たようなユーティリティ構成を得ようとすると、ディスクがほぼ40〜50GB必要だった。Gentooは最新版にするのもISOを1回ダウンロードするだけで済み、RAM 2GBの古いノートPCでも非常に高速に起動するので、満足して使っている。
Gentooが好きだ。中核的な利点の1つは、ローリングリリースのディストリビューションであることだ。
15年間動き続けたサーバーがあり、Gentooを使っていた。プロバイダーを変えなければ今でも続いていただろう。イメージを移すより新規インストールするほうが簡単だった。
DebianやFedoraでは同じ幸運はなかった。特定のバージョン向けにあらかじめパッケージ化されていないライブラリやアプリのバージョンが必要になると、どちらもかなり面倒で、アップグレード後にも何かが壊れて目立つダウンタイムが発生した。
自分の個人サーバーは17年になる。VMプロバイダー運にも恵まれて高い稼働率を維持でき、17年間の総ダウンタイムはおそらく1日ほどだ。もともとは家庭用IPからメールホスティングをするのが現実的でなくなったために作ったシステムだった。
デスクトップシステムは2008年からなので約18年になる。そのとき64ビットのユーザー空間へ移行し、その後イメージを作り直す理由も衝動もなかった。元のハードウェアはDatahandキーボード以外もう残っていないが、テセウスの船のように少しずつ置き換えてきたわけだ。
自分にとってGentooは透明性、選択、柔軟性だ。コンピューターにどう動いてほしいかという感覚は昔から強かったが、Gentooはそれを実現するのに良い道具だった。
メインの開発マシンで Gentoo をもう約15年使っていて、Debian unstable から移ってきた
正直、なぜ使っていて、なぜ気に入っているのかを正確に言うのは難しいが、結局のところ単によく動くし、変える必要を感じないということだと思う
細かな不便はある。
~amd64を使えば新しいソフトウェアを使えるが、libreoffice のようなバイナリパッケージは使えず、コンパイルに少し時間がかかることがあるときどき
emergeが詰まって手直しが必要になるが、Debian sid のaptと大きく違う体験ではない本当に印象的なのは、パッケージメンテナとコミュニティ全体の 応答性、技術力、問題解決への意欲 だ。人生で一度は bugs.gentoo.org に何か提出してみることを勧めたい
Chimera を試してみようかと思ったことはあるが、考えただけでまだやってはいない
以前、BOINC を動かす本番サービスで Gentoo を使っていた
PHP、Perl、Apache のようなパッケージを、標準の Fedora リポジトリにはない特定のフラグ付きでコンパイルする必要があり、前任のシステム管理者は全部手作業でコンパイルしたうえ更新していなかった。この状況では Portage のほうがはるかに良い解決策だった
メインデスクトップとして Gentoo を14年間使っていて、再インストールなしで、当時作ったシステムをコンピュータだけ移し替えながら使い続けている。間違いなく勧められる。非常に堅牢だ
当時の Linux 経験は数か月しかなく、Ubuntu からそのまま移ってきたが、インストール作業だけでも多くを学べた。ドキュメントが素晴らしかったからこそ可能で、手で触るアプローチのおかげで何年にもわたって Linux の知識が大いに身についた
コンパイル済みシステムのアップグレードは低負荷でバックグラウンド実行でき、バイナリベースのシステムよりずっと安定している。特に、単一コマンドでカスタム クロスコンパイルツールチェーン を作れる
crossdevのようなツールが魅力的だ何年もの間、Gentoo に失望させられたことはなかった。まだ使ったことがないなら、ぜひ確認してみる価値がある
どれも素晴らしい目標に聞こえるし、すてきなプロジェクトだ。Gentoo を使わなくなってもう何十年も経つが、昔、PC に一晩中何かをコンパイルさせておいて、朝見たら依存関係を見つけられず80%くらいで失敗していた記憶が、いまでもどこか愛おしい。当時はまったく楽しくなかったが、今では懐かしい
もう一度使ってみてもいいかもしれない。"Gentoo aims to be fun" というなら、本当に楽しい気がする
一方ではコンピュータが強力になって、ほとんどのパッケージはすぐコンパイルできる。とはいえ、いまだにマシンを殺せる巨人たち、特に 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 は数回しか使ったことがないので楽しそうだ