■ 1. 概要
- Linus Torvaldsを招いたQ&Aセッションの書き起こし(場所はDebianカンファレンス)
- Linuxカーネル開発・ディストリビューション・ライセンス・セキュリティ等の幅広いテーマについて質疑応答が行われた
■ 2. Linuxディストリビューションと個人的な利用環境
- 2007年のインタビュー以降もDebianをインストールしたことはない
- ディストリビューションは「インストールが容易で作業の妨げにならないこと」が最重要との立場
- Ubuntuは試したが
make installが機能しなかったため断念した- 個人の作業環境はWebブラウザと3つのターミナルウィンドウのみという極めてシンプルな構成
- 家族のマシンを管理する必要があるため一度使い始めたディストリビューションからの変更が困難
■ 3. Linuxデスクトップの普及問題
- アプリケーションのパッケージングがLinuxデスクトップ普及の最大の障壁
- Windowsや macOS向けにはバイナリを提供できるがLinux向けは困難な状況
- 問題の本質はディストリビューションごと・バージョンごとに異なるバイナリが必要になること
- glibcをはじめとする共有ライブラリが頻繁にABIを破壊することが根本原因
- カーネルにおける「ユーザ空間を壊さない」という唯一の絶対ルールをディストリビューションが守っていないと批判
- ValveがLinuxデスクトップを救う可能性があると期待:
- 複数バイナリを作成せず静的リンクを使用するため各ディストリビューションも対応せざるを得ない
- ゲーム自体よりもこのバイナリ配布モデルの実証が重要
■ 4. アプリケーションのバイナリ配布問題
- gitやsparseのような問題と異なり本質的に複雑であり短期間での解決は困難
- 解決策として現状は静的リンクと独自ファイルシステムの同梱が現実的
- Dockerコンテナを用いたアプリケーション配布の可能性に期待
- アプリケーションに求められる要件:
- グラフィックライブラリやOpenGLなどのUI要素
- USB・シリアルポート・Bluetooth等のハードウェア直接アクセス
- Javaのような移植性重視の環境ではハードウェアアクセスが困難
■ 5. ディストリビューションに対する改善要望
- タイムゾーン設定や無線プリンタへの接続など日常操作に管理者権限が不要になること
- 一般ユーザが管理者権限なく作業できる環境を整備してほしい
- ディストリビューションのパッケージ管理者はコアパッケージに集中すべきであり小規模プロジェクトのパッケージ管理は工数の無駄
■ 6. コミュニティにおけるコミュニケーションスタイル
- 自身の攻撃的な言動を認めつつ文化的背景や個性の違いを理由に変える意思がないと表明
- 敬意は与えられるものではなく獲得するものという立場
- オープンソースでは合わない人物を避け自分に合う協力者を選べる利点がある
- 「政治的正しさ」を優先するあまり技術的品質が低下したプロジェクトの存在を懸念
■ 7. systemD
- 予想に反してsystemDを嫌いではないと表明
- 評価する点:
- Unixのinitシステムの問題を解決した
- 起動速度の向上は実質的な成果
- 批判する点:
- バグレポートが無視される事例がある
- Linuxカーネル固有技術への依存によるポータビリティの欠如
■ 8. GCCのバージョンについて
- 問題となっていたGCCの特定バグはカーネル側で修正済み
- インラインアセンブリを使用しないプロジェクトへの影響は限定的
- GCC 4.2以降のバージョンはおおむね問題なし
■ 9.
revokeシステムコールの実装
- 実装に向けた提案パッチを確認中
- CFSと共通のインフラ基盤を使用できる可能性があり設計上の利点
- 実装は確実に行われる見込みだが次バージョンへの搭載は未確定
■ 10. ドライバ開発とioctlの問題
- ioctlはバイナリ互換を破壊しやすい設計上の問題を内包
- 典型的な問題:
- 32ビットと64ビット環境でデータ型のアライメントが異なる(例:
dma_addr_t)- ioctl呼び出しのデータ構造変更によるABI破壊
- ドライバ開発者がこれらの問題を認識していないケースが多く理解できるが残念
- GPUレイヤーはかつて同様の問題で被害を受けた後改善された事例がある
■ 11. 後方互換性の維持
- 1991年当時のバイナリが現在も動作するという実績がある
- 真の互換性問題は古いバイナリではなく現代の複雑なバイナリで発生
- UI関連ライブラリのほうが低レベルコードより互換性が壊れやすい
- ライブラリのバグ修正が依存アプリケーションを壊す具体例:
- glibcが
memcpyの未定義動作への依存を修正したことでAdobe Flash Playerが動作しなくなった- カーネルでもバグ修正が結果的に互換性を破壊する事例は発生しており完全な保証はできない
- 商用環境では2年遅れでカーネルを使用するケースがあり破壊が遅れて発覚することがある
■ 12. GPL v3とライセンス
- GPL v2の理念: ソースコードを提供する代わりに変更点を還元するという対等な関係
- GPL v3を強く批判する理由:
- Tivoization条項により「ソースを渡しても自分のデバイスで使えない」状態が生じ得る
- これはGPL v2の精神に反する
- FSFがTivoization条項の無効化について不誠実な説明を行ったと批判
- 対応: Linuxカーネルを意図的に「GPL v2のみ」と明示しGPL v3への自動アップグレードを阻止
- GPL v3は別の目的のために選択するライセンスとしては有効であるという立場
- BSD/ISCライセンスは「コードを自由に使ってほしい」という目的に適している
■ 13. FSFへの評価
- FSFの一部の人物を「過激で視野が狭い」と批判
- 寄付先としてはEFFを推奨
- GPL v3をめぐるFSFの説明には不誠実な点があったと明言
■ 14. gitの発展
- gitの現在の成功はJunio Hamano(2006年頃から保守担当)の貢献によるところが大きい
- 良い技術者を見極める基準として「センス(taste)」があるとし、Junioにそれを認めた
- 分散型バージョン管理のモデルが広く受け入れられた
- GitHubがgit普及に大きく貢献した:
- ホスティングを容易にした
- オープンソースへの参入障壁を下げた
- かつて批判されたUI上の設計(リネームの扱い等)が後から正当性を認められた
■ 15. セキュリティへのアプローチ
- セキュリティコミットをコミットログに明示的に記載することに反対:
- 攻撃者が最初に読むのがコミットログであるため情報提供になりかねない
- あらゆるバグはセキュリティバグになり得るため区別に意味がない
- SELinuxへの評価:
- かつてはパフォーマンスへの悪影響が深刻だったため無効化していた
- 現在は改善されており有効化した状態で性能問題を修正した
- セキュリティは単一の層で解決できるものではなくカーネル・ユーザランド双方の多層防御が必要
- セキュリティ研究者(ブラックハット含む)の技術力を高く評価しつつも過度に白黒思考な姿勢を批判
■ 16. 世界観と現状認識
- 公の場での発言が批判的に見えるのは問題発生時にのみ発言するためであり基本的には楽観的
- かつて批判したNvidiaも現在はLinuxカーネルに積極的に貢献するようになった:
- Android市場の重要性を認識したことが態度変化の主因
- Linux全体として良い方向に進んでいると評価