- Debianの独特な慣行は、30年続く大規模な汎用オペレーティングシステムが品質、セキュリティ、自由ソフトウェアの原則を長く維持するために積み重ねてきた選択から生まれている
- 特定用途のディストリビューションではなく、ほとんどの人と目的に合う汎用ディストリビューションを目指しており、パッケージを含めるかどうかは自由ソフトウェア性と保守品質が中核的な基準である
- 憲章、社会契約、DFSGは、初期の緩やかな運営が限界を露呈したあとに生まれた仕組みで、民主的な意思決定と限定されたリーダー権限を制度化している
- 自己完結型ビルドとバンドルライブラリ回避は、外部リポジトリや重複依存関係に振り回されず、緊急のセキュリティ修正、再ビルド、新アーキテクチャ移植を可能にする保守戦略である
- メンバー審査、リリースコードネーム、遅い変更速度は、数千のパッケージと数千万台のインストール基盤を持つプロジェクトが信頼、ミラーリングコスト、合意形成コストを管理する方法である
Debianが目指すオペレーティングシステム
- Debianは高品質、セキュリティ、汎用性を備えたオペレーティングシステムを目指しており、活発に使われている大半のコンピュータで動作する自由・オープンソースソフトウェアだけで構成されることを望んでいる
- 汎用オペレーティングシステムという目標は、Debianがほとんどの人にとって、ほとんどの目的で適していなければならないという意味である
- あらゆる状況に合うわけではないが、目指す価値のある目標である
- デスクトップ、サーバー、ゲーム、科学研究のような特定目的に集中するディストリビューションとは異なる判断を生む
- パッケージ化するかどうかは、ソフトウェアの用途よりも次の基準に大きく左右される
- ソフトウェアが自由ソフトウェアであるか
- Debianが高品質なパッケージとして保守できるか
憲章とガバナンス
- Debianは、明示的に民主的なオープンソース組織に近い
- 意思決定手続きがよく定義されている
- 毎年Debian Project Leaderを選出する
- プロジェクトリーダーの権限は厳しく制限されており、通常リーダーシップと結び付けられる多くの権限が他者に明示的に委任されている
- 初期のDebian Project Leaderたちは、自ら退くまで事実上の全権を持つ独裁者に近かった
- あるプロジェクトリーダーが一線を越えたあと、反発を受けて退き、その結果として民主主義が導入された
- Debianは公式の憲章でプロジェクトの規則を定義している
- 現在のルール体系は、歴史初期により少ない規則とより少ない官僚制ではDebianでうまく機能しなかった経験に由来する
社会契約とDebian Free Software Guidelines
- 1990年代半ばは、まだ“open source”という用語が導入される前であり、“free software”はFree Software Foundationが定義していたものの、解釈の余地が大きかった
- Debianはより明確なルールを求めてDebian Free Software Guidelines(DFSG) を作り、これを社会契約の一部とした
- 社会契約は、Debianが自らと世界に対して何者であり何をするのかを約束する基盤文書である
- DFSGはその一部である
- Debian憲章は社会契約を意図的に変更しにくくしている
- より詳細なルールは、Debianが何を受け入れるのかを明確にし、関連する議論を単純化する
- DFSGは後にOpen Source Definitionの土台となった
自己完結型ビルドの原則
- Debianは自己完結型(self-contained) の原則を貫いている
- Debianがパッケージ化したものはすべて、Debian内の依存関係だけを使ってビルドされなければならない
- Debian内のすべてのものは、Debianが直接ビルドしなければならない
- この原則は多くの追加作業を生むことがある
- 現在のプログラミング言語ツール群は、ビルド時にオンラインリポジトリから依存関係を取得することを前提としている場合が多い
- Debianではそのような方式は許可されない
- 核心的な理由は、外部依存関係が後で消える可能性があるためである
- Debianはサードパーティのパッケージリポジトリを統制していない
- パッケージやリポジトリ全体が消えれば、Debianはそのパッケージを再ビルドできなくなる可能性がある
- 新しいコンパイラへの更新、セキュリティ問題の修正、新アーキテクチャへの移植、バグ修正の反映には再ビルドが必要である
- 自己完結でなければ、緊急のセキュリティ修正時に数万のパッケージとその依存関係がすべて利用可能でなければならないため、Debianはすべての依存関係をパッケージ化する道を選んでいる
バンドルライブラリを避ける理由
- Debianは、パッケージ化対象ソフトウェアに含まれるライブラリのコピーやその他の依存関係のコピーを使うことを避ける
- 多くのアップストリームプロジェクトは、依存関係をまとめて同梱したり、vendor化したりするほうが簡単だと考える
- Debianの立場では、人気ライブラリのコピーが複数生じる可能性がある
- そのライブラリにセキュリティ問題や重大な問題が起きた場合、すべてのコピーを見つけて修正しなければならない
- 緊急のセキュリティ問題では、この作業が貴重な時間を浪費することになる
- zlibの事例では、Debianはアーカイブ内にバンドルされたzlibのコピーを数十個発見し、DebianパッケージがDebianでパッケージ化されたzlibバージョンだけを使うようにするために相当な労力を費やした
- そのためDebianは、緊急事態が起きる前にパッケージ化段階で先回りして作業し、Debian内のパッケージがDebianでパッケージ化されたライブラリバージョンを使うようにしている
- アップストリーム開発者は、自分たちが検証したバンドル版だけを扱いたいことがあり、この方式は時にDebianとの摩擦を生む
メンバー審査プロセス
- Debianはオペレーティングシステムとして規模も複雑さも大きく、広く使われているため、構成員を信頼する必要がある
- 特に新しいパッケージをアップロードする人への信頼が重要である
- 1990年代のLinuxの技術的制約のため、すべてのDebianパッケージはインストール過程で完全なrootアクセス権を持っていた
- すべてのDebian開発者は、潜在的にはDebianが動作するどのマシンでもrootユーザーになり得る
- Debianが数千万台のマシンで動作していることを考えると、これは大きな権限である
- 新しい構成員は複数の方法で検証される
- 理想的には、Debian開発コミュニティに十分長く参加して他の人々に知られているべきである
- コミュニティ内で信頼を築かなければならない
- このプロセスは、Debianに参加しようとする人、とりわけ小規模なオープンソースプロジェクトに慣れている人にとって、かなりもどかしく感じられることがある
リリースコードネーム
- Debianは各メジャーリリースにコードネームを付ける
- この慣行は元々、Debianパッケージアーカイブのミラーリングコストを下げるために生まれた
- 1990年代半ばにDebian 1.0リリースを準備していたときは、コードネームを使わずバージョン名でディレクトリを作っていた
- 新リリースの開発には時間がかかるため、“1.0”ディレクトリが事前に作られた
- あるCD-ROM出版社が、Debian 1.0が完成する前に“1.0”と表示したディスクを早期に大量生産した
- その結果、Debian 1.0 CD-ROMを受け取った人々は実際の1.0ではないものを受け取ることになった
- 単純な解決策は、“1.0-not-released”のようなディレクトリで準備し、リリース完了後に“1.0”へ名前を変えることだった
- しかしディレクトリ名が変わると、すべてのミラーがリリースを再ダウンロードしなければならず、当時のDebianの規模ではコストが大きかった
- 当時の規模は「数百のパッケージ」と「数十MB」程度だった
- その後、Debianアーカイブにはpool構造が追加された
- すべてのリリースのファイルが同じディレクトリツリーにあり、メタデータファイルが各リリースに属するファイルを指定する
- この構造はミラーリングを容易にした
- 現在ではコードネームをやめてバージョンだけを使うことも可能かもしれないが、Debianが関心を持つかどうかは分からない
Debianがゆっくり変化する理由
- Debianは非常に大きなプロジェクトであり、大きなプロジェクトは変化が遅い
- 多くのパッケージに影響する変更では、何百人ものボランティアが作業しなければならないことがあり、素早く進めるのは難しい
- 一部の作業は少人数で処理でき、Debianにはそれを可能にする手順がある
- 例として、GNU C compilerの新バージョンがアップロードされた場合、他のパッケージで必要な修正を見つける作業は通常少数の人でできる
- 変化に時間がかかる理由は、合意形成が必要だからでもある
- 合意には幅広い議論が必要である
- このような議論には時間がかかり、ごくまれにしか短縮できない
- Debian開発者は技術的判断において保守的な傾向がある
1件のコメント
Hacker News のコメント
Self-contained と バンドルされたライブラリを持たないことは、エコシステムの一部が面倒すぎるとして背を向けた重要な概念だった
その結果として生じる問題を改めて経験してから、「ソフトウェアサプライチェーン」のような用語を付けたわけで、Debian は最初からこうした問題を避けるやり方をしてきたため、同じ苦痛を比較的少なく済ませている
複数のディストリビューションや OS にまたがってソフトウェアを配布するなら 依存関係のバンドルは合理的で、ディストリビューションを保守する側からすれば、セキュリティパッチを一度適用すれば済む 共有ライブラリのほうが明らかに望ましい
OS レベルでは Nix や Silverblue、アプリケーションレベルでは Snaps や Flatpak のような流れが出てきており、解決策は分からないが、Debian も近いうちに何かする必要がありそうだ
別のバージョンを使うには慎重にテストし、見つかったバグを直す必要があるが、Debian にそのリソースがあるのかは分からない。結局は 検証されていないライブラリの組み合わせを使って、うまく動くことを願う形になるが、そうはならない気がする
かなり以前から linux-firmware リポジトリ由来の公開ファームウェアはソースからビルドせず、バイナリだけを配布してきたし、アーカイブ内にも似た例はもっとあるはずだ
Debian がすべての tarball から生成済みファイルを体系的に削除して再生成しているわけでもない。特に AI/ML 周りでは、学習データすら入手できない可能性が高く、学習コストも負担しきれない
https://wiki.debian.org/EmbeddedCopies
いくつかのオープンソースソフトウェア組織は、単に少しすごいという程度ではなく、人々が協業する方法として典型的な企業モデルよりはるかに優れ得ることを示すほど驚くべき存在だ
Debian は非常に長く使ってきたが、その組織についてはよく知らず、この記事は良い入門だった
IETF もインターネットをほぼ作り上げた組織なのに、会員制度もなく、ただ動いている。このような組織があまり知られていないことに驚く
企業の世界がインターネットの動作方式を掌握しようとして IETF と競った プロトコル戦争も興味深い: https://en.wikipedia.org/wiki/Protocol_Wars
OSI が TCP のようなインターネットの一部を X.プロトコルで置き換えるというプロジェクトを毎月発表していた時代があったが、生き残って繁栄したのは X.509 くらいだった
こうした民主的な協業組織が、従来型の企業モデルより実際にはるかに優れているのか気になる
経済規模で見れば IETF や Debian の収入は企業とは比べものにならないが、貢献者や創作者の立場では「誰が利益を得るのか？」と問うことになり、貢献者たちは何とか持ちこたえている
IETF や Debian 型のモデルが企業モデルと競争できるのか試してみる価値はありそうで、プロトコル戦争では一度実際にうまくいった
IETF のワーキンググループには相互運用性のために協力しようとする企業ベンダーのエンジニアが多い一方で、ISO は伝統的なトップダウンの政府主導組織に近い
Ubuntu を 13 年ほど使ってから今年 Debian に移行し、かなり気に入っている
以前は、グローバル更新方式のパッケージングモデルは何が起きているのか把握しにくく、時々バージョン衝突も起きるため、技術的に最も堅牢な方法ではないと考えていた
しかし時間がたつにつれ、Debian の安定性とプロジェクトの善意を高く評価するようになった
時には技術的な優秀さより、プロジェクトの目的や目標のほうが重要だ
インストール後にデーモンが自動起動する方式のような技術的選択には不満があるが、パッケージとアップグレード全般の 一貫性がもたらす利点のほうが大きい
Apt も本当に優れたパッケージマネージャだ
標準状態でも高速で、システムは stable のままにしつつ Nginx だけ backports から新しいバージョンを使う、といったかなり込み入ったシナリオにも対応している
気にしている一つ二つのパッケージだけ新機能を受け取り、残りは安定して退屈なままにできるという感覚が良い
主な理由は 退屈で古いが、きちんと動く技術を使っているからで、netplan、snapd、systemd-resolver をもう見なくて済む
Sid から持ってきたり libc6 のアップグレードのような面白いことをしたりしない限り、すべて apt でインストールしているなら バージョン衝突は普通は見えないはずだ
LIW は大きな点を一つ見落としている。Debian は ボランティア組織なので、ボランティアがやりたくないことを誰も強制できない
強制されていない人々が緩やかに循環する民主主義構造を作って意思決定を行い、慎重なリソース利用から生まれる自給性が組織の核に見える
私にとってその対立は「Debian とは何か」という概念を永続的に変えたし、それが良かったのか悪かったのかは誰の話を聞くかによって変わる
こうした組織でも、他の人たちの言うとおりにしなければ、当然ながら外に出されることになる
ときどき、お金の心配をまったくしなくていいほどの大金を手にする想像をする
そのときどのオープンソースプロジェクトに寄付するかをいつも考えるのだが、Debianは常に最初の候補のいくつかに入る
あとはお金さえあればいい。もちろん、それまでの間もDebianには寄付している
そのほうがずっと面白い
Debianは素晴らしいかもしれないが、ドライバーサポートの問題があり、それを消極的にしか認めていないように見える
https://www.reddit.com/r/debian/comments/paxj85/why_debian_w...
「一部のユーザーがDebian Free Software Guidelinesに適合しないプログラムを必要としていることは認める。こうしたソフトウェアのために、FTPアーカイブにcontribとnon-freeの領域を作った。」
1〜2年前、数台のマシンでDebianを動かしていたが、WiFiのアップデートが入ったところで動かなくなり、ロールバックなどを調べた末、結局Ubuntu、実際にはKubuntuに替えたらうまく動き、問題はなかった
Debian 12では、自由ソフトウェア純粋主義者がハードウェアを使うために非自由ドライバーだけは譲歩できるよう、専用のnon-free-firmwareリポジトリまで作った
すでにインストール済みのシステムなら、non-freeリポジトリを有効にしてlinux-firmware、またはハードウェアに合ったより具体的なfirmware-*パッケージをインストールすれば解決するはず
最初のリリースのころ、PurdueでIan Murdockと一緒に働いていた
彼はシステム管理者兼開発者で、私は図書館のWebデザイナーだった
彼はGNU/Linuxのやり方と、「言論の自由としての自由」という意味での自由ソフトウェアを心から信じていた
初期の原動力はパッケージングとパッケージ管理の難しさから来ており、おそらくこれが彼の最大の貢献だろう
Network-of-Workstations、つまりNOWというP2Pインフラのような構想にも情熱を持っていたが、うまく定着はしなかった
彼が後を託したBruce Perensが、記事で言われている権威主義的なリーダーだ
私は彼のことが好きだし、Linus Torvaldsのようなオールドガード式の管理スタイルだが、ボランティアが多い大規模で複雑なプロジェクトではそのスタイルが効く
昔のLinuxとDebianの時代は本当に楽しかったし、私は他の人たちほど深くのめり込んではいなかったが、あの時代が懐かしい
最近は金の匂いがする人たちがあまりにも多く入ってきたが、まあそういうものだ
Ianのマニフェストがすべてを説明している: https://www.debian.org/doc/manuals/project-history/manifesto...
聞いたことがないし、Googleも役に立たない
退いた後、亡くなるまでの歩みはかなり不安定に見える
私よりも古い文章だ
DebianはToyotaのようなものだ
信頼できるが退屈で、しかもボランティアたちが作っている
Debianのポリシーのために、実際のバージョンではなく、かなり制限されたRetroArchのバージョンが提供されることもある
RetroArchには「Core Updater」という独自のパッケージ管理機能があり、エミュレーターをライブラリファイルの形でダウンロードしてインストールするが、Debianはこれがパッケージ管理システム全体を迂回するという理由で禁止している
ただし、Debianソースパッケージの依存関係をインストールした後に元のソースコードをビルドすれば、全機能を備えたRetroArchを自分でビルドできる
KodiとRetroArchを動かそうとして苦労して学んだが、それ以外では素晴らしいOSだ
個人的にはDebianの原則と安定性が好きで使っています
ほかのディストリビューションのユーザーや、いくつかの上流プロジェクトから、Debianがパッケージを「修正する」と不満を言っているのを聞いたことがあります
本当にそうなのか、そうだとすればきっと正当な理由があるはずなので、説明を聞きたいです
1つ目は、ソフトウェアをDebianが望む形で動作させるためのパッチです。設定は/etc/に保存し、実行中に追加ダウンロードを行わず、バンドルされたライブラリではなくシステムライブラリを使う、といったものです
2つ目は、セキュリティバックポートです
Debianはリリース時に機能を固定し、セキュリティアップデートだけを提供しますが、最近の多くのソフトウェアは、セキュリティ修正も新機能と一緒に新リリースにまとめて入れます
この2種類が合わさると、Debianの1.2と「本物の」1.2の間の差が大きくなり、バグ報告の対応が難しくなります
たとえば1.2-Debianのバグ報告を受けても、上流プロジェクトは更新されたライブラリ一式とともに「本物の」1.4だけをサポートしている、という具合です
3つ目は最近ではかなり少なくなった方法ですが、Debianがソフトウェアを改善できると判断してパッチを当てる場合です
これによって、SSHキーから乱数性が取り除かれるような問題が起きたこともあります: https://github.com/g0tmi1k/debian-ssh
1つはChromeのように、バグ修正リリースがほとんど別に存在せず、新バージョンにバグ修正が含まれる漸進的バージョン方式です
もう1つはメジャーバージョン中心の方式で、セマンティックバージョニングのようにバージョン1と2があり、バージョン2の後でもバージョン1にバグ修正だけを適用した1.1が出る、というものです
Debianは基本的に2つ目の方式でしかうまく機能しません
APIの安定性を維持するため、1つ目の方式で開発されたソフトウェアとは合いません
これを回避するために、Debianはバージョン3の「修正」をバージョン1へバックポートし、独自の1.debian-2を作ります
問題は、上流プロジェクトが一度もリリースしたことのない挙動に関するバグを受け取るようになる点です
Debianにはそうする自由がありますが、上流プロジェクトにも、Debianが押し付ける追加作業量に不満を持つ自由があります
必要であれば、その期待に合わない上流プロジェクトにパッチを当てますし、まさにそれができる点こそ自由ソフトウェアの核心です
https://www.debian.org/security/2008/dsa-1571を見れば分かります